当 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 链。案例规格可以很小：
yaml
- id: stale-01
question: "这个决定现在还有效吗？"
expected_mode: memory_answer
support_layer: user_authored_decision
evidence: [source_link, ticket, supersession_marker]
must_not_reuse: [superseded_conclusion]
- id: unseen-01
question: "没有记录的模块为什么变慢？"
expected_mode: no_match
support_layer: fresh_inspection_required
evidence: []测试只对照 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。