Agent 工具体系：从 MCP 协议到层次化工具发现
工具是连接 Agent 语言"大脑"与真实数字世界的"手脚和感官"。本章从五类工具的分类出发，系统讨论了工具设计的通用原则、能力分发渠道（MCP 协议与 Skill Hub），以及当工具数量爆炸时的层次化组织与主动发现机制，最后逐类深入分析了感知、执行、协作三类工具的设计要点。
五类工具的分类框架
书中从两个维度来审视工具：调用方向 （交互由谁发起）和作用对象（交互作用于什么），将 Agent 工具分为五类：
| 工具类型 | 调用方向 | 作用对象 |
|---|---|---|
| 感知工具 | Agent 主动调用 | 获取信息 |
| 执行工具 | Agent 主动调用 | 改变世界 |
| 协作工具 | Agent 主动调用 | 驱动其他 Agent 或人类 |
| 用户沟通工具 | Agent 主动调用 | 向用户传递信息 |
| 事件触发工具 | Agent 注册、外部触发 | 驱动 Agent 开始执行 |
前三类由 Agent 主动调用，是本章讨论的核心。事件触发工具和用户沟通工具涉及异步运行时，属于另一层面的设计。
工具设计的通用原则：ACI 与三个维度
能力的表达形式：专用工具 vs Skill
同一项能力可以做成不同形态，构成从专用 到通用的谱系：
- 专用工具：结构化函数调用，确定性高、可测试、参数受 schema 约束，代价是每个工具定义占用数百 token。
- Skill：用自然语言编写的操作文档，Agent 通过终端或代码解释器执行，只需少量通用工具即可覆盖大量场景。
书中提出的默认取向是：通用工具优于专用工具，除非存在安全、权限或性能理由。提供通用执行器（如 code_interpreter）相当于给 Agent 一个"元能力"，一个 Python 解释器可以替代数十个特定功能工具。
退回专用工具有四种情况：安全与权限审计需要、屏蔽平台差异、使用频率极高、参数结构复杂。
工具描述的艺术
工具描述的核心是让 LLM 知道"什么时候用"，而不只是"能做什么"。书中强调：清晰列出工具的边界条件------做不到什么、不接受什么输入------往往比描述能力本身更重要。参数描述应使用具体例子代替抽象规范，并为每个工具附带 1-5 个真实调用示例，加入示例后工具调用准确率可从约 72% 提升到 90%。
参数传递的保真性
一个容易被忽视的反模式是静默输入转换 ------工具在执行前悄悄"修正"模型的输入参数。书中以 Cursor 的弯引号转直引号问题为例：读取工具原样返回弯引号，替换工具却将其静默转换为直引号，导致匹配失败而模型无法自行诊断。核心原则是：模型感知到的世界与工具操作的世界之间，不能存在系统性偏差。
MCP 协议与 Skill Hub：能力分发的两条渠道
MCP：统一工具接入的开放标准
Model Context Protocol（MCP）是 Anthropic 于 2024 年底发布的开放标准，旨在统一 AI 模型与外部工具、数据源之间的通信协议。其核心设计包括：
- 标准化工具描述格式：通过 JSON Schema 定义参数类型和约束
- 传输层灵活性：本地采用 stdio，远程采用 Streamable HTTP
- 三类原语：工具（可执行操作）、资源（只读数据）、提示模板（可复用提示词）
MCP 的生态价值在于"一次开发，处处可用"。一个 MCP 服务器可以同时被 Cursor、Claude Desktop、OpenClaw 等兼容客户端使用。
Skill Hub：更轻量的分发机制
Skill 不需要协议，一个 skill 就是一个装着 SKILL.md 的文件夹，分发机制是注册表。Vercel 的 skills.sh 和 OpenClaw 的 ClawHub 是两个代表性平台。Skill 的常驻上下文成本比 MCP 工具定义便宜一到两个数量级------安装一个 skill 只是往磁盘拷一个文件夹，常驻上下文的只有目录中的 name 和 description。
第三方能力的安全风险
无论走 MCP 还是 Skill Hub，引入第三方能力都意味着把不受控制的文本注入 Agent 上下文。主要风险包括工具描述投毒（提示注入的变种）、恶意或被劫持的服务器、以及同名工具遮蔽。Skill 比 MCP 风险更大，因为它不仅包括工具描述，还包括可能运行在用户电脑上的代码。
工具规模问题：从层次化组织到主动发现
当可用工具从十几个增长到成百上千时，"选哪个工具"本身就成为一个需要设计的问题。书中给出了三层递进的解决方案。
层次化组织与按需加载
最朴素的方案是只暴露索引，需要时再查询具体定义。Cursor 的实践显示，这种方式使 MCP 工具相关任务的总 token 消耗减少了 46.9%。Pi Coding Agent 走得更远：核心模块刻意不内置 MCP，默认只看到一个约 200 token 的代理工具，通过"搜索→查看定义→调用"按需发现后端工具。
模型原生的主动工具发现
更进一步的思路是让 Agent 从被动接受者变为主动发现者：在执行过程中意识到能力缺口时，主动用自然语言声明需求，系统再动态匹配并注入。MCP-Zero 是代表性工作，论文报告在约 2800 个工具上比全量注入节省约 98% 的 token。
动态加载工具会破坏 KV Cache，但 OpenAI 的 tool_search 与 defer_loading、Anthropic 的 tool_reference 等原生支持已经解决了这个问题------把新工具的完整 schema 追加到上下文末尾，静态前缀保持稳定。
Skills：把工具发现变成"按需查阅"
Skills 机制采用渐进式披露策略，不再需要嵌入索引和语义匹配基础设施。Agent 启动时只看到一份薄薄的目录，当前上下文真正需要某种能力时，模型才去读取对应的 sub-skill。这更接近人类使用参考资料的方式------顺着索引和目录，根据当下需要逐个查阅。
三类工具的设计要点
感知工具：控制信息量
感知工具的核心挑战是返回信息量可能远超 Agent 处理能力。设计要点包括：
- 搜索类工具返回结构化候选列表而非全文，提供分页或游标
- 读取类工具支持 offset/limit 参数，截断时明确标示
- 只读性带来工程红利：结果可缓存、调用可并行
- 多模态感知有三种路径：原生多模态处理、提取为文本、工具化分析
执行工具：安全是核心
执行工具的错误代价可能极高，安全机制应构建多层防护体系：
- 输入验证：路径遍历检查、命令注入检测、快速失败
- 权限控制：文件操作限制工作目录、命令黑名单、API 配额
- 提议者-审核者机制：事前审批用不同模型家族的独立审查者，事后验证采用模态切换
- Sidecar 机制：与主模型流式输出并行的轻量级安全校验，只读结构化工具调用数据，不被提示注入操纵
协作工具：子 Agent 与人工介入
协作工具的核心是子 Agent 的生命周期原语：启动与取消（spawn_subagent、cancel_subagent）、消息传递（send_message_to_subagent）、发现（list_agents）。人工介入（HITL）需要设置超时阈值和默认行为，并形成学习循环------人类的批准、拒绝及其理由构成带证据的反馈数据。
小结
工具设计决定 Agent 的能力上限。本章的核心脉络可以概括为三个层次：第一，能力用什么形式表达------默认往通用端靠，只在安全、参数复杂度等四种情况下退回专用工具；第二，能力靠两条渠道分发------MCP 统一专用工具接入，Skill Hub 用包管理器分发 Skill 文档；第三，当工具增长到成百上千时，层次化组织、按需加载、主动发现与 Skills 依次接管，把"选哪个工具"变成"查哪条资料"。感知工具的关键在粒度与输出控制，执行工具的关键在层次化安全防护，协作工具的关键在子 Agent 生命周期与人工介入闭环。
本文内容整理自开源技术书《深入理解 AI Agent》(bojieli/ai-agent-book)，采用 Apache 2.0 许可证