直到前几天Anthropic发了一篇技术博客,我才恍然大悟——问题根本不仅仅是模型贵不贵,而是整个工具调用的架构就有问题。 就像你家水费贵不是因为水价高,而是因为水管一直在漏水。
Anthropic这次提出的代码执行方案,怎么说呢,不是小修小补,是从底层架构上重新设计了AI Agent的工作方式。根据官方测试,处理同一个CSV文件,Token消耗从756,539直接降到8,369——降了98.9%!
这篇文章我就用最接地气的方式,把这个方案拆开了讲清楚。看完你就明白,为什么说这才是真正解决Token消耗的"道",而不是之前那些"术"。
一、问题的本质:AI Agent的"记忆负担"
1.1 Token到底是个啥?为什么它是个大问题?
在讲解决方案之前,咱们先把Token这个东西说清楚。很多人用Claude Code,根本不知道背后的Token消耗有多恐怖。
生活化比喻:
- AI每次处理的Token数量也有上限(Claude的上下文窗口是200K个Token)
为什么Token消耗是个大问题?
对于订阅用户(Pro/Max/Team):
对于API用户:
共同的问题:
- Token过多会超出AI的"记忆容量"(Claude上下文窗口200K)
Token与实际内容的对应:
- 100,000 Token ≈ 75,000个英文单词 ≈ 200页A4纸
1.2 Claude Code的Token交换机制——问题藏在这里
真的,大多数人用Claude Code的时候根本意识不到背后在发生什么。我来给你详细拆解一下:
当你输入一个提示词,Claude Code CLI实际在做什么:
看到没有?最坑的地方不是数据本身,而是每次请求都要重复发送那4万Token的工具定义!
关键问题:Token消耗的"雪球效应"
第1轮对话:43k输入 + 0.2k输出 = 43.2k
第2轮对话:186k输入 + 2k输出 = 188k(包含第1轮历史)
第3轮对话:374k输入 + 1k输出 = 375k(包含前2轮历史)
第4轮对话:可能超过上下文限制!
实际Token消耗公式:
每次请求Token = 系统提示词(3k) + 工具定义(40k) + 累积历史 + 新内容
例如第5轮对话:
= 3,000 + 40,000 + 200,000(前4轮累积) + 新内容
= 243,000 Token起步!
1.3 传统AI Agent面临的四大困境
让我用生活化的例子来说明传统AI Agent的问题:
场景假设: 你要让AI助手帮你完成一个任务——"从Google Drive下载一份会议记录,然后上传到Salesforce"
困境1: 工具定义占用大量空间(就像背字典)
传统做法:AI需要先把所有可能用到的工具说明书全部记在脑子里,即使这次用不到。而且每次API请求都要重新发送一遍所有工具定义!
类比: 你要查一个词,却被要求先把整本字典背下来,
而且每次查新词都要重新背一遍!
具体表现:
- Google Drive工具说明: 2000个Token
- Salesforce工具说明: 3000个Token
- 每次请求都要发送: 50,000 × N次请求 = 巨大浪费!
而实际上,这个任务只需要用到Google Drive和Salesforce两个工具!
困境2: 中间结果反复传递 + 历史对话累积(双重负担)
传统方式的痛点:
新方式的巧妙之处:
三、为什么能省这么多Token？三大核心机制
好了，前面讲了问题在哪儿，现在讲讲Anthropic这个方案到底是怎么省Token的。
3.1 机制一：按需加载工具定义
传统方式的浪费：
你想想，Claude Code连接了50个MCP工具，每次请求都要：
- 把50个工具的说明书全部塞进上下文（可能5万Token）
第1次请求：系统提示(3k) + 50个工具(50k) + 问题(0.1k) = 53k
第2次请求：系统提示(3k) + 50个工具(50k) + 历史(53k) + 数据(10k) = 116k
第3次请求：系统提示(3k) + 50个工具(50k) + 历史(116k) + 新问题 = 169k
总计：338k Token，而且大部分是重复的工具定义！
代码执行方式的巧妙：
把工具变成磁盘上的文件：
./servers/
└── google-drive/
├── getDocument.ts // 这个文件占0 Token！
├── uploadFile.ts // 在磁盘上，不在AI上下文里
└── listFiles.ts
AI需要用哪个工具，就读那个文件。不需要的根本不碰。
类比理解：
- 传统方式：去图书馆前，把所有书的目录都背下来（每次去都要背一遍）
关键：不是省50k Token，而是省了50k × N次请求！
3.2 机制二：数据在沙箱里流动（最核心）
这是整个方案最精妙的地方！
生活化类比：
你是公司老板（AI），要把一批货物（10,000行CSV数据）从仓库A运到仓库B。
传统方式：
- 你要亲自查看每一件货物（10,000行数据进入AI上下文）
- 告诉司机怎么运（又传一遍，再消耗10,000 Token）
新方式：
代码示例对比：
// 传统方式：数据必须经过AI上下文
// 步骤1：AI调用工具获取数据
result1 = callTool("googleDrive.getDocument", { id: "abc123" })
// ⚠️ result1的10,000 Token内容进入AI上下文
// 步骤2：AI看到数据，分析处理
// （AI需要在上下文中处理这10,000 Token）
// 步骤3：AI调用工具上传
callTool("salesforce.updateRecord", { data: result1 })
// ⚠️ 又把10,000 Token传一遍
// AI上下文负担：10,000 × 2 = 20,000 Token
// ===== 新方式：数据不进AI上下文 =====
// AI只写一段代码（500 Token）：
import { googleDrive } from'./servers/google-drive';
import { salesforce } from'./servers/salesforce';
// 在沙箱中执行，数据不进AI上下文：
const doc = await googleDrive.getDocument({ id: "abc123" });
// ✅ doc的10,000 Token只在沙箱中
await salesforce.updateRecord({ data: doc.content });
// ✅ 数据直接从沙箱传到Salesforce
// AI上下文负担：只有代码的500 Token！
关键洞察：
- 10,000行CSV数据从Google Drive流向Salesforce
3.3 机制三：复杂逻辑在代码里处理
场景： 筛选所有金额超过100万的客户（2000个客户数据）
传统方式需要：
对每个客户：
1. AI调用工具查询客户信息（往返1次）
2. AI判断金额是否>100万（在上下文中思考）
3. 如果符合，加入结果列表
2000个客户 × 往返1次 = 2000次API调用
每次都要重复发送工具定义和历史对话
Token消耗：几十万甚至上百万
代码执行方式：
// AI写一段代码（300 Token）
const customers = await crm.getAllCustomers();
// 2000个客户数据只在沙箱中，不进AI上下文
// 在沙箱中用代码筛选（一行代码，瞬间完成）
const highValue = customers.filter(c => c.amount > 1000000);
return {
count: highValue.length,
topCustomer: highValue[0].name
};
// 只返回简单结果（100 Token）
总计：300 + 100 = 400 Token
节省：99.6%！
为什么快这么多？
- 循环、判断、筛选这些逻辑，代码做比AI做快1000倍
- 2000条数据在沙箱里处理，不占用AI的"脑容量"
3.4 省Token的本质：职责分工
说白了，Anthropic这个方案就是让AI和代码各干各擅长的事：
类比：就像公司里，CEO（AI）负责做决策，员工（代码）负责执行。 CEO不需要亲自搬每一箱货物，只需要下达指令，剩下的让员工去干。
四、核心优势总结
理解了省Token的机制，我们来看看这个方案到底带来了什么好处：
4.1 Token效率提升（理论值可达98%+）
对订阅用户（Pro/Max）：
对API用户：
4.2 按需发现工具（Progressive Tool Discovery）
传统方式的问题：即使你有100个工具，AI也要一次性加载所有定义，浪费大量Token。
新方式：
- AI需要用Google Drive工具时，才去读
./servers/google-drive/目录
- 工具定义可以写得更详细（因为不需要一次性全部加载）
好处：
4.3 数据处理不占上下文
示例：Excel数据筛选
任务："从10,000行Excel中找出销售额前10名"
传统方式：
新方式：
省了99%！
4.4 更强的控制能力
AI可以用完整的编程能力：
// 1. 循环处理
for (let customer of customers) {
if (customer.amount > 100000) {
await sendEmail(customer.email);
}
}
// 传统Tool Calling：每个客户都要一次往返！
// 2. 并发处理
const [data1, data2, data3] = awaitPromise.all([
getDriveData(),
getSalesforceData(),
getSlackData()
]);
// 传统方式：只能串行调用，慢很多
// 3. 条件分支
if (customer.type === 'VIP') {
// VIP流程
} elseif (customer.totalSpent > 10000) {
// 老客户流程
} else {
// 新客户流程
}
// 传统方式：需要多次往返才能走完分支
4.5 隐私保护
关键：敏感数据可以完全不进AI上下文
// 客户的身份证号、银行卡号等敏感信息
// 可以在沙箱中直接从数据库传到CRM
// AI完全看不到这些数据！
const customers = await oldCRM.getCustomers();
// 包含敏感信息，但只在沙箱里
await newCRM.batchImport(customers);
// 直接传输，不经过AI
// AI只看到：{ success: 5000, failed: 0 }
这对金融、医疗等行业特别重要。
4.6 可复用技能（最有想象力的部分）
生活化类比：就像你平时做菜：
实际应用：
// 第一次：AI写代码处理客户数据
const result = await analyzeCustomerData(csvFile);
// 这段代码可以保存为"customer-analysis"技能
// 以后：直接调用这个技能
import { customerAnalysis } from './skills/customer-analysis';
const result = await customerAnalysis(newCsvFile);
// 不需要AI重新写代码！
技能库的价值：
4.7 状态持久化
代码可以把工作进度保存下来，下次继续：
// 保存进度
await fs.writeFile('./progress.json', JSON.stringify({
processedCount: 1000,
lastRecordId: 'xyz123',
remainingCount: 4000
}));
// 下次继续
const progress = JSON.parse(await fs.readFile('./progress.json'));
// 从上次中断的地方继续处理
特别适合：
五、什么时候应该用代码执行模式？
看完原理，你肯定想知道：这玩意儿适合我吗？
✅ 适合的场景
1. 数据量大（几千行以上）
2. 多个工具需要协作
- 从Google Drive读取 → 处理 → 上传到Salesforce → 发邮件通知
3. 需要复杂逻辑
4. 涉及敏感数据
5. 需要频繁执行的任务
❌ 不适合的场景
1. 简单的单次工具调用
2. 需要创意性生成
3. 交互式对话
判断标准
一个简单的原则：
如果满足以下任意2条，就该用代码执行模式：
✓ 数据量 > 1000行
✓ 需要用3个以上工具
✓ 有循环或复杂判断逻辑
✓ 涉及敏感信息
✓ 需要定期重复执行
反过来说：简单任务、一次性操作、创意性工作，传统方式反而更快。
六、社区现状：实话实说
Anthropic这个代码执行方案发布已经快一周了,我也花了不少时间去看社区的反馈。说实话,反应挺有意思的——有人兴奋得不行,有人冷静观望,还有人直接提出了很尖锐的问题。
6.1 开发者的真实反馈
我在Hacker News和Reddit上看了几天讨论,大概可以分成这么几派:
兴奋派(约30%):"这简直是革命性的!终于不用为Token发愁了!" "我们团队已经在测试,效果确实惊人" "这才是AI Agent该有的样子"
观望派(约50%):"理论上很美好,但实际落地难度呢?" "安全性怎么保证?不敢在生产环境用" "等等看有没有大公司先踩坑"
质疑派(约20%):"这不就是把Tool Calling换成了代码生成吗?" "复杂度提升了一大截,值得吗?" "沙箱安全问题怎么解决?"
6.2 最多人问的几个问题
问题1: "这东西到底能不能用在生产环境?"
Simon Willison(数据库专家、Django核心开发者)的看法我觉得很中肯:
"这个方案在理论上非常优雅,但实际部署需要解决很多工程问题——沙箱隔离、错误处理、性能优化...不是说搭个环境就能跑起来的。"
真的是这样。Anthropic给出的是技术方案,不是开箱即用的产品。你想要实际用上,得自己搭环境、做安全加固、处理各种边缘情况。
问题2: "Claude Code会不会原生支持?"
这个问题问得最多。大家都在猜测Anthropic会不会把这个方案内置到Claude Code里。
我的判断是:短期内不会。
为什么?
- Claude Code现在的架构是基于MCP服务器的,改动太大
- Anthropic可能会先观察社区的反应和最佳实践
但长期来看?我觉得大概率会。因为这个方案的优势实在太明显了,Token效率提升98%不是开玩笑的。可能会以某种可选模式的形式出现,比如:
# 传统模式(默认)
claude-code chat
# 代码执行模式(需要手动开启)
claude-code chat --execution-mode
问题3: "安全性到底有多大风险?"
这个问题最尖锐,也最实际。让AI写代码在沙箱里执行,听起来就有点危险。
实际风险:
Anthropic的应对:
但说实话,100%安全是不可能的。你得根据自己的场景评估风险:
6.3 社区里传出来的一些声音
虽然这个方案才发布一周,但社区里已经有一些讨论和分享。
有人在Hacker News评论:"我们团队在考虑用这个方案重构现有的数据处理pipeline,估计能省不少Token,但确实需要重新设计架构。"
Reddit上有开发者说:"看起来很美好,但实际搭建环境可能要花不少时间。我更关心的是安全性问题,毕竟是让AI写代码然后直接执行。"
GitHub的Issue里有人提问:"MCP服务器什么时候能支持代码执行模式?现在好像还没有现成的实现。"
说白了,大家都在观望阶段。理论上很美好,但实际能不能用、好不好用,还得等社区慢慢探索。
七、思考与总结
7.1 方案定位：方向正确，但路还长
说实话,写完这篇文章,我的感受挺复杂的。
Anthropic提出的这个代码执行方案,从技术角度看确实很优雅。本质上就是把AI擅长的能力(编写代码)和不擅长的能力(管理大量上下文)进行了清晰的分工。
核心思路:
理论收益:
但你想想,这个方案现在还只是纸面上的。Anthropic只是发了篇技术博客,展示了一个架构设计,并没有提供现成的工具。
和之前那两篇文章的区别:
- tmux方案 - 现在就能用,装个tmux马上见效
- Router方案 - 配置文件改改,立刻省钱70%
- 代码执行方案 - 好是好,但得自己搭环境、写代码、做安全加固...
现实情况是:
所以啊,这个方案对我们普通用户来说,更像是一个"未来方向",而不是立刻能用的解决方案。
最大的价值在哪儿?
我觉得不是马上能用,而是指明了一个方向 —— AI Agent的Token消耗问题,不能只靠"省着用",得从架构层面重新设计。这个思路是对的,但从技术方案到生产可用,中间还有很长的路要走。
就像Docker刚出来的时候,大家都说容器化是未来,但真正普及花了好几年。代码执行方案可能也是这样,概念很新颖,但落地需要时间。
写到这儿,读者可能会问这几个我也困惑的问题，如是我先说说我不成熟的看法，欢迎大家指正:
7.2 这个和Claude的Skills有啥区别?
你想想,Claude Code已经有Skills功能了——可以保存常用的代码片段和工作流,下次直接调用。那代码执行模式和Skills到底有啥不一样?
我的理解:
Skills更像是"记忆":
代码执行模式更像是"换引擎":
打个比方:
- Skills是记住了"红烧肉的菜谱",下次按菜谱做
7.3 MCP被降级成工具列表了?
这个问题更有意思。MCP(Model Context Protocol)本来挺高大上的——"模型上下文协议",听起来是要统一AI和外部工具交互的标准。
但在代码执行模式里,MCP服务器变成了啥?就是磁盘上的一堆文件:
./servers/
├── google-drive/
│ ├── getDocument.ts
│ └── uploadFile.ts
└── salesforce/
└── updateRecord.ts
这算不算把MCP"降级"了?从"协议"变成了"工具库"?
我的看法:
也不能说是降级,更像是回归本质。
你想想MCP最早的目标:让AI能方便地调用各种工具。但传统Tool Calling的问题是,工具定义要全部塞进上下文,太浪费Token了。
代码执行模式的巧妙之处在于:
这反而让MCP更灵活了:
7.4 这会不会是AI Agent的终局?
看完Anthropic这个方案,我在想:这会不会就是AI Agent的最终形态?
可能不是。
因为这个方案解决的只是Token消耗问题,但AI Agent还有其他挑战:
- 可解释性 - AI写的代码,出问题了怎么debug?
- 用户体验 - 普通用户不懂Docker,怎么降低门槛?
而且,随着模型能力的提升,可能会出现新的解决思路。比如:
- 更大的上下文窗口(100万、1000万Token)?
- 混合架构(简单任务用Tool Calling,复杂任务用代码执行)?
AI这个领域变化太快了。
今天看起来革命性的方案,说不定明年就被新技术取代了。所以与其说是"终局",不如说是"当下最优解"。
7.5 Anthropic的创新之路
这篇文章写了挺长时间的的,讲了很多技术细节。写完之后,其实我最大的感受不是这个方案有多牛,而是Anthropic这家公司的创新能力真的挺强的。
你想想,从去年11月份初到现在,他们陆续推出了:
- Subagents - 让Claude能拆解复杂任务,多个Agent协作
- Skills - 让Claude能记住常用的工作流
- Code Execution with MCP - 现在这个代码执行方案
每一个都是在解决AI Agent实际使用中的痛点。而且你会发现,这些创新是有延续性的:
它们不是各自为战,而是在逐步构建一个完整的AI Agent生态。虽然每个功能单独看都还不够成熟,但放在一起看,你会发现Anthropic在下一盘大棋。
相比之下,有些公司只是把模型做大、做快,但在工程化、产品化这一块没怎么投入。Anthropic不一样,他们既有技术创新(模型本身),也在认真思考怎么让AI真正好用。
当然,理想和现实之间还有差距。Code Execution这个方案,思路是对的,但离普及确实还早。
就这样吧,今天就聊到这儿、写这种烧脑的文章也挺累的!
参考资料
- Anthropic官方博客: Code execution with MCP
- Model Context Protocol (MCP) 文档
粤ICP备14082021号
免费POC，
零成本试错
