MCP的新特性——代码执行.

这个月，准确说是2025年11月4日， anthropic 发布了MCP的新特性——代码执行，这一特性解决了哪些问题？又有怎样条件约束呢？该特性适用于哪些应用场景呢？

如果您希望快速上手MCP，可以参考本人的《MCP极简入门》一书——

MCP 代码执行特性使LLM能够在沙箱中编写并运行 Python/JavaScript 代码，将工具能力转化为可导入的代码模块，而非依赖前端的预定义。这带来了显著的 Token 节省，工具定义和数据管道可以从数十万token降至数百。该机制支持动态数据分析、多步运算、格式转换以及无需维护函数库的隐私安全管道。其核心逻辑在于：从代码执行出发，根据实际需求动态生成代码，再将稳定流程固化为函数，从而在“灵活生成”与“稳定复用”之间保持平衡。

然而，其代价是执行延迟较高。即便简单操作也需要 5–15 秒，远超函数调用的亚秒级响应，并需额外投入沙箱基础设施，带来系统复杂性的提升。

这一机制在 Agent 系统中体现了延迟与灵活性的关键权衡。函数调用适用于高并发、预定义的生产 API，响应快且稳定，但每项新功能均需开发周期。代码执行则反向运作，由 Agent 即时编写代码响应新需求，无需开发者介入，特别适用于内部工具、原型设计与长尾任务——约 80% 的场景无需定制代码。有团队借此将“开发新功能”的周期从两周压缩至 30 秒，实现了从“提交工单”到“直接询问模型”的转变。

但MCP的代码执行并非万能。在高频 API 或关键任务流程中，传统函数在延迟、可靠性和运维简洁性上仍具优势。成功上线的系统通常策略性地结合两者，兼顾灵活与稳定。

1. MCP代码执行解决的问题

目前 LLM 仍主要扮演“协调者”角色，所有数据都流经模型，导致 Token 快速膨胀；每个决策都触发新一轮推理，加剧延迟；而基础编程结构（如循环、变量、重试）的缺失，进一步限制了执行效率。

1.1 问题 1: 工具定义膨胀

假设您正在构建一个销售运营 Agent，它需要调用来自 Google Drive（15 个工具）、Salesforce（30 个工具）、Slack（20 个工具）和 Gmail（25 个工具）的共 90 个工具接口。

在响应用户请求之前，大模型需要预先加载所有工具的定义——这个过程耗时约 3 秒，消耗约 15 万 Token，成本约 0.45 美元，而目的仅仅是让模型“知道”自己具备哪些能力。

当用户提出诸如“提取会议记录，用电子邮件发给张三”这样的请求时，实际仅需使用两个工具：gdrive.readDocument 与 gmail.sendEmail。然而在传统机制下，我们仍不得不为其余 88 个未被调用的工具承担额外开销。

1.2 问题2：冗余传输导致效率低下

当用户提出“将 Drive 上的第三季度销售记录同步到 Salesforce”这类请求时，Agent 通常需要先读取约 12,000 字（约 50,000 Token）的文本内容，再将完全相同的内容复制并提交至 Salesforce。这一过程不仅消耗约 250,000 Token、引入近 10 秒延迟，更造成了资源浪费——我们实际是在付费让 AI 执行一次简单的“复制粘贴”操作，却重复计费两次。

1.3 问题3：缺乏循环机制，推理延迟显著

以“监控 Slack 中的部署消息并发送确认邮件”为例，由于缺乏原生循环支持，Agent 必须反复查询 Slack、进行多次推理。十轮检查可能累积 20 秒以上的延迟，且每次“重新检查”都会消耗额外的 Token 与时间。

我们应当从根本上转变对 AI Agent 的认知定位：它不应是被步步指挥的“顾问”，而应是被赋予开发能力的“执行者”。

关于Agent 的开发的更多内容可以参考高强文老师的《Agent开发与应用》一书——

