让 Agent 跑一个跨系统的长任务，前十分钟都好好的：开头交代的规则记得住，中间每一步也都对。但到了第十几步，它突然像失忆了一样，把最初那句”金额超过一万必须人工确认”忘得干干净净。这不是个例。长任务里 Agent 丢上下文，几乎和它出幻觉一样常见，而且越到任务后期越容易发生。
很多人第一反应是换更大的窗口。窗口大了确实能装下更多内容，但它只是把”遗忘”推迟了，没解决”往里面放什么”的问题。更大的窗口意味着更高的成本，也意味着 Agent 在每一轮都要在更多无关内容里找关键信息——找得到找不到，全凭运气。真正该做的，是把上下文当成一个需要管理的预算，而不是一个无限大的仓库。
窗口不是越大越好
先想清楚一个问题：Agent 每一轮推理，能真正”注意到”的信息是有限的。你把二十万字的项目文档全塞进去，模型确实读得完，但它会不会在关键时刻想起来用第五条第三款，完全是另一回事。上下文管理的本质，是保证 Agent 在正确的位置、以正确的形式看到正确的信息，而不是把”信息越多越好”当信仰。
这跟 需求验收标准 的道理一样：验收不是”看起来能跑”就行，上下文也不是”看起来都在”就够。要问的是，关键约束有没有被 Agent 真正接住。
四个动作：裁剪、压缩、检索、遗忘
我自己会把上下文管理拆成四个动作，对应不同的场景。
裁剪，是开始任务前就决定哪些信息进上下文。任务目标、权限边界、必须人工确认的节点，这些放在最前面；无关的历史对话、旧版本说明，一开始就不该进来。裁剪做得好的任务，Agent 很少在关键规则上犯错。
压缩，是任务进行中做的。每完成一个阶段，把前面的过程压成一段摘要，保留决策和结果，丢掉中间那些试错过程。这就像给 Agent 写周报：不用把每天的流水账都留着，但结论和理由必须清楚。
检索，是让信息按需进来。与其把整个知识库塞进上下文，不如让 Agent 需要哪块取哪块。前提是知识库本身是新鲜的——知识库陈旧内容巡检 那篇里说过，旧口径如果不清理，Agent 检索到的可能是个错误答案。
遗忘，是最容易被忽略的动作。任务进行中，某些信息已经失效了：价格更新了、负责人换了、上一步的结果被推翻了。这些信息如果不主动清出去，就会在下一次决策时跳出来捣乱。主动遗忘和 AI Agent 记忆系统进化 里讲的跨会话记忆是两回事——那边解决的是”换一个 Agent 重新养一遍”的问题，这边解决的是单次任务里”过期信息赖着不走”的问题。
长任务怎么落地
落到实际工作里，我建议团队先做四件事。第一，任务开始前给 Agent 一份上下文预算：这个任务最多带多少资料、哪些是必须的、哪些遇到再取。第二，每个阶段结束强制做一次摘要，把摘要作为下一阶段的输入。第三，关键决策的证据留在上下文外面而不是里面——证据包 的思路是用结构化记录保存输入、工具轨迹和结果，上下文里只需要放一个引用。第四，对长任务定期做 回放对照，用同一批样本验证上下文调整之后，行为没有悄悄变差。
总结
上下文管理不是模型能力问题，是工程问题。窗口大了只是把问题往后推，真正决定长任务成败的，是裁剪、压缩、检索、遗忘这四个动作有没有形成闭环。先把上下文预算立起来，再逐步加摘要和检索，你的 Agent 在长任务里”掉线”的概率会小很多。
