OKF Agent Memory 开源:GIT 原生持久化记忆,以及 Coding Agent 跨会话状态层与企业 Agent 工程新基线

2026 年下半年,Git 原生持久化的 Agent 记忆方案开始系统化出现。9 月 5 日,一个名为 OKF Agent Memory 的开源项目在 Hacker News 上发布,获得了 81 个点赞与广泛讨论,自我定位是「基于 Open Knowledge Format (OKF) v0.2 的、域中立的、Git 原生持久化项目记忆」。它解决了一个让所有生产 Coding Agent 用户都头疼的工程痛点——每次上下文窗口关闭或会话重置,Agent 都会「忘记」架构决策、领域发现、操作规则;传统的解决方案要么把大量知识塞进 AGENTS.md 或 CLAUDE.md 导致「prompt 膨胀」与「注意力漂移」(agent 忽略关键指令),要么把行为规则丢进向量数据库但 agent 永远不会主动语义搜索操作约束。OKF Agent Memory 的工程方案是「双记忆架构」(Dual-Memory Agent Architecture, DMAA)——Layer 1 是「推式规范工作记忆」(~100-150 tokens 的极简行为法典,使用 Agent Action Grammar 确定性微语法,常驻系统提示),Layer 2 是「拉式语义域记忆」(OKF v0.2 知识包,基础占用 0 tokens,按需检索);查询耗时低于 300 微秒。几个月前(2026 年 2 月 12 日),Letta 公司也发布了一篇关于「Context Repositories」的工程博客,提出「把 Agent 上下文存储在本地文件系统,基于 Git 版本化」的方案——Agent 可以利用完整的终端与编码能力(包括编写脚本、生成子 Agent)来管理上下文,支持渐进式信息披露、Token 空间内的上下文重写、多 Agent 通过 Git worktree 并发写入记忆等。两个项目代表了一个工程新基线:Agent 跨会话状态层正在从「会话级临时数据」走向「Git 原生持久化资产」,让 Agent 记忆可以像代码一样被版本化、审查、迁移。

一、OKF Agent Memory 的双记忆架构(DMAA)

OKF Agent Memory 的工程设计从「失败模式」出发——它识别出 Agent 记忆管理的两个核心失败模式,然后针对性地设计解决方案。第一失败模式是「Prompt 膨胀」——把所有知识与规则塞进 AGENTS.md 或 CLAUDE.md,文件膨胀到 20K+ tokens,导致「注意力漂移」(Agent 忽略关键指令);第二失败模式是「RAG 盲区」——把行为规则丢进向量数据库,但 Agent 在执行一般任务时从来不会主动语义搜索操作约束(格式化规则、安全规则等)。这两个失败模式共同导致「Agent 知道但不应用」的工程痛点——知识存在但不被使用。

OKF Agent Memory 的工程解决方案是「双记忆架构」(DMAA)——把记忆严格分为两层。第一层是「推式规范工作记忆」(Normative Working Memory, Push Layer)——一个常驻系统提示的极简行为法典,~100-150 tokens,使用「Agent Action Grammar (AAG)」确定性 ASCII 微语法表达;这一层只包含「零容忍不变量」(项目特定的安全规则、伦理准则、语气风格),保证 Agent 在每个会话开始时就能看到这些关键约束。第二层是「拉式语义域记忆」(Semantic Domain Memory, Pull Layer)——一个 OKF v0.2 知识包,基础占用 0 tokens,按需检索;Agent 通过 `okf_search`、`okf_show` 等工具在微秒级时间内检索相关知识,而不是把整个知识库塞进上下文。

DMAA 架构的几个关键工程指标展示了它的工程成熟度——查询耗时低于 300 微秒,图验证约 4 毫秒,基于内存 BM25 检索;这些指标意味着 Agent 在每次操作中可以多次查询记忆而不会成为性能瓶颈。另一个关键工程决策是「100% Git-Native」——所有记忆都是版本化的纯文本,可以用标准 `git diff`、`git log` 检查、审计、审查;无需外部数据库,无供应商锁定。OKF Agent Memory 还基于 Google Cloud Platform 发布的 OKF v0.2 开放标准(支持 provenance、trust tiers 等),意味着记忆格式本身是标准化的,可以跨不同 Agent 框架互操作。

二、Letta Context Repositories:文件系统即记忆

Letta 的 Context Repositories 方案从「文件即记忆」的角度切入同一问题。它把 Agent 的记忆存储在本地文件系统中,让 Agent 可以利用完整的终端与编码能力(包括编写脚本、生成子 Agent)来管理上下文,支持渐进式信息披露(progressive disclosure)与 Token 空间内的上下文重写。这种「文件系统即记忆」的工程设计有几个关键优势——文件是 Agent 与人类都能理解的通用原语,Agent 可以用熟悉的工具链(grep、sed、bash 脚本)操作记忆;每个会话开始时,Agent 拥有自己的本地记忆副本,可以离线操作;Git 自动版本化所有记忆变更,提供完整的审计历史。

Letta 的工程设计在「多 Agent 协作」场景下尤其有价值。传统的 Agent 记忆系统在多 Agent 协作时面临并发写入冲突问题——多个 Agent 同时尝试修改同一份记忆会导致数据竞争。Letta 的解决方案是 Git worktree——每个子 Agent 拥有独立的 worktree,可以在不干扰其他 Agent 的情况下修改记忆;子 Agent 完成修改后,合并回主分支,通过 Git 的冲突解决机制协调冲突。这种「并发 worktree」机制让 Letta 支持「记忆 swarm」(memory swarm)——多个记忆子 Agent 并行处理不同方面的学习,然后合并到共享记忆库。例如,Letta 的 `/init` 工具可以选择性地从 Claude Code 或 Codex 历史中学习,fan-out 到并发子 Agent,每个子 Agent 在自己的 worktree 中处理历史片段,然后合并到「主记忆」分支。