传统函数调用模式将 Agent 视为高成本顾问，每个步骤都需经过其思考、决策、反馈与等待，你持续为它的“注意力”付费。而新一代 Agent 架构应支持将稳定流程封装为可复用的代码模块，让 AI 能够自主编写、调试与运行脚本，仅在必要时进行干预，从而实现高效、低成本的长尾任务自动化。

2. MCP 代码执行的工作原理

MCP 代码执行将 AI Agent 视为一名熟练的开发人员：你提出任务要求，它编写脚本一次性完成所有处理。开发人员（即大语言模型）只需介入一次——理解需求并编写解决方案脚本，之后便由脚本自主处理循环、重试、数据整理与条件判断等重复性工作。

与传统做法不同——即在 Agent 明确需求前就强行载入 90 项工具手册——MCP 采用更高效的方式：将工具组织为结构化的文件系统，让 Agent 按需取用。

2.1 文件系统模式：工具即代码

可以将 MCP 工具库比作一个图书馆。过去，系统会在你提问前就将所有 90 本书的内容复印并堆在你面前；而现在，它只提供一张目录卡。你查看“Google Drive”和“Gmail”类目，走到对应书架，仅取出需要的两本书，其余 88 本仍安静地留在原位。

传统配置（全部载入 LLM 上下文）：

SYSTEM:
- gdrive.readDocument(...)
- gdrive.writeDocument(...)
- salesforce.createLead(...)
...

约 150,000 Token 用于工具定义。

MCP 文件系统结构：

./servers/
├── google-drive/
│ ├── index.ts
│ ├── readDocument.ts
│ ├── writeDocument.ts
│ └── ...
├── salesforce/
│ ├── index.ts
│ ├── createLead.ts
│ └── ...
├── slack/
│ └── ...
└── gmail/
└── ...

仅需了解文件夹名称，用数个词代替了 150,000 Token。

2.1.1 示例1：渐进式工具发现

用户请求：“从 Drive 获取会议记录并发送至 abel@company.com”

步骤 1：查看可用系统
Agent 列出服务器目录：
javascript
const availableServers = await fs.readdir('./servers');
// 返回：['google-drive', 'gmail', 'salesforce', 'slack']

Agent 判断：“我需要 Google Drive 获取文档，Gmail 发送邮件，暂不需要 Salesforce 或 Slack。”

Token 消耗：约 100（仅文件夹名称）。

步骤 2：查看 Google Drive 功能
javascript
const gdriveTools = await fs.readdir('./servers/google-drive');
// 返回：['index.ts', 'readDocument.ts', 'writeDocument.ts', ...]

Agent 判断：“我需要读取文档，因此选择 readDocument.ts。”

累计 Token 消耗：约 300。

步骤 3：理解 readDocument 的使用方式
Agent 仅载入所需工具文件：

// ./servers/google-drive/readDocument.ts
import{ callMCPTool } from "../../../client.js";

interfaceReadDocumentInput{
  documentId:string;
  fields?:string;
}

interfaceReadDocumentResponse{
  title:string;
  content:string;
  metadata:{ createdAt:string; modifiedAt:string; owner:string};
}

/**
 * 从 Google Drive 获取文档
 */
export async functionreadDocument(
  input: ReadDocumentInput
): Promise<ReadDocumentResponse>{
return callMCPTool<ReadDocumentResponse>('google_drive__read_document', input);
}

Agent 理解该工具需要 documentId，并返回标题和内容。此步骤 Token 消耗：约 200。

步骤 4：对 Gmail 执行相同操作
检查 gmail 目录，找到 sendEmail.ts，仅载入该工具定义，累计 Token 消耗：约 650。

相较于传统方式需预先载入全部 90 项工具（150,000 Token），MCP 仅需不到 1% 的 Token 成本，实现精准工具调用。

步骤 5：编写并执行解决方案

import { readDocument } from './servers/google-drive';
import { sendEmail } from './servers/gmail';

// 获取会议记录
const doc = await readDocument({ documentId: 'abc123' });

