手握 REA 的 138 个逆向工具，Agent 为什么会手写脚本绕远路？

2.1 ToolSearch 机制的搜索边界#

为了控制上下文开销，现代 Agent 运行时（如 Claude Code）普遍引入了工具延迟加载机制（Deferred Tools）：

• 核心工具（Bash、Read、Write、Edit 等）：定义常驻系统提示词，随时可用；
• Skill 技能库：以单行描述常驻系统提示词，只有显式调用时才读取具体指引；
• 外接 MCP 工具：在初次加载时被放入延迟池，上下文里只保留纯英文工具名（例如 mcp__rea__inspect_binary_layout）。

当 Agent 认为需要某项工具时，必须先通过 ToolSearch 发起查询，将该工具的完整参数 Schema 载入当前轮次，随后才能发起调用。

2.2 渐进式披露的中间层缺失#

按照标准的渐进式披露（Progressive Disclosure）模型，工具的暴露应当分为三层：

• L1（意图感知）：工具/技能的简短定位（占极少 Token）；
• L2（功能导览）：工具适用的业务场景、限制与推荐组合；
• L3（参数契约）：具体的 JSON Schema 与调用规范。

当前延迟加载的问题在于直接跳过了 L2。留在上下文里的只有 L1 的裸标识符。对于 mcp__rea__analyze_javascript_application 这种机器命名的英文长串，大语言模型在没有看到完整描述前，无法建立它与“解构桌面端前端打包产物”的语义关联。

这就导致了负向循环：无法凭空预测精确关键词 → 触发不了 ToolSearch → 误以为没有现成工具 → 退回训练权重极高的通用解法（Bash/手写脚本）。

2.3 Skill 与 MCP 的生态位分化#

在实际运行中，Skill 很少被遗漏，而 MCP 工具遗漏率极高。原因在于两者的信息表达范式不同：

• Skill 具备自然的 L2 属性：它的提示词是由人写的业务场景描述（如“逆向工程、反编译与二进制分析分诊”），天然契合 LLM 的自然语言意图匹配；
• MCP 本质是远程过程调用（RPC）：它提供的是原子化能力。如果让 100 多个 MCP 工具全量常驻，每轮对话要额外承担数万 Token 的静态开销，同时稀释模型对业务指令的注意力。

业界逐渐达成的共识是：Skill 充当控制层（神经与路由），MCP 充当驱动层（手和脚）。复杂 MCP 必须由 Skill 在前端进行意图收拢，而不是直接平铺给模型自由挑选。

2.4 训诫式规则的执行失效#

项目此前制定过针对性的开发纪律（如“先出方案，禁止直接编码”）。但这类抽象准则在面对技术执行时容易被旁路绕过。

当模型认为“写个 Python 脚本 10 秒就能跑完”时，它在逻辑上误判这是最高效的捷径，因此不会意识到自己违反了规范。依赖模型主观自觉的口头约束，无法阻断行为惯性，只有硬性的确定性路由才能形成有效约束。

第一层：核心提示词中的意图映射（强制必读）#

在核心规则文件（CLAUDE.md）中建立高频意图与工具的硬编码映射表，每轮会话常驻：

在每轮大型任务执行前，增加确定性自检：当前任务命中的意图域是否已调用指定 Skill？未调用则前置阻断。

第二层：知识库全量图谱（按需扩展）#

在项目知识库中维护全量映射表，涵盖中低频场景（如安全审计、数据导出、环境部署等）以及所有 MCP 的具体方法索引。当第一层的精简规则无法覆盖边界场景时，检索知识库进行二次对齐。

第三层：子代理规程继承（闭环防漏）#

在多代理协作（Multi-Agent）场景中，主代理派发给子代理的任务 Prompt 必须显式声明对应 Skill 的约束条件与工具链路径，避免出现“主代理以为子代理会查工具，子代理以为主指令无需扩展”的协同盲区。