完成第一次记忆会话与验收

文档摘要

完成第一次记忆会话与验收本节摘要:前几节你已接入 Agent 并做过一次「先说后问」的对话验证,但肉眼判断「Agent 似乎记住了」还不够严谨。本节给你两套更系统的验收方法:一是「对话侧」的行为验收,用一组结构化的测试对话确认召回真的发生;二是「控制台侧」的痕迹验收,直接去面板里看记忆到底沉淀成了什么资产、被谁召回过。两套方法互为印证——对话侧看效果,控制台侧看证据。做完本节,你就能确信「记忆真的生效了」,并对它的存与取都有了直观认识,后续章节的原理讲解也就有了落脚点。

完成第一次记忆会话与验收

本节摘要:前几节你已接入 Agent 并做过一次「先说后问」的对话验证,但肉眼判断「Agent 似乎记住了」还不够严谨。本节给你两套更系统的验收方法:一是「对话侧」的行为验收,用一组结构化的测试对话确认召回真的发生;二是「控制台侧」的痕迹验收,直接去面板里看记忆到底沉淀成了什么资产、被谁召回过。两套方法互为印证——对话侧看效果,控制台侧看证据。做完本节,你就能确信「记忆真的生效了」,并对它的存与取都有了直观认识,后续章节的原理讲解也就有了落脚点。

一、两套验收方法为什么要并用

单凭任何一种方法都有盲区:


┌─────────────────┐   ┌─────────────────┐
│ 对话侧行为验收   │   │ 控制台痕迹验收   │
│ 看效果           │   │ 看证据           │
└────────┬────────┘   └────────┬────────┘
         │                     │
         │   可能误判          │   可能对不上
         │   (Agent 猜对的)   │   (沉淀了但没召回)
         ▼                     ▼
              ┌──────────────────────┐
              │ 两者互印证 = 确信生效 │
              └──────────────────────┘

方法	看什么	优势	盲区
对话侧行为	Agent 是否「不问就用对」	贴近真实体验	可能是 Agent 猜对或训练数据里本就有
控制台痕迹	资产是否沉淀、是否被召回	有无铁证	沉淀了未必被召回到这次对话

关键概念:对话侧回答「记忆有用吗」,控制台侧回答「记忆真的在吗」。两个问题都重要,合起来才是完整的验收。

二、对话侧行为验收:结构化测试对话

设计一组「信息密度高、可观测」的测试对话,覆盖三类典型记忆:

记忆类型	喂什么	问什么	怎么算通过
偏好	「我们统一用 Go,禁止 ORM」	「写个查询订单的接口」	默认 Go + 手写 SQL
约束	「鉴权模块别动,移动端在用」	「重构一下鉴权」	主动提醒约束
事实	「我们的 CI 跑在 GitHub Actions」	「在哪看构建日志」	直接答 GitHub Actions

⚠️ 注意:喂的信息要「反直觉」——即不太可能是模型训练数据里默认就有的。比如「禁止 ORM」比「用 RESTful」更好,因为后者模型本来就会默认这么做,无法区分是「记住了」还是「猜的」。

执行时还要注意一点:召回发生在「会话初始化与请求转发之间」,所以新开一个会话再问,比在同一会话里紧接着问更能验证「跨会话记忆」——后者可能只是上下文还在窗口里。

三、控制台痕迹验收:看沉淀与召回

打开控制台(http://localhost:8125),按以下路径核查「记忆真的在吗」:


控制台核查路径
  ① 资产背包 / Chat Memory
       → 看你喂的偏好是否被提炼成 L1 Atom(如「技术栈:Go,禁止 ORM」)
       → 在 = 沉淀成功(L0 录制 + L1 抽取都工作了)

  ② 同一条资产的「使用次数 / 最近使用」
       → 数字 > 0 或时间戳更新 = 召回成功(召回引擎工作了)

  ③ 该资产的「绑定 Agent」(Loadout)
       → 绑定了你接入的 Agent = 装配生效(过滤机制工作了)

三条核查对应三个子系统:① 对应抽取 Pipeline(第 6 章),② 对应召回引擎(第 6 章),③ 对应装配机制(第 3 章)。如果三条都通过,说明从「录入 → 抽取 → 召回 → 装配」的完整链路都工作了。

💡 技巧:控制台看到的 L1 Atom 是「抽取后」的精炼形式,可能和你原话措辞不同(例如「禁止 ORM」可能被提炼为「约束:不使用对象关系映射」)。这是正常的——抽取 Pipeline 做的就是把原话提炼成结构化记忆,详见第 6 章。

四、验收不通过时的分流

把两种验收的结果组合起来,能快速定位问题出在哪一段:


沉淀了吗？(控制台①)   召回了吗？(控制台②)   装配了吗？(控制台③)   对话对吗？
     ├─ 否 → 抽取链路问题(核心服务/抽取Pipeline,第6章)
     ├─ 是   ├─ 否 → 召回引擎问题(检索/预算,第6章)
     │       ├─ 是   ├─ 否 → 装配问题(Loadout/可见性,第3/5章)
     │       │       ├─ 是   ├─ 否 → 注入问题(代理层injection,第8章)
     │       │       │       ├─ 是 → ── 全链路通过 ──

这张分流图是后续所有排错的「主心骨」——附录 A 的排错表很多条目最终都会归到这几个节点上。

本节要点回顾

两套并用:对话侧行为验收看效果,控制台痕迹验收看证据,合起来才确信。
对话侧要点:喂「反直觉」信息,新会话再问,覆盖偏好 / 约束 / 事实三类记忆。
控制台三核查:资产是否沉淀(抽取)、是否被召回(召回引擎)、是否绑定 Agent(装配),对应三个子系统。
措辞差异正常:L1 Atom 是精炼后的结构化记忆,和原话不同是抽取在工作,不是 bug。
分流主心骨:沉淀 → 召回 → 装配 → 注入四节点排错图,是全书故障定位的骨架。

至此你已完成「跑起来 + 接入 + 验收」的完整闭环,拥有了一套确信可用的记忆系统。第 2 章我们退一步,建立这张系统的全局地图——理解了地图,后续十一章的细节才有坐标。