Anthropic：用 Code execution 补齐 MCP 短板

发表于 更新于 分类于 本文字数： 3.6k 阅读时长 ≈ 3 分钟
本文解读Anthropic关于用代码执行补齐MCP短板的技术文章。针对MCP面临的工具选择困境和上下文诅咒两大瓶颈，Anthropic提出让模型编写并执行代码来使用工具的创新方案。核心思想是将工具封装为代码API，让LLM在本地安全环境中生成业务逻辑代码完成多工具交互，大幅减少与模型的交互次数和Token消耗。

自大语言模型（LLM）问世以来，AI 领域经历了翻天覆地的变化。我们见证了模型从简单的文本生成，走向了更广阔的应用天地。为了打破 LLM 固有的局限性——比如知识截止和无法与现实世界交互——业界提出了诸多解决方案。其中，最核心的就是 “工具调用”（Tool Calling）。无论是通过联网搜索获取最新信息，还是连接企业 API 获取专有数据，工具调用都极大地扩展了 LLM 的能力边界，几乎所有主流 LLM 厂商都已将其作为标配。

随着应用场景日益复杂，我们开始面临新的挑战：工具数量的爆炸式增长。当一个 AI Agent 需要面对成百上千的工具时，问题也随之而来。工具的定义、参数、调用方式和返回结果五花八门，亟需一个统一的标准。为了解决这个 “规范” 问题，Anthropic 公司（也就是 Claude 模型的开发者）提出了模型上下文协议（MCP, Model Context Protocol），旨在统一工具的创建和使用规范。MCP 的出现，可以说为整个 AI 应用生态奠定了一块重要的基石。

MCP 之初，我思考的两个瓶颈

其实，从 MCP 协议刚发布时，我就深入研究了一番。当时我隐约感觉到，尽管 MCP 统一了规范，但它可能并非最终的解决方案。我的担忧主要有两点：

  1. 选择的困境：MCP 只是统一了标准，但当工具数量达到 100、200 甚至更多时，如何让模型从海量工具的描述和定义中，精准、高效地选择出最合适的那一个？这对模型本身的理解和推理能力构成了巨大的挑战。
  2. 上下文的诅咒：模型的上下文窗口是有限且宝贵的。大量的工具定义会挤占本就有限的上下文空间；同时，在复杂任务中，多次工具调用的中间过程和结果也会被载入上下文。这些对最终目标可能并无直接帮助的 “噪音”，不仅会稀释模型的注意力，影响后续的推理判断，还会显著增加 API 调用的成本。

当时，这些还只是我的一些思考，站在那个时间点，我并没有清晰的解决方案。后来，我也关注到业界的一些探索，比如 Shopify 曾提出的用 “即时指令”（Instant Instructions）来按需加载工具，我之前也写过一篇解读：shopify：构建生产级 agent 实践 (Building production-ready agentic systems： Lessons from Shopify Sidekick (2025) - Shopify)，这在一定程度上缓解了工具过多的问题，但上下文窗口和成本的痛点依然存在。

Anthropic 给出的新思路——代码执行

就在最近，Anthropic 官方发布了一篇名为《Code execution with MCP: Building more efficient agents》的文章，提出了一个令人眼前一亮的思路：通过代码执行（Code Execution）来解决上述问题。

我仔细阅读后，发现这个思路非常巧妙。它不再让模型直接 “调用” 工具，而是让模型 “编写并执行代码” 去使用工具。其核心思想可以概括为两点：

  1. 将工具视为代码 API：首先把每一个 MCP 工具或外部服务，都封装成一个本地代码库中的 API 函数。模型不再需要看到冗长的 JSON 定义，而是像程序员一样，通过读取函数签名和文档来理解如何使用它。
  2. 让 LLM 在本地写代码、跑代码：模型直接生成一段完整的业务逻辑代码，这段代码在本地安全环境中执行，完成与各个 API 的交互、数据处理和逻辑判断，最后只将最关键的结果返回给模型。避免了之前每次工具调用都需要和 LLM 进行交互，现在可以本地一次运行调用很多个工具。

这个方案完美地回应了我之前的两个担忧。官方发布文章还解释了其他方面的好处，下面给大家针对原文章做下解读。

解读：代码执行如何让 AI Agent 更高效？

让我们深入剖析一下 Anthropic 文章中提到的几个关键优势：

1. 上下文效率的革命性提升

