LangChain 最近推出的 OpenWiki，表面上看是一个自动生成 repo 文档的工具。

它真正打到的是 agent 工程里一个越来越核心的问题：

Agent 的记忆层，正在从 prompt 技巧变成基础设施。

这件事会影响很多开发工作流。

今天的 coding agent 工作流里，开发者经常会先塞一段规则给它：项目怎么启动、测试怎么跑、哪些目录不要碰、架构上有什么约束。再复杂一点，就写进 AGENTS.md、CLAUDE.md，或者放进某个系统提示词。

短任务里，这样做还可以。

任务一长，问题很快出现。

Agent 每次都要重新读背景。同一批文件被反复探索。架构约束和临时说明混在一起。旧事实没有失效，新事实没有沉淀。上一次任务里学到的东西，下一次又从零开始。

这时候，真正的问题已经不在“模型能不能读更多 token”。

问题变成了：

一个 agent 系统，应该如何拥有长期、可维护、可追溯、可更新的记忆层。

OpenWiki 的价值就在这里。

它生成 wiki，更新 AGENTS.md / CLAUDE.md，让 agent 知道去哪里读仓库知识。这个动作看起来很小，但背后代表了一种架构变化：

Prompt 负责当前任务。记忆层负责长期背景。权威源仍然是代码、ADR、PR、commit、runbook 和人工确认事实。Wiki 是一层可导航、可审阅、可被 agent 消费的 derived context。

我认为它值得单独拎出来讲，原因正在这里。

一、Agent 记忆层的历史路径

Agent 的记忆问题不是突然出现的。

它是从软件工程和知识管理一路演化过来的。

最早，团队主要依赖 README、Wiki、Confluence、Notion、飞书文档。

这套东西服务的是人。人可以慢慢读，可以判断哪一页过时，可以问同事，也可以凭经验补上下文。文档不够新鲜，虽然麻烦，但不会立刻让整个系统失控。

后来有了代码搜索和 IDE 索引。

开发者能更快找到函数、类、引用、调用关系。对开发者来说，这是巨大的进步。但它解决的是“找代码”，没有解决“理解意图”。

系统可以找到某个模块在哪里，却未必回答这些问题：

为什么这个模块这样切分？ 哪些依赖不能碰？ 当初做过哪些取舍？ 历史上踩过什么坑？ 谁对这个边界负责？

再后来是 RAG。

文档被切片、embedding、召回、重排，再交给模型回答问题。RAG 让模型可以引用企业资料，也让知识库问答变得很容易搭。

但 RAG 的核心仍然是检索和阅读材料。

它回答的是：提问时怎么找到资料、拼出证据、交给模型生成答案。

长期 agent 需要的还有另一半：平时怎么记，怎么更新，怎么失效，怎么审阅，怎么写回。

于是出现了 memory API、stateful agent、LangMem、Mem0、Letta 这类路线。它们开始把 memory 作为 agent 的一等能力：用户记忆、会话记忆、agent 记忆、semantic memory、episodic memory、procedural memory。

这一步很关键。

但如果放到企业和研发场景里，只靠 memory API 还不够。

企业记忆不能只是一个黑盒偏好列表。它要能被人看见、能追源、能删除、能审计、能处理权限、能区分当前事实和历史事实。

再往后，就是 OpenWiki 这类 Knowledge Compiler / Repo Wiki 方向。

它不急着把所有东西塞进向量库，也不急着建一套完整企业图谱。它先做一件朴素但很有用的事：

把复杂仓库编译成一层人和 agent 都能读的上下文。

这是一条很现实的路。

因为 repo 天然有边界。git 天然有变化记录。Markdown 天然可 review。AGENTS.md 天然可以成为 agent 入口。

所以 repo wiki 很适合作为 agent 记忆层的第一站。

二、记忆层的底层逻辑

记忆层的第一性问题，其实只有一句：

模型的上下文窗口不能承担组织记忆。

上下文窗口再长，也只是一次运行时材料。

组织记忆要解决的是另一类问题：

什么值得长期保留？ 这个事实来自哪里？ 现在还有效吗？ 它和哪些模块、系统、客户、决策有关？ 谁能读？ 谁能改？ 错了怎么办？ 下一次 agent 怎么用？

这套问题无法靠更长 prompt 解决。

更长的 prompt 只会把更多材料塞进一次任务里。它不会自动区分权威源和派生上下文，不会自动标记过期事实，不会自动把任务结果写回长期系统。

所以记忆层需要变成一套基础设施。

可以把它拆成六个动作：

capture -> compile -> retrieve -> use -> update -> govern 

capture 是捕获。代码、PR、issue、runbook、会议、决策、事故、客户反馈，都可能成为上下文来源。