// 通过邮件发送
await sendEmail({
  to: 'abel@company.com',
  subject: `Meeting Notes: ${doc.title}`,
  body: doc.content
});

console.log(`Sent "${doc.title}" to john@company.com`);

此脚本首先导入所需工具，接着调用 Google Drive 获取文档内容，最后使用 Gmail 发送邮件。即使系统扩展至 50 个服务器、500 项工具，Agent 仍仅载入当前任务所需的 2–3 项，Token 成本保持稳定，系统能力却呈指数级提升。

2.1.2 示例 2：数据原地处理（管道模式）

用户请求：“将 12,000 字的销售记录从 Google Drive 同步至 Salesforce”

传统模式下，数据如同经过“传话游戏”，必须流经 LLM 处理：

1. Google Drive 提供 12,000 个词语的内容；

2. LLM 接收并缓存全部内容；

3. LLM 将内容重新转发至 Salesforce；

4. Salesforce 最终接收文档。

而在代码执行模式下，数据完全不经过 LLM，实现端到端直接传输：

import { readDocument } from './servers/google-drive';
import { updateOpportunity } from './servers/salesforce';

// 步骤 1：读取文档（数据保留在执行环境中）
const transcript = await readDocument({ documentId: 'abc123' });

// 步骤 2：将数据附加至 Salesforce（服务端直连）
await updateOpportunity({
  opportunityId: '006Qx000000abcd',
  fields: { Notes: transcript.content }
});

// 步骤 3：仅将摘要发送给 LLM
console.log(`Attached "${transcript.title}" (${transcript.content.length} chars) to opportunity`);

执行过程说明：

• 第 1–2 行：导入工具，建立系统间连接通道；

• 第 5 行：从 Google Drive 读取文档，数据仅保留在执行环境的私有工作区中，全程不进入 LLM 处理；

• 第 8–11 行：指令 Salesforce 直接从执行环境获取并保存内容，实现服务端数据直传；

• 第 14 行：仅将执行摘要（约 50 Token）返回 LLM，避免传输全部 50,000 Token 内容。

2.1.3 示例 3：原生编程结构（“设置即忘”模式）

用户请求：“监控 Slack 中的部署完成消息，并发送确认邮件至 team@company.com”

传统 Agent 需反复主动查询与推理，效率低下：

检查 Slack →“无结果”→ LLM 推理 →“再次检查”
...
检查 Slack →“发现目标”→ LLM 推理 →“发送邮件”

该流程通常需要 10 次推理周期、约 20 秒完成，且成本高昂。

代码执行模式下，Agent 编写自主监控脚本，实现持续检测：

import { getChannelHistory } from './servers/slack';
import { sendEmail } from './servers/gmail';

let found = false;
let attempts = 0;
const MAX_ATTEMPTS = 60; // 最长 5 分钟

while (!found && attempts < MAX_ATTEMPTS) {
  const messages = await getChannelHistory({
    channel: 'C123456',
    limit: 10
  });

  found = messages.some(m => 
    m.text.toLowerCase().includes('deployment complete')
  );

  if (!found) {
    console.log(`Attempt ${attempts + 1}: No deployment message yet`);
    await new Promise(resolve => setTimeout(resolve, 5000)); // 等待 5 秒
    attempts++;
  }
}

if (found) {
  await sendEmail({
    to: 'team@company.com',
    subject: '✅ Deployment Confirmed',
    body: 'Production deployment completed successfully.'
  });
  console.log('Confirmation email sent');
} else {
  console.log('Timeout: No deployment message after 5 minutes');
}

脚本逻辑说明：

• 第 4–6 行：设定监控边界，跟踪查找状态与尝试次数，设置 5 分钟超时保护；

• 第 8 行：启动循环，持续执行直至找到目标或达到超时；

• 第 9–13 行：获取指定 Slack 频道中最近 10 条消息；

• 第 15–17 行：检测消息中是否包含“deployment complete”（不区分大小写）；

• 第 19–23 行：若未找到目标，记录进度、等待 5 秒后再次尝试；

