上一篇，Agent 知道自己在给谁干活了——人格告诉它”你是谁”，安全告诉它”哪里不能动”。

但关掉会话再开一个，它还记得吗？

一、关机就失忆

装好了人格、写好了安全规矩，Agent 第一次干得漂亮。解绑测试点，5 个聚焦节点，我直接能进用例草稿。

第二天，我让它帮我分析另一条测试链路。它问我的第一句话是：”你们设备的联网形态有哪些？”，昨天刚教过它，它忘得干干净净。我又需要再次重复一次需求。又过了两天，我让它帮忙看一条需求，又使用表格形式输出了测试项，缺少了所属模块、功能，无法让我直接使用。

同一件事教三遍，模型每次都在”聪明地回答”，但每次回答的起点都是零，就像一条只有7秒钟记忆的鱼，让人无可奈何的实习生，每天都要教相同的东西，就是不知道记下来

这不是它不够聪明。它差的不是聪明，是记性。

我把这个问题拆了一下：

最后一行是关键——Agent 的价值不是”一次干得好”，是”越用越好用”。记忆是它越用越好的关键，所以经常听见有人讲“养龙虾”、“调教AI”。

二、记忆不是垃圾桶

那什么样的事情要记下来，什么事情不用记下来？AI怎么知道要记下来？

在一些教程中，会按日期保存记忆，比如昨天一份、今天一份，但是我认为这种方式并不太好，记得内容太多了，并不是每天的对话都有必要记下来。所以我采用了部分记忆的形式，把一些经常遇到的问题、AI出过错的全部让AI记下来，比如某次遇到的公司网络 TLS 的问题、Python 在 Windows 上的编码坑、PPT 生成时踩的六个坑，全往记忆文件里堆，因为我担心后面再遇到相同的问题，AI会不断的重复查找、搜索的过程，有时候AI出错了，会在错误的路上不断尝试。但是堆完发现：Agent 启动时要读的文件越来越长，token 花在”读记忆”上的比例越来越高，留给业务逻辑的空间反而被挤小了。我过分的堆记忆，并没有节省 token，反而浪费了 token。

记忆不是垃圾桶，是长期操作系统配置——这条原则是被撑过之后才长出来的。

我把记忆拆成了三层：

三层的设计思路是分层记忆：索引层自动加载，详情层按需打开。MEMORY.md 全文不到 20 行，只放索引和触发时机——”启动新任务时至少打开 persona 加 corrections-log”。Agent 每次启动只花几十个 token 读索引，真正需要时才去读详情。

整个记忆的运转方式如下：

flowchart TD    A[会话启动：读索引层 MEMORY.md] --> B[按需加载详情层]    B --> C[带着记忆干活]    C --> D{你纠正了吗？}    D -->|没有| E[完成]    D -->|纠正了| F[判断：6个月后还有价值吗？]    F -->|是| G[写入 FACT.md]    F -->|否，但值得留痕| H[追加到 JOURNAL]    F -->|一次性，不值得记| I[不记]    G --> A    H --> A

这张图的核心不是"存"，是"筛选"——纠正了不等于要记，记了不等于永久存。三条过滤规则：

1. 6 个月后还有价值吗？
   
    有 → FACT.md；没有 → 下一条
2. 能从代码、文件、git 历史推导出来吗？
   
    能 → 不记，别重复
3. 是一次性事件吗？
   
    是 → JOURNAL 留痕，不进 FACT

三层加三条，干的事就一件：让记忆只留值得留的，token 只花值得花的地方。

三、记忆是怎么长出来的

记忆不是一开始就设计好的。是我纠正过它之后，才一条一条长出来的。

第一条：测试用例定义

有一次 Agent 帮我拆用例，它把”按系统逻辑执行得到错误结果”分到了反向用例。这个定义不合规——按 IEEE/ISTQB 主流定义，反向用例是输入非法、系统按设计拒绝或报错，不是”系统出错了就算反向”。我纠正了并把它写进了长期记忆：

用户的《测试用例设计规范》中，正向/反向等概念统一采用 IEEE/ISTQB 主流定义。不接受”按系统逻辑执行得到错误结果=反向”这种非主流定义。

写进去之后，它再也没犯过这个错。

第二条：拆分查漏

做语音产品能力拆分的时候，Agent 按需求文档拆完，但是在人工确认阶段，发现漏了两个行业常识行为：唤醒 15 秒保持窗口、流式断句拒识。虽然在需求文档中并没有明确写，但这是语音产品”该有但没有写出来”的隐含行为，恰恰是测试最容易漏的地方。我纠正之后写进了长期记忆：

