Context Management（上下文管理）¶
定义¶
Context management 是 agent 系统中管理 LLM 可用信息的机制集合——包括 context window 内的信息组织，以及跨 session 的状态传递。
机制¶
Context Window 内¶
- Compaction：Claude Agent SDK 的内建能力，在 context 接近上限时压缩对话历史，使 agent 不会因 context 耗尽而中断。
- 工具结果管理：选择性保留或丢弃工具调用结果。
跨 Session¶
Compaction 本身不足以解决 长时运行 agent 的问题——压缩后的 context 可能丢失关键细节，导致下一个 session 误解状态。
Anthropic 的解决方案是 外部化状态：
- Progress file（claude-progress.txt）：agent 在每个 session 结束时写入结构化的进度摘要
- Git history：commit message 作为变更的可审计记录
- Feature list（feature tracking）：任务完成度的客观指标
关键洞察：context management 不仅是 LLM 内部问题，更需要 harness engineering 层面的外部机制配合。
"顺行性遗忘"类比¶
Karpathy 在 2025 YC 演讲 中用电影类比精确捕捉了 context management 的根本困境：LLM 患有"顺行性遗忘"（anterograde amnesia）——weights 固定、context window 每个 session 清零，如同《Memento》和《50 First Dates》的主角。
与人类同事的对比揭示了差距的本质：人类同事加入组织后会逐步积累上下文、回家睡觉巩固记忆、发展长期专业知识。LLM 不会原生地做到这些——context window 是工作记忆，必须被显式编程。"很多人被类比误导了"——把 LLM 当作会自主学习的同事，是 context management 问题的根源之一。
这与上述 Anthropic 的外部化状态方案完全对齐：progress file、git history、feature list 本质上都是在为一个"每天失忆的同事"构建外部记忆系统。
Context Reset vs Compaction¶
Anthropic 在 harness 迭代 中发现两种策略各有取舍：
| Compaction | Context Reset | |
|---|---|---|
| 机制 | 压缩对话历史，同一 agent 继续 | 清空 context，启动新 agent + 交接文件 |
| 优势 | 保持连续性 | 提供干净起点 |
| 劣势 | Context anxiety 可能残留 | 增加编排复杂度和延迟 |
Context anxiety：模型在接近 context 上限时过早收尾、草草完成工作的倾向。Sonnet 4.5 表现严重（必须用 context reset），Opus 4.5/4.6 明显减轻（compaction 即可）。
这揭示了 context management 与模型能力的耦合——策略选择取决于具体模型的行为特征，而非一刀切的最佳实践。
与 Augmented LLM 的关系¶
Augmented LLM 的三大增强维度（检索、工具、记忆）中，context management 横跨所有三者——它决定了检索结果如何进入 context、工具输出如何保留、跨 session 记忆如何组织。
相关概念¶
- Long-running agents — context management 最具挑战性的场景
- Context engineering — context management 是 context engineering 的核心机制层
- Augmented LLM — context 是增强能力的载体
- Harness engineering — context management 是 harness 的核心职责之一
- Feature tracking — 外部化状态的具体形式
Codex 的 Compaction 实现¶
OpenAI 在 agent loop 拆解 中展示了 compaction 的演进：
1. 手动 /compact → LLM 总结 → 替换 input
2. Responses API /responses/compact 端点 → 返回 type=compaction + encrypted_content（保留模型潜在理解）
3. 自动触发：超过 auto_compact_limit 自动调用
关键优化：prompt caching——保持后续请求是前序的精确前缀，使采样成本从 O(n²) 降为 O(n)。破坏 cache 的操作需要谨慎管理。
模型能力与 Context 策略的共演化¶
Harnessing Claude's Intelligence 用 BrowseComp 数据展示了 context 管理能力随模型演进的跃升：
| 模型 | Compaction 得分 |
|---|---|
| Sonnet 4.5 | 43%（不随 budget 变化） |
| Opus 4.5 | 68% |
| Opus 4.6 | 84% |
差异不在技术机制，而在模型"知道保留什么"的判断力。Sonnet 3.5 在长时对局中写流水账；Opus 4.6 蒸馏出战术教训。这暗示 context management 的未来方向不是更复杂的外部系统，而是更智能的模型自主管理。
Opus 4.6 的平台级 Compaction¶
Opus 4.6 发布 将 compaction 从 SDK 特性升级为 API 级能力，加上 1M token context window，根本性地扩大了 context 预算。Adaptive thinking 和 effort 控制提供了智能-延迟-成本的新调节维度，间接影响 context 利用率。
Context Rot：长 Context 的性能代价¶
Chroma 的 Context Rot 研究 提供了一个关键的实证补充：context management 不仅是"放什么进去"的问题，也是"放多少进去"的问题。
18 个前沿模型的系统性测试表明，模型性能随输入长度增长而可测量地退化（context rot），即使在极简任务上。三种退化机制——注意力稀释、干扰项干涉、结构干扰——对 context management 策略有直接影响：
- Compaction 的价值重定位：compaction 不再仅仅是防止 context window 溢出的被动手段，而是主动维持模型性能的关键机制。即使 context window 足够大（如 Opus 4.6 的 1M token），过长的 context 也会损害性能。
- 检索优于堆积：context rot 为"只检索相关子集"的策略提供了实证支持，与"尽可能多塞入 context"的直觉相反。
- Distractor 过滤：不仅要过滤无关内容，还需识别和过滤"相关但不正确"的干扰信息——这是传统 context management 未充分考虑的维度。
这一发现与上述"模型能力与 Context 策略的共演化"形成互补：更智能的模型可以更好地判断"保留什么"，但 context rot 本身是结构性的，不会因模型能力提升而完全消失。
Context Engineering 框架下的定位¶
Effective Context Engineering 将 context management 置于更广义的 context engineering 框架中，补充了几个重要维度：
- Compaction 的取舍艺术：过度激进的 compaction 会丢失后期才显现重要性的微妙 context。推荐流程：先最大化 recall 确保不丢关键信息，再迭代优化 precision 去除冗余
- 工具结果清理是最安全的轻量级 compaction——深层历史中的工具调用原始结果很少需要再次查看
- Structured note-taking（agentic memory）作为 compaction 的互补策略：agent 定期将笔记写入 context window 外的持久存储，后续按需拉回。Claude 玩 Pokemon 展示了跨数千步骤维持记忆连贯性的能力
- Sub-agent 架构提供第三条路径：子 agent 在独立 context window 中深入探索，仅返回 1000-2000 token 的压缩摘要，实现关注点分离
三种长时策略的适用场景：compaction 适合连续对话流，note-taking 适合有里程碑的迭代开发，sub-agent 适合需要并行探索的复杂研究。
长 Horizon 任务中的 Context 挑战¶
SWE-EVO 的实验间接验证了 context management 在多步任务中的关键性。论文 Section 2.3 专门综述了 context engineering 对长 horizon agent 的影响：
- Meta Context Engineering 将 context 组装视为优化问题，在 SWE-bench Verified 上达到 89.1%（对比手工基线 70.7%）——context 质量的差异本身就值 ~18 个点
- Memory 架构（如 MemGPT、hierarchical storage）使 agent 能跨单 session 限制维持连贯推理
- 在 SWE-EVO 的多步演进任务中，agent 需要在跨数千词的需求规格和涉及数十文件的改动之间保持连贯推理——这正是 context management 的极限场景
SWE-EVO 中强模型的主要失败模式（指令遵循——理解歪了 release notes）也暗示：当需求规格足够复杂时，context 的组织方式（如何呈现多条需求、如何关联 PR 上下文）直接影响 agent 的理解质量。
记忆脚手架的反面证据¶
Beyond pass@1 对 10 个模型在两种脚手架（ReAct 和 Memory-augmented）下的对比测试表明：episodic memory（便签本式记忆）在长任务上全线失败——6 个模型 GDS 下降、4 个中性、0 个改善。最大的负面效应出现在中等能力模型上（Kimi K2.5 -0.14、Mistral 24B -0.13）。
机制分析：便签本的每次 add_to_memory() 调用消耗步数预算，积累的便签注入 system prompt 消耗 context 空间。在短任务上代价可控（便签少），在长任务上代价 load-bearing（便签积累）。
这为 context management 策略增加了一条重要约束：更多的 context 不一定更好。与 context rot 的发现一致——无论是被动堆积还是主动记录，过多的 context 都会损害性能。记忆机制需要配合过期、分层、或按需检索策略，而非朴素的"全部保留"。
压缩质量的实证比较¶
Factory 的 Context Compression 评估 首次在 36,000+ 条真实开发 session 消息上对比了三种生产级 压缩策略，为 compaction 策略选择提供了量化依据：
| 方法 | 总分 | 机制 | 压缩率 |
|---|---|---|---|
| Factory（结构化摘要） | 3.70 | 锚定式迭代合并，显式 section | 98.6% |
| Anthropic（SDK 内建） | 3.44 | 全量重生成结构化摘要 | 98.7% |
| OpenAI（compact 端点） | 3.35 | 不透明压缩表示 | 99.3% |
关键发现对 context management 策略的影响：
- 增量合并优于全量重生成：Factory 的锚定式方法在多次压缩周期中保持更高的一致性，因为关键细节不会在每次重生成中漂移
- Artifact tracking 是普遍弱点（所有方法 2.19-2.45/5.0）：仅靠 compaction 无法可靠追踪文件变更，需要外部化的 artifact 索引配合——这与上述"外部化状态"策略互相印证
- Tokens per task 才是正确指标：高压缩率导致的信息丢失最终需要重新获取，可能超过节省的 token。这进一步支持了 compaction 的价值定位——不是最小化 token，而是最大化可用信号
Manus 的生产级 Context Engineering 五维框架¶
Manus 在四次架构重建后总结的 context engineering 框架，将 context management 结构化为五个正交维度：
| 维度 | 操作方向 | 核心机制 |
|---|---|---|
| Offloading | 移出 context | 文件系统作为无限外部 memory，零 token 成本 |
| Reduction | 压缩历史 | 仅限可恢复压缩（保留路径/URL 指针） |
| Retrieval | 按需读回 | 文件搜索工具作为结构化检索层 |
| Isolation | 隔离子任务 | 子 agent 在独立 context window 中运行 |
| Caching | 重用计算 | stable prefix engineering + session affinity |
"可恢复才可压缩"原则：Manus 明确禁止不可恢复的压缩——网页内容可移出 context，但 URL 必须保留；文档内容可省略，但文件路径必须保留。不可恢复的压缩等同于数据销毁。这与 context reset（全部丢弃再重建）的做法形成对比：两者都减少 context 长度，但 Manus 方案通过外部指针保留了信息可及性。
错误保留作为隐式 belief update：失败记录和错误信息被刻意保留而非清除，使模型通过 context 历史隐式更新对哪些操作无效的信念，错误恢复行为自然涌现，无需显式错误处理逻辑。
todo.md 的注意力工程：Manus 任务平均 50 次工具调用。模型存在"中间迷失"退化——在深入执行后遗忘早期全局计划。解决方案不是在 context 中"存储"计划，而是在每次 agent loop 迭代中更新 todo.md，将全局目标持续推入 context 的近期位置（高注意力区域）。这是注意力操控而非记忆操控。
Claude Code 内部 Context 架构（2026 源码分析）¶
Claude Code 源码泄露的社区分析揭示了生产级 agent 系统的 context 管理实现细节：
Append-Only JSONL 历史：对话历史以追加式 JSONL 文件存储，压缩前的消息永不物理删除。消息携带三类元数据标志：isCompactSummary（是否是压缩摘要）、isVisibleInTranscriptOnly（是否仅在用户 transcript 中可见）、isMeta（是否为元消息）。API 调用前通过这些标志过滤——用户可见 transcript 与模型接收的 context 可以显著偏离。
AutoCompact 机制：接近 token 限制时，autoCompact.ts 派遣次级 Claude 实例对历史进行摘要。摘要器在 <analysis> 标签内推理（思维链），随后剥除推理过程，仅将压缩摘要插回 context。源码注释记载了一个生产 bug："1,279 个 session 出现 50 次以上连续压缩失败（最多 3,272 次），每天全球浪费约 25 万 API 调用"——修复为 MAX_CONSECUTIVE_AUTOCOMPACT_FAILURES = 3。
Microcompaction：比 autoCompact 更轻量的机制，在空闲期后（与 cache 过期时间挂钩）触发。保留 tool_use blocks，但将实际工具输出替换为 [Old tool result content cleared]，始终保留最近 5 条工具结果。默认禁用，通过 GrowthBook feature flag 服务端控制。
Cache 边界标记：源码包含 __SYSTEM_PROMPT_DYNAMIC_BOUNDARY__ 命名标记，将系统提示分为"全局缓存区"（工具定义、核心指令）和"session 特定区"（项目配置、git 状态、时间戳）。14 向量的 promptCacheBreakDetection.ts 和"sticky latch"机制防止功能切换意外触发 cache miss。详见 prefix caching。
虚拟上下文管理：OS 视角的统一框架¶
MemGPT（Packer et al., 2023）提出了 虚拟上下文管理，将上述各种策略置于一个统一的 OS 类比框架下：context window = RAM，外部存储 = 磁盘，compaction = RAM 内压缩，structured note-taking = write-back，sub-agent = 多进程隔离。
这一框架的价值在于揭示：本节记录的各种 context management 策略并非零散的工程技巧，而是对同一个有限快速存储 + 无限慢速存储资源管理问题的不同解法——与 OS 虚拟内存管理面临的问题同构。但需注意类比的边界：LLM 不是确定性处理器，context 变化直接影响推理质量（context rot），信息换入换出的代价不对称。
OS 级 Context 切换：快照与恢复¶
AIOS 将 context management 扩展到推理中断与恢复维度——既非 compaction（有损压缩），也非 full reset（全部丢弃），而是精确快照。
当 agent scheduler 中断一个 agent 的 LLM 推理时，context manager 保存中间状态：
- 文本快照：保存已生成的文本（适用于闭源 API）
- Logits 快照：保存搜索树的中间状态（候选 token + 概率），恢复时从断点精确继续
这与上述策略的适用场景不同：compaction/note-taking/sub-agent 解决的是"context 太长怎么办"，快照恢复解决的是"推理被中断怎么办"。在多 agent 并发场景下（Round Robin 调度），推理中断是常态而非异常，快照机制是基础设施级需求。
AIOS 的 Memory Manager 还实现了 LRU-K 换页策略：访问不足 K 次的 agent 对话历史从 RAM 换到磁盘——这是 MemGPT 分层存储思路在多 agent 场景下的自然延伸。
Session 外部化：平台级 Context 存储¶
Managed Agents 将 context 存储从 sandbox 内部提升为独立的持久化服务——session 不是 Claude 的 context window，而是 context window 之外的可查询对象。
这解决了 compaction/trimming 的根本矛盾：这些操作是不可逆的，但无法事先知道未来的 turn 需要哪些 token。Session 日志保证了所有事件都可以被回溯查询（getEvents() 按位置切片），即使已从 context window 中移除。
与 MemGPT 的 虚拟上下文管理 相比，两者都将 context 从 RAM 类比扩展到 RAM + 磁盘模式。但 Managed Agents 进一步将存储从执行环境中分离：MemGPT 的外部存储在同一进程中，session 是独立的持久化服务。这使得 harness 可以崩溃后从 session 恢复，也使得不同的 harness 实现可以共享同一个 session——这是 meta-harness 架构的基础。
harness 还可以在将 session 事件传递给 Claude 之前做任意变换——包括面向 prefix caching 命中率的 context 组织和面向特定模型的 context engineering。存储与变换的关注点分离，使两者可以独立演进。
References¶
sources/manus-context-engineering.mdsources/claude-code-source-leak-2026.mdsources/dont-break-the-cache.mdsources/anthropic_official/effective-harnesses-long-running-agents.mdsources/anthropic_official/harness-design-long-running-apps.mdsources/anthropic_official/harnessing-claudes-intelligence.mdsources/anthropic_official/introducing-claude-opus-4-6.mdsources/openai_official/unrolling-codex-agent-loop.mdsources/chroma-context-rot.mdsources/anthropic_official/effective-context-engineering-for-ai-agents.mdsources/arxiv_papers/2512.18470-swe-evo.mdsources/arxiv_papers/2603.29231-beyond-pass-at-1-reliability-science-framework.mdsources/factory-evaluating-context-compression.mdsources/arxiv_papers/2403.16971-aios-llm-agent-operating-system.mdsources/arxiv_papers/2310.08560-memgpt-towards-llms-as-operating-systems.mdsources/karpathy-software-is-changing-again.mdsources/anthropic-managed-agents.md