记忆管理

字数：约3000字 | 阅读时间：9分钟 “把派活做成流水线，把拍板留给人。” 「记忆工程」系列第三篇。上一篇讲完数据模型，这篇兑现第一篇埋的伏笔：这个项目由我和几个AI协作开发，一台服务器上的AI做编排，另外几台机器上的AI分头写代码。这篇把这条流水线拆开讲讲。 先交代起点，免得后面显得太顺。立项时项目手里有什么？一份需求提案、一份设计文档、一轮五路红队评审——结论FAILED，11个阻塞性问题；外加一张14个开发任务的清单。开工数：0。 决策者没打算自己一行行补代码，也没打算找一个"超级Agent"托管一切。最后跑通的东西说出来很朴素：一块任务板，一条纪律，三台机器上各跑一个干活的AI，工头也住在其中一台服务器上。 一、第一个决定：不并行 直觉上，多台机器就该并行，越多越快。我们拍板的第一个架构决策恰恰相反：全局串行。 原因一半是钱：三个干活的AI共用同一个编码模型的订阅额度，并行等于三倍烧钱抢饭吃。另一半是评审链：串行让每个任务都有干净的"谁写的、谁评的"记录，出了问题翻commit就能定位到环节。并行省下的时间，排查时会加倍还回去。 机制落在共享记忆库里的一把全局锁上：任何worker开工前先看锁，锁上写着当前任务和执行者；干完、评完、落库，才轮到下一个。推进时段也卡着额度的低峰走——工作日的深夜和清晨，加上周末全天，每晚一到两个任务，不贪多。 还有条潜规则：纯架构设计、文档合并这类不消耗编码额度的活，工头直接干，不进流水线排队。 二、谁干什么，谁不许夸自己 分工是踩过坑之后修出来的： 节点 角色 主要产出 工头主机 编排+评审集成 派活、收报告、架构文档、静态评审 云服务器A worker 编码、CI、文档、巡检、看门狗 Windows笔记本 worker 编码重活、实测类任务 人类决策者 拍板者 检查点验收、例外处置 其中一条纪律值得单独一段：禁止自审自批。谁写的代码，交叉评审必须换一台机器。评审报告本身也是一次commit，和代码一样进Git历史。到收官时，仓库里攒下191个commit、35份评审文档——评审在这个项目里是交付物，有编号、有结论、可追溯。 三、一个任务的一生 拿一个典型任务走一遍全流程： 任务板上认领（任务板是一份人人可读的Markdown清单）→ 读spec、写代码、跑测试 → push到远端 → 协调器把变更集派给另一台机器交叉评审 → 评审报告落docs目录 → 阻塞项退回修复，非阻塞项记档留给下一个任务吸收 → 任务板打勾 → 共享记忆库沉淀一条经验。 几个数字：MVP阶段8个里程碑任务全部走完这套流程；加上收尾和增强轮，任务板上T1到T16全部打勾；自动化测试从0涨到近400个，全绿。 更重要的是检查点制度。整条流水线只在三种情况下需要人出场：战略拍板（要不要做）、阶段验收（specs二审、demo验收）、例外处置。流水线跑了一个多月，人真正出手一只手数得过来——三次检查点拍板，外加几次事故处置。其余时间，任务板自己转。 四、翻车集锦：流水线是修出来的 听起来太顺了？事故记录都在档案里。 **事故一：凭空蒸发的任务。**凌晨给笔记本上的AI派了个分析任务，日志显示已开工，十来分钟后再看：临时目录清空、AI进程归零，任务没了。根因查了一圈才定位：笔记本在Linux子系统（WSL）里跑AI，派活的会话被一个300秒超时杀掉后，子系统判断"没人用了"，五分钟后把整个实例连锅端了。处置：换Windows原生方式跑AI，加"保温"长连接防回收，顺便立了规矩——所有事故必须落档，格式固定：现象、根因、处置、沉淀。 **事故二：评审查死的罗生门。**笔记本上的AI连着两次在评审任务里"卡死"：进程活着，不报错，就是不产出。靠对比采样才抓到真相：它在Windows上跑测试套件，Node测试进程启动极慢，600秒超时根本跑不完；AI随即陷入"读日志→诊断→再等等"的补救循环，永远不会主动放弃。由此总结出判死三件套：CPU采样对比、日志最后写入时间、产出物是否存在——三条证据齐了就判死重派，不再干等。顺带改了纪律：笔记本从此只做纯静态评审，实跑测试的活交给服务器。 事故三：派发通道不可靠。工头派活走消息通道，丢过三次。最后长出来的机制叫心跳自主开工：每个worker有自己的巡检节奏，主动检查任务板和锁文件，发现该自己干的活没人干，就按决策记录自行开工。协调通道从必需品降级成了加速器——它挂了，活照样往前走。 三次事故，三份档案，三条新纪律。这条流水线的可靠性，一半是设计出来的，另一半是这么修出来的。 五、工头干完活，拆了自己的工棚 流水线的最后一环是监督。每小时一轮看门狗巡检：任务板状态、worker进程、锁文件、远端同步，只读写档不发通知，有异常才升级。稳定期连续几十轮巡检结果一字不差——这种"无聊"是流水线健康时的标准长相。 收官方式有点意思。MVP验收通过后，每小时协调器按设计执行了自我移除：任务板全勾、锁状态改成"等待拍板"、协调进程注销。工头干完活，自己拆了工棚，这件事本身也写进了完成记录。 六、写在流水线边上 带得走的三条： **串行是纪律，也是保险。**并行度上不去的时候，先把评审链做干净； **事故是流水线的一部分。**翻车不落档，等于白翻； **人只出现在必须拍板的地方。**检查点之外，人和AI互不打扰。 照例：本文由 AI 起草、人类审校拍板。这个栏目本身，就是这个项目的人机协作现场记录。 「记忆工程」系列 · 03 | 上一篇：把记忆存进Git：一个AI记忆系统的数据模型

