长期上下文不是更大的窗口，而是一套可维护、可纠错、可演化的个人知识工程。
原文链接：AI 小老六
当 LLM 长期记忆 开始进入日常工作流后，一个很快会暴露出来的问题是：模型在单次对话里的推理能力越来越强，但长期上下文的继承能力仍然很弱。每次重新打开一个会话，都像重新启动一个临时进程：身份、项目背景、关注方向、旧结论、已踩过的坑，都需要重新装载。
这类问题很容易被误判成“缺少一个更大的上下文窗口”，或者“需要一个更强的向量数据库”。但如果把它放到工程系统里看，真正缺失的不是 存储本身，而是一套能持续维护、能区分证据来源、能在规模变大后继续演化的个人工作上下文系统。
Karpathy 在 “LLM Knowledge Bases” 中提出过一个很朴素但关键的判断：中等规模知识集未必需要复杂 RAG，raw/ 原始资料、结构化 Markdown、索引和 LLM 推理，已经可以编译出一个可用的知识库。这个判断可以再往前推一步：如果把知识库从“资料整理工具”升级成“持续运行的工作上下文”，它就不只是 wiki，而更像一个轻量的个人操作系统。
很多 AI 记忆方案会从“保存聊天记录”开始，但聊天记录只是原始日志，不等于可用上下文。真正有用的上下文至少要回答四个问题：
| 上下文问题 | 需要沉淀的内容 | 典型载体 |
|---|---|---|
| 当前用户是谁 | 偏好、约束、长期状态、协作习惯 | meta/me.md |
| 当前在关注什么 | 活跃主题、未闭环问题、近期判断 | meta/threads.md |
| 最近发生了什么 | 原始对话、工具输出、纠错信号 | logs/ |
| 已形成哪些知识 | 文章、素材、项目结论、技术判断 | content/ |
这里的关键不是把所有对话堆进一个文件，而是把对话拆成不同生命周期的数据：原始信号保存在日志中，稳定事实进入 meta，主题材料进入 content，临时判断保留来源和时间。下一次会话启动时，AI 不需要回放所有历史，只需要先读入口文件和索引，就能恢复“我在和谁协作、最近在推进什么、哪些信息可信”。
这种设计把 AI 会话从“无状态函数调用”变成了“带启动上下文的工作进程”。会话仍然是临时的，但它挂载的文件系统是连续的。
图：Markdown、Git 与 LLM 共同构成可审计的长期上下文工作台
个人或团队级别的中等规模知识系统，第一性问题通常不是召回，而是可维护性。向量数据库擅长相似度检索，却不天然解决这些问题：
Markdown + Git 的好处在于，它把这些治理动作变成了普通工程动作：文件可读、diff 可查、commit 可追溯、目录可分权、索引可审计。一个轻量版本的记忆系统可以只由几类目录组成：
| 目录 | 职责 | 工程含义 |
|---|---|---|
meta/ |
用户、目标、活跃线程 | 会话启动时的上下文装载区 |
logs/ |
每天的原始对话与工具输出 | append-only 事件流 |
content/ |
文章、素材、研究结论 | 可复用知识层 |
_agents/ |
各类维护 Agent 的规则与 scope | 后台 owner 注册表 |
_signals/ |
跨域问题、冲突、升级请求 | Agent 间通信通道 |
这个结构不复杂，却有一个重要变化：知识不再只靠“搜索出来”，而是被持续整理成有责任边界的文件。LLM 的角色也不是把所有内容塞进 prompt，而是像编译器一样，把原始材料编译成可链接、可索引、可审计的知识层。
图：原始材料被编译为可装载的会话上下文
这类系统通常不会一开始就设计成多 Agent。更可能的演化路径是：先有一个大规则文件，所有职责都塞进去。它既要和用户聊天，又要写日志，还要更新索引、维护知识库、检查一致性。
这很快会遇到“注意力竞争”问题。对话过程本身需要流畅推进，维护过程又需要结构化写入和校验。当同一个会话同时承担这两类任务时，经常会出现两种故障：要么聊着聊着跑去改文件，要么改完文件后丢失了当前对话脉络。
第一轮拆分通常会把系统变成“读写分离”：
这个阶段可以解决“对话被维护任务打断”的问题，也让系统开始具备定时维护能力。但它仍然有一个隐含假设：后台进程只要定期扫描全局，就能发现有价值的问题。
实践中，这个假设很容易失效。格式错误、索引缺失、文件生命周期异常，可以靠规则扫描发现；但“这条信息应该归谁管”“这条推导能不能当事实”“这个结论是不是跨域影响另一个主题”，就不是简单 Lint 能判断的。系统真正难的地方不是文件格式，而是内容归属和证据治理。
一个长期记忆系统最危险的污染源，不是信息缺失，而是把不同可信度的信息混在一起。用户明确说过的话、工具实际返回的结果、仓库里已有的证据、AI 根据上下文推导出的解释，这四类东西不能同级处理。
如果 AI 把自己的推理静默写成事实，下游 Agent 后续再消费这些文件时，就会把二级推导当成一级证据。错误不会立刻爆炸，但会在长期迭代中被放大，最后形成“越维护越偏”的知识库。
因此，记忆系统需要一条底层协议：所有写入都必须保留 来源等级。
| 等级 | 证据类型 | 示例 | 处理方式 |
|---|---|---|---|
| A | 用户确认、工具输出 | 明确反馈、CLI 结果、API 返回 | 可直接下发维护 |
| B | 仓库证据、日志索引 | 已提交文件、历史记录、索引摘要 | 可用，但保留引用 |
| C | AI 推导、二手信息 | 模式判断、原因猜测、外部转述 | 先标注，必要时验证 |
| D | 冲突、过期、无 owner | 与旧结论矛盾、无人负责 | 上报、隔离或等待决策 |
这条规则看起来像文档规范，实际是系统安全边界。它约束了 Agent 的写入权限：AI 可以推断，但不能把推断伪装成用户事实；可以补充解释，但必须让后续维护者看得出这只是派生判断。
图：信息按证据等级进入不同处理路径
当系统继续变大，单纯的“后台进程”会逐渐变成瓶颈。原因不是进程不够多，而是它们缺少内容责任边界。更稳定的形态，是把系统拆成一组 owner：每个 owner 只负责自己的 scope，并按同一套证据协议消费日志。
在这种模式下，对话层只负责保存原始事件；各个 owner 自己读取日志，判断哪些内容属于自己的责任田，再更新对应文件。新增 owner、休眠 owner、拆出子 owner，都不应该影响正常对话。
这和传统任务调度的差别很大。调度框架关心“谁什么时候运行”；Self-Governing Repo 更关心“谁对哪块知识负责、能采纳什么证据、遇到边界问题时怎么升级”。
一个 owner 至少需要具备四个动作：
| 动作 | 触发条件 | 结果 |
|---|---|---|
| 消费 | 日志中出现与 scope 相关的新信号 | 更新自己的知识文件 |
| 拒绝 | 信号不属于自己的责任田 | 不越权写入 |
| 下拆 | scope 过大、主题开始异质 | 创建或建议子 owner |
| 上报 | 冲突、跨域、风险、无法判断 | 写入 _signals/ |
这里真正发生变化的不是“多了几个 Agent”，而是维护责任从中心化调度变成了分布式治理。owner 可以消费同一份日志，但必须守住自己的边界；处理不了就上报，而不是越权替别的 owner 做判断。
图：owner、signal 与 Governor 形成自治理闭环
当 owner 体系稳定后，还会出现一个新的问题：谁来维护 owner 本身？
这就是 Governor 的位置。Governor 不接管业务内容，也不替某个 owner 写具体知识。它看的是组织结构：哪些 owner 的 scope 太大，哪些长期没有新信号，哪些 signal 一直没人消费，哪些文件开始出现责任重叠。
可以把 Governor 看成一个轻量的系统治理层：
图：日志、owner、signal 与 Governor 的治理关系
这套机制让记忆系统从“固定流程”走向“可演化组织”。早期的 Lint、GC、Refactor 更像巡检任务；后来的 owner + signal + Governor 更像一个小型组织：每块知识有人看护，跨域问题有沟通通道，组织边界会根据工作负载自动调整。
长期系统一定会写错东西。真正重要的不是承诺不出错，而是让纠错成本足够低，并让纠错信号能改变后续行为。
一个有效的纠错闭环通常包含三步：
git log 或历史记录追查错误来源，判断是规则缺失、执行偏差，还是信号丢失，再把结论写入 review_feedback.md。下一次 Agent 运行时，先读取与自己相关的 pending feedback。如果反馈指向自己的规则缺陷，就先更新维护协议，再继续处理新日志。
这个过程很像强化学习，但它不需要训练模型本身：
| 记忆系统组件 | 强化学习类比 | 作用 |
|---|---|---|
| 用户纠错 | reward signal | 指出行为好坏 |
| Agent 写入行为 | policy | 决定如何维护文件 |
review_feedback.md |
experience replay buffer | 保存失败样本和归因 |
| 规则修正 | policy update | 改变下一次维护策略 |
这也是文件系统方案的优势之一。纠错不是一条消失在聊天窗口里的抱怨，而是会落到仓库里，变成下一轮维护的输入。用户只需要自然指出问题，系统负责把这个信号变成可执行的规则更新。
当记忆系统具备长期上下文后，另一个自然能力会出现：它可以按关注方向主动发现信息。
普通搜索需要用户先提出问题；Discovery Pipeline 则先读取当前关注主题，再定期搜索、筛选、打标、归档。比如系统知道当前重点是 Agent 架构、产品动态、协议、端侧 AI、记忆机制和测试方法，就可以自动从外部信息流里捞出相关事件。
这里的关键不是“每天搜新闻”，而是搜索结果会进入同一套证据和 owner 体系：
因此，Discovery 更像一个懂当前研究方向的信息雷达。它不替用户做最终判断，但能降低“错过关键变化”的概率，并把外部变化变成可维护的知识增量。
长期记忆系统对写作的改变也很明显。传统写作常常是临时打开文档，从零组织材料；而有记忆系统后，写作更像装配：
content/ 中逐步形成索引和版本。比如“LLM 是 Runtime，Prompt 是 Code”“Agent 从交互进程演化为守护进程”“MCP 可以类比计算机网络协议”这类判断，往往不是某一次写作时突然出现的，而是在多次对话、材料补充、版本修订中逐渐稳定下来。
这让写作的重心从“临时生成一篇文章”变成“持续沉淀可复用判断”。文章只是某个时间点的导出结果，真正有价值的是背后不断积累的材料池、主题索引和判断演化轨迹。
图：写作素材从日常对话和外部发现中持续装配
把前面的机制合在一起，可以得到一个更完整的系统图：
图：可演化记忆系统的输入、治理与知识闭环
这张图里最重要的不是某个目录名，而是闭环关系：输入进入原始事件层，证据分级决定可信度，owner scope 决定归属，signal 处理跨域和冲突，Governor 维护 owner 体系，纠错反馈反过来修改规则。
这种方案适合中等规模、强个人或小团队语境的知识系统。它的优势是透明、可审计、易演化，不依赖重型基础设施；它的限制也同样清楚：
但在个人工作流、研究资料库、AI Agent 项目沉淀、技术写作素材池这些场景里，Markdown + Git + LLM 仍然是一个很强的起点。它把复杂问题推迟到了真正需要的时候，同时保留了后续升级空间。
更重要的是，这套系统提供了一种新的设计思路：不要急着把长期记忆做成黑盒数据库，先把它做成一个可以被人和 Agent 共同阅读、共同维护、共同纠错的仓库。只要证据、责任田和反馈闭环设计得足够清楚，记忆系统就会从资料夹慢慢长成一个可治理的工作上下文。
LLM 记忆系统的关键，不是把更多历史塞回 prompt，而是让历史变成可维护的工程资产。原始对话要进入日志，稳定事实要进入 meta，知识材料要进入 content，维护责任要交给 owner，跨域冲突要通过 signal 升级，纠错反馈要能改变下一次写入策略。
从这个角度看，Self-Governing Repo 不是“多 Agent 炫技”，而是一套关于长期上下文的工程协议。它解决的是 AI 协作中最朴素也最难的问题：当对话结束后，哪些东西应该留下来，谁负责维护它们，后续发现错了又如何修正。
Loop Runtime 架构拆解：别再手动催 Agent，先把工程闭环跑起来
Hermes Agent Skill Runtime 架构拆解：让 AI Agent 不再从零开始
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。