伯克利实验揭开智能体降本真相:Claude Code比开源壳贵两倍却多干不了几个活


加州大学伯克利分校的团队发现,你给同一个AI大脑换上不同的外壳,账单能差出五倍,活儿却干得一样多!

你的AI编程助手正在悄悄多收你一笔隐形税!

伯克利团队用七个模型和三个调度壳跑了两千多次编程测试,发现同一个模型换壳后成功率几乎不变,但成本最高差五倍,最小壳反而最省钱。

一个AI大脑配三个外壳,账单差五倍

你现在可能已经在用AI帮你写代码了,比如让一个聊天机器人帮你改bug、写函数、甚至从头搭一个小项目,这类能自己动手干活的AI系统有一个专门的名字,叫编程智能体(coding agent),它和普通的聊天AI最大的区别在于,聊天AI只会回答问题,而编程智能体能直接操作你的电脑文件系统,打开代码、修改代码、运行测试,像一个真正的程序员一样在终端里敲命令。

编程智能体并不是一个单独的软件,它其实由两个部分拼在一起:一个是负责思考的大脑,也就是大语言模型,比如Anthropic公司做的Claude系列、OpenAI公司做的GPT系列;另一个是负责跑腿的外壳,学术上叫harness(调度壳),调度壳的工作是帮大脑管理工具箱、组织上下文信息、控制执行流程,你可以把它想象成一个项目经理,大脑只管想方案,项目经理负责把方案变成具体的操作步骤,调取正确的工具,把结果喂回给大脑。

市面上不同的公司给同一个大脑配了不同的项目经理,Anthropic有自家的Claude Code,OpenAI有自家的Codex CLI,开源社区也有人做了一个极简的调度壳叫Pi,这三个调度壳管理工具的方式、组织信息的风格、调用模型的频率全都不一样,就像同一个厨师进了三家不同的餐厅,食材一样,但厨房动线、点菜系统、服务员传话方式完全不同,最后端出来的菜味道差不多,账单却可能天差地别。

伯克利的研究团队决定把这件事量化,他们挑了七个当时最强的模型,包括Claude Fable 5、Claude Opus 4.8、GPT-5.6 Sol、GPT-5.6 Luna、Kimi K3等,然后把每个模型分别塞进三个调度壳里跑,一共组成二十一种搭配,测试用的考题来自两个公开的编程基准测试:SWE-bench Lite专门考修bug的能力,Terminal-Bench 2.0专门考在命令行里完成复杂操作的能力,每道题跑三次取平均值,总共跑了两千多次实验。

结果一出来就让所有人愣住了,同一个模型在三个调度壳里的成功率几乎一模一样,Claude Fable 5在Claude Code里做对了97.8%的题,在Codex CLI里做对了96.7%,在Pi里也做对了96.7%,差距不到两个百分点,但是账单呢,Claude Code平均每次尝试花掉1.33美元,Pi只花了0.67美元,整整差了一倍!

这就怪了,活儿干得一样好,为什么有的壳要收你两倍的钱?

壳越重税越高,第一通电话就露馅

要搞清楚钱花在哪里,你得先知道AI模型的计费方式,大语言模型按token(词元)收费,token可以粗略理解成模型阅读和生成的文字碎片,一个英文单词大约等于一个到两个token,一个汉字大约等于一到三个token,模型每读一段话、每写一段话,都在烧token,而调度壳的核心工作之一就是决定每次给模型喂多少信息,这个信息量直接决定了你的账单厚度。

研究团队拆开每次实验的第一轮调用记录,发现了一个触目惊心的差距,Claude Code在第一次给模型发消息时,平均塞进去了超过七万token的上下文,而Pi只塞了不到两千token,差了整整三十多倍,这些上下文里装的东西包括:系统指令、工具定义、安全规则、格式要求,Claude Code光是工具定义就写了七万多个字符,Pi的工具定义只有两千多字符。

你可以这样理解这个差距,假设你请了一个翻译,Pi的做法是递给他一张纸条写着"帮我翻译这段话",Claude Code的做法是先给他一本三百页的操作手册,规定他必须用什么字体、什么格式、遇到什么词要怎么处理、哪些词绝对不能翻译,然后再说"帮我翻译这段话",翻译结果可能完全一样,但那个翻译按阅读字数收费,你猜哪个更贵!

更关键的是,这个膨胀的上下文不是一次性的开销,它会像滚雪球一样在每一轮对话中重复出现,编程智能体修一个bug通常需要十几轮对话,每一轮都要把系统指令和工具定义重新发给模型,Claude Code的每轮上下文都比Pi胖出一大截,十五轮下来,累积的token差距就变成了账单上实实在在的美元差距。

研究团队算了一笔总账,在SWE-bench Lite测试中,Claude Code的平均花费是Pi的两倍,是Codex CLI的一点六倍,在Terminal-Bench 2.0测试中,Claude Code的花费是Pi的一点五倍,而成功率的波动范围在SWE-bench Lite上不超过正负两个百分点,在Terminal-Bench 2.0上不超过正负五个百分点,你多花的钱几乎没有买到任何额外的成功率!

这笔多出来的钱,研究团队给它起了一个名字,叫调度壳税(Harness Tax),就像你打车时司机绕路多收的那段里程费,你到达了同一个目的地,但走了一条更贵的路,而且你很可能根本不知道自己被绕了路,因为你只看到了最终的成功率,没有拆开账单看每一轮的token消耗。

四个工具干翻几十个,小壳反杀大壳

Pi这个调度壳到底做了什么,能让它用不到两千token的初始上下文就追平那些塞了七万token的大壳,答案简单到让人不敢相信:Pi只给模型提供了四个工具,读文件、写文件、编辑文件、执行命令行,就这四个,没有任何花哨的网页搜索、代码索引、智能补全之类的附加功能。

