AI研究员聊天到没电：几十万次对话后为何原地打转？

这种人你见过没有。

聊天到了后半程，十分钟前聊的正事他早忘了，脑子里全是刚才那句玩笑，或者反复琢磨自己三句话前说错的一个细节。话越多，他脑子越乱。

把这个角色换成帮你做科研的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的上下文信息越来越多时，它的表现反而会下降，这种现象有个专门名字叫“上下文腐化”（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却是失忆的，它看到的永远是为它单独定做的那一份。

SLA框架怎么运转？论文里设了两个角色。

顾问（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跑到2.5亿token时为1501.7，跑满10亿token降到1275.7，追平最强基线最终成绩花了9.863亿token。

SLA在2.5亿token时是1149.3，10亿token时是1112.0，追平只需6790万token。

这组数字意味着什么？SLA花掉6790万token，就达到了SwarmResearch消耗9.863亿token才拿到的水平，算力省下93.1%。三次独立运行中，SLA最差的一回跑出1122周期，仍好于所有基线方法里最好的一次——1191周期。

换个场景，FrontierSWE这个长周期软件工程基准测试包含四个具体任务，例如把C语言库libexpat转成x86-64汇编代码、用Zig语言重写Git的部分功能。这里出现了一个颇耐人寻味的现象。

预算消耗到25%、也就是1.75亿token时，四个任务上SLA全都落后于当时表现最好的基线方法。等预算用满7亿token，四个任务上SLA又全都翻了过来。

具体到分数：libexpat任务，SLA在25%预算时拿到18.82，比最强基线低0.85分；预算用满后升至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：这是斯坦福大学等机构提出的自动化科研框架。它的做法是让干活的AI智能体每回都从零起步、不带对话历史，所有研究进展由系统统一存管，每次调用时再现场拼装定制信息，长对话拖累AI表现的问题就这样绕开了。

Q2：跟其他自动化研究框架比，SLA效果怎样？

A：在Anthropic内核优化任务上，SLA耗6790万token就追平了基线方法花9.863亿token才拿到的成绩，算力省下93.1%，并且所有测试任务上最终都拿到最好成绩。

Q3：论文为何强调评估AI研究系统要用更长时间？

A：原因在于论文发现了“排名反转”：预算用到25%时SLA还落后于其他方法，预算用满后却全面反超。只看短期表现，结论可能完全相反。