Letta 还设计了「渐进式信息披露」机制——记忆文件的目录结构始终在系统提示中,作为导航信号;每个记忆文件包含 YAML frontmatter,描述文件内容;`system/` 目录下的文件会被完整加载到系统提示,其他文件按需检索。这种「渐进式信息披露」让 Agent 能够在不同任务上下文中动态调整可见记忆,而无需每次都检索整个记忆库。

三、Coding Agent 跨会话状态层的工程基线

OKF Agent Memory 与 Letta Context Repositories 共同代表了一个工程判断:Coding Agent 的跨会话状态层应该遵循「Git 原生 + 双记忆架构 + 渐进式信息披露 + 多 Agent 并发」的工程基线。这个基线包含几个关键维度。第一维度是「Git 原生」——所有 Agent 记忆都应该是版本化的纯文本,可以用标准 Git 工具审查、迁移、协作;这种选择让 Agent 记忆可以像代码一样被工程团队管理,而不是黑盒的外部服务。第二维度是「双记忆架构」——把「关键约束」(零容忍不变量)与「大量知识」(领域发现、操作规则)分离,前者常驻系统提示,后者按需检索;这种设计解决了「prompt 膨胀」与「RAG 盲区」的根本问题。第三维度是「渐进式信息披露」——Agent 记忆应该按需展示,而非一次性全部加载;`system/` 目录作为常驻、其余作为按需,让 Agent 能够在不同任务上下文中动态调整可见记忆。第四维度是「多 Agent 并发」——多个 Agent 应该能够并发修改记忆而不产生冲突,Git worktree 提供了天然的并发原语。

第五维度是「性能可接受」——记忆查询必须足够快(< 1 秒),不能成为 Agent 执行的性能瓶颈;OKF 的 BM25 检索 < 300 微秒、图验证 ~4 毫秒展示了性能优化的方向。第六维度是「标准兼容」——记忆格式应该基于开放标准(OKF v0.2),让不同 Agent 框架能够互操作;标准化避免记忆数据被锁定在特定 Agent 框架。第七维度是「零外部依赖」——记忆应该能够完全在本地存储与检索,不需要外部向量数据库或云服务;这种设计让 Agent 记忆可以部署在隔离网络、homelab 等受限环境。

四、企业构建 Agent 跨会话状态层的实践路径

企业部署 Agent 跨会话状态层有几个具体的实践路径。第一步是「选择记忆方案」——基于 OKF Agent Memory 与 Letta Context Repositories 等开源项目,根据企业 Git 平台、Agent 框架、集成深度选择合适的方案;OKF 适合需要标准化知识格式与 AAG 微语法的企业,Letta 适合需要灵活文件系统记忆与多 Agent 并发的企业。第二步是「设计双记忆架构」——明确划分「推式工作记忆」(关键约束,常驻系统提示)与「拉式域记忆」(大量知识,按需检索)的边界;推式记忆应该控制在 100-200 tokens,拉式记忆可以无限扩展。第三步是「建立记忆生命周期管理」——定义 Agent 何时保存记忆、何时更新记忆、何时遗忘记忆;记忆生命周期应该与项目阶段、任务类型、用户偏好等因素联动。第四步是「建立记忆审计机制」——基于 Git 的版本化能力,定期审计记忆变更、识别过期记忆、清理冗余记忆;记忆审计让企业能够保持记忆库的高质量,避免 Agent 引用过时或错误信息。

第五步是「建立多 Agent 协调机制」——当多个 Agent 同时修改记忆时,基于 Git worktree 隔离每个 Agent 的工作空间,通过合并流程协调冲突;多 Agent 协调让企业能够部署多个 Agent 同时学习,大幅提升记忆构建效率。第六步是「建立评测体系」——基于真实任务评估 Agent 记忆的有效性(是否引用了正确知识、是否避免了错误应用);评测结果应该定期反馈到记忆架构的优化。第七步是「建立迁移路径」——当企业需要更换 Agent 框架或记忆方案时,基于 Git 原生与开放标准的记忆格式应该能够平滑迁移,避免记忆资产被锁定。

五、从 Agent 跨会话状态到企业 AI 资产化

OKF Agent Memory 与 Letta Context Repositories 的出现标志着一个 Agent 时代的工程转向——从「会话级临时数据」走向「Git 原生持久化资产」。这种转向的工程价值与传统 IT 时代从「临时文件」走向「版本控制资产」的演进路径类似——临时文件方便但不可持续,版本控制资产能够被审查、协作、迁移,最终成为企业的有形资产。Agent 记忆的 Git 原生化让 Agent 的学习经验、领域知识、操作规则可以累积、传承、协作,真正成为企业的智能化资产。

从更宏观的视角看,Agent 跨会话状态层的成熟代表企业 AI 化进入了一个新阶段——从「关注单次任务能力」走向「关注长期能力积累」,从「演示概念」走向「可累积的资产」。模型可以换,围绕 Coding Agent 建立的 Git 原生记忆层(双记忆架构、渐进式信息披露、多 Agent 并发、性能可接受、标准兼容、零外部依赖)才是企业 AI 时代的关键护城河。OKF Agent Memory 与 Letta Context Repositories 等开源项目的工程价值,正在于它们让 Agent 时代的记忆基础设施真正落地,让企业能够在 AI Agent 时代构建真正可累积、可传承、可协作的智能化资产。