• 第 26–33 行：找到目标后发送确认邮件，超时则记录状态。

该脚本仅需一次生成（约 3 秒），即可自主运行。例如若在第 9 次检查时发现目标，总耗时约 45 秒。虽然总时间可能略长，但带来显著优势：

• 成本降低 96%；

• 仅需 1 个推理周期，流程更可预测；

• 轮询任务在廉价执行环境中运行，不占用推理资源；

• 潜在故障点从 10 个减少至 1 个。

真正的优势在于可预测性与可靠性。传统方法中每个推理周期都可能出错，而生成的脚本行为完全确定，严格按代码逻辑执行，杜绝随机性错误，实现稳定自动化监控。

如果您希望进一步采用MCP 来开发智能体应用，可以参考：

2.2 高级模式：隐私保护数据管道

以下是一种传统函数调用难以实现的高价值模式：让敏感数据全程不接触 LLM。

用户请求：

“将我的 Google 表格中的 847 条客户联系人导入 Salesforce，但我不希望你看到任何人的电子邮件或电话号码。”

通过代码执行，这可以轻松实现：

import{ getSheet }from'./servers/google-drive';
import{ createLead }from'./servers/salesforce';

const sheet =awaitgetSheet({ sheetId:'xyz789'});
console.log(`Found ${sheet.rows.length} rows to import`);

let successCount =0;
let errorCount =0;

for(const row of sheet.rows){
try{
awaitcreateLead({
      firstName: row.firstName,
      lastName: row.lastName,
      email: row.email,// 个人数据仅流经执行环境
      phone: row.phone,// 从不进入 LLM 上下文
      company: row.company
});
    successCount++;
}catch(error){
    console.log(`Error on row ${row.rowNumber}: ${error.message}`);
    errorCount++;
}
}

console.log(`Import complete: ${successCount} created, ${errorCount} failed`);

执行流程解析：

• 第 4 行：Agent 获取电子表格，847 行包含邮箱、电话等敏感数据仅流入隔离的执行环境

• 第 10–23 行：脚本逐行处理，在 Salesforce 中创建线索——所有个人数据直接从执行环境流向目标系统，全程不经过 LLM

• 第 25 行：LLM 仅收到最终摘要：“Import complete: 843 created, 4 failed”

可以将执行环境理解为“密封运输车”：敏感数据从源系统安全送达目标系统，LLM 作为调度员只知晓任务起止，从不接触具体内容。

隐私合规优势：
- LLM 服务商无法接触个人身份信息
- 系统日志不包含敏感数据
- 更易于满足 GDPR/CCPA 等合规要求
- 安全审计流程更加清晰

部分实施方案还加入了额外的保护层：当 Agent 意外尝试记录敏感数据时，MCP 客户端会自动拦截并执行标记化处理：

{ 
  firstName: 'John', 
  lastName: 'Smith', 
  email: '[EMAIL_0]',  // 经 MCP 客户端标记化
  phone: '[PHONE_0]',  // 真实值被替换
  company: 'Acme Corp' 
}

MCP 客户端维护私有查询表，在数据需要发送至 Salesforce 时自动还原真实值。即使 LLM 尝试查看，也始终无法获取原始信息。

这一模式为下列高风险场景开启了自动化可能：
- 人力资源数据（员工档案、薪酬信息）
- 财务记录同步（交易数据、账户信息）

- 医疗健康信息（患者记录、诊断数据）
- 任何要求“AI 不得接触个人数据”的合规场景

代码执行并非万能解决方案。对于高频 API 调用或任务关键型流程，传统函数调用在延迟控制和运维复杂度上仍具优势。实际系统中，两者应战略性地结合使用。

3. MCP 代码执行的适用场景

MCP 代码执行尤其适用于需要高度灵活性与快速迭代的场景。例如，在面对临时性数据分析请求时，传统函数调用方式往往需要经历长达两周的需求排队、功能开发与部署上线流程。而通过代码执行，分析人员只需向Agent提出需求，即可在30秒内获得一个能够自动查询、排序并返回结果的定制脚本；当分析维度需要调整时，Agent也能立即修改脚本而无需重新部署。这使得数据洞察的周期从以“周”为单位缩短至以“秒”为单位，彻底改变了内部数据分析的工作范式。

