「反向 Skill」模式：当工具主动喂 Agent

📄 核心概念

传统模式（Function Calling / MCP Tool Use）是 Agent 主动拉工具：Agent 决定何时调用、调用什么，每次调用都消耗 token。

反向 Skill 模式是工具主动喂 Agent：工具提前把数据准备好、精简好，直接注入 Agent 的工作区，Agent 在完整上下文中干活，无需多轮调用。

🔧 四种实现方式

1. Context Provider（上下文注入）

• 最典型例子：Claude Code 的 CLAUDE.md
• 不是让 Agent 去 read 项目结构，而是启动时自动把项目概要、代码规范、架构说明注入上下文
• Cursor 的 @codebase 也是类似思路 — IDE 主动扫描项目，不是 Agent 逐个问
• 节省了 Agent 的「侦查轮次」，直接进入决策阶段

2. Hook + Event Pipeline（事件驱动）

• Agent 不需要问「改了什么文件」，Hook 在 git diff 后自动把变更摘要、相关测试结果、错误日志喂进来
• 典型流程：代码变更 → Hook 触发 → 自动收集 diff + 测试结果 + 错误日志 → 注入 Agent 上下文
• 省掉了多轮 tool call 的隐性成本（延迟 + 累计 token）

3. MCP Resource / Prompt（协议层支持）

• MCP 规范里有 Resource 和 Prompt 两个概念，但社区一直重度依赖 Tool
• Resource = 工具注册数据源，Agent 按需订阅
• Prompt = 预定义的上下文模板，启动时自动加载
• 这两个本来就是「反向」设计，但因为 Tool 最直观，一直被冷落

4. Pre-processing Pipeline（预处理管道）

• Sub-agent 或脚本先预处理数据，精简后再喂给主 Agent
• 例如：代码搜索 → 结果去重 → 提取关键片段 → 注入主 Agent 上下文
• 比让主 Agent 自己搜、自己筛、自己读要省 token 得多

🔥 为什么现在才火

1. 长上下文窗口变大了

可以塞更多预处理数据，不怕浪费窗口。100K+ 的上下文窗口让「一次性注入大量上下文」变得可行。

2. Token 成本算过账了

多轮 tool call 的隐性成本远超一次性注入：每轮 tool call 消耗 token（工具描述 + 输入 + 输出），还有网络延迟。10 轮 tool call 的累计成本可能是一次性注入的 3-5 倍。

3. Agent 准确率瓶颈

Agent 自己决定调什么工具，经常调错或漏调。工具主动喂数据，减少了 Agent 的决策负担 — Agent 不需要决定「要不要调用」，而是直接在已有的上下文中工作。

🔄 和 MCP Tool Plugin 架构的关系

OpenClaw 的 Skill 系统其实是混合模式：

• SKILL.md 定义了编排流程 → 这是「反向」思维（预定义上下文注入）
• MCP Tool 执行具体操作 → 这是「传统」思维（Agent 拉工具）

• Skill 不只是文档，而是上下文管道 — 把 SKILL.md 变成一个能预处理数据、精简上下文的 pipeline
• 减少 Agent 的工具选择负担 — 不是列 20 个工具让 Agent 选，而是根据场景自动注入最相关的 3 个
• MCP Resource 替代部分 Tool 调用 — 只读场景走 Resource 注入，写入场景才走 Tool

🤔 引发思考

「环境即指令」的统一模式

反向 Skill 模式和 Harness Engineering 的核心理念高度一致：与其训练模型变得更聪明，不如设计更好的环境让模型更容易成功。

反向 Skill = 给 Agent 设计更好的信息环境

Harness Engineering = 给 Agent 设计更好的执行环境

两者殊途同归 — 环境设计能力才是 AI Agent 的真正竞争力。

📎 相关阅读

• MCP 规范 - Resource：https://modelcontextprotocol.io/docs/concepts/resources
• Claude Code CLAUDE.md：https://docs.anthropic.com/en/docs/claude-code/memory
• Cursor @codebase：https://docs.cursor.com/context/@-symbols/@-codebase

逍遥云初 | 2026.04.16