智能体记忆

AI 很擅长读代码和读对话,但一旦会话结束,就会忘记『自己在这个工作台里能做什么』。 于是对于已经成功做过一次的事(部署·构建·连接数据库),它在下一次会话又会误判成『没有凭据,做不了』。

智能体记忆让 AI 把已验证的事实存入精确匹配抽屉,并在下一次会话自动取出复用。它不与 RAG(语义近似检索)竞争,而是分工——事实判断交给抽屉,近似检索交给图书馆。

为什么需要 —— 从一次真实事故说起

Blyck 部署原本在这台 PC 上可以直接完成(aws CLI 已配置,有直接部署记录),流程也已文档化。然而智能体每次会话都反复误判成『没有凭据,无法部署』。原因是它只看了代码注释,就推断出『需要额外步骤 = 我做不了』。

诊断后发现,薄弱环节不是回忆,而是存储。

阶段	状态	依据
回忆(recall)	正常	只要存了,一定会被读到
存储(capture)	失败	『这台 PC 可部署』从未被持久化存储过

也就是说,问题不在于记不住,而在于根本没有创建要记住的条目。 行为(一次 s3 cp)看似易失,但它所证明的能力(『可部署』)是持久且可复用的事实。这种区分上的失败,正是盲区所在。

核心原则

记忆不丢进 RAG 大锅里。 事实/能力记忆不靠语义近似检索,而靠精确匹配取出。
存储不依赖自觉。 把成功的行为自动晋升为能力候选(但有审批门)。
回忆自动注入。 相关记忆无需调用即可进入上下文。
断定无法做到之前先验证。 在说『做不了』之前,先查记忆 + 用廉价探针确认。

比喻 —— 图书馆与桌面抽屉

📚 图书馆检索(RAG):把代码·对话·日志全堆起来,『找相似的』。量大且近似,会混入垃圾。→ 用于『以前类似的代码在哪来着?』。
🗂️ 桌上的便签抽屉(记忆):只放寥寥几条已验证的核心事实,整洁。精确,且始终可见。→ 用于『这台 PC 可部署』『别碰 PROD DB』。

RAG 与记忆不是竞争,而是分工。事实判断交给抽屉(首选),近似检索交给图书馆(辅助)。

类型化精确抽屉

记忆以类型化记录存入 workspace.sqlite 的专用表。

字段	说明
`type`	`capability` · `decision` · `rule` · `procedure` · `fact`
`scope`	`workspace`(默认) · `global`
`key`	精确匹配标识符(例如 `deploy:blyck`)
`body`	人类可读的事实正文
`confidence`	0~1(已验证=1.0)
`proof`	依据(例如『aws sts 通过;s3 cp 成功』)
`status`	`active` · `stale` · `retired`

存储(capture)—— 用三重机制补强薄弱环节

方式	触发	垃圾拦截
显式	`memory_write(key, body, type, scope)` MCP 工具	仅限有意调用
自动晋升	从活动日志检测成功事件(部署·构建·认证·连接数据库)→ 生成候选	审批门
反思遍历	聊天结束/里程碑时汇总会话 → 提取『学到的持久事实?』候选	审批门

三条路径都只有在审批之后才进入抽屉,因此没有 RAG 式自动吸入的噪声。

自动晋升分类器晋升为能力候选的成功事件示例:

外部认证/部署成功(aws … 成功、gh auth、deploy/publish)→ capability
构建/打包成功(npm run dist、测试通过)→ capability/procedure
数据库/SSH 连接成功(凭据已验证)→ capability
用户以命令式给出的规则(『别碰 PROD』)→ rule
过于琐碎或一次性的(如单纯读文件)排除——避免审批疲劳

回忆(recall)—— 自动注入

每个回合组装上下文时,都会插入记忆召回阶段。

用当前查询·活动面板·项目做 key 精确匹配 + 轻量语义匹配。
把排名前 k 的 active 记忆自动注入系统提示(无需另行调用)。
recency·importance 加权 + decay → 长期不用的记忆 stale→retired。

AI 工具(MCP)

工具	权限	作用
`memory_write(key, body, type, scope)`	确认	把事实显式存入抽屉(相同 key 覆盖)
`memory_read(key?/query?)`	读取(自动)	用 key 精确匹配或轻量语义匹配查询记忆

大多数回忆都由自动注入处理,因此无需逐个调用 memory_read。它用于补充查询自动注入遗漏的条目。

decay 与清理

为避免抽屉膨胀,基于 last_seen 清理长期不用的记忆。

capability · rule · procedure 免于自动消亡 —— 目的正是防止上文§事故复发。一旦验证过的能力,即便不用也不会消失。
仅 decision · fact 在 90 天→stale,180 天→retired。
显式查询时 stale→active 复活。

完整流程 —— 今天的案例

[保存] 首次部署成功 → 活动日志 "s3 cp blyck-releases 成功"
   → 晋升分类器检测到 → 候选 {capability, key:"deploy:blyck",
      body:"本 PC 可直接部署:npm run dist → s3 cp → cloudfront invalidate",
      proof:"aws sts 通过;s3 cp 成功"} → [批准] → 钉入抽屉

[召回] 下一次会话 "部署" → 上下文组装自动注入 "deploy:blyck"
   → "无凭据" 的推断本身不可能 → 事故零复发

与 Claude 文件记忆的关系

本功能照搬了 Claude Code 文件记忆(MEMORY.md + *.md,每次会话自动加载)的精确·自动回忆,同时补足了它的弱点。

项目	Claude 文件记忆	Blyck 定着抽屉
存储位置	Markdown 文件	workspace.sqlite 表
存储触发	智能体判断(手动)	手动 + 行为自动晋升 + 反思遍历
自动存储	✗	✓(成功事件晋升)
垃圾	少	几乎为 0(UNIQUE key + 审批)
去重	人工管理索引	`UNIQUE(scope, key)` 自动
decay/清理	手动	基于 `last_seen` 的 stale/retire
领域感知	通用	针对 Blyck 活动(部署·DB·SSH)特化

决定性差异在于自动存储。 上述事故是在 Claude 文件记忆开启的情况下发生的——回忆完好,薄弱环节在于『存储依赖判断』这一点。Blyck 有活动日志这一行为记录,因而能把成功事件自动晋升为能力候选,而这正是仅靠文件记忆在结构上无法做到的部分。

安全

跨聊天记忆默认 scope=workspace + 敏感信息过滤,不与全局会话不迁移、只读的原则冲突。
密钥不存入记忆正文(OS 加密存储 + 自动遮罩走另一条路径)。

FAQ

Q. 已经有 RAG 了,为什么还需要记忆? → RAG 是语义近似,做事实判断会混入垃圾。像『这台 PC 可部署』这类已验证的事实,必须从精确匹配抽屉里 1:1 取出才安全。两者分工。

Q. 我得逐条说『记住』吗? → 不用。虽然可以用 memory_write 显式存储,但成功事件会作为自动晋升候选浮现,你只需审批即可。聊天结束时,反思遍历还会自动提取规则。

Q. 存错的记忆会一直跟着我吗? → 相同 key 会被覆盖,decision/fact 会被 decay 清理。错误的能力记忆可以用 memory_write 更新或将其 retire。

Q. 已验证的能力因为不用而消失,不会又出事吗? → 所以 capability·rule·procedure 免于自动消亡。一旦验证过的能力,即便不用也会留在抽屉里。