标签
Anthropic的新研究发现，相同或相似的AI智能体可能趋同于同一个错误决策，将个体错误变成系统级故障；而且更强的智能体并不会自动地更好地协调，这表明需要制度性层级来协调智能体。
这篇 arXiv 论文提出了一种以交互为中心的分类法，用于将 LLM 智能体故障定位到具体组件（模型 vs 框架 vs 环境），在交互边上组织了 41 种故障模式，使修复具有可操作性。论文使用人类标注和前沿模型评审员验证了该分类法。
作者反思了长期运行的人工智能代理如何遭遇与初始提示无关的失败，并认为环境设计（工具、文档、验证、架构规则）更为重要。他们讨论了诸如 harness 工程、保持 AGENTS.md 文件精简、使用 linter 和评估器代理等概念，同时指出了成本权衡。
一位开发者分享了让单一AI代理处理过多任务的教训，导致多种失败模式。他们提倡拆分角色、强制结构化输出并仔细设计交接。
构建了一个本地控制系统来管理代理改进循环，捕获跟踪，发现重复故障，使用Codex/Claude Code起草修复方案，并仅在通过检查和评估后应用更改。
Opik 是一个用于AI代理可观测性的开源平台，它不仅限于追踪，还能自动诊断故障、提出修复方案并进行验证，从而在没有人工干预的情况下关闭调试循环。
一位开发者分享了在多个代理运行中可视化失败聚类如何改变了他们的调试方法，强调了建立反馈循环的必要性，使代理能够从过去的错误中学习，而不是将失败视为孤立的问题。文章提到了手动变通方法和一个名为BentoLabs的平台，该平台实现了闭环改进。
讨论了编码代理在复杂长期任务中的挑战，指出了奇怪的用户体验问题和低效的代理交互，并主张对代理框架拥有更多控制权。
本文将AI代理比作电影《记忆碎片》的主角，认为代理的失败往往源于工作区数据分散、过时，而非模型本身的不足。文章强调，工作区需要提供可靠、统一的上下文，使代理能够有效行动而无须猜测。
Cursor的工程笔记揭示，代理失败往往源于框架（脚手架）而非模型本身，不同供应商的工具格式差异会导致静默错误和可靠性问题。
文章认为，令人印象深刻的AI与无用的AI之间的区别往往不在于模型本身，而在于围绕它的工作流——上下文、记忆、工具访问和编排。它表明，工作流架构可能成为比原始模型能力更重要的竞争优势。