模型: openai/gpt-5.4 生成日期: 2026-04-01 书名: Claude Code VS OpenCode：架构、设计与未来 章节: 第8章 — 配置与可定制性 Token消耗: N/A（当前运行环境未暴露按文件统计的Token数量）
8.2 项目记忆系统
配置决定智能体在会话开始前“应该怎样工作”，而记忆系统决定会话结束后“哪些东西应该留下来”。在现代 AI Coding Agent 中，记忆早已不只是聊天历史。它更像是一层持久化知识结构，用来保存协作习惯、项目上下文和非代码层面的长期信息。
本书讨论的三个系统有一个共同起点：它们都把 CLAUDE.md、AGENTS.md、README.md 这类 Markdown 文件当作知识载体。这个约定非常关键，因为它同时服务两类读者：人类开发者可以直接维护，Agent 也能直接注入到上下文中。
共同约定：用 Markdown 做可审计知识库
OpenCode、Claude Code 和 OMO 共享的核心模式，是把项目知识外化到纯文本文件里。README.md 首先是写给人的，但它也天然是 Agent 的项目背景材料。CLAUDE.md 和 AGENTS.md 则更偏向智能体使用，它们承载规则、约束、工作方式和局部约定。
这背后有一个非常重要的架构变化：项目记忆不再完全藏在黑盒数据库里，而是部分转化为可读、可 diff、可 review、可版本化的工件。
Claude Code：类型化记忆模型
Claude Code 在记忆建模上走得最远。在 src/memdir/memoryTypes.ts 中，它把记忆明确分成四类：
userfeedbackprojectreference
这四类并不是随意命名，而是对“什么值得长期记住”做了边界约束。
user 记录用户的角色、偏好和能力结构。feedback 记录用户或团队对工作方式的反馈，例如“不要这样做”“以后保持这种方式”。project 记录项目中的进行中目标、约束、时间点、事故背景等，它们通常无法仅靠读代码推导出来。reference 则记录外部系统入口，比如 Linear、Grafana、文档站点、Slack 频道等。
更重要的是，Claude Code 还明确规定什么“不应该”写进记忆。比如代码模式、架构结构、文件路径、git 历史，以及已经写在 CLAUDE.md 里的内容，都不应存入 memory。这个边界非常成熟：记忆只保存“不可从当前项目状态直接推导”的信息。
Claude Code 还支持 scope，也就是作用域。它区分 private memory 和 team memory。可以把 scope 理解为“知识的归属边界”：有些记忆只属于某个用户，有些应该对团队共享。源码中的 teamMemPaths.ts 展示了这套路径与校验逻辑。
此外，Claude Code 对记忆陈旧性也有明确处理。memoryAge.ts 会把记忆转化为 “today”“yesterday”“47 days ago” 这样的可读年龄，并在较旧记忆上加 freshness warning。这个设计很有深度，因为 persistent memory 最大的问题不是“忘记”，而是“记错且不自知”。Claude Code 明确承认 memory 是时间切片，而不是实时真相。
OpenCode：更像 instruction memory，而不是 typed memory
OpenCode 的持久化思路不同。它在 session/instruction.ts 中负责发现并加载 AGENTS.md、CLAUDE.md 以及旧的 CONTEXT.md。这些文件既可以来自全局目录，也可以沿项目目录树向上查找；同时还支持配置中声明的 instruction 路径和 URL。
这意味着 OpenCode 更像是在构建一套 instruction management system，而不是 Claude Code 那种强类型 memory store。它假设长期知识最好通过“文档化指令”来表达，而不是拆成大量细粒度记忆条目。
这并不弱，只是取向不同。OpenCode 擅长的是显式、可检查的上下文注入。Agent 进入仓库后，会沿目录树发现 instruction files，把它们纳入 system prompt 组装流程。随着 agent 深入子目录，局部 instruction 也可以逐步生效。
所以，OpenCode 的记忆更偏向“文档即记忆”；Claude Code 的记忆则是“文档 + 类型化持久知识”。
OMO：自动注入上下文，再加工作记忆
OMO 在这个问题上做得非常工程化。
第一，context-injector 会自动把关键项目文档，例如 AGENTS.md 和 README.md，注入到对话上下文里。这意味着主智能体不需要每次都先自己想到去读这些文件。OMO 把项目背景变成默认存在的底层上下文。
第二，rules-injector 会在相关文件被读取或修改时，把 .sisyphus/rules/*.md 中的规则片段注入进来。这是一种按需激活的记忆机制。它不是把所有规则一股脑塞进 prompt，而是在具体工作触发时注入相关规则。若借用系统领域术语，这更像 demand paging，也就是“按需分页”，而不是一次性静态加载。
第三，OMO 很强调目录级知识局部性。它支持分层 AGENTS.md 的使用。Agent 越深入目录树，越可能命中更具体、更局部的 instruction 文件。对于大型 monorepo，这种局部性非常关键，因为不同子系统往往有不同规范。
第四，OMO 还引入了 Atlas notepad 体系，位于 .sisyphus/notepads/。其中会记录 learnings、issues、decisions、problems 等内容。这和 Claude Code 的长期 typed memory 不完全一样。它更接近一种跨多回合、多子任务的 working memory，也就是“工作记忆”。
“工作记忆”不是教科书里典型的 AI coding 术语，但从计算机系统角度看，可以把它理解为外部 scratchpad：它可以跨轮次持久存在，但仍然强绑定于某个计划、某次编排、某个执行过程。
这个区别很重要。长期记忆保存的是关于用户或项目的较稳定事实；notepad 保存的是某个执行计划中逐步积累的操作性知识。
从 Prompt Engineering 走向 Context Engineering
这三套系统真正共同体现的趋势，是从 Prompt Engineering 转向 Context Engineering。
所谓 Prompt Engineering，本质上是想写出一段足够聪明的说明文字，让模型一直表现良好。Context Engineering 则关注另一件事：什么信息应该被放进上下文、何时放进去、以什么作用域存在、过期后如何提醒或更新。
Claude Code 用 typed memory、scope 和 freshness check 实现这一点。OpenCode 用 instruction file 发现、frontmatter 解析和 prompt 组装实现这一点。OMO 则用自动注入、规则钩子、目录级知识和 notepad 体系，把上下文管理做成了编排基础设施。
这是一种非常本质的升级。Prompt 只是字符串；Context System 则是一套信息架构。
设计启示
好的 Agent 记忆系统至少应满足四个条件。
第一，必须区分“可推导事实”和“不可推导事实”。代码里能重新读出来的东西，通常不应该长期存成 memory。
第二，必须承认记忆会陈旧。没有 aging 机制的 memory，长期看会变成累积性的错误来源。
第三，必须支持多作用域：个人、团队、项目、任务局部。这些作用域对应的是现实世界中的所有权边界。
第四，必须让持久化知识可审计。Markdown、notepad、typed memory files 的共同优点，是人类能检查、修订和删除它们。
所以，未来 Agent 的关键并不只是更大的 context window。更大的窗口当然有帮助，但它并不能自动解决知识组织问题。真正困难的是：哪些内容应该进入 durable instructions，哪些应该写入长期记忆，哪些只适合放在临时 scratchpad，哪些则应始终从 live state 重新计算。
这就是从 Prompt Engineering 走向 Context Engineering 的核心：不是写更漂亮的话，而是设计更清晰的记忆边界。