这直接挑战了一个根深蒂固的行业直觉,大家一直觉得工具越多越好,功能越丰富越强大,Claude Code和Codex CLI都内置了十几个甚至几十个专用工具,每个工具都有详细的参数说明和使用规范,这些工具定义本身就占了上下文的大头,但实验数据表明,模型靠最基础的四个工具就能完成绝大多数编程任务,多出来的工具并没有显著提高成功率,反而因为占用了大量上下文窗口而推高了成本。

研究团队画了一张成本-成功率曲线图,横轴是每次尝试的花费,纵轴是累积成功率,他们把所有尝试按花费从低到高排列,然后逐步累加,画出一条帕累托前沿(Pareto frontier),帕累托前沿的意思是,在每一个花费水平上,你能达到的最高成功率是多少,结果Pi频繁出现在这条前沿线上,意味着在同样的预算下,Pi能帮你解出最多的题,而Claude Code虽然也出现在前沿线上,但它的位置明显更靠右,也就是更贵。

这里有一个非常反直觉的细节,Claude Fable 5在Claude Code和Pi里平均都用了大约十五轮对话完成任务,轮数几乎一样,但Claude Code每轮的花费是Pi的两倍,这说明问题不在模型思考了多少步,而在每一步的"行李"有多重,Claude Code让模型背着三十多倍的行李跑了同样的步数,体力消耗自然翻倍。

这就引出了一个更深层的问题,如果四个工具就够用,那那些复杂调度壳里多出来的功能到底在给谁服务,研究团队给出了一个谨慎的推测,丰富的工具可能在某些极端场景下有用,比如需要跨多个代码仓库搜索、需要访问外部文档、需要处理超长上下文的任务,但对于日常编程任务,这些附加功能更像是一个过度包装的礼盒,盒子比礼物还贵!

亲儿子不如外人,原生配对翻车了

行业内还有一个流传很广的假设,每家公司的大模型肯定跟自家的调度壳配合得最好,因为模型在训练阶段就会针对自家环境做优化,OpenAI甚至在官方文档里明确说过,GPT-5-Codex专门为Codex环境中的软件工程任务做过优化,按这个逻辑,Claude模型应该在Claude Code里表现最强,GPT模型应该在Codex CLI里表现最强,对吧!

实验数据把这个假设撕得粉碎,研究团队把六个Anthropic和OpenAI的模型在两个基准测试上的表现逐一拆开对比,一共十二组比较,结果在九组里,表现最好的搭配竟然不是原生配对,而是跨公司的混搭,Claude Sonnet 4.6在Codex CLI里做对了68.9%的题,在自家Claude Code里反而只做了66.7%,GPT-5.6 Sol在Pi里做对了83.3%的题,在自家Codex CLI里只做了78.9%,而且后者的花费还是前者的将近两倍。

这意味着大模型的能力具有很强的通用性,它并不像一把只能插进特定锁孔的钥匙,而更像一把万能钥匙,能在不同的调度壳里都发挥出接近的水平,调度壳对模型的限制远没有大家想象的那么大,真正决定成败的还是模型本身的推理能力,调度壳只是一个传递信息的管道,管道粗一点细一点,水流的速度差不多,但粗管道的维护费贵得多。

这个发现对普通用户来说有一个非常实际的意义,你不需要被品牌绑定,你不需要因为用了Claude模型就必须买Claude Code的账,也不需要因为用了GPT就必须待在Codex CLI里,你完全可以像换手机壳一样换调度壳,挑一个又便宜又好用的,把省下来的钱花在调用更多次模型上,反而能提高整体成功率。

但是这里有一个必须说清楚的边界,这些结论来自两个公开的基准测试,SWE-bench Lite和Terminal-Bench 2.0的题目都是开源的,模型在训练阶段很可能已经见过类似的题目,在真实的、模型从未见过的私有代码库上,复杂调度壳的附加工具可能会发挥更大的作用,伯克利团队自己也承认,结论的适用范围目前还局限在这两个测试集上!

你正在交的隐形税,怎么砍掉

现在你已经知道了调度壳税的存在,下一步就是搞清楚怎么在自己的工作流里砍掉这笔冤枉钱,研究团队的数据指向了三个具体的操作方向。

第一步,拆开你的调度壳看第一通电话的上下文大小,如果你用的是Claude Code或者类似的重量级调度壳,打开它的系统提示词和工具定义,数一下字符数,如果超过了一万字符,你就已经在为大量模型根本用不上的指令付费了,你可以尝试把工具定义精简到读、写、编辑、执行命令行这四个核心操作,观察成功率是否真的会下降,研究数据告诉你大概率不会!

第二步,同一个模型至少跑两个不同的调度壳做对比,不要只看成功率,一定要把每次尝试的token消耗拉出来算单价,你可能会发现那个成功率低了两个百分点的壳,每次尝试的成本只有原来的一半,算下来同样的预算你能多跑一倍的尝试次数,总体成功率反而更高,这笔账很多人从来没有算过!

第三步,把调度壳的复杂度当成一个需要根据任务难度动态调整的变量,日常改bug、写单元测试、做代码审查这类任务,极简壳完全够用,只有当你面对跨仓库重构、长链路调试、需要大量外部知识检索的复杂任务时,才值得启用那些带十几个专用工具的重型壳,研究团队在结尾留下了一个悬而未决的问题,他们发现即使是同一个调度壳,在不同任务上的token消耗波动也能达到十倍以上,这暗示着真正的终极方案可能是一个能根据任务难度自动膨胀或收缩的自适应调度壳,但目前还没有人做出来!