第 9 节 · Agent 不缺智商，缺的是记忆¶
我每天打开一个新的 Claude Code 会话（session，一次对话），做的第一件事不是介绍自己。
因为不用。我雇的 agent 总经理张口就能引用上周拍板的事：那个验证闭环走到哪一步了、量化为什么从赚钱业务降级成研究项目、某个诊断决策门当初为什么被判定为 NO-GO。它甚至记得六天前有一条指令悬空了没人追踪，污染了下游，把一个回测口径误当成了实盘口径。
这些都不是模型记住的。
你以为 AI 跨会话失忆是模型问题，其实是工程问题。同一个模型，开两个会话，第二个会话对第一个会话发生过的事一无所知——这是所有 agent 工具的默认状态，不是 bug，是 context window 的物理边界（模型一次能看进来的字数上限）。模型没有变笨，是它根本没地方放过去的事。
AI 没有"记住"，是记忆系统让它"找回来"。
我是一家一人公司的董事长。这家公司没有员工，只有我和一群 agent。agent 会跨会话失忆，这点和员工会离职一样躲不开；但公司得记住自己说过什么、拍过什么、为什么这么拍。组织连续性的物理载体，不能压在一个会失忆的模型上。
于是就有了这套记忆系统。这一节不讲论文翻译，也不做工具推荐——就是一家一人公司每天真在用的法子，包括它管用的地方，以及老实说，它还没做到的地方。
一、记忆的误区：不是塞 context，是分层、索引、按需召回¶
很多人解决 agent 失忆，第一反应是把所有聊天记录塞进 context。最新的对话、上周的决策、项目背景文档、角色设定，全往 context window 里堆。结果就是 context 越撑越长，模型越跑越慢，关键信息反而被稀释——你问它"上周那个决策为什么定的"，它给你编一个听起来像、其实根本没有的版本。
这是把记忆问题当成了容量问题。
记忆不是把所有聊天塞进 context，是分层加上索引加上按需召回。 这句话是这一节所有判断里最重要的一句，我把它再写一遍：记忆是工程，不是容量。
打个比方。把所有家当全背身上的流浪汉，走得慢，还分不清哪件重要；有图书馆的人，平时口袋里只装正在读的那一本，其余的按需去架子上取。这两种人看起来都"拥有"很多东西，但只有后一种能真正用起来。
agent 也一样。一个把全部历史塞进 context 的 agent，就是那个流浪汉——它背着的不是记忆，是负担。真正有记忆的 agent，像有图书馆的人：口袋里装的是"此刻正在想什么"（工作记忆），图书馆里分类好"长期怎么组织"（长期记忆），还有一个相册存放"过去发生过什么"（情景记忆）。
这三层不是我们发明的，是认知科学和操作系统里几十年的老框架。问题是，绝大多数 agent 项目停在了第一层——要么全塞 context，要么塞完 context 再外挂一个向量库当垃圾桶，扔进去就不管了。
没有索引的记忆层，像把书全堆在地上的图书馆——书再多也找不回来。
下面这部分是这一节的核心，也是我们这家一人公司摸索下来最有心得的一点：我们的"图书馆"不是一层，是两层叠加。这个"两层"的洞察，不是我设计出来的，是从每天的实践里慢慢长出来的——写到第三年才看清楚。
二、这家公司怎么搭：两层记忆系统¶
先把骨架亮出来。我们这家一人公司的记忆真相，不是"一层三层文件"，是两层叠加：
- 顶层：跑 agent 的外壳程序自动维护的一份记忆入口文件——一份人工策展的记忆索引，时间倒序铺，最新追加的在顶部。
- 底层：项目自建的
core / archival / recall三层文件目录。
两层职责完全不同：顶层是"最近发生了什么"的流式索引，底层是"长期怎么组织"的结构化沉淀。这层区分非常关键——很多人把"索引"和"记忆"混为一谈，结果要么只有索引没有正文（点进去 404），要么只有正文没有索引（找不到）。
图 B-9-1（待出）：两层记忆怎么叠起来——顶层是随手可查的流式索引，底层是分好类的三层文件目录
顶层：一份人工策展的"报纸头版"¶
这份入口文件由外壳程序给每个项目自动维护，路径不用我操心。
真实状态：63 条记忆卡片，每条一行，格式是「卡片名 — 一句话摘要」，附一个文件链接。比如这一条：
自下指令无人追踪的陷阱 — 一句话摘要：agent 自己给自己下指令、自己执行，没有写进任何追踪系统，悬空六天，下游把回测口径误当成了实盘口径
这条卡片背后是一个真实故事：我雇的 agent 总经理自己给自己下了一条指令，自己执行了，但没有写进任何追踪系统，悬空六天，下游把一个回测口径当成了实盘口径。被发现后，沉淀成一条记忆卡片，链接到一份独立的 Markdown 文件，详述来龙去脉。
机制是这样的：外壳程序在会话里识别到"值得记"的事实，自动追加一条卡片到这份入口文件，同时把详细内容写成一份独立的 Markdown 文件。外壳程序负责写，人负责读和策展——哪条该升级、哪条该合并、哪条该删，人来拍板。
它的形态像报纸头版：今天发生了什么，一眼扫到底；想看哪条的详情，点链接进去读全文。
这里有一个非常关键的工程细节：同一个事件会被多条记忆从不同角度沉淀。那个被误当实盘的回测节点，在三条记忆里都出现了——量化系统那条里出现 5 次（它是核心节点），量化降级那条里出现 1 次，指令悬空那条里出现 1 次。三条卡片，三个视角，链接到三份独立文件。这不是冗余，是记忆系统在捕捉同一个治理断点的不同侧面。
底层：core / archival / recall，三层文件目录¶
| 层 | 角色 | 真实状态 | 类比 |
|---|---|---|---|
| core/ | 工作记忆（每次会话自动加载） | 5 个文件，共 214 行 | 口袋里此刻在读的那本 |
| archival/ | 长期记忆（按需读取） | 按类分：决策、教训、用户研究等 | 图书馆，书都分类好在架子上 |
| recall/ | 情景记忆（历史会话摘要） | 只有一个 0 字节的占位文件，设计未跑 | 老照片相册，设计了，还没贴照片 |
core/ 是跨会话记忆能跑通的物理原因。 项目根上有一份每次都会加载的入口文件，里面写着几句"自动导入"指令，分别指向 core/ 里的一份技术栈、一份架构说明、一份项目背景。
每个新会话启动，这五个文件会自动塞进对话的开头——不需要人去复制粘贴。这就是为什么 agent 总经理张口就能记得上周的决策——不是模型聪明，是这 214 行 core 文件每次都在场，模型根本不需要"记"，它只需要"读"。
这里要诚实标注一个细节：core/ 自定的红线是"≤200 行"，实际跑了 214 行，超了 14 行。这是预算压力——业务在长，core 也在长，还没腾出手做收敛。不藏。
archival/ 是按需调出的长期记忆。 里面最有意思的是一份只有 19 行的决策表格：每一条记录一项组织决策、做出时间、依据、影响、状态，原始决策之外还挂着五条修订版。比如有一条写的是"三层架构：总部—业务单元—基础设施"，依据是"抽象被证实可行"，状态标注为"已修订"；修订版的结论是"简化为两层：创始人—产品/客户，三层架构适合 50 人的公司，一人公司里业务单元层是过早抽象"。
一张表格里同时保留原始决策和修订版，这是组织记忆该有的样子：不仅记住"现在是什么"，还记住"曾经以为是什么、为什么改"。 这种演化痕迹，向量库存不下来。
recall/ 要诚实说：是空的。 设计了一个目录准备放历史会话摘要，实际只有一个 0 字节的占位文件。情景记忆层设计预留，未启动。不藏，反而是这一节诚实度的加分项——做了的不吹，没做的不编。
五条业务线一致复制¶
内容、量化、模型、知识、研究五条业务线，全部复制了 core / archival / recall 三层模板。深度不一，诚实标注：
- 内容线：core 4 个文件，archival 完整（决策、教训、用户研究都在用）
- 量化线：core 3 个文件，archival 只有决策一类（一份 81 行的双数据源架构决策记录）
- 模型线：core 3 个文件，archival 完整（含一份 83 行的十年基建路线图）
- 知识线：core 3 个文件，archival 未落地——只有 core，骨架没填肉
- 研究线：core 3 个文件，archival 浅（决策、教训各 5 行）
模板可复制 ≠ 内容必填——先铺骨架，再随业务长肉，这是一人公司能跑起来的现实路径。
这里还有一处真实的演化痕迹：总部用的是单文件表格（一份表格列所有决策），模型线用的是散文件模式（一份决策记一个文件）。同一套规范，不同业务线各自演化出了不同风格。这不是 bug，是一个组织在生长时必然留下的痕迹——总部喜欢俯瞰（表格），模型线喜欢深挖（独立文件）。两种风格并存，反而比强求统一更健康。
三、学术锚点：我们的三层 ≈ MemGPT 三层¶
写到这里，可能有读者觉得：你这套三层，是不是事后套学术？
不是。2026 年 8 月，我们对着记忆、协同、知识库三个方向并行检索了一手 arXiv 资料（arXiv 是学术论文预印本网站），发现我们这套 core / archival / recall 三层骨架，与 2023—2026 年学术最前沿的 MemGPT 三层是逐字对应的同构关系：
| 我们的层 | MemGPT / Letta 层（arXiv 2310.08560） | 功能对应 |
|---|---|---|
| core/（自动加载） | main context（在上下文） | 此刻在想什么 |
| archival/（按需读取） | archival memory（分页调出） | 图书馆里按需取 |
| recall/（设计未跑） | recall memory（检索历史） | 老照片相册 |
MemGPT 是 2023 年那篇把操作系统虚拟内存分页思想搬进 agent 记忆的奠基论文：main context 是当前在跑的、archival memory 是分页调出来的长期、recall memory 是检索历史。我们这套三层文件，物理实现不同（它是文件系统，不是分页虚拟内存），但功能划分一一对应。
图 B-9-2（待出）：我们这套三层和 MemGPT 三层的逐层对应关系
这不是事后附会。这次扫描的判断是：这是"把人类组织学回写进 agent 架构"这一范式，在同一时期从学术和产品两端各自长出来——MemGPT 用 OS 内存管理隐喻，A-MEM 用 Zettelkasten 笔记法，OrgAgent（arXiv 2604.01020）用公司层级，都在从人类已有的组织、认知、笔记学里找架构灵感。我们这家一人公司算是这条路线在产品端的一个早期样本。
我们先趟出来的三件事¶
这次扫描列出我们已经在用、学界刚刚承认靠谱的三件事：
第一，文件系统作载体。 我们的记忆是 Markdown 文件，可读、可 diff（改了哪一行都看得见）、可 git 版本化（每个版本都留底）、可手工修复。学界过去几年的主流是向量库 / embedding 黑盒（把文字变成一串数字来比对的黑盒）——直到 Letta 自家的基准开始问 "Is a Filesystem All You Need?"，文件系统路线才被承认为稳健替代。我们用 Markdown 跑了两年。
第二，人工策展作为安全机制。 2026 年新披露的 MemPoison / GhostWriter 类攻击，能向全自动记忆系统注入伪造事实——agent 检索到一条假记忆，会基于假事实做决策，而且很难发现。我们这份记忆入口文件是人工策展的，写什么、升级什么、删什么，都过人的判断。在记忆污染成为真实威胁的年代，人工反而成了不可替代的安全层。
第三，人工索引比 LLM 反思更可信。 Generative Agents 那条线让 LLM 自己给记忆打 importance 分，自动决定什么值得记——结果是噪声大、容易把无关细节升级成"重要记忆"。我们让人来做这个判断，人是比 LLM 更可靠的"什么值得记"判断者。
我们还没做到的四件事¶
诚实清单，不藏：
- 无语义检索。 规模天花板，找回靠人脑记路径。文件数一旦超过几千份就会触顶。
- 无遗忘机制。 core/ 只靠 200 行硬上限，没有时效驱动的淘汰。重要和不重要的一起挤在 214 行里。
- recall/ 是空的。 情景记忆层设计预留，未启动。
- 无自动反思。 Letta 已经在做 sleep-time compute——agent 空闲时离线整理自己的记忆。我们这套全靠人，没有这一层。
做了的不吹，没做的不藏。这句话写在这里，是因为这一节要面对的不是 demo 评审，是真正想做这件事的工程师。
四、组织连续性压在记忆系统上¶
回到一开始的问题。一人公司没有员工，agent 会跨会话失忆，那这家公司的"组织记忆"压在哪里？
压在这个两层记忆系统上。
传统公司的连续性，压在员工脑子 + 文档系统 + 企业文化这三件事上。员工记得"我们为什么这么决策"，文档系统存着流程和规章，企业文化让新来的人知道"我们这里怎么做事"。一人公司这三件事全部落空——没有员工，agent 跨会话记不住，"企业文化"在一家没有员工的公司里听起来像个笑话。
但组织必须连续。于是连续性的物理载体，只能是 Markdown 文件 + 自动加载机制 + 人工策展路由。它不会离职，不会因为模型升级突然失忆（顶多换个外壳程序，重新挂上同一份记忆入口文件），不会因为 token 超了就忘掉关键决策。
代价是需要工程。需要人写 core，需要人维护 archival，需要人决定什么该随手记、什么该归档。这套系统的护城河，恰恰在于它不能全自动——一旦全自动，就回到了 MemPoison 的脆弱区。
最后一份诚实清单：
- 做了：两层叠加（流式索引 + 三层文件目录）、五条业务线复制、core 自动加载、人工策展路由
- 没做：recall 情景层、语义检索、遗忘机制、自动反思
记忆让 agent 记住事。但记住事的 agent 之间怎么协同、怎么相互质疑、怎么不陷入"礼貌敷衍"的虚假共识——这是另一节要讲的。多 agent 协作本质是管理学问题，不是 prompt 问题。
传统公司的记忆在员工脑子里，一人公司的记忆在 Markdown 文件里——后者不会离职，但需要工程。