工具设计与 MCP

用途：决定给 Agent 哪些工具、怎么设计接口，以及协议层（MCP）解决什么问题

为什么工具设计比提示词更关键

Agent 的能力上限常由工具决定：工具返回的信息不完整、粒度不合适或有副作用不可逆，再好的推理也无法弥补。工具是系统中确定性的部分，应该承担尽可能多的判断。

好工具的六个特征

特征	说明
意图明确	一个工具做一件事，名字与参数直接表达用途
输入严格	参数有类型、枚举与约束，非法输入早失败并给出可执行提示
输出结构化	返回可解析结果（含状态、错误码、摘要、定位信息），不返回大段自由文本
有界	限制返回体量（分页、截断、摘要 + 引用），避免撑爆上下文
幂等或标注风险	只读工具天然幂等；写工具必须带幂等键或明确不可逆提示
可观测	记录调用参数摘要、耗时、结果状态，便于归因

反模式

• 万能工具（execute_anything(action: string)）：不可验证、不可控、错误无法归因。
• 一次返回全量数据：上下文成本爆炸，实际只需要其中几行。
• 写操作无幂等：重试造成重复副作用。
• 错误信息含糊（“failed”）：Agent 无法判断该重试还是该改方案。
• 工具数量过多：选择困难与误用率上升，按任务暴露必要子集而不是全量挂载。

读写分离与权限分层

类别	示例	策略
只读	检索、读文件、查状态	可自由调用，可缓存
局部写	编辑指定文件、追加日志	限制路径与范围，越界失败
高危写	删除、迁移、发消息、部署、支付	需确认（人工或门禁）、幂等键、审计留痕

默认最小权限：Agent 只拿到完成本任务所需的最小工具集与最窄作用域（分支、目录、环境）。

MCP 解决什么

Model Context Protocol（MCP） 是模型/客户端与外部工具、数据源之间的开放协议，目标与 USB-C 类似：把“N 个模型 × M 个集成”变成标准化两端。

它规范了三类能力：

能力	含义
Tools	可被模型调用的动作（带参数 Schema）
Resources	可读取的上下文数据（文件、记录、系统数据）
Prompts	预置提示模板

工程意义：工具实现与宿主解耦、可复用、可独立测试；但也带来新的关注点——第三方 Server 的权限边界、返回内容不可信（提示注入风险）、版本与供应链安全。

安全注意

1. 工具返回内容不是指令：外部数据（网页、Issue、日志）中可能包含诱导性文本，必须与系统指令隔离处理。
2. 写操作要校验来源：只有受信任的调用链才能触发高危动作。
3. 凭据不进上下文：密钥由工具侧持有，模型只见结果不见凭据。
4. 沙箱与配额：执行类工具在隔离环境运行，限制网络、文件与资源用量。
5. 审计：所有工具调用留痕（谁、何时、参数摘要、结果状态）。

常见误区

误区	修正
用提示词弥补工具缺陷	先把可机械化的判断交给工具
工具越多越强	选择噪声与误用率上升
高危操作无确认	门禁 + 人工确认 + 幂等
相信工具返回的文本是安全的	视为不可信数据，与指令隔离
把凭据放进上下文	由工具侧持有

延伸阅读

• Model Context Protocol 官方规范与文档
• 本站：fail-closed 门禁设计、测试即门禁、编排拓扑
• 函数调用（function calling）与各推理服务工具接口的公开文档