超越幻觉：AI Agent 的隐性失败模式

Agent 的失忆分类与递归成本漂移

2026 年 7 月 24 日更新：新增了 Cursor 在 SQLite 重写实验中发现的 3 种 Swarm 特有故障。

AI 会犯错，模型会产生幻觉，模型会编造内容——这些都是老生常谈的问题。然而，到了 Agent 工程实践中，这些说法几乎没有什么实际指导意义。知道模型会犯错之后，你又能怎么办？除了不信任任何输出，或者要求逐行复核所有内容，最终把生产力提升完全抵消掉之外，还能得到什么？

我经常使用 Agent 工具，也惊叹于它们在过去半年里的巨大进步。但与此同时，许多大型任务严重偏离常识和任务初衷，也常常让我恼火不已。

最近，在阅读大量有关 AI Agent 的资料时，我开始更加关注人们指出了哪些故障模式。其中很多都让我深有共鸣。当有人把某种模式提炼成模型或 AI Agent 的一个简短特征时，比如「参差不齐」（jaggedness），这种总结堪称宝藏。这类知识可以帮助你建立对 AI Agent 能力的直觉，并找到围绕 Agent 合理组织工作的方式。它还能帮你形成健康的预期，不至于轻信那些被过度炒作的「黑灯工厂」，以及我们身边其他凭空捏造的 AI 能力胡扯。

下面是我尝试整理的一套分类，概括了几篇博客文章和会议演讲中提到、同时也符合我个人观察的故障模式。

为什么这会演变成疲劳

有两个相互关联的问题并不完全属于故障模式表格，但它们解释了为什么这一切会如此迅速地让人疲惫不堪。

首先，生成速度超过了审查速度。Mario 所说的「他妈的慢一点」并不只是在表达情绪，而是一项操作层面的约束。一旦 Agent 生成代码、测试、issue 和 PR 的速度超过人类阅读它们的速度，瓶颈就会从打字转移到判断。审查 Agent 可以发现一部分问题，但它无法恢复人类对工作的掌控。如果没有人阅读代码，就没有人知道哪些部分至关重要；等到用户开始大声抱怨时，现场已经没有任何人真正理解系统了。

其次，同样的动态也会从代码仓库蔓延到外部。AI 生成的 issue、AI 生成的 PR、合成评论、生成式文档、泛泛而谈的文章：其中一些可能确实有用，但这个信息渠道被看似合理的文本填满的速度，远远超过人们筛选它们的速度。这就是范围更广的 AI 垃圾内容问题。它留下的认知残留，是疲劳、犬儒、AI 脑腐，最终演变成全大写的 prompt，恳求机器别再自作聪明，赶紧完成真正的工作。

因此，「慢下来」并不是怀旧，也不是居高临下的道德说教，而是一条实用规则：把生成式工作控制在可审查的范围内，在验证成本低廉的地方使用 Agent，并保留足够多的人类理解，确保人仍然能够说「不」。

修复方法，以及它们会破坏什么

Anthropic，《面向长时间运行 Agent 的高效 Harness》，2025 年 11 月

Anthropic，《面向长时间运行应用开发的 Harness 设计》，2026 年 3 月

Random Labs，《Slate：超越 ReAct 与 RLM》，2026 年 3 月

Mario Zechner，《在垃圾内容泛滥的世界中构建 Pi》，AI Engineer 会议演讲，2026 年 4 月

Cursor（Wilson Lin），《Agent Swarm 与新的模型经济学》，2026 年 7 月

我之前的文章，《长周期 Agent 已经到来，但完全自动驾驶还没有》，2026 年 3 月

Pi Agent 的创建者 Mario 在演讲里使用「f.ck」这个词的频率实在太高了。而我发现，自己也陷入了类似的状态：在 prompt 里大量使用全大写，以及一堆 F.CK。我猜，这就是看过太多 AI 输出之后，AI 疲劳的具体表现吧 :)

部分评论可能只有登录后的访客才能看到。请登录以查看全部评论。

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。