OpenWiki Brains 与 wiki memory 模式：智能体记忆从反应式推到主动式

摘要

LangChain 在 7/10 发布 OpenWiki Brains 0.1.0（npm 包名 openwiki，MIT 协议）。该版本把 OpenWiki CLI 的覆盖范围从代码库文档扩展到个人工作流的多源接入：Personal Brain 模式接入 Gmail、Notion、git 仓库、X、Hacker News、Web search 六类连接器，按用户设定的节奏自动刷新到本地 markdown wiki。同期 LangChain 发布概念文章，把 Cognition DeepWiki、Karpathy LLM Wiki、Factory AutoWiki、LangMem/Letta/Mem0/Zep 放到同一坐标系，提出 wiki memory 作为通用智能体记忆形态。截至 7/13，仓库累计 10.9K stars。

引言

让智能体自己查看原始数据、自己写入本地 markdown 文件——而不是写入向量库——OpenWiki Brains 0.1.0 在这个方向上做了一个反直觉的工程选择。LangChain 对现有助手内置记忆的整体评估是：Claude、ChatGPT、LangSmith Fleet 等内置记忆属于反应式（reactive），只记录用户显式说出的内容或对话中可推断的内容，不适合跨工具、每天变化的工作上下文。OpenWiki Brain 把记忆推到主动式（proactive）——智能体在用户没有说"记下来"的情况下，根据初始化时给定的提示词从连接器抽信息，写入本地 wiki。

OpenWiki 的演化路径

OpenWiki 仓库于 6/22 创建，最初定位是为代码库生成并维护智能体文档的 CLI——在 git 仓库内运行，在 openwiki/ 目录写出文档，并在仓库根的 AGENTS.md 与 CLAUDE.md 里维护自己的 … 引导块。CI workflow 自动开 PR 更新。7/9 发布的 0.1.0 版本拆出两个独立模式：

• Code Brain
  （原有）：在当前代码库内运行，输出 openwiki/ 文档，覆盖 git history、文件关系、编码约定
• Personal Brain
  （新）：在本地 ~/.openwiki/wiki/ 内运行，从六类连接器拉取信息合成 markdown，由 macOS LaunchAgent 按用户设定的节奏自动刷新

两个模式分开的原因在于它们解决的问题不同：Code Brain 关心仓库结构与代码约定，Personal Brain 关心跨工具的工作上下文。底层思路一致——为智能体提供一层由智能体自己维护、持久化、可检视、随时间更新的上下文。

截至 7/13，仓库 10.9K stars、743 forks、MIT 协议、npm 包名 openwiki，一周内从 0.0.2 走到 0.1.2 共五个版本。

主动式与反应式的工程分界

现有助手内置记忆只能保存用户显式告诉它的内容，以及能从对话里推断出来的内容。 这一层适合保存用户偏好与已分享的事实，不适合处理"Slack 里刚到的项目更新""Notion 里新落下的会议纪要""邮件里某条线程、X 上某条收藏"这类跨工具、每天变化的工作上下文。

在工程实现上，OpenWiki Personal Brain 通过六个连接器接入：

• git-repo
  ：读取本地仓库 manifest
• x
  （OAuth 2.0 + PKCE）：timeline、user posts、mentions、bookmarks、list posts
• notion
  （OAuth，走托管的 Notion MCP server）：工作区检索
• gmail
  （Google OAuth）：邮件
• web-search
  （Tavily + LangChain）：定向搜索
• hackernews
  ：公开 API

确定性连接器（git/x/gmail/hackernews）直接拉数据写 manifest，具备智能体特性的连接器（notion/web-search）由智能体携带工具在摄入阶段搜索。原始数据与 manifest 写入 ~/.openwiki/connectors/，数据源相关的子智能体把原始数据合成到 ~/.openwiki/wiki/。Slack 连接器在路线上。

主动式记忆在摄入阶段就让智能体工作，不必等到查询阶段。 初始化时用户告诉 OpenWiki Brain 关注什么（默认提示词是通用个人助理，可定制），后续每次按节奏刷新时，智能体都按该提示词在连接器数据里筛选、合并、写入。反应式记忆只在对话里出现信号时被动更新，不做主动摄入。

为什么是 markdown 文件，不是向量库

LangChain 在公告里显式做了这个选择，给出的理由是：

Markdown is easy to read, easy to inspect, and easy for agents to navigate. It also keeps the brain visible on the filesystem instead of hiding it behind an interface.

