记忆库能通过测试 不等于回答值得信：Coding Agent Memory 的两层评估设计

当 Agent 回答“上次为什么改这个路径”时，最危险的不是答得慢，而是答得像真的：引用相邻工单，把已推翻的结论当当前结论，或把症状说成根因。仓库测试全绿，用户仍不知道答案有没有证据。

先声明：本文不发布虚构准确率，也不把 lint 通过当“记忆有用”。讨论对象是 miniLV/coding-agent-memory 的评估设计，以及 Issue #4 提出的 10～20 个安全案例。目标是让答案说清楚：凭哪条证据、属于哪层支持、是否应该回答。

1. 为什么常规流水线测试不够

字段、日期、链接和退出码检查的是“能不能写出来”，却没有覆盖三件事：当前结论与已替代结论并存时会不会误复用；精确 ticket、路径或根因问题是否带回对应证据；记忆没有相关内容时能否返回 NO_MATCH，转入 fresh inspection。

README 的公开命令 node --test scripts/*.test.mjs && node scripts/wiki-lint.mjs --strict，证明本地工作流可重复、来源约束可检查；它不证明未来问题都能答对。更现实的是，当前检索是按流程执行的 Agent Skill，不是可枚举结果的确定性查询内核。若旁边再放词法 evaluator，或把预录答案塞进评估器，测试容易自证：两边共享假设，绿灯只说明彼此配合。

2. 先定义“支持层”

规格要显式区分两条轴：用户写下的决策与Agent 推断的总结；记忆可回答与必须重新检查仓库。每个案例至少声明：

• expected_mode：memory_answer 或 no_match（需要 fresh inspection）。
• support_layer：user_authored_decision、agent_inferred_summary、fresh_inspection_required。
• evidence：允许的来源链接、ticket、路径或段落定位。
• must_not_reuse：相似但过期、只描述症状、或不属于本流程的证据。

“误复用”是拿不该支持当前结论的证据来支持；NO_MATCH 不是失败，而是安全结果：记忆不足，应该查新。

3. 第一层：确定性证据保留评估

现在就能做的第一层不评判文风，只检查产物是否留下可复核事实：日期、来源、工单、路径、当前/已替代关系、根因与症状区分，以及 Daily 到来源的 provenance 链。案例规格可以很小：

- id: stale-01question: "这个决定现在还有效吗？"expected_mode: memory_answersupport_layer: user_authored_decisionevidence: [source_link, ticket, supersession_marker]must_not_reuse: [superseded_conclusion]- id: unseen-01question: "没有记录的模块为什么变慢？"expected_mode: no_matchsupport_layer: fresh_inspection_requiredevidence: []

测试只对照 evidence ID、时间和关系，验证“有证据才允许回答”，不生成漂亮的标准答案。10～20 个安全案例覆盖 Issue #4 的范围：当前/已替代结论、精确 ticket/path、根因/症状、可复用指导、无匹配、引用完整性和多工作流长样本。产物是可审计的证据报告，不是“记忆准确率”。

4. 第二层：Agent-in-the-loop 有用性评估

第一层稳定后，再把真实 Agent 放进回路，但不给预录答案。运行记录保存案例版本、evidence ID、回答、声明的 support_layer、是否 NO_MATCH、是否请求 fresh inspection、模型/配置和时间。

评估器检查支持关系而非逐字相等：引用是否在允许集合；旧结论是否标为 superseded；根因问题是否引用根因证据；memory_answer/no_match 是否符合规格；需要查新时是否停止记忆推断。确定性来自固定案例、证据集合与审计日志，有用性来自真实 Agent 的选择。不要再加并行词法 evaluator，也不要把期望答案硬编码进 Skill，否则仍是自证。

总结

测试通过，只说明系统守住了已声明的约束；答案可信，还要证明引用了正确层级的证据，并在无证据时拒绝猜测。 先做证据保留，再做 Agent-in-the-loop，才能把格式正确与记忆可靠分开。

你更难复现的是“旧结论误复用”还是“该 NO_MATCH 却继续猜”？欢迎把边界案例补到 Issue #4；如果这套分层思路有帮助，再给仓库点个 Star。