MCP Code Execution解读：让Agent用代码调用工具，而不是搬运上下文

摘要

Anthropic Engineering 在《Code execution with MCP: Building more efficient agents》中讨论了一个重要工程方向：当 Agent 接入越来越多 MCP server 和工具时，不应继续把所有工具定义和中间结果都塞进模型上下文。更有效的方式，是把 MCP 工具暴露为代码 API，让 Agent 编写代码去调用工具、过滤数据、处理控制流，并只把必要摘要返回模型。

这篇文章和最近讨论的 Advanced Tool Use、Context Engineering 有明显关联，但切入点不同：它聚焦 MCP 工具如何从“模型直接逐个调用”转为“执行环境中的程序化接口”。对研发团队来说，这意味着 Agent 平台不能只设计 tool schema，还要设计代码运行时、文件系统、状态持久化、安全沙箱和可审计边界。

背景：MCP 工具越多，直接调用越低效

MCP 的价值在于把 Agent 和外部系统连接起来。开发者只要实现一次 MCP 客户端，就可以接入大量 server：文档系统、CRM、监控平台、代码仓库、表格、消息系统等。问题是，当工具数量增长到几十、几百甚至上千个时，传统直接工具调用模式会遇到两个瓶颈。

第一个瓶颈是工具定义占用上下文。很多 MCP 客户端会在任务开始前把所有工具名称、说明、参数和返回结构直接放进模型上下文。Anthropic 举例：当 Agent 连接到上千个工具时，模型在读用户请求之前就可能要处理几十万 token 的工具定义。

第二个瓶颈是中间结果反复进入上下文。比如用户要求“从 Google Drive 下载会议纪要，并附加到 Salesforce 线索记录”。直接工具调用下，模型先调用文档工具，完整纪要进入上下文；随后模型再把纪要写进 Salesforce 更新工具参数，相当于大文本在上下文中又流动一次。Anthropic 提到，两小时会议纪要可能带来额外 50,000 tokens；更大的文档甚至会直接突破上下文限制。

这说明，问题不只是成本和延迟。模型在大文本之间复制、转换、拼接时更容易犯错。Agent 平台需要避免让模型充当数据搬运工。

技术要点一：把 MCP server 映射成代码文件树

Anthropic 提出的做法，是把 MCP server 呈现为代码 API，而不是一次性塞进上下文的工具列表。一个实现方式是为所有可用工具生成文件树，例如 servers/google-drive/getDocument.ts、servers/salesforce/updateRecord.ts。每个文件对应一个工具，并包含类型接口和调用包装。

这样，Agent 可以像开发者一样探索文件系统：先列出 servers 目录，看有哪些 server；再读取特定工具文件，理解输入输出；最后写代码调用需要的工具。它只加载当前任务相关的工具定义，而不是预加载全部工具。

Anthropic 的示例显示，这种方式可将工具定义相关 token 从 150,000 降到 2,000，节省 98.7%。这个数字背后的架构意义更重要：工具发现从“系统提示词的一部分”变成“运行时文件系统导航”。

技术要点二：让执行环境处理大结果，而不是让模型读全量数据

代码执行的第二个价值，是把大结果留在执行环境里处理。比如从表格中读取 10,000 行数据，直接工具调用会把所有行送进上下文，再让模型人工筛选。代码模式下，Agent 可以写脚本读取所有行，在执行环境中 filter 出 pending 订单，只打印前 5 行和计数给模型。

这对研发系统非常实用。日志检索、表格清洗、监控指标聚合、客户列表迁移、仓库文件扫描，本质上都是数据处理任务。让模型逐行读原始数据，不如让模型生成确定性代码，由代码完成过滤、join、聚合、排序和分页。

这并不是削弱模型，而是把模型放在更合适的位置：模型负责理解意图、选择策略、生成代码、解释结果；执行环境负责高吞吐和确定性数据处理。

技术要点三：控制流应该由代码承担

