模型: openai/gpt-5.4
生成日期: 2026-04-01
书名: Claude Code VS OpenCode：架构、设计与未来
章节: 第20章 — 上下文工程
Token用量: 约 6,700 input + 1,850 output

20.2 四种记忆策略

上下文工程真正落到可执行层面，离不开对“记忆”这件事的重新理解。很多人会把记忆简单理解成“把历史留着”，但对 coding agent 来说，这远远不够。好的系统不会把 memory 当成一个混在一起的大桶，而会采用多种不同的记忆策略，分别应对不同问题。最值得单独讨论的四种策略是：JIT retrieval（即时检索）、compaction（压缩）、structured notes（结构化笔记）、sub-agents（子智能体）。

这四种策略并不互斥，反而常常协同工作。它们真正回答的是四个不同问题：信息应该何时被拿进来？历史应该何时被压缩掉？哪些状态应该显式写下来？哪些工作应该被放到独立上下文里？

一、JIT retrieval：需要时再取

JIT 是 just-in-time 的缩写，原意来自制造与系统设计中的“准时制/按需供给”。放到 agent 语境里，JIT retrieval 指的是：不是一开始就把所有可能相关的信息塞进上下文，而是在确定需要的时候再检索进来。

这在仓库级 coding work 里特别重要。一个大型代码库有成千上万文件，不可能也没必要先全塞给模型。更合理的方式是：先搜索，再读局部；先定位，再深入。只有当前假设真正需要某个文件、某条历史、某段文档时，才把它拉进上下文。

JIT retrieval 最适合“相关信息范围很大，但当前真正相关的子集未知”的场景。比如项目文档库、历史会话、代码仓库、外部 API 文档。它的优点是节省上下文预算、减少噪音；缺点是如果搜索系统太弱，或者检索路径设计不好，可能导致频繁往返。

OpenCode 通过文件工具、搜索工具、会话结构为这种策略提供了基础。OMO 则把它做得更动态，比如通过 rules injector 只在合适时机注入规则。Claude Code 虽然对用户暴露得更少，但其 memory 与 retrieval 行为本质上也在做类似事情。

二、Compaction：让历史变轻

Compaction 可以直译为压缩，但在 agent 系统里它不是简单文本压缩，而是在保留有效状态的前提下，把长历史折叠成短而可继续工作的形式。长任务进行到一定阶段后，原始历史会越来越长，模型不得不花很多 token 回看自己已经做过的事。这时，如果继续硬扛，效率和稳定性都会下降。

所以 compaction 的目标不是“把东西变短”这么简单，而是保留：任务目标、已完成动作、关键发现、未解决问题、当前计划，以及必须继续遵守的约束；同时舍弃：冗长表述、已经无用的岔路、重复确认和过细过程细节。

什么时候适合用 compaction？答案很直接：当历史已经学会了它该教会模型的东西，而继续完整重放它反而开始拖累判断时。

Claude Code 的 auto-compact 代表的是产品级实现：系统主动感知上下文压力并压缩。OpenCode 的 session compaction 展示了框架层机制。OMO 则说明 compaction 不只是窗口大小触发，还可能和工作流、todo、continuation 状态一起被组织。

三、Structured Notes：把中间状态显式写出来

Structured notes 可以理解为“面向机器消费的有结构笔记”。它不是普通聊天记录，而是对当前任务状态的显式编码。里面通常会写：当前目标、已知事实、关键文件、待验证假设、风险点、下一步动作、未完成事项等。

为什么这很重要？因为大量 coding task 的关键发现，往往字数很短、价值却极高。例如：“只在 macOS 下复现”“问题发生在兼容层而非核心模块”“测试都过了，只差 snapshot 更新”“旧配置仍然被 hook 注入”。这些如果埋在聊天历史里，模型以后要重新找出来很贵；如果被提炼成结构化笔记，就会成为非常稳定的工作记忆。

什么时候适合用 structured notes？凡是任务跨很多步、中间发现又需要长期保留、或者人类和 agent 都需要共享稳定检查点时，都适合。OMO 的 todo discipline（待办纪律）和 continuation 很接近这种思路。Claude Code 的 memory 系统也朝这个方向演化，只是产品包装更强。OpenCode 则给上层实现这种状态对象提供了灵活底座。

四、Sub-agents：把记忆拆到独立上下文里

很多人谈 sub-agents 时只把它们当作一种编排方式，但其实它也是一种记忆策略。因为一旦委派出一个子 agent，系统本质上就创建了一个新的上下文分区。它不再要求主上下文持续吸收所有局部细节，而是让一小块工作在一小块记忆空间里完成。

这种方法特别适合需要 scope isolation（作用域隔离）的任务：代码库探索、外部文档检索、独立验证、平行调查、审阅复核。通过子 agent，主上下文可以只保留问题定义和结果摘要，而不用承受整个局部探索过程的全部细节。

当然，sub-agents 不是没有成本。它有启动成本、总结成本、编排成本。如果任务本身很小、上下文污染也不严重，那委派反而得不偿失。只有当“上下文隔离收益”大于“委派额外成本”时，sub-agent 才值得使用。OMO 是这方面最鲜明的例子，Claude Code 更保守地使用，OpenCode 则提供其底层可实现性。

什么时候该用哪一种

这四种策略可以很简洁地对应四个问题。

• JIT retrieval：我现在需要事实，但还不知道哪些事实最重要；
• compaction：我已经学到了很多，不能再背着原始历史继续走；
• structured notes：我需要把关键中间状态稳定地存下来；
• sub-agents：这块工作不该继续污染主上下文，应该独立处理。

在优秀系统里，这四者往往会串起来工作。主 agent 先按需检索，发现有价值的信息后写进结构化笔记；历史太长时做压缩；遇到特别适合隔离的子问题时，再委派给子 agent。这样形成的不是“单一记忆”，而是一套分层记忆架构。

其核心思想是：记忆不等于把一切都留住，而是决定什么该加载、什么该保留、什么该凝缩、什么该外化、什么该隔离。很多人把大 context window 误认为记忆问题的终结，其实它只是延后了问题的暴露。真正让系统稳定的，不是窗口更大，而是记忆策略更清晰。

所以，对 coding agent 来说，优秀的记忆不是“记得最多”，而是“记得最有选择性”。JIT retrieval、compaction、structured notes、sub-agents，正是这种选择性如何变成正式架构的四种典型方式。