Appearance
多Agent共享知识系统：我的三仓架构实践
不要让每个 AI 都有一套孤立记忆，而是让它们共用一个可审计的知识系统。
最近我做了一件很小、但可能会长期改变我使用 AI 的事情：我把自己的 AI 工作系统，拆成了三个仓库。
不是三个软件仓库，而是三个「认知仓库」：
- Memory：记住我是谁
- Wiki：记住我们想清楚了什么
- 文稿库：记住我们正在做什么
起点：每个 Agent 都像刚认识我
我发现自己同时在用不同的 AI 入口：OpenAI Codex、Claude Code、Hermes、OpenClaw。
每个 Agent 都很强，但它们有一个共同问题：它们都像刚认识我。
哪怕我已经在另一个对话里讲过自己的偏好、项目、资料、关系、判断框架，换一个入口之后，很多事情又要重新说一遍。
这不只是麻烦。更大的问题是：如果每个 Agent 都有一套自己的 memory，时间久了，我会得到五六个版本的「我」。
- 一个 Agent 记得我的写作计划
- 一个 Agent 记得我的出版社关系
- 一个 Agent 记得我的工具配置
- 一个 Agent 又根据某次临时对话，错误地形成了一个过期判断
最后的问题就变成：到底哪个记忆是真的？
一、不要急着做「统一数据库」
很多人一听到「多 Agent 共享记忆」，第一反应是：那是不是应该有一个统一 memory 数据库？
我一开始也这么想。但后来发现，这个方向很容易变成新的负担。
因为不同 Agent 的记忆系统并不一样：有的是 Markdown 文件，有的是向量数据库，有的是 SQLite，有的是自动摘要……
如果强行合并，表面上看是统一了，实际上会引入几个问题：
- 记忆格式不一致
- 写入规则不一致
- 过期机制不一致
- 不知道哪个 Agent 写入的内容更可信
- 一旦插件坏了，整个工作流都会被拖慢
这个经历让我确定一件事：个人 AI 知识系统的核心，不应该是某个黑箱 memory 插件，而应该是一套人能看懂、Agent 也能遵守的知识结构。
二、我的三仓结构
我最后确定了一个很简单的分工。三个地方，各有职责：
| 位置 | 定位 | 内容特征 |
|---|---|---|
| Memory | 私人记忆 | 偏好、长期约束、稳定事实 |
| Wiki | 知识关系网络 | 概念、对比、人物关系、方法论 |
| 文稿库 | 可执行工作台 | 项目卡、行动清单、变现数据、工具链 |
一句话：Memory 记事实，Wiki 记知识网络，文稿库记成品。
更直观一点：
- Memory = 让 Agent 理解我的地方
- Wiki = 我思考的地方
- 文稿库 = 我做事的地方
三、Memory：让 Agent 理解我
Memory 放什么？放那些相对稳定、长期有效、会影响 AI 如何理解我的信息。
比如：
- 我的基本背景
- 我的长期偏好
- 我的沟通风格
- 我的重要关系
- 我的项目历史
- 我的长期约束
它回答的问题不是「这篇文章讲了什么」，也不是「这个项目下一步怎么做」。
它回答的是：Agent 应该如何理解我？
这类信息非常重要，但也最敏感。所以我给 Memory 定了一个原则：默认只读，授权写入。
写入必须满足几个条件：
- 用户明确要求记住
- 先检查是否已有相关记录
- 追加优先，不覆盖
- 私人记忆、公开信息、推断、待核实要分层
- 不把凭据、隐私细节、未经确认的人物画像随便写进去
这让 Memory 成为一个稳定的私人事实层，而不是一个自动堆垃圾的地方。
四、Wiki：让知识可以被复用
Wiki 是整个系统里最关键的一层。它不是 Obsidian 的炫技，也不是简单资料夹。
它是我和不同 Agent 一起形成的「长期知识网络」。
适合放进 Wiki 的内容包括：
- 一个概念到底是什么
- 两个工具有什么区别
- 某篇文章的关键观点
- 某个方法论和我的工作有什么关系
- 某个判断以后还会不会复用
- 多个 Agent 应该遵守什么协作规则
这里我用了一个很重要的原则：不要在查询时才检索，要在摄入时就编译。
很多人的知识库是这样的：先把资料扔进去，等以后需要时再让 AI 检索。
但问题是，未经整理的资料，只是资料堆。
真正有价值的是：
- 这篇文章和我已有的哪个主题有关？
- 它更新了哪个概念？
- 它推翻了哪个旧判断？
- 它能不能变成一个未来会反复问的问题？
- 它应该链接到哪个人物、产品、公司、方法论？
所以 Wiki 的作用，不是存东西，而是编织关系。
五、文稿库：真正做事的地方
文稿库不是 Wiki。这是我这次整理中最重要的一个判断。
Wiki 和文稿库的动作本质不同：
- Wiki = 思考
- 文稿库 = 执行
Wiki 里放的是概念、关系、判断。文稿库里放的是项目卡、行动清单、投稿邮件、课程材料、公众号文章、变现方案、工具链。
一个负责「想清楚」，一个负责「做出来」。
如果把它们强行合并，边界会变模糊：
- 这个文件是知识定义，还是项目状态？
- 这段内容是长期判断，还是本周待办？
- 这个页面应该被所有 Agent 引用，还是只是某篇文章的草稿？
边界一模糊，后面所有 Agent 都会困惑。
所以我的策略是：内容分仓，导航合并。
六、什么叫导航合并？
导航合并的意思是：两个地方仍然分开，但入口体验统一。
比如我在 Wiki 里有一个 AI 平台导航页。这个页面不保存每个平台的全部项目资料，只保存：
- 平台是什么
- 它和其他平台的关系
- 它的核心定位
- 对应文稿库项目卡的链接
当我要真正执行时，再跳到文稿库里的项目卡。
类似这样：
Wiki/index.md
→ AI平台导航
→ OpenClaw 实体页
→ 文稿库/OpenClaw/项目卡.md这样做的好处是：用户和 Agent 都可以从 Wiki 开始找东西，但真正的项目推进、行动清单、草稿和交付物，仍然留在文稿库。
检索体验统一，内容边界清晰。
七、三个入口，不是三个孤岛
为了让不同 Agent 都能接入这套系统，我保留了三个关键入口：
第一个，Codex / Openclaw 的自动入口
/Users/guan/AGENTS.md这个文件是 Codex / OpenCode 会自动读取的约定入口。我把它当成一个适配器，告诉 Codex 去读真正的权威架构。
第二个，Hermes Memory 的入口
/Users/guany/.hermes/memories/memory/MEMORY.md这是私人记忆层的入口。Hermes、OpenClaw 这一类常驻型 Agent，可以从这里理解我的长期背景。
第三个，跨 Agent 的权威共享架构
/Users/guan/Documents/LLM-Wiki/_meta/yongchuan-ai-knowledge-system-architecture.md这才是真正的总说明。所有 Agent，只要能读本地文件，都应该先读它。
八、这套系统真正解决了什么？
它解决的不是「AI 有没有记忆」，而是更底层的问题：多个 AI 入口，如何共同服务同一个长期目标？
以前，一个 Agent 做完一件事，知识留在对话里。换一个 Agent，又从头开始。
现在，流程变成：
新资料进入
→ raw 原文归档
→ Wiki 编译成知识关系
→ 文稿库沉淀成行动产物
→ 必要时 Memory 记录稳定事实Agent 不再只是「回答问题」，它开始参与建设一个长期系统。
每一次阅读、每一次判断、每一次复盘，都可以变成下一次工作的起点。
九、给普通用户的建议
如果你也想搭建类似系统，不一定照搬我的目录。但我建议你至少区分三类东西：
第一类：私人事实
比如你是谁、你在做什么、你的长期偏好、你和哪些人有关系。这类东西要谨慎写入，稳定后再保存。
第二类：知识网络
比如你长期关注的主题、方法论、工具比较、文章消化、项目判断。这类东西要持续编织，不要只让 AI 做一次性摘要。
第三类：行动产物
比如文章、方案、课程、清单、邮件、项目卡。这些东西要放在真正能执行和交付的地方。
最简单的版本可以是：
memory/
wiki/
workbench/不一定复杂，关键是边界清楚。
结语：不要把记忆交给黑箱
我越来越觉得，个人 AI 系统最重要的不是用了哪个模型，也不是装了多少插件。
而是你有没有一套属于自己的知识操作系统。
模型会变，Agent 会变，插件会变。但如果你的知识资产是清晰的、可读的、可迁移的，那么换任何入口都能继续工作。
不要让每个 AI 都单独记住你。让所有 AI 都学会进入你的知识系统。
这才是多 Agent 协作真正开始的地方。
关键词：多Agent协作, AI知识系统, Memory系统, Wiki知识库, 个人知识管理, Agent共享记忆, 知识架构设计
