Anthropic 讲解用代码执行提升 MCP 智能体的上下文效率

模型上下文协议（MCP）是一个用于将 AI 智能体连接到外部系统的开放标准。将智能体连接到工具和数据传统上需要为每一对组合进行自定义集成，这造成了碎片化和重复工作，使得真正互联的系统难以扩展。MCP 提供了一个通用协议——开发者只需在其智能体中实现一次 MCP，即可解锁整个集成生态系统。

自 2024 年 11 月推出 MCP 以来，采用速度很快：社区已构建了数千个 MCP 服务器，SDK 已覆盖所有主流编程语言，业界已将 MCP 采纳为连接智能体与工具和数据的事实标准。

如今，开发者经常构建能够访问数十个 MCP 服务器中数百或数千个工具的智能体。然而，随着连接工具数量的增长，预先加载所有工具定义并通过上下文窗口传递中间结果会拖慢智能体并增加成本。

在本博客中，我们将探讨代码执行如何使智能体更高效地与 MCP 服务器交互，在处理更多工具的同时使用更少的 token。

工具带来的过度 token 消耗会降低智能体效率

随着 MCP 使用规模的扩大，有两种常见模式会增加智能体的成本和延迟：

1. 工具定义使上下文窗口过载；
2. 中间工具结果消耗额外的 token。

1. 工具定义使上下文窗口过载

大多数 MCP 客户端会预先将所有工具定义直接加载到上下文中，使用直接工具调用语法将它们暴露给模型。这些工具定义可能如下所示：

工具描述占用更多上下文窗口空间，增加响应时间和成本。在智能体连接到数千个工具的情况下，它们在读取请求之前需要处理数十万个 token。

2. 中间工具结果消耗额外的 token

大多数 MCP 客户端允许模型直接调用 MCP 工具。例如，你可能会要求你的智能体：“从 Google Drive 下载我的会议记录并将其附加到 Salesforce 线索。”

模型将发起如下调用：

每个中间结果都必须经过模型。在此示例中，完整的调用记录会流经两次。对于一场 2 小时的销售会议，这可能意味着额外处理 50,000 个 token。更大的文档甚至可能超出上下文窗口限制，导致工作流中断。

对于大型文档或复杂数据结构，模型在工具调用之间复制数据时可能更容易出错。

使用 MCP 的代码执行可提升上下文效率

随着代码执行环境在智能体中越来越常见，一种解决方案是将 MCP 服务器呈现为代码 API，而不是直接工具调用。智能体随后可以编写代码与 MCP 服务器交互。这种方法同时解决了两个挑战：智能体可以只加载它们需要的工具，并在将结果传回模型之前在执行环境中处理数据。

有多种方法可以实现这一点。一种方法是从已连接的 MCP 服务器生成所有可用工具的文件树。以下是使用 TypeScript 的实现：

然后每个工具对应一个文件，大致如下：

我们上面的 Google Drive 到 Salesforce 示例变成了如下代码：

代理通过探索文件系统来发现工具：列出 ./servers/ 目录以查找可用的服务器（如 google-drive 和 salesforce），然后读取它所需的具体工具文件（如 getDocument.ts 和 updateRecord.ts）以了解每个工具的接口。这让代理只需加载当前任务所需的定义。这将 token 用量从 150,000 个减少到 2,000 个——节省了 98.7% 的时间和成本。

Cloudflare 发布了类似的发现，将配合 MCP 的代码执行称为“Code Mode”。核心洞见是相同的：LLM 擅长编写代码，开发者应利用这一优势来构建更高效地与 MCP 服务器交互的代理。

配合 MCP 的代码执行的优势

配合 MCP 的代码执行使代理能够更高效地利用上下文：按需加载工具、在数据到达模型之前进行过滤，并在单一步骤中执行复杂逻辑。使用这种方法还有安全和状态管理方面的好处。

渐进式披露