字数：约2800字 | 阅读时间：8分钟 “索引烧了可以重建，正本烧了就什么都没了。” 「记忆工程」系列第二篇。上一篇讲了为什么要给 AI 造一个"第二大脑"，这一篇往下挖一层：记忆到底长什么样，为什么必须能 diff，以及四条底线是怎么一条条落进代码里的。 一、先说清楚"正本"是什么 上一篇发出去之后，被问得最多的问题是：向量库、嵌入式数据库、各种记忆框架都有，为什么偏要从"一堆文件加一个 Git 仓库"开始？ 先给结论：我们要的不只是“存得下”，更要"毁不掉"。 所谓正本，就是把所有派生物全删掉之后还剩下的那份东西。embedding 索引删了，可以从 Markdown 重建；缓存删了，可以重新生成。这些都可以坏，坏了重跑就行。但 Markdown 和 Git 历史要是没了，整个系统就只剩一个空壳。反过来，只要这两样在，索引层随便推倒重来，十分钟满血复活。 这个设计被真实场景检验过。项目进行中，本机的记忆仓库被一次强制重置打翻，AI 在巡检报告里提示了异常。最后我们是靠 Git 的操作日志（reflog）把现场完整恢复的——那些记忆要是存在某个私有数据库里，那次大概率就是永久丢失，连"去哪找"都不知道。 记忆系统天然处在各种自动化程序的写风险之下：AI 会写错，脚本会写崩，重置会误伤。把正本放在最笨、最老实、二十年不会过时的格式上，就是给整个系统设了一个止损下限。 二、骨架：三种记录 结论先行：整个记忆库只有三种记录——Topic、Fact、Relation。 **Topic 是实体节点。**一个项目、一个工具、一次会话、一个设计决策，都是 Topic。它是记忆图里"名词"的部分。 Fact 是关于某个 Topic 的一条离散陈述。“切片查询默认走三级降级"是一条 Fact，“查询接口只监听本机"也是。每条 Fact 独立存在，独立带状态，独立过期。 **Relation 是带类型的边。**MVP 只留了七种：depends-on、part-of、belongs-to、authored-by、references、conflicts-with、supersedes。 为什么只留七种？因为实际运行里我们观察到一个现象：关系类型一旦放开，AI 就开始发明关系——“somewhat-related-to"这种模糊边一多，图就废了，查询时全是噪音。宁可类型少，也要收敛。 三、一条事实的解剖 空谈模型容易飘，看一条真实的记忆。这是演示库里的一条 Fact（commit 哈希做了截断）： --- type: fact id: fact-alpha-getuser-main topics: [project-alpha] status: active confidence: high provenance: demo-seed repo: …/project-alpha version: main commit: 1a2b3c4 axis: subject --- Alpha 在 main 分支只提供 getUser(id) 单点查询，无限流。 前面这几行 frontmatter 是机器读的索引：id 是唯一编号，topics 声明这条事实挂在哪些实体上，status 是生命周期状态（active / expired / superseded / contested / pending-review），confidence 是置信度，provenance 记来源。 ...

