Code Execution with MCP: Building More Efficient Agents（用 MCP 代码执行构建更高效的 Agent）

随着 Agent 通过 MCP 连接的工具越来越多，传统的直接工具调用变得低效。把 MCP server 呈现为可编程的代码 API，让 Agent 用代码与之交互，可以大幅减少 token 消耗。

两个低效问题

1. 工具定义过载

MCP 客户端把所有工具定义预先载入上下文窗口——连接数千个工具时，Agent 在读用户请求之前就要先处理「数十万 token」的文档，徒增延迟和成本。

2. 中间结果重复过境

直接工具调用要求所有结果流经模型上下文。典型例子：从 Google Drive 下载会议转录并附加到 Salesforce——完整转录文本要过境上下文两次（一次作为检索结果，一次写入更新调用）。一场 2 小时会议可能多耗 50,000 token。

解法：代码执行

把 MCP server 组织成文件系统结构：

servers/
├── google-drive/
├── salesforce/
└── ...

每个工具是一个带类型接口的 TypeScript 文件。Agent 通过探索文件系统按需发现和加载工具，编写代码直接处理数据，只把最终结果返回给模型。

效果： 文中案例 token 用量从 150,000 降到 2,000——节省 98.7%。

五大收益

1. 渐进式披露： 模型擅长导航文件系统，按需加载工具定义；辅以可配置详细级别的 search_tools（仅名称/含描述/完整 schema）
2. 上下文高效的工具结果： 在执行环境内过滤转换数据——获取 10,000 行表格时「Agent 只看到 5 行而不是 10,000 行」
3. 控制流效率： 循环、条件、错误处理都在代码环境中执行，不需要在 Agent 循环中反复推理，还降低首 token 延迟
4. 隐私保护： 中间结果默认留在执行环境；PII 可由 MCP 客户端自动 token 化，数据从来源流向目的地而不进入模型上下文
5. 状态持久化与技能： 中间结果可写文件跨会话续用；可复用的代码实现可以保存为「技能」，让 Agent 的工具箱随时间进化

注意事项

代码执行引入复杂性：需要安全的执行环境（沙箱、资源限制、监控），这些基础设施带来「直接工具调用所没有的运维开销和安全考量」。需要在 token 效率收益与实现成本之间权衡。

结论

这一方法本质上是把成熟的软件工程模式应用到 Agent 架构。MCP 是基础协议，代码执行是其上的演进中的最佳实践——作者鼓励社区分享实践发现。