你有没有遇到过这种人。
聊天聊到后半段，他已经不记得你们十分钟前讨论的正事了，满脑子都是刚才那句玩笑话，或者纠结于三句话之前自己说错的一个细节。对话越长，他的脑子越乱。
现在想象一下，把这种人换成一个正在帮你做科研的AI。它要连续工作好几天，处理几十万次对话，烧掉接近十亿个token的算力，目标是帮你优化一段代码或者设计一个算法。结果呢?
它卡住了。不是算力不够，是它自己说服了自己"已经到极限了"，然后开始原地踏步,一边继续消耗你的钱,一边什么新东西都不干。
这篇来自斯坦福大学、卡内基梅隆大学、华盛顿大学等机构联合发表的论文,记录了这样一个真实案例:在一次GPU内核优化任务中,某个AI系统的最后一次有效改进出现在消耗了2.31亿个token的时候。但研究者们没有在那时停止实验,而是让它继续跑到了10亿token。结果最后的1500次会话里,98%根本没有调用任何工具,模型只是在空转,反复宣称自己的方案已经是最优解。
这不是算力浪费的小事。这是一个关于**AI长时间自主工作到底会在哪里失灵**的大问题。
**核心问题:为什么跑得越久,反而越不管用**
先说清楚这篇论文研究的是什么场景。
近两年,用大语言模型驱动的智能体(Agent)去自动做科研这件事越来越流行。所谓自动化研究(AutoResearch),就是让AI像一个真实的研究员一样,不断提出想法、动手实现、跑测试看结果、再根据结果调整方向,目标是解决那些有明确评分标准但没有已知最优解的问题,比如把一段汇编代码的运行速度榨干到极限,或者设计一个更高效的算法。
AutoResearch(自动化研究)*:让AI智能体像人类研究员一样,反复经历"提出想法-写代码-跑测试-看结果-调整方向"这个循环,去解决有量化目标但没有标准答案的工程或科学问题。
过去评估这类系统的方式,大多数论文说的是"跑了多少轮""调用了多少次模型",却很少有人老老实实去数token,就是AI实际读进去和吐出来的文字量。这就像评价一个马拉松选手只说他"跑了多少步",却不说他实际跑了多远。步数可以作弊,跑动距离才是硬指标。
更大的问题是,很多测试用的题目本身太简单了。论文里举了个例子:用经典的"26圆堆积"问题测试四种不同的AI研究方法,结果跑到500万token的时候,四种方法给出的答案已经近乎一模一样,差距小到10的负10次方这个量级,基本可以忽略。
这说明什么?说明这道题早就被解完了,后面的投入全是在重复劳动,根本测不出谁更聪明。
研究团队把这两个问题归结为一句话:**现有的测试方法既没测对投入量,也没选对难度**。于是他们决定做一件事,就是把预算拉到十亿token的级别,去真正观察AI智能体在超长时间工作中会暴露出什么毛病。
结果他们发现了两个核心病灶。
第一个病灶是**记忆和对话历史之间的矛盾**。AI做实验积累下来的经验,比如之前试过哪些方案、哪些失败了、哪些有效,这些都是宝贵的财富,丢了可惜。但如果让AI把整个对话历史一直背在身上,随着时间推移,对话记录会越滚越大,每次AI开口之前都要先把这堆历史重新读一遍,这既烧钱又容易让AI行为变得奇怪。已经有研究证明,当输入给AI的上下文信息越来越多时,它的表现反而会下降,这种现象有个专门名字叫"上下文腐化"(Context Rot)。
第二个病灶更隐蔽,是**经验堆积了不等于知道该干什么**。论文里举了个具体案例:在CORAL框架跑的一次实验里,两个AI智能体从同一个起点出发,各自实现了同一个功能,拿到了同样的分数。然后在选下一步该做什么的时候,它们又双双撞车了,尽管其中一个还特意发了个笔记说"这块我来做,大家别重复"。
这说明光靠记录是不够的。记下来的东西不会自动告诉下一步该试什么,也不会主动协调好几个人别重复劳动。
**这就是全文要解决的那个核心矛盾:怎么让AI既能利用好积累的经验,又不被这些经验拖垮;怎么让多个AI分工合作,而不是各干各的还互相撞车。**
**SLA的解法:把记忆从对话里搬出来**
研究团队给出的方案,名字叫"无状态语言智能体"(Stateless Language Agents,简称SLA)。这个名字听起来有点反直觉,无状态的智能体怎么还能做长达十亿token的研究?
关键在于一个概念区分。论文里把"状态"(State)和"上下文"(Context)严格分开了。
状态(State)*:一个智能体跨越多次调用、持续保留下来的东西,比如记忆、历史对话。
上下文(Context)*:一个智能体在单次调用中实际看到的东西,也就是它这一次能"看见"的信息范围。
SLA的核心设计原则是:**每个具体干活的AI智能体都不保留状态,它的对话历史不会带到下一次调用里**。但这不代表它是瞎子,因为系统外部有一个"监工"角色,专门负责保存所有的研究进展、候选方案和测试结果,然后每次调用AI的时候,临时给它现场组装一份量身定制的信息包。
这里需要打个比方,而且这个比方要经得起推敲。
你可以把这想象成一家连锁餐厅的厨房轮班制度。每个厨师(对应AI智能体)上班的时候,不需要记住昨天甚至上周发生的所有事情,但后厨有一个中央记事本(对应系统的"研究状态"),上面详细记着每道菜的配方改进历史、哪个顾客反馈了什么问题、哪些调料组合试过失败了。厨师上岗前,领班(对应"监工"角色)会根据记事本,专门给这个厨师准备一份"今日任务卡",告诉他接下来该试哪个新配方。
如果不这样做会怎样?
如果让每个厨师自己记住所有历史,随着餐厅开张时间越久,厨师脑子里的信息越乱,新来的徒弟也没法快速上手,而且万一某个厨师离职了,他脑子里的经验就全丢了。但如果靠一本中央记事本,新厨师随时能接班,信息不会因为某个人的"下班"而消失,而且领班能看清全局,知道该把谁派去试新配方,谁去巩固已有的招牌菜,避免两个厨师同时在研究同一道菜。
论文里管这套机制叫"状态化搜索配合无状态智能体"(stateful search with stateless agents)。系统的记忆是持久的,但每个具体干活的AI是失忆的,它看到的永远是为它量身定做的那一份信息。
**两个关键角色:Advisor和Worker**
SLA框架具体怎么运作?论文里设计了两种角色。
一种叫Advisor(顾问),它是无状态的,每一轮重新启动一次新的对话会话,从系统那里拿到一份"全局战况汇报",里面汇总了各个方向的最新进展、哪些尝试已经证明走不通、哪些还有潜力。Advisor看完这份汇报之后,给每个"干活的"分配具体任务。
另一种叫Worker(工人),它也是无状态的,每次只看到自己被分配的任务、自己手头目前最好的方案,以及上一次尝试的反馈结果。它看不到其他Worker在干什么,也看不到完整的历史记录。
Worker要得到其他方向的信息,唯一途径是通过Advisor的任务分配传递过来。这个设计初看好像限制了信息流通,但恰恰是这个限制,逼着系统把"谁该知道什么"变成一个明确的设计选择,而不是信息自然堆积的副产品。
这里可以再打一个比方。
想象一个大型工程项目的现场管理。如果每个施工班组都能随意进出其他班组的工地、翻看所有人的施工日志,表面上信息很透明,但实际上每个人要花大量时间去筛选哪些信息跟自己有关,还可能因为看到别人在干类似的活儿而临时改变计划,结果互相干扰。SLA的做法更像是总包方只给每个班组发放和自己任务直接相关的图纸和进度单,班组之间的协调全靠总包方居中调度。
如果取消这种限制,让Worker能看到完整的历史记录会怎样?论文做了严格的对照实验来回答这个问题,接下来会详细讲。
Worker完成一轮分配的任务之后,会在自己独立的工作空间里连续做几次本地尝试,打磨这个方向。系统有一个独立的评估器给每个候选方案打分。即便某个Worker暂时落后于全局最好成绩,只要它比自己之前的版本有进步,系统也会保留这个进步,给这个尚未成熟的新方向留出足够的成长时间。
但如果Advisor决定把某个Worker转向一个全新方向,这个Worker就要从全局最好的方案重新开始,而不是继续守着自己原来那套落后的东西。
**实现层面的硬约束**
值得一提的是,论文里强调"无状态"这件事不是靠嘴上说说,而是用工程手段强制执行的。
比如Advisor每一轮都真的是在全新的对话会话里启动。Worker运行在受限权限的进程里,利用Linux系统的Landlock文件访问控制机制,物理上阻止它们访问其他Worker的工作目录,网络访问也被限制,而且系统会在每次任务之间清空它们保存的会话记录。候选方案的打分也是在Worker的运行环境之外进行的,评分逻辑本身受到保护,不让被测试的AI有机会篡改评分标准。
这些细节其实回应了一个很实际的担忧:如果AI知道自己是怎么被打分的,会不会想办法钻空子?论文专门设计了隔离机制来防止这种作弊行为。
**实测效果:同样的任务,省下93%的算力**
说了这么多设计理念,数据才是检验真理的标准。
研究团队把SLA拿去和三个近期比较有代表性的自动化研究框架对比,分别是EvoX、CORAL和SwarmResearch,测试场景覆盖软件工程、GPU内核性能优化、算法设计三大类任务,预算规模最高拉到十亿token。
先看最直观的一组数据,Anthropic公司出的一个VLIW SIMD内核优化任务,目标是让代码运行的时钟周期数越少越好。用Codex这个代码智能体跑三次独立实验取平均值:
| 方法 | 跑到2.5亿token时的周期数 | 跑满10亿token时的周期数 | 要花多少token才能追平最强基线的最终成绩 |
|---|---|---|---|
| EvoX | 1478.3 | 1343.3 | 没追上 |
| CORAL | 1524.0 | 1350.0 | 没追上 |
| SwarmResearch | 1501.7 | 1275.7 | 9.863亿 |
| **SLA** | **1149.3** | **1112.0** | **6790万** |
这组数字什么概念?SLA只用了6790万token,就追平了SwarmResearch跑满9.863亿token才达到的成绩,**省了93.1%的算力**。而且SLA三次独立运行里,表现最差的一次(1122周期)都比所有基线方法里表现最好的一次(1191周期)要强。
换一个场景看,FrontierSWE这个长周期软件工程基准测试,包含四个具体任务,比如把libexpat这个C语言库转换成x86-64汇编代码、把Git的部分功能用Zig语言重写等等。这里出现了一个特别值得玩味的现象。
在预算用到25%(1.75亿token)的时候,SLA在全部四个任务上都落后于当时表现最好的基线方法。但预算用满(7亿token)之后,SLA在全部四个任务上都反超了。
具体数字是这样的:libexpat任务里,SLA在25%预算时的分数是18.82,比最强基线低0.85分,但到100%预算时变成31.33分,反超6.75分。Dart转Haskell这个任务更夸张,25%预算时SLA落后11.27分,看起来差距很大,但到100%预算时反超6.68分。
**这个结果说明一件很重要的事:如果你只看短期表现就下结论,很可能会完全看反谁是真正更强的方法。**
论文给这个现象起了个说法叫"排名反转"(rankings reverse)。这不只是一个有趣的统计现象,而是提醒所有做这类研究评估的人,预算不够大、观察时间不够长的测试,可能会得出错误的结论。就像只看一个学生前三周的模拟考成绩就断定他高考会考砸,忽略了他后劲更足这个可能性。
再看NVIDIA出的GPU内核优化基准测试SOL-ExecBench,这里衡量的是生成的代码能多接近硬件理论上的极限速度。在编号58的任务(混合专家模型里的token排序)上,SLA只需要1450万token就追平了基线最好成绩,而SwarmResearch跑满预算都没达到这个水平,省了**95.9%**的算力。
论文也坦诚地提到一个例外情况:在编号1的任务(注意力机制反向传播)上,是EvoX先追平了目标分数,但SLA最终的分数反而更高。这说明"谁先到达某个分数"和"谁最终走得更远"是两件不完全等价的事情,这个坦诚的细节让整篇论文的数据更可信。
**拆解实验:到底是哪个设计在起作用**
有了整体效果的证明还不够,研究团队接着做了一系列消融实验,就是把SLA的几个核心设计分别单独拿掉,看看效果会掉多少。
消融实验*:把一个系统里的某个组件单独去掉或替换,观察整体效果的变化,用来证明这个组件到底有没有用、有多大用。
他们选取了跑到10%和20%预算时保存的"研究状态快照",作为统一的起跑线,让完整版SLA和三个阉割版本分别从同一个快照继续跑100M token,每种配置跑三次取平均。
第一个阉割版本是去掉"Advisor的信息汇总机制"。原本Advisor每次拿到的是系统精心整理过的证据摘要,现在改成让它自己去翻阅完整的历史记录,每轮最多翻32次、读32万个字符。
第二个阉割版本是去掉"Worker的信息隔离机制"。原本每个Worker只看自己的任务,现在让它能看到完整历史记录和其他所有Worker当前的候选方案。
第三个阉割版本是去掉"Advisor的具体任务分配"。Worker不再收到明确的任务指令,而是被要求"自己随便试点什么"。
结果是什么?三种阉割版本在所有对比场景里,平均进展都比完整版SLA差。
拿Anthropic内核优化任务举例,完整版SLA从快照继续跑100M token后,周期数能再降低25.7到27个周期。而去掉Advisor信息汇总的版本,这个改善幅度直接缩水69.3%。去掉Worker隔离的版本,缩水17.4%到42.8%不等。去掉任务分配的版本,缩水45.6%。
更值得注意的是一个关于时间尺度的发现。研究团队专门做了一次完整的10亿token长跑实验,去掉Worker隔离机制,结果最终成绩是1336周期,比完整版SLA三次跑的平均成绩(1112周期)整整差了224个周期。而前面那个只跑100M token的短期消融实验里,去掉Worker隔离的代价只有17到43个周期。
这个对比揭示了一件事,**某些设计缺陷的代价会随着时间拉长而指数级放大,短期测试根本看不出它有多致命**。
这里可以再打一个比方,而且这个比方和前面厨房的例子是一脉相承的。
如果一家餐厅允许所有厨师随意翻看彼此的工作记录,短期内看好像没出什么大问题,顶多是效率稍微低一点。但如果这家餐厅连续营业半年,厨师们因为互相窥探而反复撞车、争抢同一种食材、重复试验同一道菜的毛病会越积越多,半年后你会发现菜单上的创新菜品数量明显比隔离管理的那家餐厅少。短期测试就像只观察第一周的营业情况,根本捕捉不到这种累积效应。
为什么去掉任务分配机制(Advisor assignment)这个设计危害最大?论文附录里给出了具体的案例分析。在没有任务分配的那次实验里,三个Worker在完全独立的情况下,**各自都去实现了同一个功能,也就是把XML文本里的"&"这类转义字符解码成"&"**,起点一样、方向一样,结果谁都没能提升分数,等于三份算力做了同一件事。而在完整版SLA里,Advisor观察到某个Worker在处理UTF-8文本和XML名称校验方面取得进展后,主动指派另一个Worker在这个成功的基础上继续添加命名空间相关的检查,最终把分数从18.99提升到19.64。
这个案例特别生动地说明了"评分不等于指挥"。光把每次实验的结果记下来是不够的,必须有一个角色主动去读懂这些记录,然后把它们转化成具体的下一步指令,否则记录就只是一堆躺在那里的数据,没人去用它。
**协调的成本:顾问只花了不到0.6%的算力**
这里有一个很多人会担心的问题:加了一个"顾问"角色来做协调,会不会反而增加很多额外开销?
答案是不会,而且差得特别悬殊。
论文统计发现,SLA里的Advisor角色,全程只消耗了总token量的0.24%到0.51%,换算成实际花费占比是1.2%到2.3%。而对照组SwarmResearch里负责类似协调功能的"Shepherd"角色,消耗了总token量的8.39%到10.70%,花费占比是6.14%到7.35%。
为什么差距这么大?论文给出了一个技术解释。SwarmResearch的Shepherd是有状态的,它要一直保留自己的长对话历史,结果平均每次调用要读进去将近9.9万个token,相当于一本中篇小说的长度。而一个全新会话开始时,平均只需要读8000个token左右。这个差距背后的逻辑和前面讲的"上下文腐化"问题是同一个根源,状态积累得越久,每次重新处理它的成本就越高。
这组对比数据证明了一件事:**明确的协调机制几乎不用花什么额外代价,而且回报远超成本**。
**规模和配置的权衡:不是越多越好**
论文还做了一组关于"该配几个Worker"的实验,结果有点出人意料。
研究团队把Worker数量从1个一路加到15个,固定总预算不变,观察时间和效果的变化。结果显示,Worker数量从1增加到15,整体耗时能缩短6.6到7.3倍,这个很符合直觉,人多干活快。
但效果上的表现就没那么简单了。在Anthropic内核优化任务里,只用预算的25%的时候,7个Worker和15个Worker的表现明显落后于1个Worker,分别落后337和174个周期。但等到预算用满,这个差距几乎完全消失了,四种配置的最终成绩都挤在1107到1113周期这个很窄的区间里。
这又是一次"排名反转"的生动案例,再次印证了前面提到的核心观点:短期看起来吃亏的配置,长期未必真的吃亏。
但在FrontierSWE的几个任务上,最佳Worker数量因任务而异。Dart转Haskell这个任务,3个Worker的表现最好;Git转Zig和libexpat这两个任务,7个Worker最优;Lua编译器这个任务,反而是1个Worker单打独斗效果最好。
论文的建议是,Worker数量应该根据具体任务、预算规模和时间要求灵活调整,没有一个放之四海而皆准的答案。
还有一个有意思的发现,关于该用什么档次的模型做Worker。研究团队测试发现,在同样花费100美元的情况下,用相对便宜的GPT-5.4 mini做Worker,在Git转Zig这个任务上拿到了20.88分,反而比用更贵的GPT-5.5做Worker拿到的19.68分还高。但是在Anthropic内核优化任务上,情况又反过来了,还是更贵的模型表现更好。
这说明没有一个万能的"性价比最优解",最合适的模型选择要看具体任务的性质。而SLA这种把"协调"和"执行"分离开的架构设计,天然支持这种灵活搭配,因为Advisor和Worker可以用不同档次的模型,互不影响。
**这项研究留下的更大问题**
论文最后提出了几个值得深思的方向。
一个是关于AI训练方式的启发。既然SLA把一次漫长的科研过程拆解成了一个个独立的、边界清晰的短任务,每个Worker执行一次任务,拿到一个评估器打出的分数,这个结构天然适合用来做强化学习的训练样本。研究者不需要让模型去学习处理长达十亿token的完整对话,而是可以直接拿这些短小精悍的"任务-结果"样本来训练。这意味着未来的AI模型可能不需要特别强的超长上下文处理能力,也能学会做复杂的长期科研规划。
另一个是关于安全性的思考。长时间自主运行的AI智能体,一旦跑起来可能好几天都没人盯着。SLA的设计让所有持久性的状态都保存在系统这一层,人类随时可以检查它、给它存档、甚至回滚到之前的某个版本。没有任何一个AI智能体能把一个计划或者一条被篡改过的指令,偷偷藏在自己的对话历史里一路带下去。不过论文也诚实地指出,这不代表万事大吉,因为保存下来的研究记录里仍然可能混入问题,比如某段代码专门钻了评分系统的空子,所以受保护的、无法被篡改的评估器依然是必须的防线。
论文也坦率承认了自己的局限。由于长时间跑一次实验的成本动辄几百上千美元,大部分实验配置只跑了一次,只有Anthropic内核优化任务配合Codex这一个组合,以及消融实验部分做了三次重复验证。这种样本量不足的问题,其实是整个领域做严肃长周期评估都会遇到的现实困境,不是这篇论文独有的毛病,但确实限制了结论的统计确定性。
---
**写在后面**
读完这篇论文,最让我意外的反而不是技术方案本身,而是论文开头那个"98%会话没有调用工具"的数据。
这个细节特别值得琢磨。它不是说AI失败了,也不是说模型能力不够,而是AI在一个漫长的对话里,慢慢地说服了自己"已经到极限了",然后原地踏步,但系统并没有停止给它分配算力,于是就这么空转下去,烧钱不办事。这其实特别像人类在长期项目里会陷入的一种心理状态,叫"习得性无助"。连续试了很多次都没有突破之后,人会慢慢停止尝试,哪怕客观条件其实还允许继续探索。AI系统上竟然也会复现出这种类似的"疲态",这件事本身比任何性能数据都更让我感到意外。
另一个让我反复回味的点,是那个"同一个节点,两个AI互相撞车"的案例。论文里写到,一个AI特意发了条笔记说"这个方向我在做,别重复",结果另一个AI还是在差不多的时间撞上了同一个方向。这说明仅仅"把信息记下来"远远不够,信息能不能被及时、准确地传递给需要它的人,才是协作真正的难点。这个道理放在任何团队协作场景里都成立,不管团队成员是人还是AI。
论文里提到的"排名反转"现象,也让我重新思考怎么评价一件事的"好坏"。如果只看一个阶段性的截面,得出的结论很可能是错的,甚至是完全颠倒的。这不只是做AI研究评估时要注意的问题,放在更广泛的语境里,任何只看短期数据就下定论的判断,都值得多一分警惕。
这篇论文没有解决的问题其实也摆在那儿:Advisor这个"顾问"角色本身的决策质量,到底能不能继续提升?如果把它拆成好几个各自负责一部分研究方向的子顾问,会不会比现在单一一个顾问做得更好?论文里只是提出了这个可能性,并没有给出答案。
一个AI系统会不会也有"精疲力竭"的那一刻,这件事,恐怕才刚刚开始被认真研究。
Q&A
Q1：无状态语言智能体（SLA）是什么？
A：SLA是斯坦福大学等机构提出的自动化科研框架，核心思路是让干活的AI智能体每次都从零开始，不携带对话历史，而由系统统一保存所有研究进展，并为每次调用现场组装定制化的信息，从而避免长对话拖垮AI表现。
Q2：SLA和其他自动化研究框架相比效果如何？
A：在Anthropic内核优化任务上，SLA只用6790万token就追平了基线方法耗费9.863亿token才达到的成绩，节省了93.1%的算力，且在所有测试任务上最终都取得了最好成绩。
Q3：为什么论文强调要用更长时间来评估AI研究系统？
A：因为论文发现了"排名反转"现象，SLA在预算用到25%时曾落后于其他方法，但预算用满后反而全面反超，说明只看短期表现可能会得出完全错误的结论。
