LLM 记忆系统：从 Markdown 知识库到 Self-Governing Repo

长期上下文不是更大的窗口，而是一套可维护、可纠错、可演化的个人知识工程。

原文链接 ：AI 小老六

导语

当 LLM 长期记忆 开始进入日常工作流后，一个很快会暴露出来的问题是：模型在单次对话里的推理能力越来越强，但长期上下文的继承能力仍然很弱。每次重新打开一个会话，都像重新启动一个临时进程：身份、项目背景、关注方向、旧结论、已踩过的坑，都需要重新装载。

这类问题很容易被误判成"缺少一个更大的上下文窗口"，或者"需要一个更强的向量数据库"。但如果把它放到工程系统里看，真正缺失的不是 存储本身，而是一套能持续维护、能区分证据来源、能在规模变大后继续演化的个人工作上下文系统。

Karpathy 在 "LLM Knowledge Bases" 中提出过一个很朴素但关键的判断：中等规模知识集未必需要复杂 RAG，raw/ 原始资料、结构化 Markdown、索引和 LLM 推理，已经可以编译出一个可用的知识库。这个判断可以再往前推一步：如果把知识库从"资料整理工具"升级成"持续运行的工作上下文"，它就不只是 wiki，而更像一个轻量的个人操作系统。

Context Bootstrap：长期上下文不是聊天记录

很多 AI 记忆方案会从"保存聊天记录"开始，但聊天记录只是原始日志，不等于可用上下文。真正有用的上下文至少要回答四个问题：

上下文问题	需要沉淀的内容	典型载体
当前用户是谁	偏好、约束、长期状态、协作习惯	`meta/me.md`
当前在关注什么	活跃主题、未闭环问题、近期判断	`meta/threads.md`
最近发生了什么	原始对话、工具输出、纠错信号	`logs/`
已形成哪些知识	文章、素材、项目结论、技术判断	`content/`

这里的关键不是把所有对话堆进一个文件，而是把对话拆成不同生命周期的数据：原始信号保存在日志中，稳定事实进入 meta，主题材料进入 content，临时判断保留来源和时间。下一次会话启动时，AI 不需要回放所有历史，只需要先读入口文件和索引，就能恢复"我在和谁协作、最近在推进什么、哪些信息可信"。

这种设计把 AI 会话从"无状态函数调用"变成了"带启动上下文的工作进程"。会话仍然是临时的，但它挂载的文件系统是连续的。

图：Markdown、Git 与 LLM 共同构成可审计的长期上下文工作台

Markdown File System：为什么不是先上向量数据库

个人或团队级别的中等规模知识系统，第一性问题通常不是召回，而是可维护性。向量数据库擅长相似度检索，却不天然解决这些问题：

某条结论来自用户原话、工具输出，还是 AI 推导？
这条信息是否过期？
多个主题之间的责任边界怎么划分？
纠错后如何追踪错误来源，并防止同类问题复发？
新的维护规则如何被下游 Agent 继承？

Markdown + Git 的好处在于，它把这些治理动作变成了普通工程动作：文件可读、diff 可查、commit 可追溯、目录可分权、索引可审计。一个轻量版本的记忆系统可以只由几类目录组成：

目录	职责	工程含义
`meta/`	用户、目标、活跃线程	会话启动时的上下文装载区
`logs/`	每天的原始对话与工具输出	append-only 事件流
`content/`	文章、素材、研究结论	可复用知识层
`_agents/`	各类维护 Agent 的规则与 scope	后台 owner 注册表
`_signals/`	跨域问题、冲突、升级请求	Agent 间通信通道

这个结构不复杂，却有一个重要变化：知识不再只靠"搜索出来"，而是被持续整理成有责任边界的文件。LLM 的角色也不是把所有内容塞进 prompt，而是像编译器一样，把原始材料编译成可链接、可索引、可审计的知识层。

图：原始材料被编译为可装载的会话上下文

从单进程到后台进程：第一轮架构拆分

这类系统通常不会一开始就设计成多 Agent。更可能的演化路径是：先有一个大规则文件，所有职责都塞进去。它既要和用户聊天，又要写日志，还要更新索引、维护知识库、检查一致性。

这很快会遇到"注意力竞争"问题。对话过程本身需要流畅推进，维护过程又需要结构化写入和校验。当同一个会话同时承担这两类任务时，经常会出现两种故障：要么聊着聊着跑去改文件，要么改完文件后丢失了当前对话脉络。

第一轮拆分通常会把系统变成"读写分离"：

对话层负责自然交流和追加原始日志。
后台维护层定期消费日志。
Lint、GC、Refactor 等进程分别处理结构检查、过期清理和深度重构。

这个阶段可以解决"对话被维护任务打断"的问题，也让系统开始具备定时维护能力。但它仍然有一个隐含假设：后台进程只要定期扫描全局，就能发现有价值的问题。

