速评：11月1日挂上 arXiv 的那篇 BOBA，56页、12幅图、44张表，标题直接把结论写在脸上——编码 agent 不能撒手不管。说得客气了。我看完的第一反应是：它针对的根本不是模型能力，而是这行当里所有人默认的那条“测试过了就算完”。
先把数字摆出来。同样10个 agent，请求一条一条独立处理，平均完成率约95%；同样的请求串成链，每条链20个前后相接的请求，取自140个真实开源项目，一共280条链，完成率掉到51%。44个点的落差，不是模型突然变笨——论文自己讲了，agent 写出来的代码质量接近人类，当下一条请求的基础完全够用。
问题出在没人发现的那个错上。
agent 判断自己干完活的标准是“我的测试过了”。测试过了等于做对了，这条等式在这个圈子里被当公理用了两年。但测试会漏。漏掉的那个错不会自己蒸发，它就躺在那儿当基础，下一条请求踩上去，失败概率翻倍——论文给的数是正常情况下的大约两倍。而且这些早期埋下的问题，后面几乎没有 agent 会回头重新发现。
这里插一句跑题的。这两年我见过太多团队拿“多个 agent 互相 review”当质量保障，架构图画得像开会一样，一个写、一个审、一个定稿。这篇论文把这个假设也一起拆掉了：让 agent 去判断某个实现到底对不对，准确率约53%。随机猜是50%。多出来那三个点，大概够付一下 token 钱，不够付一次事故。
这种“agent 审 agent”的做法，眼熟。它成立的前提是审查者拥有独立于产出者的判断力，而论文测出来的结果是两边共享同一套盲区。它们不是不认真，是根本不知道自己在看什么。
有意思的是后面那组。在失败请求后面补一次外部否定反馈、安排一轮修复，链式完成率从51%提到59%。八个点，不算多，但方向很清楚：被挑出来修掉的错误，之后就不再明显拖累后续请求了。也就是说，这些 agent 缺的从来不是写代码的手，是缺一个在它们说“过了”的时候能说“没过”的东西。
这才是真正扎人的地方。论文没在说模型不行，它在说这套东西的验证回路是断的。而现在行业的力气花在哪？更长的 context window、更强的单点能力、更复杂的 agent 编排。全在提高产出能力。产出能力早就够用了——95%那个数就在那儿摆着。
至于这个95%，我打个问号。不是怀疑论文，是怀疑它被读的方式。单点任务的分数这几年一路往上走，太多人拿它当“agent 能自己干完一个项目”的证据。这篇等于把评测方法的底给掀了：你测的是每一步会不会写，人家问的是二十步连着走会不会塌。前者95，后者51，差的不是能力，是评测维度选错了。拿前者论证后者，不是乐观，是没读题。
当然得让步。10个 agent、280条链、请求全部取自开源项目，这套设置离那种需求三天一变、文档比代码还旧的真实项目还有距离；51%到59%也只是补了一次外部反馈，离能撒手差得远。论文是论文，不是产品评测，我不觉得它能证明你手上那个具体工具不行。
但它证明的是更基础的一件事：把“测试通过”当完成信号，在单步任务里是效率，在链式任务里是会 compounding 的债。这笔债不在第一次体现，在第二十次。完成率的暴跌从来不是发生在最难的那一步，而是发生在所有“应该没问题”的步骤堆起来之后。
这里立个 flag。接下来半年，如果 agent 这条赛道真有一次方向调整，我猜不会出现在模型参数上，会出现在“谁来验证”上——要么把人放回回路里但换个位置，要么长出一层独立于产出者的验证。至于现在这套“它自己说过了就算过”的流程，我不觉得能撑到明年这个时候还被当成默认。
反过来问一句：全网都在算 agent 什么时候能独立交付一个完整项目，有几个人算过，它第一次说“过了”而其实没过的时候，你这边有没有东西能拦住。