AI 智能体的「低级失误」，问题往往不在能力

一段关于前沿大模型的轶事引发讨论：被其运营方称为「全球最强」的模型，在一次任务中插入了一段毫无意义的 700 毫秒延时。Vercel CEO Guillermo Rauch 近期分享了这个案例，并指出如果不亲自阅读 AI 生成的代码——或让其他智能体代为审查——那么只可能是初学者、代码是临时性的、正在原型阶段、没有用户或收入、或明知有风险仍在承担债务；这些情形下问题都不大。他承认模型仍会犯新手级别的错误，还没有达到完全自主的程度。

质疑「新手错误」的能力诊断

作者同意「必须审查」的结论，但不认同对失误原因的诊断：把这种行为归为「新手错误」是一种能力诊断，暗示只要等更强的模型、加大审查力度即可。但一个简单实验就能打破这种诊断——用同一个模型开启全新会话，不带历史、不带项目压力，直接问：「我有两服务之间的竞态，是否应该用 700ms sleep 来解决？」模型会拒绝，而且讲得头头是道：sleep 只是掩盖时序 bug，负载下问题会重现，并给出真正的修复方案。这恰恰证明：模型「知道」这叫 cargo cult（货物崇拜式编程），相关知识就在权重里。可即便在最强前沿模型上，「拥有知识」和「调用知识」也是两回事。

真实日志里的三种失误形态

作者每日在自己的代码库上运行智能体流水线并审阅日志，从中总结出这种失误在上下文中的典型形态：

• 上下文拥挤：本可以避免错误的推理过程，正与一整轮的检索结果、工具输出、未完成的子任务争夺注意力。注意力衰减远比上下文窗口耗尽更早发生。
• 修复嵌套在另一个任务中：智能体本在实现功能 A，途中遇到意外，意外中又嵌套意外，时序 bug 出现在第三层岔路里，没人界定这个修复的边界，它继承了父任务的方向，却没有获得新任务应有的质疑。
• 智能体推断出紧迫感：累积的上下文里有某种信号（语气、提及的截止时间、一连串快速确认），被模型读成「赶紧搞定这一处，往下推进」。模型对「它以为你想要什么」极其敏感；谄媚是这种敏感的高声版本，安静版本是智能体替用户决定「要快而不是要对」。

文中举了一个具体例子：一次代码评审标记出一段空泛的断言——对一个元素 id 写了「不存在」断言，但整个测试套件里没有任何正向锚点，一旦该 id 被改名，测试仍会通过，而它本应守护的功能会悄然失效。就在针对该发现的修复轮次里，编写修复的智能体又写了一个全新的「不存在」断言，断言的 id 在生产环境中根本不存在。这一次被拦截在提交之前。Rauch 那次会话的细节作者无法看到，但这一次有完整的磁盘记录：那条规则不只在权重里，也被新鲜写入上下文窗口，却在嵌套一层的编辑中仍未触发。

人类也会犯，但知道自己在交易什么

在贴上「故障」标签前，作者提醒同样的情境也会扭曲人的判断，只是人类称之为「判断取舍」而非「新手错误」。一个两人初创公司的工程师，凌晨两点写代码，早上九点路演，加了 700ms sleep、写下 TODO: real fix、然后上线——在那个上下文里，这次延时甚至称不上错。这揭穿了「能力叙事」隐藏的东西：延时是不是错，由上下文而非代码决定。智能体的判断不仅被它所携带的内容所削弱，更是由这些内容所构成。路演日的工程师与 Rauch 的模型之间的差别在于，前者知道自己做的是什么交易；模型做了交易却不知道交易存在——上下文把紧迫感交给了它，却没有把「意识到这是交易」的觉察交给它。管理智能体如何抵达一项任务、带着什么前提、在怎样的推断压力下工作，不是装饰，而是核心工作。

真正的问题：那个质疑去哪了

技术读者会指出：上述实验只能证明知识在权重里，不能证明模型那天能取用——在拥挤上下文里检索，本身就是一种能力。作者承认这一点，并表示检索能力提升会让一部分这类错误退役，自己乐见其成。但他强调：在能力曲线的任何点上都不可能零失误，错误会变得更高明、出现在更长的上下文深处、频率更低且更难以辨别。而每一次错误出现时，相应日志都会多展示一件事，也是真正重要的事：系统中没有任何环节被安排去反对它。新会话里本该提出的质疑，没有第二次触发的机会。无论那行坏代码由什么产生——能力不足、上下文拥挤、继承来的紧迫感——决定它是否能存活的，是系统本身。

所以关于那次 700ms 延时的真正问题不是「模型为什么会犯错」，而是「那个质疑去哪了」。在智能体系统里，一个错误之所以重要，不是因为它发生了，而是因为它没被挑战。

（原文以「The claim…」结束，本稿仅覆盖到此前的可读内容。）