compile 是编译。原始材料不能直接等于记忆。它要被整理成 module map、runbook、decision、constraint、known gotcha 这类更适合 agent 使用的形式。

retrieve 是检索。Agent 不应该每次读完整仓库，它应该根据任务打开相关上下文。

use 是消费契约。Agent 要知道哪些内容只是导航，哪些内容可以引用，哪些内容必须回源码或 ADR 验证。

update 是写回。Agent 完成任务后，应该提出新的上下文候选，比如新的坑、新的约束、新的模块边界。但这些内容要先进入 candidate 状态，不能直接变成 verified fact。

govern 是治理。谁写入、谁确认、何时过期、能不能被删除、能不能被审计，这些决定记忆层能不能进入生产。

这就是记忆层和普通知识库的区别。

普通知识库更关注“资料能不能被问到”。

Agent 记忆层关注“上下文能不能长期参与工作流”。

三、记忆层最容易踩的坑：把派生上下文当权威源

这一点特别重要。

Repo wiki、自动总结、RAG answer、memory entry，都不应该天然成为权威事实。

权威源仍然应该是：

• 代码；
• ADR；
• PR 和 review；
• commit；
• issue；
• runbook；
• 测试；
• 会议记录；
• 人工确认过的事实。

Wiki 的角色是 derived context。

它负责把权威源整理成更容易读、更容易导航、更适合 agent 消费的形态。它可以帮助 agent 少走弯路，但不能替代源码、决策记录和真实运行结果。

这就像地图和土地的关系。

地图很重要。没有地图，行动效率很低。但地图过时的时候，最终还是要看真实地形。

放在 agent 工作流里，这个边界应该写进规则：

repo-context 是 derived context。架构敏感修改必须回到源码、ADR、PR 或 runbook 验证。任务结束后，agent 只能提交 context update candidate，不能直接标记为 verified。

这个小规则能避免一个很大的问题：记忆污染。

一旦 agent 把推断写进长期记忆，下一次又把这条记忆当事实使用，系统就会开始自我强化错误。

所以记忆层要有状态。

至少需要五种状态：

candidate -> verified -> stale -> superseded -> archived

 candidate 是候选，只能作为线索。

verified 是确认过、有来源的事实。

stale 是可能过期的上下文。

superseded 是被新事实替代的历史背景。

archived 是保留追溯价值，但默认不进入当前上下文的材料。

这套状态机，比“有没有文档”更重要。

很多企业知识系统失败，根源常常不在文档数量，而在旧文档仍然以当前事实的身份参与工作。

四、为什么成本问题会变成核心技术问题

讲记忆层，不能只讲知识管理。它背后还有很现实的成本问题。

Agent 的成本，不只是模型调用费用。

它至少包括四类成本：

第一类是 token 成本。

如果每次任务都把规则、README、历史决策、runbook、常见坑、相关代码一起塞进上下文，成本会很快失控。上下文越长，模型越容易被噪声干扰，延迟也会上去。

很多团队会直觉地说：那就换更长上下文模型。

这只能缓解容量问题，不能解决选择问题。

真正该问的是：这次任务到底需要哪些上下文？

记忆层的价值，就是把“每次全量塞”变成“按任务选择性打开”。

第二类是探索成本。

Coding agent 在陌生仓库里，经常会反复读入口文件、搜索相同关键词、打开一堆无关模块。表面上看只是多花了几个工具调用，实际上背后是时间、token、错误率和 review 成本。

Repo wiki 如果做得好，可以直接降低探索成本。

Agent 先读 module map，再读相关 runbook 和 constraints，然后再进源码。路径会短很多。

第三类是错误成本。

这是最贵的。

Agent 误解模块边界，改错层级，破坏架构约束，引用过期事实，或者绕过某个隐含规则，都会把成本转移给人类 reviewer。

这类成本不一定体现在账单里，但会体现在：

• PR review 变慢；
• 人要反复纠正 agent；
• 团队不敢让 agent 做长任务；
• 自动化越多，返工越多；
• 最后信任被消耗掉。

记忆层如果只是“更会搜索”，价值有限。它真正要降低的是上下文理解错误。

第四类是最容易被忽视的维护成本。

知识会过期，wiki 会漂移，本体会变复杂，memory 会积累垃圾，这个整理的成本会很高。长期记忆越多，维护成本越高，甚至高到你肉疼的程度。

这就是为什么记忆层必须有 lifecycle、owner、source、last_verified、confidence、review queue。

没有维护机制，记忆层会从资产变成负债。

所以成本问题最后会落成一个技术判断：

便宜的记忆，关键在于每次任务都能低成本拿到刚好够用、足够可信、可追溯的上下文。

