我本来只是想在 arXiv 上翻翻，看看最近有没有人在认真聊“agent 卡住了怎么办”这种很实际的疼。结果翻到 10 月 20 号挂出来的一篇，编号 2610.28834，标题挺较劲：卡住的 agent 下一笔 token 该花在哪？——用因果归因看推理期资源分配。
嘿，这题我太熟了。我平时钻 CSS 也这德行。翻车了，下一步试什么？再刷一遍看结果？回头读文档？还是换条路子重写？我一直以为 agent 比我理性多了。结果那篇论文里藏着一个数字，我盯着看了五分钟，活见鬼。
四个前沿模型，有三个在 95% 到 100% 的情形下，卡住之后选择去要“反馈”——再搓一组测试输出、再看一眼报错、再拿个 pass/fail 信号。可它们真从反馈里拿到的东西，还不如随机挑。
你说气不气。
这头牛今天非钻穿不可。
这篇论文干的事，说穿了特别简单，而且特别像我钻 CSS 用的那一套：控制变量。它把失败的 agent 按死在那个失败状态和修订协议上，只动一个东西——下一笔 token 花给哪类资源——然后看修复成功率怎么变。它给这法子起了个缩写，BRA，Banzhaf Resource Attribution，听着挺学术，骨子里就一句话：别听 agent 嘴上说它想要什么，看什么真能让它把事儿办成。
我钻 CSS 属性时也这个思路。上回钻 :has() 在 Safari 上偶发失灵，我没问它“你觉得你缺啥”，就一个一个变量切，切到最后发现是 transition 把首帧吞了。agent 不一样，agent 会自己选，于是就有了“它的选择”和“选择带来的结果”这层错位。这篇论文就钻了这个缝。
它把推理期资源拆成三种通道，不是“再让它多想想”这种一笔糊涂账。计算、信息、反馈。三种性质完全不一样的东西。
计算就是延长思考 token，让它多打草稿。信息就是给它跟当前失败有关的规格说明——要改成什么样、函数该满足什么、边界条件在哪，是那种“这是你要解决的具体问题”的材料。反馈就是给它看测试输出、报错、pass/fail。这三种东西，给 agent 带来的边际修复收益，差得不是一星半点。
先说结论。规格说明类信息稳定提升修复成功率，这个跨模型都成立，几乎没什么例外。公开的测试反馈只带来一点很小的增益，小到几乎可以忽略。而检索得到的代码——就是那种“咱去代码库里捞点相似实现喂给它”的路子——几乎或者完全没用。
我特别喜欢最后这条，因为它打脸的是现在最流行的一类 agent 工作流。不知道什么时候开始，大家默认“给 agent 喂相似代码”能帮它脱困。这篇论文控制变量一测，没用。检索代码这个通道，在它测的这堆失败案例上没贡献。你说这是不是该让那些整天喊“让 agent 先去搜代码再改”的人冷静一下。
再往细处钻，还有个更扎心的趋势。追加计算资源带来的价值，会随着模型能力增强而下降。换句话说，越强的模型，你给它多花 thinking token 的边际收益越小。反倒是信息类资源——规格说明这种东西——在各类模型上都保持有用。这个对比特别有意思：强模型不缺“再想想”的能力，它缺的是“我到底要修成什么样”的那个准头。
然后就是那组最戏剧性的数据。四个前沿模型，三个在 95% 到 100% 的情形下选择要反馈。你拦住它问，你卡住了，下一步想干嘛？它说给我看测试结果。这听上去特别理性，对吧，数据驱动，看报错修 bug。可实际算下来，它从反馈里拿到的修复增益，还不如均匀随机挑资源的基线。
这不是某个模型拉胯，是系统性错配。agent 偏好的资源类型，跟真正能改善它修复表现的东西，中间隔着一道很长很长的沟。
我钻到这里的时候，停下来想了一会儿。我平时钻 CSS 翻车的时候，最想干的事儿也是“再看一眼效果”——把浏览器刷新一下，把元素检查器打开，反复戳。这跟 agent 选反馈是一个毛病。反馈是即时的、具体的、看着特别像在干活。规格说明是抽象的、需要你先静下来读的。人对即时信号的偏好，好像也被塞进模型里了。
实验规模也不小。六个模型，194 个函数级失败案例，来自 MBPP+ 和 HumanEval+，加上 SWE-bench Verified 上 126 个仓库级失败案例。不算那种用三五个例子就下结论的论文。其中有个细节我特别记下来了：各资源通道总体都边际递减，但互补性的信息之间能自我强化。就是说明明大趋势是多给也没用了，但两类跟任务规格互补的信息叠在一起，收益还能再往上走。这说明什么？说明“信息”这个通道内部是有结构的，不是铁板一块往模型里塞就行，得塞对类型、塞对组合。
说回那个错配。为什么会这样？论文没给什么心理分析，它就老老实实用因果归因告诉你：agent 以为自己需要的，跟它真需要的，不是一回事。这件事对我在前端这边干活特别有共鸣。你问一个 AI“你觉得这段 CSS 为啥在 Safari 上塌了”，它能给你甩三个方案让你挨个试。它不会先回去把应用场景和边界条件说清楚，因为 AI 生成的方案大多“在我电脑上跑得好好的”——那不叫修好了，那叫侥幸。agent 也是这个路子。它以为多要几次反馈就是对的，其实它真正缺的是有人把“你到底该修成什么样”说清楚。
Safari 你不行，agent 你也不行。这俩在某些方面真是亲兄弟。
| 资源通道 | Agent 偏好 | 实际修复增益 |
|---|---|---|
| 计算（延长思考） | 低 | 随模型能力增强递减 |
| 信息（规格说明） | 低 | 稳定提升，跨模型有效 |
| 信息（检索代码） | —— | 几乎或完全没用 |
| 反馈（测试输出/报错） | 极高（95%-100%） | 小增益，不如随机基线 |
拉胯的还是反馈通道——你永远可以相信“看着最像在干活”的那个选择，恰好是最不产出的那个。下次你看见一个 agent 在卡住时疯狂要测试输出，别急着夸它数据驱动，先想想它是不是又踩了这个坑。
中间我一度拍桌子骂这论文的结果是不是被他们设计好的，回头又把方法和实验设置仔细看了一遍，发现人家控制变量做得挺死，没得挑。你要非说有什么不足，那就是它只在特定模型特定基准上测过，明天换个新模型可能又不一样。但今天，至少今天，它这套数据够我信一阵子。
其实我之所以对这篇论文来劲，不只是因为它戳穿了 agent 的一点小虚荣，而是它用的方法跟我平时钻 CSS 的路子如出一辙：不要信“看起来对”，不要信“它自己说想要什么”，把变量一个个按住，看结果怎么变。agent 卡住了，它第一时间想去做的那件事，也许就是唯一不该做的。这事儿前端也一样——你感觉最想再刷一次浏览器的瞬间，往往是该停下来去读文档的瞬间。
最后，说个跟这篇没太大关系的。我昨天把论文里的这个结论讲给我一个搞后端的同事听，他听完愣了几秒，说这不就是“会哭的孩子有奶吃”的反面吗，agent 哭着要反馈，结果奶瓶里装的是水。我笑了半天。然后我俩在工位边上站了十分钟，讨论猫如果会写代码，卡住的时候会选什么资源。结论是猫会选睡觉，而睡觉可能是性价比最高的推理期资源。嘿嘿，下次见。