对抗长任务上下文溢出的四种机制:LangChain 公布阈值
MarkTechPost 梳理了智能体运行框架应对上下文溢出与目标丢失的四种机制,并列出各家已落地的具体阈值。
智能体(Agent)最简单的形式,就是大语言模型(LLM)在循环中调用工具。MarkTechPost 的一篇综述指出,这个循环在短任务上可行,但一旦任务持续一小时、涉及 200 次工具调用,就会以两种方式失效:上下文溢出和目标丢失。AWS Samples 面向自主云端编码智能体的设计指南还补充说,浅层智能体无法长期维持状态。解决问题的不是模型层,而是运行框架(harness),AWS 将其描述为“管理除模型之外的一切”。
扩大上下文窗口的帮助比预期小。Chroma 的 Context Rot 报告评估了 18 个模型,包括 GPT-4.1、Claude 4、Gemini 2.5 和 Qwen3,发现输入越长,性能越不可靠,即便是简单的检索任务也是如此。Anthropic 的上下文工程指南用“注意力预算”解释机理:n 个 token 会产生 n² 对关系,每增加一个 token 都在消耗有限预算。Manus 则称,典型任务约需 50 次工具调用,输入与输出的 token 比接近 100:1。
各家公布的阈值
在 LangChain Deep Agents 中,超过 20000 token 的工具返回会被写入文件系统,并以文件路径加前 10 行预览取代;当会话上下文超过窗口的 85%,较早的写入和编辑调用会被截断为指针。Claude Code 将自动记忆限制在前 200 行或 25KB,默认延迟加载 MCP 工具模式,压缩后重新读取的文件若超过 5000 token,则以路径引用而非内容返回。
压缩机制也进入了 API 层。OpenAI 的 Responses API 通过 compact_threshold 提供服务端压缩,并设有独立的 /responses/compact 接口,OpenAI 表示 Codex 依靠该机制支撑长时间运行的编码任务。Manus 的做法更朴素:智能体建立一个 todo.md 并逐步重写,把整体计划重新推到上下文末尾。
更多实现细节见 MarkTechPost 原文。