6.3 工具生态与 MCP：别重复造轮子

6.3 工具生态与 MCP：别重复造轮子

本节摘要：前面各章的工具都是项目自研的，但查询、邮件、日历、文件这类能力全行业都需要。工具生态协议（以 MCP 为代表）把"造工具"与"用工具"解耦：工具方按统一协议暴露能力，智能体运行时发现并调用。本节讲清协议的分层结构、与 Function Calling 的关系，以及接入外部工具的安全边界。

每个智能体项目启动时，几乎都要重写同一批工具：读文件、查数据库、发消息、抓网页。实现不难，难的是每家系统的接口各异、鉴权方式各异、错误处理各异——造轮子的成本不在轮子，在适配。工具生态协议（Model Context Protocol，MCP 是目前事实上的代表）的思路，是把这层适配标准化：工具方实现一次协议，所有支持协议的智能体都能用；智能体实现一次协议，所有按协议发布的工具都能接。

协议的三层结构

能力层。工具提供方把一个能力包装成 MCP 服务器：查询订单的接口、读文件的能力、检索引擎的入口，各自实现为独立的服务。每个服务器对外暴露三样东西——工具（可调用的操作）、资源（可读取的数据）、提示模板（可复用的提示片段）。

协议层。定义双方的通信契约：怎么发现对方有哪些工具（工具发现）、调用的消息格式（就是第 2 章的 JSON Schema 思路）、结果与错误怎么回传。发现机制是关键创新——智能体接入一个新服务器后，先"问一声"你有什么，动态把工具清单并入自己的契约，无需改代码。

运行层。智能体一侧的运行时（宿主）负责统一管理：连了哪些服务器、每个工具的权限边界、调用日志与审计。第 2.2 节的参数校验、观察清洗在这一层继续生效——生态只是换了工具的来源，治理逻辑一寸不让。

与 Function Calling 的关系

一句话定位：Function Calling 是"模型怎么表达调用意图"的协议，MCP 是"工具从哪来、怎么被发现"的协议——两者是上下游而非竞争。MCP 服务器把工具按标准格式暴露后，宿主把它们翻译成模型的 Function Calling 定义；模型输出调用意图，宿主路由到对应的 MCP 服务器执行。理解了这一层，"用了 MCP 还要不要 Function Calling"这类问题就不存在了。

案例：从自研工具到接入生态的改造

背景：一个内部运维智能体，自研了邮件、日历、文档检索等九个工具的适配代码，两 名维护者苦不堪言——邮件系统一升级，适配层就修。

操作：把九个能力按来源分类：邮件、日历用社区现成的 MCP 服务器替换；文档检索接公司检索团队的 MCP 化服务；剩下两个与内部系统深度耦合的保留自研，但也按 MCP 的工具定义格式包装，统一纳入宿主管辖。

结果：自研适配代码从九份减到两份；邮件系统升级那次，社区服务器一周内跟进更新，运维智能体零改动。工具发现机制还带来意外收益——接入公司新上线的会议室服务时，智能体没有改一行代码，动态并入了新工具。

解读：这次改造的判断标准值得记住：通用能力用生态，核心差异化能力自己留。邮件日历是全行业同质的，接现成；深度耦合内部系统的工具是公司的独特资产，自研且按协议包装——生态与自研不是二选一，是按能力属性分层。

变式：企业内部推行 MCP 的常见形态是建一个内部工具市场——各团队的系统能力 MCP 化后注册上架，其他团队的智能体按权限接入。工具的复用从"拷代码"升级成"接协议"，跨团队的能力共享第一次有了工程化的通道。

接入的安全边界

外部工具引入的攻击面必须正视，三道边界写在宿主的治理层：

权限最小化。每个工具声明所需的读写范围，宿主按声明授予权限——一个只读检索工具不该拥有删除权限。权限声明与校验的格式，沿用第 2.2 节参数校验的思路扩展而成。

审计全程。生态工具的每次调用都记录：谁、调了什么、参数是什么、返回了什么。第 2.3 节的轨迹机制在这里扩展一条：工具来源（自研还是哪个生态服务器）也要入轨迹。

内容隔离。生态工具返回的内容与用户指令在提示里要分层标注——工具带回的文本是"数据"不是"指令"，防止外部内容夹带指令注入（这个威胁在第 7 章安全一节正式展开）。

⚠️ 常见坑：把生态工具当可信组件直接放行。第三方工具与第三方依赖库的风险同构——来源要审、权限要限、调用要记，三条缺一，生态的便利就会变成攻击者的便车。

本节要点回顾

• 解耦造与用：MCP 把工具适配标准化，工具方实现一次、所有智能体可用；发现机制让接入零代码。
• 上下游关系：Function Calling 管模型怎么表达调用，MCP 管工具从哪来——层次分明，不是竞争。
• 分层接入：通用能力用生态，内部共享走市场，核心差异化自己留；三者统一纳入权限与轨迹治理。
• 安全三条边：权限最小化、调用全程审计、工具返回按数据而非指令对待。

知识与工具都接上了，智能体的能力拼图完整了。但"能力齐"离"敢上线"还有最后一公里：怎么证明它可靠、怎么拦住它闯祸——下一章评测与护栏。

工具描述：生态时代的"选中率"新解

2.2 节讲过工具描述决定模型选对工具的概率，接入了生态之后这件事多了一层含义：你的智能体要在别人的工具描述上做决策，别人家的智能体也在你的工具描述上做决策。企业内部建工具市场时，工具描述的质量标准值得提前统一：动词开头、写清使用时机与"不用于"、参数给格式示例、标注权限级别与数据敏感度。一份描述规范花的治理成本极低，却在每次调用里持续收回——它是工具市场里杠杆率最高的公共品。

反向的教训同样成立：接入第三方工具前，把它的描述当"广告"读——宣称的能力要在沙箱里逐项验一遍，实际参数约束、错误行为、限流策略这些"说明书没写的部分"，往往才是集成工时的真正大头。生态降低了接入的门槛，没有降低验证的责任。