模型非常擅长浏览文件系统。将工具以代码形式呈现在文件系统上，使模型能够按需读取工具定义，而不是预先全部读取。

或者，可以在服务器中添加一个 search_tools 工具来查找相关定义。例如，在使用上文假设的 Salesforce 服务器时，代理搜索“salesforce”并只加载当前任务所需的那些工具。在 search_tools 工具中加入一个详细程度参数，让代理可以选择所需的详细程度（例如仅名称、名称和描述，或包含 schema 的完整定义），也有助于代理节省上下文并高效地查找工具。

上下文高效的工具结果

在处理大型数据集时，代理可以在返回结果之前在代码中过滤和转换结果。设想获取一个 10,000 行的电子表格：

代理看到的是五行而不是 10,000 行。类似的模式适用于聚合、跨多个数据源的连接或提取特定字段——所有这些都不会使上下文窗口膨胀。

更强大且上下文高效的控制流

循环、条件判断和错误处理可以用熟悉的代码模式完成，而不是串联单个工具调用。例如，如果你需要在 Slack 中发送部署通知，代理可以这样写：

这种方法比通过代理循环在 MCP 工具调用和 sleep 命令之间交替更高效。

此外，能够写出并执行条件树也节省了“首 token 时间”延迟：代理不必等待模型评估 if 语句，而是可以让代码执行环境来完成这件事。

保护隐私的操作

当代理使用配合 MCP 的代码执行时，中间结果默认保留在执行环境中。这样，代理只能看到你显式记录或返回的内容，这意味着你不希望与模型共享的数据可以在你的工作流中流转，而永远不会进入模型的上下文。

对于更敏感的工作负载，代理框架可以自动对敏感数据进行令牌化。例如，假设你需要将电子表格中的客户联系方式导入 Salesforce。代理这样写：

MCP 客户端会拦截数据，并在其到达模型之前对 PII 进行令牌化：

然后，当数据在另一次 MCP 工具调用中被共享时，它会在 MCP 客户端中通过查找进行去令牌化。真实的电子邮件地址、电话号码和姓名从 Google Sheets 流向 Salesforce，但从不经过模型。这可以防止智能体意外记录或处理敏感数据。你也可以利用这一点来定义确定性的安全规则，选择数据可以流向何处以及从何处流入。

状态持久化与技能

具有文件系统访问权限的代码执行使智能体能够在多次操作之间保持状态。智能体可以将中间结果写入文件，从而能够恢复工作并跟踪进度：

智能体还可以将自己的代码持久化为可复用的函数。一旦智能体为某项任务开发出可用的代码，它就可以保存该实现以供将来使用：

这与技能的概念密切相关——技能是可供模型使用的可复用指令、脚本和资源文件夹，用于提升模型在专门任务上的表现。向这些保存的函数中添加一个 SKILL.md 文件，就能创建一个结构化的技能，模型可以引用和使用它。随着时间的推移，这使你的智能体能够构建一个更高层能力的工具箱，不断演进其高效工作所需的脚手架。

请注意，代码执行本身也带来了复杂性。运行智能体生成的代码需要一个安全的执行环境，并配备适当的沙箱、资源限制和监控。这些基础设施要求增加了运维开销和安全考量，而直接工具调用则避免了这些问题。代码执行的好处——降低令牌成本、降低延迟以及改进工具组合——应当与这些实现成本进行权衡。

总结

MCP 为智能体连接众多工具和系统提供了一个基础协议。然而，一旦连接的服务器过多，工具定义和结果就可能消耗过多的令牌，从而降低智能体的效率。

尽管这里的许多问题看似新颖——上下文管理、工具组合、状态持久化——但它们在软件工程中已有已知的解决方案。代码执行将这些既有的模式应用于智能体，让它们使用熟悉的编程构造来更高效地与 MCP 服务器交互。如果你实施了这种方法，我们鼓励你与MCP 社区分享你的发现。