能力层/测试点拆分不是文档搬运：除需求基线对照外，必须用领域常识做完整性挑战，主动列出”该领域行业标准行为但文档未提”的清单提请用户确认。

这条规则现在每次拆分都自动加载。Agent 不光搬文档，还会去想”这个领域还有什么文档没提但行业一定有的”。

第三条：功能谱系图边界

启动功能谱系图项目的时候，Agent 想一次性把谱系图和测试用例治理全做完——功能点、能力、契约、测试点、用例、责任人，一口气全拆。我并没有同意这么做，因为工作量非常大，虽然AI能够处理，但是为了让每一项处理都能够达到预期，需要一定的人工干预，并且功能非常多、需求梳理耗时，测试点和用例的质量又不齐，需要单独治理。谱系图本身能先创造价值，应该分阶段落地。这条也写进了记忆。

三条放在一起看：

Agent 越来越好用，不是模型升级了，是记忆积累了你跟它之间的校正历史。

每一次纠正，如果只是嘴上说说，下次它还会犯。写进记忆，才是一条校正变成一条规则。

四、Token 预算：该记什么、该忘什么

记忆要花 token。上下文窗口就那么大，每多读一条记忆，业务逻辑的空间就少一点。所以记忆的第二条铁律是极简记忆——非必要绝对不记，不要什么都往里塞。

以下是我决定一件事要不要进长期记忆的三个判断：

这和前面系列文章提到的极简主义是一脉的：AGENTS.md 主文件 200 行以内，专项文件按需加载——大头留给业务逻辑，不喂给冗长的规则说明。记忆也是同样的逻辑：索引层常驻，详情层按需，长期层只放值得放的。

一个反例：我刚开始用的时候，把”公司网络下 git clone 会 TLS 失败”这个坑写进了长期记忆。后来我发现，这个信息每次启动都要读，但不是每次都要用——它只在装 skill 的时候才有价值。我把这条从”每次必读”降级为”JOURNAL 留痕”，装 skill 的时候再去翻。省下来的 token，用在业务逻辑上。

记忆的效率不在于”存了多少”，在于”每次启动时花了多少 token 读到了多少有用的东西”。

五、个人用 vs 团队用

如果只是个人电脑上自己用，记忆怎么管都行——自己的纠正、自己的偏好、自己的 token 预算，出了事自己兜底。但放到团队，必须要考虑工程化的落地实践，“再小的一件事，放到十四亿人头上就是大事”，虽然我们的团队并不大，但是也需要考虑效率和成本问题。

谁的纠正进共享记忆？ 我纠正 Agent 用 IEEE/ISTQB 定义来分用例，这条写进共享记忆，全团队受益。但 A 同事习惯用 Appium、B 同事习惯用 Pytest——这种个人偏好不能进共享记忆，进了就会打架。

谁的偏好是标准？ 测试组写测试点的规范是团队标准，必须进共享记忆。但我个人的工作习惯——这种是我的，不该让团队的 Agent 也读。

新人入职怎么用？ 这才是记忆最大的团队价值——新人不用从零开始教 Agent。继承团队的 FACT.md，Agent 就知道我们设备没有 5G、知道我们用 IEEE/ISTQB 标准、知道我们测试组不接 App 标记同步。团队记忆是组织知识的载体，新人进来不是面对一个空白的 Agent，是面对一个已经被整个团队校准过的 Agent。

但这带来一个治理问题：谁有权写共享记忆？写错了谁背锅？

这个问题我现在还没有完美答案，但有一条底线：团队共享记忆的变更必须留痕——谁、什么时候、改了什么、为什么。这和（三）里 SAFETY.md 的变更日志是同一个逻辑。

六、对照

回过头看没有记忆的 Agent：

没有记忆的 Agent，像一个每次见面都失忆的搭档——你得把昨天聊过的全重新说一遍。有了记忆的 Agent，像一个跟你磨合过很久的同事——它知道你的规矩、你的偏好、你纠正过它什么，新任务进来直接干。

它变好用不是因为它变聪明了，是因为它记住了你教过它什么。

记忆这件事，说到底就是——你教它一遍，它得记住。记不住的搭档，教再多也白搭。记住了，一条纠正变成一条规则，下回不用你再说，它自己就知道了。 这就是我们怎么把一个 Agent 从临时工变成真正助手的方法。只有不断的使用、调教、纠错，它才算真的进到了你的工作流里，而不是只在你屏幕上路过了一下。