实践中，这个假设很容易失效。格式错误、索引缺失、文件生命周期异常，可以靠规则扫描发现；但"这条信息应该归谁管""这条推导能不能当事实""这个结论是不是跨域影响另一个主题"，就不是简单 Lint 能判断的。系统真正难的地方不是文件格式，而是内容归属和证据治理。

Evidence Routing：原始信号和 AI 推导必须分层

一个长期记忆系统最危险的污染源，不是信息缺失，而是把不同可信度的信息混在一起。用户明确说过的话、工具实际返回的结果、仓库里已有的证据、AI 根据上下文推导出的解释，这四类东西不能同级处理。

如果 AI 把自己的推理静默写成事实，下游 Agent 后续再消费这些文件时，就会把二级推导当成一级证据。错误不会立刻爆炸，但会在长期迭代中被放大，最后形成"越维护越偏"的知识库。

因此，记忆系统需要一条底层协议：所有写入都必须保留 来源等级。

等级	证据类型	示例	处理方式
A	用户确认、工具输出	明确反馈、CLI 结果、API 返回	可直接下发维护
B	仓库证据、日志索引	已提交文件、历史记录、索引摘要	可用，但保留引用
C	AI 推导、二手信息	模式判断、原因猜测、外部转述	先标注，必要时验证
D	冲突、过期、无 owner	与旧结论矛盾、无人负责	上报、隔离或等待决策

这条规则看起来像文档规范，实际是系统安全边界。它约束了 Agent 的写入权限：AI 可以推断，但不能把推断伪装成用户事实；可以补充解释，但必须让后续维护者看得出这只是派生判断。

图：信息按证据等级进入不同处理路径

Owner Scope：多 Agent 的重点不是数量，而是责任田

当系统继续变大，单纯的"后台进程"会逐渐变成瓶颈。原因不是进程不够多，而是它们缺少内容责任边界。更稳定的形态，是把系统拆成一组 owner：每个 owner 只负责自己的 scope，并按同一套证据协议消费日志。

在这种模式下，对话层只负责保存原始事件；各个 owner 自己读取日志，判断哪些内容属于自己的责任田，再更新对应文件。新增 owner、休眠 owner、拆出子 owner，都不应该影响正常对话。

这和传统任务调度的差别很大。调度框架关心"谁什么时候运行"；Self-Governing Repo 更关心"谁对哪块知识负责、能采纳什么证据、遇到边界问题时怎么升级"。

一个 owner 至少需要具备四个动作：

动作	触发条件	结果
消费	日志中出现与 scope 相关的新信号	更新自己的知识文件
拒绝	信号不属于自己的责任田	不越权写入
下拆	scope 过大、主题开始异质	创建或建议子 owner
上报	冲突、跨域、风险、无法判断	写入 `_signals/`

这里真正发生变化的不是"多了几个 Agent"，而是维护责任从中心化调度变成了分布式治理。owner 可以消费同一份日志，但必须守住自己的边界；处理不了就上报，而不是越权替别的 owner 做判断。

图：owner、signal 与 Governor 形成自治理闭环

Governor Loop：系统如何判断自己该演化

当 owner 体系稳定后，还会出现一个新的问题：谁来维护 owner 本身？

这就是 Governor 的位置。Governor 不接管业务内容，也不替某个 owner 写具体知识。它看的是组织结构：哪些 owner 的 scope 太大，哪些长期没有新信号，哪些 signal 一直没人消费，哪些文件开始出现责任重叠。

可以把 Governor 看成一个轻量的系统治理层：

owner 太大时，建议拆分责任田。
owner 长期无输入时，进入休眠或合并。
signal 堆积时，推动路由和决策。
规则反复失效时，要求修改 owner 的维护协议。

图：日志、owner、signal 与 Governor 的治理关系

这套机制让记忆系统从"固定流程"走向"可演化组织"。早期的 Lint、GC、Refactor 更像巡检任务；后来的 owner + signal + Governor 更像一个小型组织：每块知识有人看护，跨域问题有沟通通道，组织边界会根据工作负载自动调整。

Correction Signal：低成本纠错才是长期学习接口

长期系统一定会写错东西。真正重要的不是承诺不出错，而是让纠错成本足够低，并让纠错信号能改变后续行为。

一个有效的纠错闭环通常包含三步：

1. 注入修正：用户指出"这个不对"后，先修正目标文件，避免错误继续传播。
1. 记录归档：把纠错写入 corrections archive，保留错误类型和上下文。
1. 追因反馈 ：通过 git log 或历史记录追查错误来源，判断是规则缺失、执行偏差，还是信号丢失，再把结论写入 review_feedback.md。