同样，在处理涉及多步操作的复杂ETL任务时，代码执行也展现出显著优势。传统方法需要将流程拆分为多个独立函数，导致数据需要多次流经LLM，不仅成本高昂，调试也极为困难。而代码执行允许Agent生成一个端到端的连贯脚本，让数据在受保护的执行环境中完成全部转换与处理，全程不接触LLM上下文。这不仅大幅降低了Token消耗，还提供了精确的错误定位和灵活的流程控制能力。

如果您希望了解MCP的更多使用场景，可以参考——

然而，代码执行并非万能解决方案，传统函数调用在特定场景下仍不可或缺。对于面向用户的高频API，例如每日被调用上万次的创建线索接口，用户期望的是亚秒级的响应速度。传统函数调用可以实现200毫秒内的稳定响应，而代码执行因包含生成、启动与执行环节，延迟通常高达数秒，难以满足用户体验要求。在支付处理等关键任务工作流中，系统的首要目标是极致的可靠性与可预测性。传统函数经过严格测试，拥有清晰的故障处理和审计链路，能提供99.99%的可用性保障；而代码执行则引入了代码生成不确定性、运行时异常等新型风险，其“灵活但脆弱”的特性在此类场景中可能带来直接的经济损失。

一个明智的技术策略在于认清这两种模式各自的优势领域。代码执行是实现敏捷性与自动化的利器，尤其适合探索性、长尾的内部任务；而传统函数调用则是构建高稳定、高性能生产系统的基石。成功的系统架构，往往来自于对二者有清晰认识的战略性组合运用。

4. 实际有效的模式：逐步正式化

在实际生产环境中，纯粹的代码执行或纯粹的函数调用都难以独立支撑复杂系统。真正有效的模式是“渐进式形式化”——以灵活的方式开始，将稳定的部分逐步固化，并根据不同需求保留两种方式的优势。

可以这样理解：代码执行如同原型设计工作室，强调快速试错与创新；而传统函数则像是标准化生产线，追求效率与可靠性。正如你不会在原型车间里批量生产iPhone，也不会用僵化的流水线去研发新功能，一个成熟的系统需要同时兼备这两种能力。

整个过程始于探索阶段。当业务团队提出一个新需求时——例如“能否生成每周销售管线健康度报告？”——你可以立即通过代码执行让Agent尝试解决。Agent会快速编写脚本，自动完成从数据查询、分组汇总到生成报告的整个流程。在30秒内，你就能验证关键数据来源、核心转换逻辑以及输出形式是否合理。这一阶段无需设计文档、排期或部署流程，核心目标是快速验证需求的价值与可行性，避免在明确价值前投入宝贵的工程资源。

当某个模式被反复验证时，便进入了正式化阶段。如果销售团队持续使用该报告，并且你观察到Agent多次生成结构相似的代码——包括查询数据、按阶段分组、汇总计算和发送邮件——这就形成了一个明确的固化信号。重复3-5次以上的相同操作强烈暗示：“将我正式化！”

此时，便可将这个稳定模式转化为一个经过充分测试的MCP函数。新的函数不仅实现了Agent探索出的核心逻辑，更具备了生产级能力：可配置的过滤条件、多种输出格式、完善的错误处理与重试机制，以及全面的可观测性支持。结果是亚秒级的响应速度、完整的测试覆盖和清晰的接口文档——它快速、可靠，并且“枯燥”，而这正是生产系统最需要的特质。

最终阶段是实现两种模式的协同共存。正式化的函数调用高效处理标准的每周报告，而代码执行则继续服务于变化与探索。当有人提出“能否按销售代表进行细分？”这类新需求时，Agent可以导入已有的稳定函数作为基础，快速扩展新维度进行分析。如果这个新变化被反复使用，则可将其进一步形式化；若仅为一次性需求，则代码执行已无需工程介入即可完成。