传统 Agent 循环中，循环、等待、重试和分支判断通常由模型反复决定。例如等待 Slack 频道出现“deployment complete”消息，直接调用模式可能是：模型查一次消息、判断没出现、等待、再查、再判断。每一步都要经过模型。

代码模式下，Agent 可以写 while 循环，定时查询 channel history，直到找到目标消息再输出结果。这样，条件判断和等待逻辑在执行环境中完成，不需要每次都回到模型。Anthropic 指出，这不仅减少 token，也能降低 time to first token 延迟，因为普通 if/while 不必由模型逐轮“思考”。

对工程团队来说，凡是可重试、可轮询、可批处理、可幂等的流程，都应优先下沉到代码层。模型不应该成为每个小分支的调度器。

技术要点四：隐私与状态管理是额外收益

代码执行还有隐私收益。中间结果默认留在执行环境，模型只看到代码显式 log 或 return 的内容。Anthropic 举了将客户联系方式从表格导入 Salesforce 的例子：真实邮箱、电话、姓名可以从 Google Sheets 流向 Salesforce，但通过 MCP 客户端 tokenization，模型只看到 [EMAIL_1]、[PHONE_1] 这类占位符。

这对企业场景很重要。很多业务流程确实需要处理敏感数据，但并不需要模型阅读敏感数据本身。代码执行加客户端脱敏，可以把“数据流转”和“模型上下文”分离开。

另一个收益是状态持久化。Agent 可以把中间结果写入 workspace 文件，例如导出的 leads.csv，后续步骤读取继续处理。它还可以把自己写出的可复用函数保存成 skills 或工具脚本。长期来看，Agent 不只是调用现有工具，还会逐步沉淀自己的 higher-level capability。

研发视角：MCP Code Execution 是 Agent 平台分层的信号

这篇文章真正重要的启示，是 Agent 平台需要分层。

第一层是协议层，MCP 负责连接外部系统和工具。第二层是代码接口层，把 MCP 工具投影成模型可导航、可导入、可组合的文件和函数。第三层是执行环境，负责运行 Agent 生成的代码、管理依赖、限制资源、保存临时文件。第四层才是模型上下文，只接收任务需要的摘要、错误和结果。

如果没有这四层分离，系统会退化成“模型背着所有工具和数据一步步走”。这种设计在 demo 中能跑，在企业工具规模扩大后会出现成本、延迟、准确率和安全问题。

实践建议

第一，给 MCP 工具生成类型化 wrapper。不要只把 JSON schema 放进提示词。把工具映射成 TypeScript、Python 或团队主语言的函数，让 Agent 可以通过文件导航和 import 组合工具。

第二，默认限制 log。执行代码时，只有摘要、错误、计数、样例行和关键 ID 应进入模型上下文。完整数据写入文件或对象存储，由后续代码继续处理。

第三，为副作用工具分级。读取、过滤、聚合可以大胆代码化；写入 CRM、发送消息、删除文件、付款、授权等动作必须有权限边界、dry run、审批和审计日志。

第四，把敏感数据流和模型上下文分离。能在 MCP 客户端或执行环境中完成 tokenization，就不要让真实 PII 进入模型上下文。模型看到占位符也可以完成大多数流程决策。

第五，监控执行环境。代码执行需要 sandbox、资源限制、超时、依赖管理、网络 egress 控制和日志审计。它降低 token 成本，但增加运行时复杂度，不能无边界开放。

风险与限制

代码执行不是直接工具调用的完全替代。简单任务、少量工具、低风险查询，直接 tool call 更简单、透明、成本低。代码模式适合工具数量多、中间结果大、控制流复杂、需要状态持久化或隐私隔离的场景。

另一个风险是 Agent 生成的代码本身可能错误或越权。尤其在企业系统中，代码执行环境必须具备最小权限、文件系统隔离、网络限制和可回放日志。否则，效率提升会换来更大的安全面。

参考来源

• Anthropic Engineering - Code execution with MCP: Building more efficient agents: https://www.anthropic.com/engineering/code-execution-with-mcp