下一次 Agent 运行时，先读取与自己相关的 pending feedback。如果反馈指向自己的规则缺陷，就先更新维护协议，再继续处理新日志。

这个过程很像强化学习，但它不需要训练模型本身：

记忆系统组件	强化学习类比	作用
用户纠错	reward signal	指出行为好坏
Agent 写入行为	policy	决定如何维护文件
`review_feedback.md`	experience replay buffer	保存失败样本和归因
规则修正	policy update	改变下一次维护策略

这也是文件系统方案的优势之一。纠错不是一条消失在聊天窗口里的抱怨，而是会落到仓库里，变成下一轮维护的输入。用户只需要自然指出问题，系统负责把这个信号变成可执行的规则更新。

Discovery Pipeline：信息雷达不是搜索，而是关注方向的自动延伸

当记忆系统具备长期上下文后，另一个自然能力会出现：它可以按关注方向主动发现信息。

普通搜索需要用户先提出问题；Discovery Pipeline 则先读取当前关注主题，再定期搜索、筛选、打标、归档。比如系统知道当前重点是 Agent 架构、产品动态、协议、端侧 AI、记忆机制和测试方法，就可以自动从外部信息流里捞出相关事件。

这里的关键不是"每天搜新闻"，而是搜索结果会进入同一套证据和 owner 体系：

和某篇文章相关的素材进入素材池。
和某个架构判断相关的变化进入对应主题。
只具备启发价值但未验证的信息标为待验证。
与旧判断冲突的信息写入 signal，等待处理。

因此，Discovery 更像一个懂当前研究方向的信息雷达。它不替用户做最终判断，但能降低"错过关键变化"的概率，并把外部变化变成可维护的知识增量。

Writing Assembly：写作从一次性创作变成持续积累

长期记忆系统对写作的改变也很明显。传统写作常常是临时打开文档，从零组织材料；而有记忆系统后，写作更像装配：

平时对话中出现的判断进入日志。
Discovery 抓到的外部材料进入素材池。
相关主题在 content/ 中逐步形成索引和版本。
真正写文章时，从多个上下文碎片中抽取结构，而不是重新发明观点。

比如"LLM 是 Runtime，Prompt 是 Code""Agent 从交互进程演化为守护进程""MCP 可以类比计算机网络协议"这类判断，往往不是某一次写作时突然出现的，而是在多次对话、材料补充、版本修订中逐渐稳定下来。

这让写作的重心从"临时生成一篇文章"变成"持续沉淀可复用判断"。文章只是某个时间点的导出结果，真正有价值的是背后不断积累的材料池、主题索引和判断演化轨迹。

图：写作素材从日常对话和外部发现中持续装配

图表复刻：一个可演化记忆系统的核心链路

把前面的机制合在一起，可以得到一个更完整的系统图：

图：可演化记忆系统的输入、治理与知识闭环

这张图里最重要的不是某个目录名，而是闭环关系：输入进入原始事件层，证据分级决定可信度，owner scope 决定归属，signal 处理跨域和冲突，Governor 维护 owner 体系，纠错反馈反过来修改规则。

工程判断：Self-Governing Repo 的边界

这种方案适合中等规模、强个人或小团队语境的知识系统。它的优势是透明、可审计、易演化，不依赖重型基础设施；它的限制也同样清楚：

如果数据规模进入百万级文档，纯 Markdown 检索会吃力，需要索引层或数据库辅助。
如果知识高度结构化，可能需要 schema、表格或图数据库承载。
如果多人协作频繁，权限、冲突合并和审计机制要更严格。
如果涉及敏感信息，必须处理访问控制和日志脱敏。

但在个人工作流、研究资料库、AI Agent 项目沉淀、技术写作素材池这些场景里，Markdown + Git + LLM 仍然是一个很强的起点。它把复杂问题推迟到了真正需要的时候，同时保留了后续升级空间。

更重要的是，这套系统提供了一种新的设计思路：不要急着把长期记忆做成黑盒数据库，先把它做成一个可以被人和 Agent 共同阅读、共同维护、共同纠错的仓库。只要证据、责任田和反馈闭环设计得足够清楚，记忆系统就会从资料夹慢慢长成一个可治理的工作上下文。

结语

LLM 记忆系统的关键，不是把更多历史塞回 prompt，而是让历史变成可维护的工程资产。原始对话要进入日志，稳定事实要进入 meta，知识材料要进入 content，维护责任要交给 owner，跨域冲突要通过 signal 升级，纠错反馈要能改变下一次写入策略。

从这个角度看，Self-Governing Repo 不是"多 Agent 炫技"，而是一套关于长期上下文的工程协议。它解决的是 AI 协作中最朴素也最难的问题：当对话结束后，哪些东西应该留下来，谁负责维护它们，后续发现错了又如何修正。