返回顶部
热门问答 更多热门问答
技术文章 更多技术文章

Anthropic革命性方案:AI Agent从15万Token干到2千Token的秘密

[复制链接]
链载Ai 显示全部楼层 发表于 昨天 22:35 |阅读模式 打印 上一主题 下一主题

大家好,之前连着写了两篇——一篇是用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: 中间结果反复传递 + 历史对话累积(双重负担)


关键问题:

  1. 数据必须经过AI上下文- 10,000 Token的CSV内容不能直接从Drive传到Salesforce
  2. 每次都要重发工具定义- 50k的工具定义在每次请求中重复发送
  3. 历史对话不断累积- 第2步要包含第1步的所有内容,第3步要包含前两步的所有内容
  4. 雪球效应- Token消耗呈指数级增长: 53k → 116k → 169k

类比说明:就像你让快递员送一个包裹:

  • 正常情况: 直接从A地送到B地
  • 传统AI:
  1. 快递员先背诵所有快递规则(每次都要)
  2. 拿到包裹,记录所有细节
  3. 回到总部汇报(带着包裹)
  4. 再次背诵规则,复述之前的对话
  5. 才能送到B地

困境3: 无法处理复杂逻辑(就像不会使用计算器)

当任务涉及循环、条件判断等复杂逻辑时,传统方式需要AI来回调用工具多次:

示例任务:"找出所有金额超过100万的客户"

传统方式需要:

  1. 调用工具获取客户列表 (往返1次)
  2. 对每个客户判断金额 (每个客户往返1次)
  3. 汇总结果 (往返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 代码执行方式 架构对比

先看一张架构对比图,你就明白差在哪儿了:

关键区别:

  1. 工具加载方式

  • 传统:一次性加载所有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工具,每次请求都要:

  1. 把50个工具的说明书全部塞进上下文(可能5万Token)
  2. 即使这次只用2个工具,其他48个的说明书也得带着
  3. 更坑的是:每次请求都要重复发送一遍!
第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。

传统方式:

  1. 你要亲自查看每一件货物(10,000行数据进入AI上下文)
  2. 记录详细信息(消耗10,000 Token)
  3. 告诉司机怎么运(又传一遍,再消耗10,000 Token)
  4. 你的大脑(上下文)被货物信息占满了!

新方式:

  1. 你只需要写一张派送单(500 Token的代码)
  2. 司机按派送单直接从A运到B(数据在沙箱里流动)
  3. 你的大脑只记住派送单,不需要记住货物详情!

代码示例对比:

// 传统方式:数据必须经过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上下文:
constdoc =awaitgoogleDrive.getDocument({id:"abc123"});
// ✅ doc的10,000 Token只在沙箱中

awaitsalesforce.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)
constcustomers =awaitcrm.getAllCustomers();
// 2000个客户数据只在沙箱中,不进AI上下文

// 在沙箱中用代码筛选(一行代码,瞬间完成)
consthighValue = customers.filter(c=>c.amount >1000000);

return{
count: highValue.length,
topCustomer: highValue[0].name
};
// 只返回简单结果(100 Token)

总计:300+100=400Token
节省:99.6%!

为什么快这么多?

  • 代码执行速度 >> AI来回调用工具
  • 循环、判断、筛选这些逻辑,代码做比AI做快1000倍
  • 2000条数据在沙箱里处理,不占用AI的"脑容量"

3.4 省Token的本质:职责分工

说白了,Anthropic这个方案就是让AI和代码各干各擅长的事

任务类型
谁来做
为什么
理解用户意图
AI
AI擅长理解自然语言
编写处理逻辑
AI
AI擅长写代码
执行循环、判断
代码
代码执行快,不占Token
处理大量数据
沙箱
数据不进AI上下文
工具间数据传递
沙箱
直接传递,不经过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(letcustomerofcustomers) {
if(customer.amount >100000) {
awaitsendEmail(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完全看不到这些数据!

constcustomers =awaitoldCRM.getCustomers();
// 包含敏感信息,但只在沙箱里

awaitnewCRM.batchImport(customers);
// 直接传输,不经过AI

// AI只看到:{ success: 5000, failed: 0 }

这对金融、医疗等行业特别重要。

4.6 可复用技能(最有想象力的部分)

生活化类比:就像你平时做菜:

  • 传统方式:每次炒菜都要从头学
  • 新方式:把"红烧肉"的做法记录成菜谱,下次直接用

实际应用:

// 第一次:AI写代码处理客户数据
constresult =awaitanalyzeCustomerData(csvFile);
// 这段代码可以保存为"customer-analysis"技能

// 以后:直接调用这个技能
import{ customerAnalysis }from'./skills/customer-analysis';
constresult =awaitcustomerAnalysis(newCsvFile);
// 不需要AI重新写代码!

技能库的价值:

  • 📚 形成组织知识库
  • ⚡ 常见任务直接调用,提升效率
  • 🎯 保证一致性
  • 💰 节省Token(不需要每次让AI生成新代码)

4.7 状态持久化

代码可以把工作进度保存下来,下次继续:

// 保存进度
awaitfs.writeFile('./progress.json',JSON.stringify({
processedCount:1000,
lastRecordId:'xyz123',
remainingCount:4000
}));

// 下次继续
constprogress =JSON.parse(awaitfs.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里。

我的判断是:短期内不会。

为什么?

  1. Claude Code现在的架构是基于MCP服务器的,改动太大
  2. 安全性问题需要时间验证
  3. 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%
  • 代码执行方案- 好是好,但得自己搭环境、写代码、做安全加固...

现实情况是:

  1. Claude Code不会短期内原生支持
  2. 社区工具还很不成熟
  3. 技术门槛挺高的
  4. 安全性还需要验证

所以啊,这个方案对我们普通用户来说,更像是一个"未来方向",而不是立刻能用的解决方案。

最大的价值在哪儿?

我觉得不是马上能用,而是指明了一个方向—— 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实际使用中的痛点。而且你会发现,这些创新是有延续性的:

  1. MCP解决了"连接"问题
  2. calude code cli 编码问题
  3. Subagents解决了"协作"问题
  4. Skills解决了"记忆"问题
  5. Code Execution解决了"效率"问题

它们不是各自为战,而是在逐步构建一个完整的AI Agent生态。虽然每个功能单独看都还不够成熟,但放在一起看,你会发现Anthropic在下一盘大棋

相比之下,有些公司只是把模型做大、做快,但在工程化、产品化这一块没怎么投入。Anthropic不一样,他们既有技术创新(模型本身),也在认真思考怎么让AI真正好用

当然,理想和现实之间还有差距。Code Execution这个方案,思路是对的,但离普及确实还早

回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

链载AI是专业的生成式人工智能教程平台。提供Stable Diffusion、Midjourney AI绘画教程,Suno AI音乐生成指南,以及Runway、Pika等AI视频制作与动画生成实战案例。从提示词编写到参数调整,手把手助您从入门到精通。
  • 官方手机版

  • 微信公众号

  • 商务合作

  • Powered by Discuz! X3.5 | Copyright © 2025-2025. | 链载Ai
  • 桂ICP备2024021734号 | 营业执照 | |广西笔趣文化传媒有限公司|| QQ