五、行业正在往哪里走

我看到的清晰方向大概有七条。

第一条是 hybrid retrieval。

向量检索、关键词、metadata filter、rerank、citation 会继续组合。单纯 vector search 很难承担企业级上下文。

第二条是 agentic RAG。

Agent 不再只做一次检索，而是会拆问题、多轮查找、判断证据缺口、继续补资料。这条线适合复杂研究和跨源分析，但主要解决的仍然是“如何找资料、读资料、形成答案”。

第三条是 memory API 和 stateful agent。

Mem0、LangMem、Letta 这类方向会继续发展。它们让 agent 跨会话保留用户、任务和过程状态。用于企业场景时，还需要补可见性、权限和事实治理。

第四条是 Knowledge Compiler / Wiki。

OpenWiki 属于这条线。它先把复杂材料编译成可读知识面，再让 agent 通过入口文件找到它。这条线很适合从代码仓库开始，因为仓库边界清楚，变化可追踪，人也能 review。

第五条是 ontology / temporal graph。

这是记忆层走向企业级之后绕不开的结构化方向。

它的核心价值，是把事实、关系和时间有效性变成可计算对象。

Wiki 让知识可读。本体让知识可计算。时间图谱让系统知道事实什么时候有效、什么时候被替代。

企业大脑最终一定会需要这一层。因为企业里的很多问题关心的是“谁负责什么、什么依赖什么、哪个决策替代了哪个决策、当前有效事实是什么”。

第六条是 workflow / runtime。

上下文不会自己保持新鲜。系统要定期 refresh、根据 diff 更新、发现 stale fact、修 broken citation、做 dedup、进入 review queue。

第七条是 governance / observability。

进入企业生产后，每次读写都要有身份、scope、审计、成本记录和质量评估。否则记忆层越强，风险也越大。

这些路线组合起来，记忆层会从一个功能，变成 agent runtime 旁边的一层基础设施。

六、从哪里开始落地

如果要落地，我建议不要从“企业大脑”这个大词开始。

更稳的第一步，是先选一个真实仓库，做一个最小 repo context plane。

第一版只需要七个文件：

repo-context/  00-index.md  01-module-map.md  02-ownership.md  03-runbook.md  04-known-gotchas.md  05-architectural-constraints.md  06-decisions.md

然后在 AGENTS.md 里只写导航入口：

复杂代码修改前，先读 repo-context/00-index.md。涉及架构边界时，必须读 architectural-constraints 和 decisions。repo-context 是 derived context，关键判断仍要回源码、ADR、PR 或 runbook 验证。任务结束后，只能提出 context update candidate，不能直接标记 verified。

这套东西不复杂，但它抓住了记忆层的核心。

它让 agent 知道哪里有长期上下文。它让人类可以 review 这层上下文。它让上下文更新有候选和确认过程。它给未来的本体、图谱和企业治理留了接口。

第一阶段也不要做太多指标。

第一阶段先看几件事：

• agent 首次定位相关模块是否变快；
• 重复探索文件数是否下降；
• review 中上下文理解错误是否减少；
• 架构敏感修改是否能引用权威源；
• 每个任务是否能产出有价值的上下文更新候选。

如果这些都没有改善，说明这层 wiki 只是漂亮文档。

如果这些开始改善，说明记忆层已经在改变 agent 的工作路径。

七、最后收一下

我对 OpenWiki 这类工具的判断很直接：

它把自动文档生成推向了更高一层：agent 记忆层的架构外移。

过去，太多长期背景被塞进 prompt。

接下来，更稳的做法会是：

Prompt 负责当前任务。Memory layer 负责长期上下文。Workflow 负责刷新和写回。Ontology / graph 负责可计算事实。Governance 负责权限、审计和质量。

Agent 系统越往长任务、后台任务、团队协作和企业生产走，这层记忆基础设施就越重要。

模型能读多少上下文，当然还会继续提升。

但真正拉开差距的，会是另一件事：

一个组织能不能持续生产、维护、治理一层可被 agent 使用的长期记忆。

这层记忆越稳，agent 越能做长期工作。

这层记忆越乱，agent 越容易把错误放大。

所以我会把这个方向看成下一阶段 agent 工程的基础设施问题。

参考来源

• Introducing OpenWiki, an open source agent for repo documentation
• Graphiti: Build Temporal Context Graphs for AI Agents
• Mem0: Universal memory layer for AI Agents
• LangMem: Long-term Memory in LLM Applications
• Letta: Introduction to Stateful Agents
• OpenSPG / KAG: Knowledge Augmented Generation
• Agent 上下文基础设施：从 OpenWiki 到企业大脑