过去我一直把 AI 的“记忆”当成一个产品功能：ChatGPT 记一点，Claude 记一点，Codex 读一点项目文件。直到我开始更重度地和 Agent 协作，才意识到这件事反了。
真正重要的记忆，不应该属于某一个 Agent。
它应该属于我。
触发我重搭个人知识库的契机，是 Andrej Karpathy 提到的 LLM Wiki 思路：不要让模型每次都从原始材料里重新检索、重新拼接，而是让 LLM 持续把原始材料“编译”成一个结构化、可链接、可维护的 Markdown wiki。这个想法击中了我，因为我当时刚好遇到一个非常具体的问题：我和 Agent 的大量沟通、决策、踩坑、项目复盘，都散落在不同聊天窗口里。
这些信息如果只停留在某个 Agent 的记忆中，本质上就不是我的资产，而是那个产品里的缓存。
1. 从聊天记忆，到共享上下文层
我的 Agent 使用路径经历了几个阶段。
最早是 Claude Chat：一个聊天窗口里问问题、写东西、整理想法。这个阶段，“记忆”看起来像是产品体验的一部分。Agent 记住我是谁、我在做什么，就已经很有用。
后来迁到 Claude Cowork，协作开始变成项目制：有文件、有上下文、有持续推进的任务。再往后到 Claude Code，Agent 不再只是回答问题，而是直接进入 repo，改代码、跑测试、读文档、做 code review。这个时候，真正可靠的上下文已经不是聊天记录，而是项目里的 git 历史、PRD、AGENTS.md、测试结果和文档。
再后来我开始 Codex 和 Claude 双持：Codex 更适合实现和 git 工作，Claude 更适合设计、研究、review 和长上下文讨论。两边能力互补，但也带来一个新问题：如果上下文分别存在两个产品的“记忆”里，它们很快就会分叉。
A 记得的偏好，B 不知道；A 做过的决策，B 只能靠我重新解释；一个账号或客户端突然不可用，整条协作链路就断一截。
某次 Claude 账号突然不可用之后，这件事变得更具体。真正让我后怕的不是少了一个工具，而是如果关键上下文只存在那个工具里，我会失去一部分自己的工作记忆。
这篇文章写出来之前，我刚做过一次真实迁移：把过去在 Claude 里沉淀下来的长期偏好、协作方式、项目背景，整理成 Codex 能读的外部记忆，并让工作电脑和家庭电脑都从同一套记忆启动。这次迁移让我更确信：真正有价值的不是某个产品里那份“记住我”的能力，而是记忆能不能被导出、被整理、被新的 Agent 读取，并且在不同机器上保持一致。
如果我只依赖 Claude 自己的记忆，切到 Codex 时，大量偏好都要重新训练一遍；如果工作电脑和家庭电脑各自维护一套记忆，它们也会很快分叉。最后可行的方式，还是把稳定偏好、项目规则和知识库维护方式写进文件，让不同 Agent、不同电脑都从同一套外部事实源启动。
所以我最后意识到，我需要的不是让某一个 Agent 更会记住我，而是把记忆从 Agent 里搬出来。
知识库负责长期上下文：我是谁、我的项目、我的方法论、我的复盘、哪些事实已经沉淀过。项目 git 负责执行上下文：当前代码、真实 diff、PRD、测试、部署状态。Agent 只是来读这些事实源、执行任务、再把有价值的新信息写回去。
这也是我后来搭个人知识库的核心转变：它不是笔记系统，而是多 Agent 协作的共享上下文层。
2. 不是所有信息都值得落库
搭知识库最容易走偏的一点，是把它变成“什么都往里塞”。我现在的判断刚好相反：知识库的价值不来自存得多，而来自筛选标准足够稳定。
我会把信息分成三类。
第一类是未来会复用的上下文。比如我在不同项目里的协作偏好、某个产品决策为什么这么做、某类坑下次应该怎么避开。这些信息如果不落库，每次换 Agent 或换线程，我都要重新解释一遍。
第二类是会影响 Agent 执行的事实。比如个人项目的 repo 规则、PRD、部署状态、KB schema、工具配置、某个服务真实验证过没有。这些不能只靠记忆，因为 Agent 会拿它们做后续动作。只要事实源错，后面跑得越快，偏得越远。
第三类是值得沉淀成资产的复盘。比如 vibe coding 项目、Agent workflow、开放平台方法论、职业发展中的长期判断。这类内容不是为了当天能用，而是为了以后能复用、能组合、能对外表达。
这里有一条必须反复强调的硬边界：公司文档、内部资料、业务数据、会议纪要、可还原到具体项目的敏感上下文，都绝对不能进个人知识库。这不是“谨慎一点”的问题，而是真的会触碰公司合规和信息安全红线。不要因为 Agent 读起来方便，就把公司材料复制、同步、改写后存进私人系统。工作相关内容只保存我自己的思考、抽象后的方法论、充分脱敏后的复盘，以及可以公开讨论的行业判断。换句话说，知识库记录的是“我如何理解和成长”，不是把公司材料搬到私人系统里。
反过来，临时聊天、一次性情绪、还没有经过验证的猜想，不急着进 wiki。它们可以留在 raw 里，但不能直接变成“知识”。
这就是我现在的三层结构：
raw/：原始材料，保存来源和上下文，不追求可读；范围仍然只限个人材料、公开资料和脱敏内容。wiki/：编译后的知识，要求可复用、可链接、可被 Agent 直接读。published/：已公开内容镜像，让站点文章和知识库之间保持连接。
这套结构背后的原则很简单：raw 保真，wiki 提炼，published 回流，git 执行。
3. 分类逻辑：生活、工作、投资，但重点不是标签
我把 wiki 分成三个大支柱：生活、工作、投资。
生活不是流水账，而是长期状态管理：旅行复盘、健康状态、生活方式、制作项目。工作不是公司文档库，也不是内部资料备份，而是个人思考、方法论、AI 产品、开放平台和职业发展复盘。投资也不是交易日志，而是资产配置、投资框架和市场分析。
这些分类不是为了好看，而是为了让 Agent 能判断：这条信息应该被放在哪里、以后应该从哪里找、和哪些页面互相链接。
这里还有一类信息不是纯文本，而是结构化数据。我用个人飞书做记账和资产配置表管理，也打通了个人飞书，让 Agent 能在授权范围内读取这些个人表格，再把月度财务复盘、支出结构、资产配置变化的解释沉淀进知识库。它和 Obsidian 的分工也很清楚：飞书适合承载表格、字段和计算，知识库适合承载解释、判断和复盘。
这里同样有合规红线：接入的是个人飞书和个人数据，不是公司飞书；同步的是个人记账、资产配置和复盘结果，不涉及公司文档、内部表格或业务数据。千万不要为了让 Agent 自动分析，就把公司飞书、公司表格或任何内部业务数据接进个人系统。
这里有一个微妙但重要的边界：分类可以是私人化的，但表达要是可公开的。
比如我可以承认我用 AI 跟进健康状态、生活状态和职业发展，这没问题；但具体体检数据、财务细节、公司内部项目、内部文档和可识别的业务信息，就不应该出现在公开文章里，也不应该原样进入个人知识库。对外展示的是系统形状，不是私人内容。
4. 为什么需要 log：知识库也要有审计链路
如果只有 wiki，知识库很快会变成另一个文件夹。
所以我保留了 index.md 和 log.md 两个文件。index 解决“有什么”，log 解决“为什么变”。
每次新增或修改重要页面，log 里会记录来源、动作、更新页面和核心结论。这样做有两个好处：
一是我自己能追踪知识是怎么来的。尤其是 Agent 参与写作和总结之后，如果没有来源记录，几个月后很难判断一段话是事实、推断，还是当时某个 Agent 的临时总结。
二是 Agent 能在下一次接手时快速恢复上下文。它不需要重新读完整个 vault，只要先看 index 和近期 log，就能知道最近发生了什么、哪些页面是新的事实源、哪些结论刚刚被修正过。
这件事在多 Agent 协作里尤其关键。Claude 做过的事，Codex 可以从 log 里接上；Codex 修改过的规则，Claude 下次也能读到。记忆不再属于某个工具，而是通过文件系统变成共享事实。
5. AGENTS / CLAUDE 文件：给 Agent 的维护协议
光有目录还不够。Agent 如果不知道规则，就会把知识库写乱。
所以我的知识库里有一份规则文件，告诉 Agent：语言怎么写、目录怎么分、raw 和 wiki 的边界是什么、哪些文件只读、哪些文件可以维护、什么时候必须更新 index 和 log。
这类规则文件的价值，在编码项目里很容易理解：AGENTS.md 或 CLAUDE.md 会告诉 Agent 怎么跑测试、怎么改代码、什么不能碰。放到知识库里，本质一样。它不是给人看的 README，而是给未来的 Agent 看的操作协议。
这也是我后来越来越相信“项目 git + 知识库”双事实源的原因。
项目 git 管执行事实：代码、diff、commit、测试、部署。
知识库管长期事实：决策、复盘、方法论、上下文、公开内容镜像。
Agent 不是事实源。Agent 是使用事实源的人。
6. 踩坑：最脆弱的地方不是模型，而是路径
这套系统真正跑起来之后，最麻烦的坑并不来自模型能力，而来自基础设施。
第一个坑是 iCloud。我的 Obsidian vault 放在 iCloud 里，手机和家用 Mac 都能同步，但某些工作环境会关闭 iCloud Drive。结果是：知识库本身很好，跨设备策略也合理，但在这些机器上就是不可用。
这让我意识到，“知识外部化”不是一句口号。外部化之后，路径、同步、权限、挂载方式，全都会变成系统的一部分。
所以我后来没有把 iCloud 当成唯一同步方案。
iCloud 仍然适合做 Obsidian 的日常同步：手机、家用 Mac、随手查看都很方便。但它不是一个足够稳定的 Agent 协作底座，因为工作电脑可能关闭 iCloud Drive，MCP 也可能被真实路径里的空格、撇号和特殊目录名绊住。
真正用来保证工作电脑和家庭电脑一致的，是私有 GitHub 仓库。
这和代码项目的逻辑一样：本地文件夹只是工作副本，真正的同步和版本历史应该交给 git。知识库也是类似的：Obsidian 提供阅读和编辑体验，iCloud 提供个人设备间的便利同步，私有 GitHub 仓库提供跨机器一致性、变更记录和回滚能力。这样即使某台机器的 iCloud 不可用，我也可以通过 git 把同一套知识库拉下来，让 Claude、Codex 或其它 Agent 继续读同一个事实源。
当然，这里同步的仍然只是个人思考、公开资料整理和脱敏复盘；公司文档、内部资料和敏感业务信息绝对不能进入这个私有仓库。私有不等于合规，“只有我自己看”也不是把公司材料放进个人仓库的理由。
第二个坑是 iCloud 路径本身。macOS 下 Obsidian iCloud vault 的真实路径长这样：
/Users/.../Library/Mobile Documents/iCloud~md~obsidian/Documents/Henson's Personal Knowledge里面有空格、撇号和特殊目录名。对人来说只是路径，对 MCP filesystem server 这类工具来说，就可能变成解析、转义和配置的坑。最后我用了一个更稳定的 symlink，把复杂路径收敛成干净入口，再让 Agent 通过这个入口访问。
第三个坑是不同 Agent 的“记忆”不通用。Claude Chat、Claude Cowork、Claude Code、Codex，各自都有自己的上下文边界。你不能假设一个产品里的偏好，会自然出现在另一个产品里。
所以最后的结论不是“记忆功能不好”，而是：产品记忆适合改善体验，不能承担系统事实源。
7. 这套系统真正解决了什么
回头看，我搭的不是一个更复杂的笔记系统，而是一个更稳的协作协议。
它解决的第一个问题是迁移。Agent 换了，账号换了，客户端换了，只要知识库和 repo 还在，核心上下文就还在。
第二个问题是接力。一个 Agent 做过的决策，不需要靠另一个 Agent 猜；它可以读 log、读 wiki、读 git history。
第三个问题是复用。一次项目复盘，不只是当天的总结，而可以变成下一篇文章、下一个项目、下一次面试表达、下一次产品判断的材料。
第四个问题是边界。raw 和 wiki 的分层，让我知道什么只是材料，什么已经被我确认成知识；git 和 KB 的分层，让我知道什么是执行事实，什么是长期上下文。
这就是我现在对个人知识库的定义：
个人知识库不是第二大脑，也不只是笔记软件。
在 Agent 时代，它是一套把个人上下文从产品记忆里外部化出来的基础设施。
当 Agent 还只是聊天助手时，记忆在聊天窗口里就够了。
当 Agent 开始进入 repo、写代码、做 review、维护文档、跨模型接力时，记忆必须离开聊天窗口，变成它们都能读取、都能更新、也都能被审计的外部事实源。
这也是我为什么把 Agent 的记忆搬出聊天窗口。