长任务 Agent 会忘事，先别急着换模型

MarkTechPost 9 月 12 日发表的一篇综述，把长任务 Agent 的问题说得很直白：短任务只是模型循环调用工具，任务持续一小时、调用两百次后，常见结果是上下文塞满，或者模型忘了最初要做什么。文章引用 AWS 的 Agent 设计资料，把这两种情况分别称为上下文溢出和目标丢失。

Anthropic 早先对‘上下文工程’的解释也指向同一个地方。窗口里的内容越多，模型检索远处信息越不稳定；上下文是有限的工作资源，不能当成一块越买越大的硬盘。窗口容量增加可以延后问题出现，却没有替任务处理旧信息。

这解释了一个常见误会：同一个模型在聊天里表现很好，放进连续数小时的代码迁移或资料研究后却开始漏步骤。任务外壳要管理的，是每一轮留下什么、删掉什么，以及下一轮怎样知道目标还在。

LangChain 的 Deep Agents 公开了一个很具体的做法：工具返回超过 2 万 token 时，把完整结果写入文件，只在上下文里留下路径和前十行预览。上下文接近模型窗口的 85% 时，旧的写入和编辑参数也会被替换成文件指针。模型需要细节时再搜索文件，当前对话不必反复携带整份内容。

这不是简单的删记录。文件名、目录和时间戳会告诉 Agent 去哪里找什么，工具也要能返回短而有用的结果。Anthropic 的文档把这种方法称为按需取用：先保留轻量索引，任务进行到某一步，再读取对应数据。

阈值属于具体实现，换模型或换框架后不能照抄。需要保留的是分工：对话保存当前决策，外部存储保存可复查的材料，工具提供检索入口。

当移出结果还不够，系统会把历史压缩成摘要，再开一个新的上下文。Anthropic 的 Claude Code 会保留架构决定、未解决的问题和近期文件；OpenAI 的 Responses API 也提供服务端 compaction，让开发者把压缩后的上下文继续传入下一次调用。

摘要的问题在于它一定会取舍。早期对话里一句限制条件，可能直到最后一步才派上用场，压缩时却被当成背景噪音。LangChain 因此把完整原始记录写到文件，并在摘要里单独保留任务意图、已建产物和下一步。这样模型忘了细节时，还有地方可以查。

待办文件解决的是另一种漂移。每隔几轮重写短清单，目标会回到上下文末尾，模型更容易继续当前工作。它也有成本：每次重写都要消耗 token，清单写得太长还会变成新的噪音。

跨会话记忆可以保存项目状态、检索结果和上次的决定，但每次重新加载都会占用注意力。MarkTechPost 引用 ETH Zurich 的两组基准测试称，自动生成的上下文文件让推理成本上升约 20% 至 23%，开发者提交的文件也带来最高约 19% 的增加。这是该文对研究的转述，不是本站复现实验。

LangChain 的公开评测还显示，待办列表并非所有任务都有效；他们把压缩提前到窗口的 10% 至 20%，用来放大不同方案的差异。这种压力测试适合找问题，不能直接当成线上性能分数。

所以，记忆文件、提示词和工具说明都要控制大小。把所有资料每次塞回去，可能只是让模型更快遇到下一次混乱。

长任务的测试不能只看最后一句回答。可以在任务中途强制压缩，检查 Agent 是否仍沿着原目标走；把一个早期事实藏在已移出的文件里，再要求它在后面找回；记录它何时开始反复确认、误报完成或跳过验收。

评测还要覆盖失败恢复。工具调用失败后，系统是否知道已经完成了哪一步？重新加载状态后，是否会重复写文件或重复提交？这些问题比一次演示能跑多远更接近交付现场。

长上下文模型仍然有用，但购买更大的窗口不能代替这些检查。先让任务外壳把材料、状态和压缩规则写清楚，再比较模型在同一组任务上的完成率与返工量，结论才有意义。