记忆系统的可观测性与调试

一、一个让我抓狂的下午

Agent 突然做了一个我完全理解不了的决定。在修复一个数据库字段映射问题时，它选择了最绕的方案——先加一个中间表做转换，再在查询时做 JOIN。

我问它：为什么不用我上次已经配好的 field_mapping 表？

它回答："我检索到了相关记录，认为那个方案不适用当前场景。"

我翻它的检索记录。发现它确实搜到了 field_mapping 的那个决策，但在检索结果中，同时出现了三条关于"数据库字段兼容"的旧记录——那是两个月前另一个完全不同的问题。那些旧记录和当前问题的关键词重叠度很高，被一起召回。

这个问题的根因不是 Agent 推理能力不够，而是我无法看到它记得什么、从哪里找到的、为什么做了这个选择。 在传统软件里，这叫缺乏可观测性；在记忆系统里，这意味着不可调试。

二、三个观测维度

维度一：内容观测——Agent 现在记得什么

你翻开记忆库，能不能在 30 秒内回答：有多少条记录？最近一周新增了什么？有没有明显过时或冲突的条目？

最简单的方法：记忆清单。 把情景记忆文件设计成人类可读的 Markdown 格式，而不是纯 JSON。每周打开看一眼。

# 记忆清单（2026.07.07）

## 本周新增
- [sync_engine] 字段映射从 hardcode 改为配置化 ✅
- [database] 新增地域维度表结构确定 ✅
- [api] 限流策略还在讨论中 ⏳

## 即将过期（剩余 7 天内）
- [config] 临时关闭了日志级别 DEBUG → 记得恢复

维度二：行为观测——Agent 检索了什么

每次 Agent 做决策时，它从记忆系统里检索到了什么，这是最关键的观测点。

关键问题： 这次决策中，Agent 依赖了哪些记忆？有没有过时的信息？有没有应该检索到但没找到的信息？

实操做法： 在 Agent 的上下文中，把检索到的记忆条目显式列出来。让用户能看到"Agent 参考了这些历史记录"。

维度三：决策观测——记忆影响了什么

反向追溯：假如我想知道"关于字段映射的所有决策"，能不能找到？

关键问题： 这条记忆被用来回答过哪些问题？它参与了多少次推理？

三、Memory Bank 模式

不需要监控系统，不需要 Dashboard。用 Markdown 文件就能跑起来：

~/.hermes/memory-bank/
├── 2026-07-01.md     ← 每天的会话摘要
├── 2026-07-02.md
├── weekly/           ← 按周归档
│   └── 2026-W27.md
└── INDEX.md          ← 快速索引

这个模式的好处：人类可读、无需额外工具、Agent 可读、版本可控。

四、排查步骤

当你发现 Agent 表现异常，怀疑是记忆系统的问题时：

五、实践建议

今天的改进： 在 Hermes 的系统提示词中加一句："当你参考了历史记忆时，说明信息来源。"

本周的改进： 建立一个 memory-bank/ 目录。每个会话结束时，让 Agent 生成一个 Markdown 摘要存入。

系列完结

从第一篇《Agent 的"失忆症"》到这一篇，记忆系统系列覆盖了：

1. 诊断篇 — 断片的三种表现
2. 框架篇 — 三层记忆模型
3. 工作记忆 — Token 预算与上下文管理
4. 情景记忆 — 跨会话持久化与检索
5. 遗忘策略 — 什么时候该忘记
6. 可观测性 — 如何调试记忆系统

六篇构成了一个完整的闭环。下一步，这些方法论应该落地到 Hermes 的实践中。