传统的工具调用方式，每一步都需要与模型交互。比如 “从 Google Drive 下载会议纪要，并更新到 Salesforce 线索里”，模型需要先调用gdrive.getDocument，拿到完整的文本内容，然后将这大段文本再次放入上下文，调用salesforce.updateRecord。 一份长篇会议纪要可能会消耗数万 Token，并且在上下文中往返两次。不仅浪费资源, 还可能因为超出上下文长度限制而导致任务失败。

一个图表展示了传统 MCP 客户端的工作流程, 模型被夹在客户端和服务器之间, 所有的工具定义、调用和结果都必须通过模型本身。

这个流程清晰地显示了模型的 “大脑” 是如何成为信息传递的瓶颈的。

而通过代码执行，模型生成的可能是这样的代码：

1
2
3
4
5
6
7
8
9
10
11
12

import * as gdrive from './servers/google-drive';
import * as salesforce from './servers/salesforce';
// 从Google Drive读取纪要内容
const transcript = (await gdrive.getDocument({ documentId: 'abc123' })).content;
// 更新到Salesforce
await salesforce.updateRecord({
  objectType: 'SalesMeeting',
  recordId: '00Q5f000001abcXYZ',
  data: { Notes: transcript }
});

整个过程在本地执行环境中一气呵成，数据从 Google Drive 直接流向 Salesforce，模型完全不需要接触中间那段冗长的文本内容，极大地节省了 Token 消耗和推理时间。文章中给出的数据显示，这种方式能节省高达 98.7% 的时间和成本。

2. 按需加载与智能过滤

面对成百上千的工具，新方法允许模型像开发者一样探索文件系统。 它可以通过列出目录来发现有哪些可用的服务（如google-drive、salesforce），然后只读取它完成当前任务所必需的几个工具文件，从而实现工具定义的 “按需加载”（Progressive disclosure）。

更强大的是，数据过滤和转换也可以在代码中完成。 想象一下，当需要从一个包含 10,000 行数据的表格中找出特定订单时，模型不再需要将整个表格加载到上下文中，而是可以编写代码先在本地进行筛选和聚合，最后只把最关键的几行结果或统计数据返回给自己看。

3. 更强大的逻辑控制与隐私保护

循环、条件判断、错误处理…… 这些复杂的逻辑控制，用代码来表达远比让模型进行多轮工具调用要高效和稳定得多。

此外，由于中间数据默认停留在本地执行环境中，敏感信息（如客户的姓名、邮箱）可以不进入模型的上下文，从而天然地实现了隐私保护。 我们甚至可以在 MCP 客户端层面做一层数据脱敏，让模型看到的只是[EMAIL_1]、[PHONE_1]这样的占位符，而真实数据则在本地环境中安全流转。

4. 状态持久化与技能沉淀

通过读写本地文件，Agent 可以轻松地保存中间状态，实现任务的中断和恢复。 更令人兴奋的是，Agent 可以将一段成功解决特定问题的代码保存下来，形成一个可复用的 “技能”（Skill）。 日积月累，Agent 就能为自己打造一个强大的、定制化的能力库，不断进化，越来越高效。

未来已来：LLM 正在成为真正的 “程序员”

当然，这篇文章也坦言，代码执行并非没有门槛。它需要一个安全的沙箱执行环境来防止潜在的风险，这带来了一定的架构复杂性和安全考量。 不过，其带来的效率、成本和能力上的巨大优势，无疑是值得我们投入的。

值得注意的是，这个方案有一个重要的前提：LLM 必须具备足够强大的代码生成能力，能够稳定、准确地编写出调用 API 的代码。而近年来，随着 Cursor、Claude code、Gemini 等一系列顶尖编程 AI 的涌现，我们已经清楚地看到，LLM 编写高质量代码的能力正在飞速成熟。这恰好为代码执行这条路线铺平了道路。

Anthropic 在文章中也提到，Cloudflare 基于类似理念发布了名为 “Code Mode” 的成果。 这也印证了 “让 AI 写代码来执行任务” 正在成为业界的一个重要趋势。

从最早的 Prompt Engineering，到后来的 Tool Calling，再到今天的 Code Execution，我们正在一步步地释放 AI Agent 的潜力。我们不再满足于让模型做一个简单的 “调用者”，而是正在把它培养成一个能自主规划、编写代码、执行任务的 “智能开发者”。

这，或许就是通往更强大、更自主的通用人工智能的一条必经之路。

原文地址： https://www.anthropic.com/engineering/code-execution-with-mcp