这个选择放在 2026 年的智能体记忆赛道里有点逆潮流。多数记忆框架（Mem0、Letta、Zep、LangMem）的默认基底是向量库或图数据库，便于检索、可承载规模、与现有 RAG 工程栈对接。LangChain 的反方向选择承载几层工程意图：

一、可检视性优先于检索效率。markdown 在文件系统上，用户可以直接打开查看智能体写了什么、改错了什么、是否泄露敏感信息。向量库的内容不可直接检视，调试与审计成本高。

二、可版本化优先于嵌入紧耦合。markdown 走 git，每次刷新可 diff、可回滚、可在 PR 里 review。这对治理智能体写入的内容是必要前提。

三、与现有智能体工作流耦合。Code Brain 已经在 AGENTS.md 与 CLAUDE.md 里嵌入引导块——智能体读取这些文件是已有习惯。Personal Brain 输出的 markdown 可直接被编码智能体或其他 CLI 智能体读取，不需要专门的检索服务。

LangChain 公告里同步列了未来探索方向：full-text search、MCP、semantic search、agentic search、Google Open Knowledge Format。markdown 是起点，LangChain 想先验证"智能体维护的文件"作为基底是否成立，再考虑在文件之上加检索层。

wiki memory 模式的生态坐标

LangChain 同期发布的「wiki memory」概念文章把这个模式放到生态坐标里：

wiki memory 的共同点是智能体维护一份持久化、结构化、可检视、随时间更新的数据结构。 它与底层 RAG 的差别在于：RAG 在查询时检索原始文本块，wiki 在摄入时合成更高层级的表示，智能体不必每次重新解析原始数据的结构。

LangChain 同时给出边界：wiki memory 不是记忆的全部。它适合持久化的领域知识，不适合短期对话状态、用户偏好、高频事件日志。后三类仍归反应式记忆系统处理。OpenWiki 因此不替代 Mem0 或 LangMem，而是补一层此前没有开源标准答案的工作上下文：持久化、文件形态、由智能体自己合成。

同期值得对照的几条信号

Karpathy 的 LLM Wiki gist（未独立核实，据 LangChain 文章引述）给出的框架与 OpenWiki 接近：LLM 增量构建并维护一个持久化的 markdown wiki，作为用户与原始数据源之间的中间层。两者的差别在于，Karpathy 给出的是概念，LangChain 给出的是开源 CLI 与六类连接器。

Factory AutoWiki 的工程更偏企业侧：多阶段多智能体流水线（survey → plan → generate in dependency order → publish）、四个交付面（web viewer / GitHub wiki / Droid session / repo 内 droid-wiki/ 目录）、CI 自动 refresh 走 GitHub Actions 或 GitLab CI、增量生成（首次跑全量、后续按 commit hash diff 只重生受影响 page）。OpenWiki 与之的差别在于部署形态：Factory 跑在工厂云上，产物落到企业交付面；OpenWiki 跑在本地，产物落到用户机器。

Cognition 的 DeepWiki 是这一模式的早期可参考样本，2025-05 发布、已索引 50K+ 公开仓库。OpenWiki Code Brain 与之的差别在于开源 CLI 与本地可控，DeepWiki 是托管服务。

收尾

OpenWiki Brains 在工程上把"智能体记忆"这个抽象问题落到一个具体、可检视的产物上——本地 markdown 文件，由智能体按节奏写入、由用户在需要时读取与修改。载体选择的影响比检索算法的选择更大：它决定了谁能审计智能体写了什么、谁能修改、谁能回滚。OpenWiki 与 Mem0 报告把记忆当成基准测试战场，是两个维度的工程取向——前者处理"用什么形态"，后者处理"用什么算法"。两者并不互斥。LangChain 把形态层先于算法层做出来并开源，是把"记忆系统应该被用户看见"这件事放到了优先级靠前的位置。下一阶段 wiki memory 是否会走向 LangChain 公告里提到的 Open Knowledge Format 等更结构化的形态，需要更长周期的观察。

信源说明

OpenWiki Brains 的特性、版本号、stars、连接器设计、Personal Brain 与 Code Brain 的分工、markdown 选择的工程理由，均来自 LangChain 官方公告与 GitHub repo README 实点核对。Karpathy LLM Wiki gist 因 robots.txt 拒绝自动 fetch，相关引述来自 LangChain 「wiki memory」概念文章的二手描述，未独立核实原文。Cognition DeepWiki 的发布时间与已索引仓库数量来自 cognition.ai 官方博客。Factory AutoWiki 的流水线与交付面设计来自 factory.ai 官方页面。Mem0 / Letta / LangMem / Zep 在 wiki memory 坐标系里的位置，属于作者基于公开材料的归类判断。