MCP 工具调用在工程上的三个老问题 过去半年把 MCP 工具调用推到生产环境的企业,几乎都会撞上同一组工程老问题。第一个问题是上下文泛滥——MCP 服务器把全部工具定义一次性加载进 Agent 的上下文窗口,包括跟当前任务无关的工具;一个中等规模的 Agent 经常要携带几百到几千个工具的描述,这些描述挤占了真正用于思考的上下文空间。第二个问题是串行调用开销——Agent 在做一件需要多个工具协
MCP 工具调用在工程上的三个老问题
过去半年把 MCP 工具调用推到生产环境的企业,几乎都会撞上同一组工程老问题。第一个问题是上下文泛滥——MCP 服务器把全部工具定义一次性加载进 Agent 的上下文窗口,包括跟当前任务无关的工具;一个中等规模的 Agent 经常要携带几百到几千个工具的描述,这些描述挤占了真正用于思考的上下文空间。第二个问题是串行调用开销——Agent 在做一件需要多个工具协作的事时,必须串行调用、每一步都把返回值写进上下文,既浪费 token 又拉长响应时间。第三个问题是模型擅长写代码胜过直接调用工具——大量内部研究表明,在工具调用密度高的场景下,让模型写一段循环代码去批量调用工具,比让模型一个个手动调用工具在 token 效率和执行时间上都明显更好。
这三个问题在过去一年多份独立工程实践中被反复确认,但解决路径并不统一。一部分实践主张"渐进式披露"——Agent 不一次性看到全部工具,而是按需检索;另一部分实践主张"用代码替代工具调用"——Agent 写代码来调用工具,而不是直接调用。每条路径都各有取舍,也各有自己的工程新样本值得借鉴。
渐进式披露的工程新样本:Keen Code 的 Skill-Driven MCP
2026 年 8 月中旬出现的一个新编码 Agent,把渐进式披露的设计推到了一个具体的工程落地形态。它的核心做法是给每个 MCP server 生成一份 skill 描述文件,描述文件本身不是 MCP 协议的官方组成部分,而是这个工具为每个 server 自动生成的一段结构化文本——包含 server 名称、用途描述、工具索引;Agent 在启动时只拿到每个 server 的 skill frontmatter,看不到完整的工具 schema;当 Agent 需要某个 server 时,它先读 skill frontmatter,再按需读特定工具的 schema 文件,最后才发起真正的工具调用。
这套设计带来的工程好处是双重的。第一,启动阶段不再把所有工具定义一股脑塞进上下文,而是只塞入每个 server 的简短描述;对于一个有 50 个 server 的中等规模 Agent,启动时塞入的描述量可能从 50 个完整 schema 降到 50 个简短 frontmatter,节省的上下文空间可以用来放更多任务相关的信息。第二,工具 schema 的更新可以即时同步——因为 Agent 是在调用前按需读 schema,server 端的 schema 改了之后,Agent 下一次启动或下一次调用就能拿到最新版本,不需要重建、build、不需要版本对齐,工具永远和 server 同步。
这套设计的工程取舍也很明确。每次 MCP 调用多了一次本地文件读操作——Agent 必须先读 skill 文件、再读 schema 文件、再发调用;这在工具调用密度低的场景下是额外的开销。但工具调用密度低的场景通常意味着 Agent 不怎么依赖 MCP,上下文压力本身就不大,渐进式披露的收益主要落在工具调用密度高的场景。
用代码替代直接调用的工程新样本:Code Mode for MCP
另一条工程路径在过去两个季度被多家团队独立探索出来——把"Agent 直接调用工具"的范式换成"Agent 写代码去调用工具"。这条路径最早由 Anthropic 在一篇工程博客里系统化提出,随后 Cloudflare 在另一篇工程博客里做了独立的实现验证,再之后被多个开源项目以不同方式落地到生产实践。
这条路径的核心思路是:不再让 Agent 一个个手动调用 MCP 工具,而是让 Agent 写一段代码,在代码里通过 SDK 调用工具。具体到 MCP 协议下,这意味着客户端只暴露两个轻量工具给 Agent——一个是"列出可用 MCP 工具",一个是"在 Python 模块环境里执行代码,代码里可以把 MCP server 当作 Python 模块来调用"。Agent 写完代码后,客户端把代码注入到一个独立的执行环境里运行,运行过程中代码对 MCP 工具的调用会被代理到真实的 MCP server。
这套设计带来的工程好处也是双重的。第一,token 效率显著提升——一次性下载文件、批量改名这类操作,在传统路径下要 N 次工具调用 + N 段上下文,在 Code Mode 下一段 for 循环代码搞定,中间结果不写回上下文。第二,模型在写代码这件事上确实比直接调用工具更稳——大量内部基准测试显示,模型写一段调用 MCP SDK 的代码,比模型手动调用 N 个工具的成功率更高、出错更少。
这套设计同样有清晰的工程取舍。Agent 写代码的能力要到位,模型必须能生成可运行的 Python 代码,而不是所有 Agent 都满足这个条件;另外,MCP 协议不强制输出 schema,意味着 Agent 在链式调用工具时必须做防御性解析,因为它没法预测输出结构。这条限制影响所有 MCP 实现,不只是 Code Mode,但在 Code Mode 下被放大了——代码里的变量类型更难推断。
两条路径的工程取舍对比
两条路径解决的是同一组问题的不同切面,但在工程落地上有明显差异。渐进式披露路径侧重"减少启动和静态加载阶段的上下文压力",对工具数量大、启动慢的场景收益大;Code Mode 路径侧重"减少运行阶段的串行调用开销",对工具调用密度高、需要批量操作的场景收益大。两套方案可以叠加——一个 Agent 既可以做渐进式披露来管理工具列表,又可以在具体任务里用 Code Mode 来执行批量操作。
在工程投入上,两条路径的门槛也不同。渐进式披露路径要求每个 MCP server 都有一份格式良好的 skill 描述文件,要么由 server 自己提供,要么由 Agent 系统自动生成;前者依赖 server 端的标准化,后者依赖 Agent 系统的元数据生成能力。Code Mode 路径要求 Agent 客户端支持代码执行沙箱,以及 MCP server 提供完整的 SDK 或等价的 SDK-like 接口;前者依赖沙箱工程,后者依赖 SDK 完整度。
在生态成熟度上,Code Mode 路径目前稍微领先——Anthropic 和 Cloudflare 已经分别在工程博客里发布了完整的设计文档和示例代码,多个开源项目已经做了生产级别的实现。渐进式披露路径相对零散,各家做法不一,目前还没有形成统一的标准化规范。
MCP 工具调用工程新基线
把上述工程实践汇总,可以画出 MCP 工具调用在 2026 年下半年的工程新基线。这条基线由四条构成。
第一条,工具列表管理必须分层。Agent 启动阶段只能看到 server 级别的简短描述,看不到完整的工具 schema;只有当 Agent 实际决定使用某个 server 的某个工具时,才按需加载 schema。这条基线是渐进式披露路径的最小落地形式,即便不做 Code Mode,只要做了这一步,Agent 的启动上下文压力就能显著下降。
第二条,工具调用必须支持批量和条件控制。Agent 在做"批量改名"、"批量重试"、"按错误码条件分支"这类操作时,不应该被迫做 N 次串行调用,必须能写循环或条件分支一次性完成。这条基线是 Code Mode 路径的核心,也是 Agent 在工具调用密度高的场景下必须具备的能力。
第三条,工具 schema 必须能即时同步。Agent 拿到的工具定义必须和 server 端当前真实定义一致,不能有版本偏差。这条基线对 server 端要求不高——任何 MCP server 都能在每次 initialize 时返回最新 schema;但对客户端要求明确——客户端不能缓存过期的 schema,必须按需获取。
第四条,工具调用必须有可审计的完整链路。每次 MCP 工具调用,无论中间经历了多少层代理、网关、沙箱,都必须留下不可篡改、可回放的审计日志。这条基线对应的是 MCP 工具调用在企业治理里的"可观测性"要求——任何一次调用,事后都能查到是哪个 Agent 发的、调的是哪个 server 的哪个工具、参数是什么、返回值是什么、走了多少层中间组件。
企业 Agent 团队的工程落地路径
把视野拉宽到企业 Agent 团队的工程落地,可以拆出三个起步动作。
第一个动作是把现有 MCP server 的元数据梳理出来。每个 server 提供了哪些工具、每个工具的 schema 是什么、哪些 server 已经提供了 skill 描述文件、哪些 server 没有——这份清单是后续所有优化的基础。没有这份清单,任何优化都是凭感觉调,改完也不知道改了什么。
第二个动作是给企业内部的 Agent 客户端加上渐进式披露。这一步不要求所有 MCP server 都提供 skill 描述文件——可以由企业内部维护一份 server 到 skill 的映射表,Agent 客户端在初始化时按这张表加载 frontmatter,在调用前按需加载 schema。这一步的工程量不大,收益大,适合作为第一个落地动作。
第三个动作是评估是否引入 Code Mode。这一步的工程量更大,需要在 Agent 客户端加代码执行沙箱、需要确认所有 MCP server 都暴露 SDK 或等价的 SDK-like 接口;但一旦落地,Agent 在批量任务上的效率会有数量级的提升。具体什么时候引入,取决于企业内部 Agent 任务的工具调用密度——调用密度高的任务占比超过一定比例,引入 Code Mode 就是值得的。
从 MCP 工具调用推到企业 Agent 工具链治理
把视野再拉宽一些,MCP 工具调用工程的演进,本质上是在解决 Agent 工具链的"上下文压力 + 调用密度 + 版本同步 + 审计可观测"四个共性问题。这四个问题在 MCP 协议下表现突出,但放到任何 Agent 工具调用场景下都成立——不管是 MCP 还是别的协议,只要 Agent 持有大量工具、需要批量调用、需要在版本上保持同步、需要治理侧审计,都会撞上同样的工程问题。
企业 Agent 治理负责人现在应当把 MCP 工具调用工程实践作为整个企业 Agent 工具链治理的样板工程。具体来说,渐进式披露、Code Mode、可观测审计这三套实践应当通用化,覆盖企业内部所有 Agent 的所有工具调用场景,而不是只针对 MCP。MCP 只是工具调用协议的一种,但协议背后的工程问题是普遍的。
更往前一步,这三套实践还能反过来影响 Agent 工具的设计规范。新设计的 Agent 工具应当默认提供 skill 描述文件、默认暴露 SDK 接口、默认支持批量调用、默认携带可审计的调用日志。这四个"默认"加在一起,就构成了下一代 Agent 工具的事实标准——任何不满足这四个默认的工具,在 Agent 工具链的演进中都会逐步被淘汰。
企业 Agent 治理负责人现在必须回答的三个问题
面对上述基线,企业 Agent 治理负责人现在至少要直接回答三个问题。第一个问题:你企业内部现在有多少 MCP server,每个 server 提供了多少工具,所有工具的完整 schema 加起来占多少 token?这个问题不回答,任何关于"上下文压力"的优化都是凭感觉调。
第二个问题:你的 Agent 客户端支不支持渐进式披露和 Code Mode?如果不支持,Agent 在批量任务上的 token 消耗和响应时间会比支持的情况下高一个数量级;如果支持,这些能力有没有真正被用起来,有没有可观测的指标说明优化效果。
第三个问题:你的 Agent 的每一次 MCP 工具调用,有没有完整的、可审计的调用日志?如果没有,事后无法区分"Agent 自主行为"和"被劫持后的行为";如果有,审计日志能不能覆盖从 Agent 客户端到 MCP server 的整条链路,包括中间所有的代理、网关、沙箱。
结语
MCP 工具调用在过去一年被显著推前,从"Agent 调用一个工具试试"演化到"Agent 调用几十个 server 协同完成复杂流水线"。每推前一步,工程侧的调用链基线就必须同步推前一步。把"Agent 直接一个个调用工具"作为主要模式的部署,在工具调用密度高、工具数量大、需要批量操作的场景下被反复证明不够。把"渐进式披露 + Code Mode + 即时同步 + 审计日志"作为基线,重新设计 Agent 的工具调用链,是当下能落地的工程基线。
任何企业 Agent 项目,只要 Agent 调用了大量工具、需要批量操作、需要治理侧审计,工程基线就必须做到这四条——工具列表管理分层、工具调用支持批量条件控制、工具 schema 即时同步、调用链全链路可审计——否则,今天不是某次工具调用事故的主角,也会是下一次事故的主角。