大家好，之前连着写了两篇——一篇是用tmux让Claude Code 24/7不间断干活,另一篇是Router混用多模型省钱70%。说实话,那两篇写完我自己也在用,效果确实不错。tmux解决了会话中断的问题,Router解决了模型选择的问题,感觉已经把Claude Code能优化的地方都折腾遍了。
但你想想,这些方案本质上都是在"省着用"——换便宜的模型、用完就断开会话、想办法减少调用次数。就像你家里水费贵,你想的办法是少洗澡、换个便宜点的供水公司。治标不治本啊。
真正的问题在哪儿? 你想想,处理一个10,000行的CSV文件做数据分析,Claude Code能烧掉多少Token?答案是75万!这不是个例,这是Claude Code的日常。用订阅账号的话,高Token消耗会快速耗尽每天5小时的使用限制;用API的话,成本也会很高。
直到前几天Anthropic发了一篇技术博客,我才恍然大悟——问题根本不仅仅是模型贵不贵,而是整个工具调用的架构就有问题。 就像你家水费贵不是因为水价高,而是因为水管一直在漏水。
Anthropic这次提出的代码执行方案,怎么说呢,不是小修小补,是从底层架构上重新设计了AI Agent的工作方式。根据官方测试,处理同一个CSV文件,Token消耗从756,539直接降到8,369——降了98.9%!
这篇文章我就用最接地气的方式,把这个方案拆开了讲清楚。看完你就明白,为什么说这才是真正解决Token消耗的"道",而不是之前那些"术"。
一、问题的本质:AI Agent的"记忆负担"
1.1 Token到底是个啥?为什么它是个大问题?
在讲解决方案之前,咱们先把Token这个东西说清楚。很多人用Claude Code,根本不知道背后的Token消耗有多恐怖。
生活化比喻:
-
Token就像AI的"脑容量单位" -
就像人脑一次只能记住有限的信息 -
AI每次处理的Token数量也有上限(Claude的上下文窗口是200K个Token)
为什么Token消耗是个大问题?
对于订阅用户(Pro/Max/Team):
-
Token消耗直接影响使用效率 -
高Token消耗会快速耗尽每天5小时的使用限制 -
同样的任务,Token少意味着能完成更多工作 -
大型任务可能瞬间耗尽你一天的配额
对于API用户:
-
每处理1000个Token都要花钱 -
Token越多,成本越高 -
Claude定价:输入15/M Token
共同的问题:
-
Token越多,响应越慢 -
Token过多会超出AI的"记忆容量"(Claude上下文窗口200K)
Token与实际内容的对应:
-
1个Token ≈ 0.75个英文单词 -
1个Token ≈ 1-2个中文字符 -
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 -
Slack工具说明: 1500个Token -
Gmail工具说明: 2000个Token -
… (还有几十个工具) -
总计: 可能高达50,000+ Token -
每次请求都要发送: 50,000 × N次请求 = 巨大浪费!
而实际上,这个任务只需要用到Google Drive和Salesforce两个工具!
困境2: 中间结果反复传递 + 历史对话累积(双重负担)
关键问题:
-
数据必须经过AI上下文 – 10,000 Token的CSV内容不能直接从Drive传到Salesforce -
每次都要重发工具定义 – 50k的工具定义在每次请求中重复发送 -
历史对话不断累积 – 第2步要包含第1步的所有内容,第3步要包含前两步的所有内容 -
雪球效应 – Token消耗呈指数级增长: 53k → 116k → 169k
类比说明:就像你让快递员送一个包裹:
-
正常情况: 直接从A地送到B地 -
传统AI:
-
快递员先背诵所有快递规则(每次都要) -
拿到包裹,记录所有细节 -
回到总部汇报(带着包裹) -
再次背诵规则,复述之前的对话 -
才能送到B地
困境3: 无法处理复杂逻辑(就像不会使用计算器)
当任务涉及循环、条件判断等复杂逻辑时,传统方式需要AI来回调用工具多次:
示例任务: "找出所有金额超过100万的客户"
传统方式需要:
-
调用工具获取客户列表 (往返1次) -
对每个客户判断金额 (每个客户往返1次) -
汇总结果 (往返1次)
如果有100个客户,就需要往返100多次!
困境4: 历史对话无限累积(Token的"雪球效应")
这是最容易被忽视但最严重的问题!
实际场景:处理一个数据分析任务
对话轮次 本次新增 累积历史 请求总Token
第1轮: 1k 0k 44k (系统3k+工具40k+内容1k)
第2轮: 100k 44k 187k (系统3k+工具40k+历史44k+新100k)
第3轮: 5k 187k 235k (系统3k+工具40k+历史187k+新5k)
第4轮: 2k 235k 280k (系统3k+工具40k+历史235k+新2k)
第5轮: 1k 280k 324k (已经超过很多模型上限!)
类比说明:就像滚雪球:
-
开始: 小雪球(初始对话) -
滚第1圈: 粘上更多雪(加入工具结果) -
滚第2圈: 雪球急剧变大(历史不断累积) -
滚第3圈: 已经推不动了(接近Token上限)
为什么会这样?
// Claude Code每次请求都必须包含:
{
system: "...", // 3k Token (每次重复)
tools: [...], // 40k Token (每次重复)
messages: [
// 所有历史对话都在这里!
{role: "user", content: "第1轮..."},
{role: "assistant", content: "回复1..."},
{role: "user", content: "工具结果1..."},
{role: "assistant", content: "回复2..."},
{role: "user", content: "工具结果2..."},
// ... 不断累积,永不清理!
]
}
二、Anthropic的解决方案:代码执行模式
2.1 核心思想:让AI写代码而不是调用工具
Anthropic的方案可以用一句话概括:
不要让AI直接调用工具,而是让AI写一段代码来调用工具!
为什么这样做?
-
AI擅长写代码 -
代码可以在独立环境中运行,不占用AI的记忆空间 -
代码可以直接处理数据,无需来回传递
2.2 MCP是什么?
MCP (Model Context Protocol) 是Anthropic推出的一个标准协议,就像USB接口一样统一了工具调用的标准。
2.3 传统方式 vs 代码执行方式 架构对比
先看一张架构对比图,你就明白差在哪儿了:
关键区别:
-
工具加载方式
-
传统:一次性加载所有50个工具定义 (50,000 Token) -
新方式:按需加载2个工具 (2,000 Token)
-
数据处理位置
-
传统:数据必须进入AI上下文 -
新方式:数据在沙箱中处理,AI看不到 -
Token消耗
-
传统:100,500+ Token,而且每次都重复发送工具定义 -
新方式:3,500 Token,稳定不增长
2.4 数据流动对比——这是关键!
再看一张数据流动的时间线对比图:
传统方式的痛点:
-
数据必须经过AI上下文 -
每次传递都消耗Token -
第二次传递时又带上了第一次的数据
新方式的巧妙之处:
-
数据在沙箱中直接流动 -
AI只看到代码和执行结果 -
20,000 Token的数据从未进入AI上下文
三、为什么能省这么多Token？三大核心机制
好了，前面讲了问题在哪儿，现在讲讲Anthropic这个方案到底是怎么省Token的。
3.1 机制一：按需加载工具定义
传统方式的浪费：
你想想，Claude Code连接了50个MCP工具，每次请求都要：
-
把50个工具的说明书全部塞进上下文（可能5万Token） -
即使这次只用2个工具，其他48个的说明书也得带着 -
更坑的是：每次请求都要重复发送一遍！
第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） -
告诉司机怎么运（又传一遍，再消耗10,000 Token） -
你的大脑（上下文）被货物信息占满了！
新方式：
-
你只需要写一张派送单（500 Token的代码） -
司机按派送单直接从A运到B（数据在沙箱里流动） -
你的大脑只记住派送单，不需要记住货物详情！
代码示例对比：
// 传统方式：数据必须经过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 -
数据从头到尾没进过AI的上下文 -
AI只看到代码和最后的执行结果 -
这就是为什么能省98%的Token！
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来回调用工具 -
循环、判断、筛选这些逻辑，代码做比AI做快1000倍 -
2000条数据在沙箱里处理，不占用AI的"脑容量"
3.4 省Token的本质：职责分工
说白了，Anthropic这个方案就是让AI和代码各干各擅长的事：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
类比：就像公司里，CEO（AI）负责做决策，员工（代码）负责执行。 CEO不需要亲自搬每一箱货物，只需要下达指令，剩下的让员工去干。
四、核心优势总结
理解了省Token的机制，我们来看看这个方案到底带来了什么好处：
4.1 Token效率提升（理论值可达98%+）
对订阅用户（Pro/Max）：
-
同样的5小时使用限制，能完成的工作量大幅增加 -
大型任务不会瞬间耗尽配额 -
Token消耗低，5小时用得更持久
对API用户：
-
直接省钱，Token少了98% -
同样预算可以处理几十倍的任务量 -
成本可控，可以大规模部署
4.2 按需发现工具（Progressive Tool Discovery）
传统方式的问题：即使你有100个工具，AI也要一次性加载所有定义，浪费大量Token。
新方式：
-
AI需要用Google Drive工具时，才去读 ./servers/google-drive/目录 -
不需要的工具根本不碰 -
工具定义可以写得更详细（因为不需要一次性全部加载）
好处：
-
可以连接上百个工具，不影响性能 -
动态扩展工具很容易 -
工具说明可以写得很详细，AI理解更准确
4.3 数据处理不占上下文
示例：Excel数据筛选
任务："从10,000行Excel中找出销售额前10名"
传统方式：
-
需要把10,000行数据传给AI -
AI在上下文中分析 -
可能需要多次遍历 -
Token消耗：20万+
新方式：
-
10,000行数据在沙箱里处理 -
AI只写处理代码 -
只返回Top 10结果 -
Token消耗：1500左右
省了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重新写代码！
技能库的价值：
-
📚 形成组织知识库 -
⚡ 常见任务直接调用，提升效率 -
🎯 保证一致性 -
💰 节省Token（不需要每次让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. 数据量大（几千行以上）
-
分析CSV、Excel文件 -
处理数据库查询结果 -
批量处理文档
2. 多个工具需要协作
-
从Google Drive读取 → 处理 → 上传到Salesforce → 发邮件通知 -
查询数据库 → 生成报表 → 发送Slack消息
3. 需要复杂逻辑
-
循环处理：遍历客户列表 -
条件判断：不同客户类型不同处理方式 -
数据筛选：从10,000条找出符合条件的100条
4. 涉及敏感数据
-
身份证号、银行卡号等 -
希望数据不经过AI上下文
5. 需要频繁执行的任务
-
每天自动生成报表 -
定期数据同步 -
自动化工作流
❌ 不适合的场景
1. 简单的单次工具调用
-
"帮我发一封邮件" -
"查一下这个客户信息" -
一次性操作，不涉及大量数据
2. 需要创意性生成
-
"写一篇博客文章" -
"帮我设计一个方案" -
AI的创造力比代码执行重要
3. 交互式对话
-
"帮我解释这个概念" -
"给我一些建议" -
需要AI的理解和推理能力
判断标准
一个简单的原则：
如果满足以下任意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写代码在沙箱里执行,听起来就有点危险。
实际风险:
-
AI可能生成恶意代码 -
沙箱逃逸的可能性(虽然很低) -
资源滥用(无限循环、内存爆炸)
Anthropic的应对:
-
严格的沙箱限制(CPU、内存、网络) -
代码执行前的静态扫描 -
超时机制 -
权限最小化原则
但说实话,100%安全是不可能的。你得根据自己的场景评估风险:
-
处理公开数据?风险可控 -
处理敏感数据?需要额外的安全措施 -
金融、医疗行业?建议等等再说,让别人先踩坑
6.3 社区里传出来的一些声音
虽然这个方案才发布一周,但社区里已经有一些讨论和分享。
有人在Hacker News评论:"我们团队在考虑用这个方案重构现有的数据处理pipeline,估计能省不少Token,但确实需要重新设计架构。"
Reddit上有开发者说:"看起来很美好,但实际搭建环境可能要花不少时间。我更关心的是安全性问题,毕竟是让AI写代码然后直接执行。"
GitHub的Issue里有人提问:"MCP服务器什么时候能支持代码执行模式?现在好像还没有现成的实现。"
说白了,大家都在观望阶段。理论上很美好,但实际能不能用、好不好用,还得等社区慢慢探索。
七、思考与总结
7.1 方案定位：方向正确，但路还长
说实话,写完这篇文章,我的感受挺复杂的。
Anthropic提出的这个代码执行方案,从技术角度看确实很优雅。本质上就是把AI擅长的能力(编写代码)和不擅长的能力(管理大量上下文)进行了清晰的分工。
核心思路:
-
AI负责理解任务,编写代码 -
沙箱负责执行代码,处理数据 -
工具按需加载,而不是全部预加载 -
数据在沙箱中流动,不经过AI上下文
理论收益:
-
Token使用量降低98%+ -
执行速度提升10倍+ -
隐私保护更好 -
可扩展性更强
但你想想,这个方案现在还只是纸面上的。Anthropic只是发了篇技术博客,展示了一个架构设计,并没有提供现成的工具。
和之前那两篇文章的区别:
-
tmux方案 – 现在就能用,装个tmux马上见效 -
Router方案 – 配置文件改改,立刻省钱70% -
代码执行方案 – 好是好,但得自己搭环境、写代码、做安全加固…
现实情况是:
-
Claude Code不会短期内原生支持 -
社区工具还很不成熟 -
技术门槛挺高的 -
安全性还需要验证
所以啊,这个方案对我们普通用户来说,更像是一个"未来方向",而不是立刻能用的解决方案。
最大的价值在哪儿?
我觉得不是马上能用,而是指明了一个方向 —— AI Agent的Token消耗问题,不能只靠"省着用",得从架构层面重新设计。这个思路是对的,但从技术方案到生产可用,中间还有很长的路要走。
就像Docker刚出来的时候,大家都说容器化是未来,但真正普及花了好几年。代码执行方案可能也是这样,概念很新颖,但落地需要时间。
写到这儿,读者可能会问这几个我也困惑的问题，如是我先说说我不成熟的看法，欢迎大家指正:
7.2 这个和Claude的Skills有啥区别?
你想想,Claude Code已经有Skills功能了——可以保存常用的代码片段和工作流,下次直接调用。那代码执行模式和Skills到底有啥不一样?
我的理解:
Skills更像是"记忆":
-
把之前做过的事情记录下来 -
下次遇到类似任务,直接套用 -
本质上还是通过API调用工具 -
Token消耗的问题没解决
代码执行模式更像是"换引擎":
-
不是记住怎么做,而是改变工作方式 -
数据不走AI上下文,直接在沙箱里流动 -
从根本上降低Token消耗 -
可以处理Skills处理不了的大数据场景
打个比方:
-
Skills是记住了"红烧肉的菜谱",下次按菜谱做 -
代码执行是"换了个大锅",可以一次炒10人份
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服务器还是MCP服务器 -
只是不需要一次性加载所有定义 -
需要哪个工具,就去读那个文件 -
协议还是那个协议,只是使用方式变了
这反而让MCP更灵活了:
-
可以连接上百个工具,不怕Token爆炸 -
工具说明可以写得很详细 -
动态扩展很容易
7.4 这会不会是AI Agent的终局?
看完Anthropic这个方案,我在想:这会不会就是AI Agent的最终形态?
可能不是。
因为这个方案解决的只是Token消耗问题,但AI Agent还有其他挑战:
-
可靠性 – 代码可能写错,沙箱可能出bug -
可解释性 – AI写的代码,出问题了怎么debug? -
安全性 – 恶意代码怎么防?沙箱逃逸怎么办? -
用户体验 – 普通用户不懂Docker,怎么降低门槛?
而且,随着模型能力的提升,可能会出现新的解决思路。比如:
-
更大的上下文窗口(100万、1000万Token)? -
更智能的上下文压缩? -
混合架构(简单任务用Tool Calling,复杂任务用代码执行)?
AI这个领域变化太快了。
今天看起来革命性的方案,说不定明年就被新技术取代了。所以与其说是"终局",不如说是"当下最优解"。
7.5 Anthropic的创新之路
这篇文章写了挺长时间的的,讲了很多技术细节。写完之后,其实我最大的感受不是这个方案有多牛,而是Anthropic这家公司的创新能力真的挺强的。
你想想,从去年11月份初到现在,他们陆续推出了:
-
MCP – 统一AI和外部工具的交互协议 -
claude code cli -
Subagents – 让Claude能拆解复杂任务,多个Agent协作 -
Skills – 让Claude能记住常用的工作流 -
Code Execution with MCP – 现在这个代码执行方案
每一个都是在解决AI Agent实际使用中的痛点。而且你会发现,这些创新是有延续性的:
-
MCP解决了"连接"问题 -
calude code cli 编码问题 -
Subagents解决了"协作"问题 -
Skills解决了"记忆"问题 -
Code Execution解决了"效率"问题
它们不是各自为战,而是在逐步构建一个完整的AI Agent生态。虽然每个功能单独看都还不够成熟,但放在一起看,你会发现Anthropic在下一盘大棋。
相比之下,有些公司只是把模型做大、做快,但在工程化、产品化这一块没怎么投入。Anthropic不一样,他们既有技术创新(模型本身),也在认真思考怎么让AI真正好用。
当然,理想和现实之间还有差距。Code Execution这个方案,思路是对的,但离普及确实还早。
