agent执行了没有配置的skill，这是什么原因

[yong326]

agent 中配置了 A、B skill，skills 目录里有A、B、C、D、E skill ，运行时，agent通过ls 识别到了C skill，用C skill执行了，这有办法处理吗，用提示词不一定靠谱

[WillemJiang]

这不是提示词问题，是"执行层（enforcement layer）"问题——你对提示词不靠谱的判断是对的。 根因在于：per-agent 的 skill 白名单（AgentConfig.skills）只在两个软层生效，而 skill 文件本身对沙箱是全量挂载、可读的，模型完全可以绕过白名单直接读文件。

为什么会绕过（代码事实）

1. 白名单只在两处生效，且都是软层：

• 系统提示词注入：只有「已启用 + 在白名单内」的 skill（A、B）会被写进系统提示词，模型"被告知"的只有 A、B。
• 斜杠激活拦截：SkillActivationMiddleware._resolve_activation（skill_activation_middleware.py:109-110）会对 /C 这种显式斜杠语法返回 "is not available for this agent"。

2. 但 /mnt/skills 是整目录挂载、且对所有线程/agent 完全一致：
   local_sandbox_provider.py:107-113 把整个 skills 目录（A–E 全部）以只读方式映射进沙箱（注释明说这些 static mapping "identical for every thread"）。
   而沙箱工具 bash / ls / read_file 的权限检查（sandbox/tools.py）只有路径穿越防护 + 只读约束，没有任何 skill 白名单 ACL——_resolve_skills_path 只做虚拟→宿主路径翻译，不校验该 skill 是否在当前 agent 的白名单里。

3. 于是：ls /mnt/skills 看到 C/D/E → read_file /mnt/skills/public/C/SKILL.md 拿到 C 的指令 → 在自己的回答里照着执行。这条路径完全不经过上面两个软层。斜杠拦截只认 /skill-name 文本，读文件根本不触发它。

处理办法（从强到弱）

① 文件系统级隔离（最可靠，推荐为主）
不要整目录挂载，按 available_skills 只把允许的 skill 挂进沙箱。当前 skills 的 PathMapping 是进程级/静态的（local_sandbox_provider.py:86-90 注释），需要把它改成感知当前 run 的 agent 白名单：解析出 available_skills = agent_config.skills（agent.py:383-384），只为白名单内的 skill 生成映射/卷挂载（AIO 场景同理，只 volume-mount 允许的子目录）。这样 ls /mnt/skills 物理上只看得到 A、B，模型"读不到"自然就执行不了。这是唯一移除能力而非"劝阻模型"的方案，对强模型也成立。

• 注意点：提示词里引用的 skill 容器路径要与挂载保持一致（现成的注入逻辑已经基于同一份白名单，所以天然对齐）；bootstrap agent 走 _BOOTSTRAP_SKILL_NAMES，同样机制。

② 工具级 ACL（中等强度）
在沙箱路径解析处加一道白名单校验：当 _is_skills_path(path) 为真、且从路径解析出的 skill 名不在当前 run 的 available_skills 中时，抛 PermissionError。代价小、能挡住 ls/read_file/直接 cat。前提是要把 agent 白名单透传进沙箱上下文（目前沙箱不感知白名单）。局限：bash 命令里的路径提取不完美（模型可以用 cat $(ls …)、变量、子shell 绕文本匹配），所以它不如挂载隔离彻底，属于"尽力而为"。

③ GuardrailProvider（官方扩展点，适合做纵深防御）
DeerFlow 已有可插拔的 GuardrailMiddleware + GuardrailProvider（见 backend/CLAUDE.md 中间件第 6 项）。写一个 provider，在工具调用阶段 deny 掉"目标路径落在 /mnt/skills/<非白名单 skill>"的 read_file/cat/ls 调用。它和 ② 是同一思路，但走的是正式的策略扩展点，不用改核心沙箱代码。同样受 bash 路径提取的局限。

④ 提示词硬化（最弱）
明确写"只允许使用 A、B，不得读取/遵循其他 skill 文件"。你已经判断不靠谱——确实，因为能力还在，强模型想读就读。

建议

以 ①（挂载隔离）为主控制，它是唯一对强模型也成立的硬约束；如果运维上做 per-agent 挂载较重，用 ② 或 ③ 做兜底（其中 ③ 更"正统"，走 Guardrail 扩展点）。不要指望单独靠 ④。落地最小改动点：local_sandbox_provider.py 的 skills PathMapping 改为按 available_skills 过滤，AIO provider 对应只挂允许的 skill 子目录。