长时运行的Agent:瓶颈究竟是模型还是其周围的脚手架?
摘要
一场从业者讨论,探讨长时运行的AI Agent故障究竟源于模型能力还是其周围的脚手架,重点分析了错误累积、上下文污染和自我修正薄弱这几种关键故障模式。
我在搭Agent时经常注意到一点:每个单独的步骤对模型来说都很简单,但整条链在长任务上还是会崩溃。我认为关键有三方面:
**错误累积。** 即使每一步的准确率有95%,一个20步的链条也只有大约三分之一的概率成功(0.95^20 大约是0.36)。小错误会很快堆叠起来。
**上下文污染。** 经过足够多的工具调用之后,上下文里塞满了旧的输出、走不通的死路和失败的尝试,模型会慢慢丢失最初的目标。
**自我修正薄弱。** 当某一步出错时,模型通常会继续在错误的基础上往下做,而不是回退并修正它。
我不确定的是,真正的修复到底来自哪里。一派认为主要靠更好的模型。另一派认为,一个精心设计的循环(检查点、校验步骤、把状态存储在上下文窗口之外)比模型本身更重要。
很好奇大家在实践中看到过什么:
- 你会把完整历史都留在上下文中,还是边走边做总结和裁剪?
- 单独的批评者(critic)或校验模型真的有帮助吗,还是只是增加了延迟和成本?
- 你的Agent通常在任务的哪个阶段开始崩溃?实际解决问题的办法是什么?
很想听听哪些做法有效,哪些没用。
相似文章
你的代理失败不是因为模型,而是因为没人构建一个停止按钮
文章认为,AI代理在生产中的主要失败点并非模型本身,而是缺乏基础设施,如停止按钮、账单监控以及工具调用的可追溯性。
我们是否过于关注模型而忽视了智能体基础设施?
一篇观点文章,质疑AI社区是否过度强调模型能力,而牺牲了构建稳健的智能体基础设施。
整天运行智能体,我发现瓶颈始终在于我如何定义“好”,而非模型本身
作者反思,运行AI智能体的主要瓶颈并非模型能力,而是人类精确定义“好”或“完成”的能力,并将其与管理人员的类比相联系。
AI代理的失败方式鲜有人论及。以下是我亲眼所见。
文章强调了AI代理工作流程中实际的系统级失败,例如上下文泄漏和幻觉细节,认为这些通常是基础设施问题而非模型缺陷。
长期运行的AI代理可能面临比记忆更大的连续性问题
反思了长期运行的AI代理所面临的连续性问题,认为需要确定性控制层来管理权威状态,并质疑现有的IAM、事务和溯源等基础设施是否足够。