现在很多模型的上下文窗口已经很大。大到足以塞进长文档、代码库摘要、会议记录、工具输出和一大段历史对话。于是很多人会自然地产生一个判断既然窗口够大就不用太管理上下文了。这个判断很危险因为长上下文解决的是容量问题不是质量问题也不是成本问题。更不是状态管理问题。窗口变大以后你确实可以放更多东西。但你仍然要回答哪些内容值得长期保留 哪些内容应该压缩 哪些内容应该缓存 哪些内容应该落盘 哪些内容应该忘掉如果这些问题没解决长上下文只是让垃圾堆变大。一、长上下文的三个代价1.1 成本。更多 token 意味着更多输入成本。如果每次请求都重复带上系统提示、工具说明、项目说明、历史对话、检索片段成本会很快变成隐性税。你可能不是被单次调用拖垮而是被每一步重复携带的上下文拖垮。1.2 延迟。上下文越长模型处理越慢。尤其是多步 Agent。一次慢一点不明显。循环多步以后延迟会被放大。1.3 注意力。长上下文不等于模型会同等重视每一段信息。无关内容越多关键状态越容易被淹没。这不是模型“忘了”。是你把工作台堆满了。真正成熟的上下文系统不是尽可能多塞。而是让每一步上下文保持可读、可控、可恢复。二、Compaction 不是摘要很多人一听压缩就想到摘要。把长历史总结成短文字。这只是最低层的做法。Agent 的 context compaction 不是文学摘要它要保留任务状态。一个好的 compaction 至少要保留当前目标 用户约束 已完成动作 关键事实 决策理由 已调用工具 产生的副作用 未解决问题 下一步计划 验证结果注意这里有几个词决策理由、副作用、未解决问题、验证结果。这些比“刚才聊了什么”更重要。因为 Agent 不是在写会议纪要。它是在恢复执行状态。如果压缩只保留结论不保留为什么做这个结论后续 Agent 很容易重复走弯路如果压缩丢掉副作用后续 Agent 可能重复执行危险动作如果压缩丢掉 open issues任务会看起来完成实际还有洞。三、Prompt Caching 解决的是重复成本Prompt caching 经常被误解成提升模型质量的技巧。它不是。它主要解决重复上下文的成本和延迟。适合缓存的内容通常有这些系统提示 工具定义 项目规则 代码库摘要 长文档 产品手册 稳定 policy 少变化的 examples这些内容在很多请求里重复出现。如果每一步都重新付全价就很浪费。但缓存也有边界。它适合稳定前缀。不适合频繁变化的任务状态。比如当前进度 最新工具输出 用户刚刚修正的约束 待确认问题 执行错误这些东西不应该为了命中缓存而硬塞进稳定前缀。缓存是成本优化。不是上下文设计的替代品。更不是把所有东西固定住的理由。四、工具输出应该落盘Agent 系统里最容易膨胀的上下文往往不是聊天历史。而是工具输出。比如测试日志 构建日志 grep 结果 网页 HTML 数据库查询 代码 diff 长 PDF 提取内容这些东西直接塞回上下文会导致三个问题贵 慢 污染下一步推理更好的方式是 offloading也就是把原始输出放到上下文之外。比如artifacts/test-log-20260623.txt artifacts/search-results.json artifacts/page-snapshot.md artifacts/query-result.csv然后只把三类内容放回上下文4.1 结构化摘要。比如测试失败 3 个集中在 auth/session 模块。 首个失败是 TokenRefreshTest错误为 expired token not refreshed。4.2 关键片段。比如错误行、堆栈顶部、相关文件路径。4.3 索引引用。告诉 Agent 原始输出在哪里需要时再读。这就像人工作时不会把整份日志背下来。你会记录摘要、错误位置和文件路径。五、遗忘是设计不是事故很多人把 memory 设计成“尽量多记”。这是另一个坑。生产系统需要遗忘机制。因为上下文里有很多东西会过期。比如用户临时偏好 过期需求 旧版本 API 已解决 bug 上一次任务的假设 一次性授权 错误的中间结论如果这些东西不被清理它们会变成污染源。遗忘不是模型能力不足。遗忘是系统能力。一个好的记忆系统应该支持scope这条记忆属于用户、项目、任务还是系统 ttl什么时候过期 owner谁能修改 source从哪里来 confidence可信度多高 delete能否删除 audit谁在什么时候用了它尤其是用户相关记忆。不能因为模型觉得“这个偏好可能有用”就永久写入。长期记忆应该是可解释、可编辑、可删除的。六、状态文件模式长任务 Agent 不能只靠聊天历史恢复。它需要外部状态。我建议至少拆成四类状态文件。6.1 progress.md。记录任务进度当前目标 已完成步骤 正在处理什么 下一步是什么6.2 decisions.md。记录关键决策选择了什么方案 为什么这么选 拒绝了什么方案 决策依据是什么6.3open-issues.md。记录未解决问题缺少什么信息 哪里需要用户确认 哪些测试失败 哪些风险还没处理6.4 verification.md。记录验证状态跑过哪些测试 结果是什么 哪些没法验证 为什么没法验证这些文件不是为了形式主义。它们有两个作用。第一让 Agent 可以恢复。上下文压缩后下一轮还能知道任务状态。第二让人类可以审计。你不需要翻 200 轮对话才能知道 Agent 为什么这么做。七、一个长任务上下文生命周期可以把长任务 Agent 的上下文设计成一个生命周期Initialize - Load Stable Context - Plan Task - Execute Step - Offload Tool Output - Update State Files - Compact Working Memory - Verify - Continue / Pause / Escalate这里的关键是分层稳定上下文比如系统提示、项目规则、工具定义可以缓存。任务状态比如进度、决策、问题要写入外部文件。工具输出原始内容落盘摘要进入上下文。工作记忆阶段性压缩。验证结果单独记录。人类输入标记来源和有效范围。这样做之后Agent 不再依赖“聊天记录还在不在”。它有可恢复的任务状态。八、常见反模式8.1 长期把完整历史塞进上下文。看似保险实际贵、慢、乱。8.2 把 compaction 做成普通摘要。丢掉决策理由和副作用后续执行会失真。8.3 为了缓存命中牺牲上下文正确性。缓存应该服务系统不应该绑架系统。8.4 工具输出原样回填。日志和 HTML 最容易污染上下文。8.5 memory 永不过期。长期记忆如果不能更新和删除就不是资产是风险。8.6 没有恢复点。Agent 一旦中断只能重跑或靠模型猜前面发生了什么。九、实践 checklist设计长上下文 Agent 前先问这些问题[ ] 哪些上下文是稳定前缀可以缓存 [ ] 哪些上下文是任务状态必须外部化 [ ] 工具原始输出是否落盘 [ ] 进入模型的是摘要、关键片段还是整段原文 [ ] compaction 是否保留目标、决策、风险和下一步 [ ] 哪些记忆有 TTL [ ] 用户记忆是否可编辑、可删除 [ ] 任务中断后能否从状态文件恢复 [ ] 验证结果是否单独记录 [ ] 哪些信息应该被主动遗忘这张表决定了长任务 Agent 是可运行还是只是长对话。十、长上下文不是免管理长上下文是一种能力不是一种架构。它让我们可以放更多材料。但生产系统真正需要的是压缩保留任务状态 缓存降低重复成本 落盘外置原始输出 遗忘避免旧信息污染 恢复让任务可以继续到这里Context Engineering 的第二阶段就完整了。第 4 篇我们讲每一步该看什么。第 5 篇我们讲 RAG 只是取回候选材料真正难的是上下文装配。第 6 篇我们讲长上下文时代仍然需要压缩、缓存和遗忘。下一篇系列进入第三阶段Harness Engineering模型之外的一切。Prompt 和 Context 解决“模型怎么想”。Harness 要解决的是模型如何在真实系统里安全、可控、可验证地行动。参考资料Effective context engineering for AI agents | Anthropic EngineeringContext engineering for agents | LangChainAnthropic Prompt Caching docsEffective harnesses for long-running agents | Anthropic Engineering参考文献长上下文时代的压缩、缓存与遗忘