连续运行六小时后,你的上下文窗口究竟会发生什么
摘要
一位实践者分享了AI代理连续运行6小时以上时,上下文窗口管理策略(摘要、RAG、截断)的真实失败模式,指出每种方法都会以仅在长时间运行时才会显现的方式降低决策质量。
关于长时间运行的代理的上下文窗口管理,文档给出的答案是:对旧轮次进行摘要,使用 RAG 进行检索,以及从前截断。但实际上,这三种方法都有只在长时间运行后才会显现的失败模式。摘要压缩了模型能看到的内容,但代价是损失了隐式状态。连续运行到第六或第七个小时时,摘要对于发生的事件在事实上是准确的,但代理做出的决策,对于任何看到完整上下文的人来说都明显是错误的。事实还在,但判断上下文已不复存在。RAG 检索假设代理知道要检索什么。长时间运行的代理往往不知道它们所不知道的。失败模式不断重复:代理不再提出正确的问题,因为它缺乏上下文,不知道一开始应该存在那个问题。从前截断是最糟糕的默认做法。你会失去任务框架,代理开始针对最近的信号进行优化,而不再受原始约束。对于你们的代理运行超过四五个小时的情况,有哪些实现是有效的?
相似文章
@GergelyOrosz: 试图弄清楚,在上下文窗口中使用更多上下文(我称之为上下文深度),在更长的运行中,错误会如何累积/代理会如何漂移……
Gergely Orosz 指出,在AI代理的上下文窗口中使用更多上下文进行更长的运行会增加错误和漂移,建议使用更短的运行和更少的上下文以提高可靠性。
我认为长上下文代理的失败方式非常无聊
一篇观点文章,认为长上下文窗口并不等同于记忆,代理失败通常很普通,比如忘记约束或重新读取文件,强调可靠性取决于上下文架构决策。
更大的上下文窗口对智能体来说其实是错误的方向吗?
作者质疑将注意力集中在扩大AI智能体的上下文窗口上是否适得其反,认为积累的垃圾信息会拖慢长时间会话,并建议保持工作上下文小巧、使用外部记忆。
你的智能体在长时间会话中表现会下降
本文讨论了AI智能体在长会话中性能下降的问题,原因是上下文窗口被原始历史、工具输出和重复推理所充斥,并提出了通过总结旧轮次和修剪工具输出来延长有效运行长度的解决方案。
上下文至关重要,但上下文腐烂才是AI智能体的真正上限,更大的上下文窗口只会让情况更糟而非更好
文章认为,上下文腐烂(即随着上下文填充导致推理质量下降)是AI智能体的真正上限,而非上下文窗口大小。它提倡采用架构方法分解任务并使用独立验证来超越限制。