字数：约2500字 | 阅读时间：7分钟 “上下文窗口是租来的，记忆得自己盖房。” 一、从一次"失忆"说起 上个月，我在两台机器上让两个AI协作开发同一个项目。A机上的AI刚做完一轮设计评审，结论写进了它的会话记录；B机上的AI第二天接着干活，对这份结论一无所知，按自己"新想"的方案把接口改了。等我发现时，两边的代码已经分叉，返工花了整整一个晚上。 这件事之后我盘了盘自己的AI工作流，发现"失忆"无处不在： 会话内失忆：上下文窗口一满，早期聊定的决策就被挤出去，AI开始"自作主张"； 会话间失忆：新会话从零开始，我要么把背景重新粘一遍，要么接受它带着错误的前提干活； 工具间失忆：A工具记住的东西，B工具看不到。换一个工具，等于换了一个没有经验的实习生； 机器间失忆：我在台式机、笔记本、服务器上各跑着AI助手，它们对同一个项目的认知互不相通。 这些问题的根子不在模型。模型的能力一直在涨，但记忆这件事，从来没有一个正经的架构位置——它被默认塞在上下文窗口里，而上下文窗口本质上是租来的临时工位。 二、结论先行：做一个"外置记忆层" am（agent memory）想做的事情一句话能讲完：把"记忆"从AI身体里搬出来，做成一个独立于任何AI、任何工具，人和程序都能读写的知识层。 它不是一个聊天记录归档工具，也不是又一个向量数据库。核心形态是四样东西： 一堆纯Markdown文件：每个文件记录关于某个"话题"（Topic）的事实（Fact）和关系（Relation）； 一个Git仓库：每次记忆变更都是一次commit，可diff、可回滚、可审计； 一层自动化维护程序：监听会话、代码提交、文件变更，自动提取新事实、更新旧事实、标记过期； 一套切片查询接口：任何AI进入任务前，报上"我是谁、在哪个项目、哪个分支、什么时间"，就能领到一份恰好够用的上下文包。 三、四条底线 设计阶段最纠结的是取舍。最后沉淀下来四条底线，一条都不能让： 1. 明文Markdown是唯一正本 记忆永远以人能直接读的Markdown存在。embedding、索引、缓存都是派生物——删了随时能重建，永远不作为事实来源。这条底线保证的是：哪天这套系统黄了，我剩下的还是一堆能直接翻的笔记，而不会是一把打不开的锁配一个看不懂的库。 2. 每次变更都是一次Git commit 谁改的、什么时候改的、改了什么——全部留在commit历史里。AI改错了记忆，和改错了代码一样，可以被review、可以revert。这条底线的价值很快就被验证过：项目进行中有一次，一个AI报告"本机仓库曾被外部进程强制重置"，我们就是靠Git的操作日志（reflog）把现场完整恢复的。要是记忆存在某个私有数据库里，那次可能就直接丢了。 3. 工作区隔离 每个项目的记忆是独立的vault（库），物理隔离，一个项目的记忆污染不能蔓延到另一个项目。多个AI对世界有不同"认知"时，靠Git分支来隔离各自的现实。 4. 跨库一等链接 记忆之间用双链语法（类似Obsidian的[[链接]]）连接，跨项目、跨库的引用是一等公民。真实世界的知识本来就不是树状的：一个"传感器"话题，会同时关联"通信协议"、“部署环境”，和"那次印象深刻的踩坑"。 四、一条记忆长什么样 空谈架构容易飘，看个简化示例（省略了部分字段）。一条关于项目的事实，在库里就是一个Markdown小节： ### fact-0217 · 切片查询默认走三级降级 - 关于: [[Tool: 切片查询]] - 陈述: 检索先走向量近似，超时或预算不足时逐级退回 token索引、图遍历，保证任何情况下都有返回。 - 版本轴: repo=am-main, branch=main, commit=f40cd48 - 来源: 2026-09-23 基准测试轮 · 置信度: 高 - 状态: 有效 机器读它，人也能读它，Obsidian里点开就能改。查询的时候，AI报上"我在哪个仓库、哪个分支、当前时刻"，系统从记忆图里切出这个"世界"下所有有效的条目，渲染成一份上下文包交出去——过期的事实一条都不会混进来。而这一切的每一次变更，都对应Git历史里一行可以追溯的commit。 五、最容易低估的难点：时间 整个设计里最反直觉、也最值钱的决定，是给每条记忆标注它属于哪个版本的世界。 举个例子。一条记忆写着"配置文件的格式是YAML"。三个月后项目重构，格式改成了JSON。这条记忆过期了吗？ 看情况——如果你的服务还跑在旧版本上，它依然有效；如果你在新分支上开发，它已经错了。所以每条事实都必须回答：“我在说哪个仓库、哪个分支、哪个提交时刻的世界？” ...