4.1 工具设计模式
引言：给 Agent 合适的工具
架构设计好了，首先得给 Agent 合适的工具。
工具是 Agent 与世界交互的唯一接口。工具设计得不好，Agent 再聪明也无用武之地——就像给一个外科医生递了一把锤子。
Anthropic 的五条工具设计原则
从 Agent 的视角写描述 — 工具描述是写给 LLM 看的"API 文档"，不是写给人的。用 Agent 能理解的语言描述输入、输出和副作用。
一个工具做一件事 — 单一职责原则。一个工具既查数据库又发邮件，Agent 就很难判断何时该用哪个功能。
用枚举代替自由文本 — 参数尽量用枚举类型，减少 Agent 的决策空间。
status: "open" | "closed"远比status: string安全。把隐式约定变成显式参数 — 如果工具调用有一个"大家都默认"的行为，把它变成显式参数。避免 Agent 靠猜来使用工具。
工具间避免重叠 — 两个工具做类似的事，Agent 会在选择上犹豫甚至选错。合并或明确区分。
反模式 vs 正确做法
工具描述写给人看LLM 理解偏差从 Agent 视角重写描述
一个工具做三件事选择困难 + 副作用多拆成三个独立工具
参数全是 stringAgent 猜格式，易出错用枚举、数字类型、正则约束
隐式默认行为Agent 不知道有默认值显式参数 + 描述默认值
工具职责重叠Agent 选错工具合并或严格区分
工具返回纯文本Agent 难以解析返回结构化 JSON
没有错误码约定Agent 不知道失败原因统一错误格式 + 可操作的错误信息
MCP 协议：工具生态的统一标准
Model Context Protocol（MCP）是 Anthropic 提出的开放协议，让 AI 模型以标准方式连接外部工具和数据源。
MCP 生态增长
- 2024 年 11 月开源发布
- 6 个月内 GitHub Star 突破 50K
- 已有 5000+ 社区 Server 实现
- 主流 IDE 全部接入（VS Code、JetBrains、Cursor）
- 从 Claude 专属走向行业通用标准
MCP 的核心价值
- 标准化：一套协议对接所有工具，不需要为每个模型写适配器
- 可组合：MCP Server 可以像乐高一样组合，构建复杂工作流
- 可复用：写一次 Server，所有支持 MCP 的客户端都能用
MCP Server 设计要点
好的 MCP Server
单一职责一个 Server 解决一个领域
资源 + 工具既能读取数据，也能执行操作
完善的 Schema参数类型、约束、示例齐全
错误友好返回 Agent 可理解和可操作的错误信息
本节小结
📌 本节核心要点
- 工具描述是写给 LLM 的文档，要站在 Agent 视角设计
- 单一职责 + 枚举参数 + 显式约定 = 好工具
- MCP 是工具生态的统一标准，正在成为行业基础设施
- 工具设计不好，再好的架构也无法落地
思考题
- 你现有的 Agent 工具，描述是写给人看还是写给 LLM 看的？试试从 Agent 视角重写一个。
- 有没有两个工具在做类似的事？如果 Agent 选错了，后果是什么？
- 如果要为你的项目写一个 MCP Server，你会选择哪个领域？为什么？
下一节预告
工具设计好了，但如果 Agent 拿着工具乱来怎么办？下一节我们谈安全与护栏。