这一模式形成了一个完整的价值闭环：通过代码执行快速探索并确认需求价值，依据重复频率识别稳定模式，将验证过的逻辑形式化为生产级函数，并始终保持代码执行为长尾需求提供灵活支持。正如一个高效运转的餐厅厨房：招牌菜拥有标准食谱和专用工位（形式化函数），而备餐区则允许厨师自由尝试新菜品（代码执行）。

该策略的核心优势在于资源优化：通过代码执行快速验证想法，仅对经过反复使用的需求投入工程时间进行固化。这远比在未知价值的情况下进行长达数周的功能开发更为高效。让代码执行成为发现用户真实需求的探针，再为已验证的需求构建可靠的生产函数，如此才能在保持系统灵活性的同时，确保核心流程的稳健可靠。

4.小结

这种方法与过去一年中各种“新人工智能范式”的根本区别在于：MCP 代码执行的目标并非取代现有技术栈，而是构建一个能够与既有基础设施协同进化的“学习层”。传统函数如同肌肉记忆——快速、可靠、无需刻意控制；代码执行则更像解决问题的思维过程——灵活、探索性强、动态适应。两者缺一不可。

如今真正创造价值的团队，采用的既非纯代码执行，也非纯函数调用，而是构建了能够智能路由的自适应系统：将重复出现的模式固化为优化函数，将新颖的请求导向灵活的代码执行，并将成功的实验逐步转化为生产级功能。这形成了一个自我增强的良性循环：

用户提出问题，代码执行率先探索解决方案；
成功模式显现后，工程团队将其形式化为可靠函数；
随着函数库不断丰富，Agent 具备了更强大的基础能力；
用户从而提出更具挑战的新问题，代码执行继续开创新的解决路径。
如此循环往复。

在这一过程中，你的 Agent 系统将日益成熟：既积累了经过实战检验的高质量函数库，又始终保有应对未来不确定需求的灵活性与创造力。

关于生产级 AI 系统的真相是：最终胜出的并非那些架构最炫酷或模型最庞大的系统，而是那些在可靠与灵活之间找到平衡、全面监控运行状态、具备优雅降级能力，并能根据真实使用反馈持续演进优化的系统。

MCP 代码执行正是实现这种平衡的战略工具——它不是包治百病的万能方案，而是一个精准解决特定类别问题的高效路径。当被用于正确的场景时，它能够出色地完成使命。

【参考资料与关联阅读】

• Anthropic: Code execution with MCP，https://www.anthropic.com/engineering/code-execution-with-mcp

• Model Context Protocol docs，https://modelcontextprotocol.io/

• Cloudflare: Code Mode，https://blog.cloudflare.com/code-mode/

• Claude Code Sandboxing，https://www.anthropic.com/engineering/claude-code-sandboxing

• E2B Documentation，https://e2b.dev/docs

•  什么可能会定义人工智能的下一个十年？

•  拆解OpenAI最大对手的杀手锏：为什么会是MCP？

• 大模型应用系列：两万字解读MCP

• MCP规范完整中译稿：2025-3-26版

• 全网首发：MCP 的10种架构模式

• MCP来了，让我们用它来自动化测试吧

• 让你的服务变成MCP Server？FastAPI MCP 指南 

• 在大模型应用中使用长短记忆： OpenMemory MCP

• 开发MCP服务，何时使用工具？何时使用资源？

• 当Semantic Kernel 遇上MCP......

• Pydantic AI与MCP相逢

• 万字解读：8种常见框架，选择哪一种来开发MCP呢？

• 采用LangGraph集成多个MCP服务器的应用

• 当RAG遇上MCP...

• 全网首发：安全性问题，使MCP成为AI应用的双刃剑，如何化险为夷呢？

• 智能体间协作的"巴别塔困境"如何破解？解读Agent通信4大协议：MCP/ACP/A2A/ANP