用户认可了一次回答，系统就应该记住它吗？ / YM

用户看完一段项目分析，说“这个有用”。产品可以把它理解成这次任务得到帮助，也可以据此保存长期记忆，甚至修改项目里的正式结论。三种反应看起来都在“学习用户反馈”，后果却不同。

一次认可究竟授权了什么？ 这是 AI 产品引入记忆时需要先回答的问题。TraceWise 的资料会参与后续检索、调查和图变更，所以我把当前任务反馈、经验复用和正式知识修改分别处理。这个选择增加了操作成本，但能让每个决定的对象更清楚。

先把反馈的时间范围说清楚

Amershi 等人在 CHI 2019 的人机交互指南中，区分了单次交互中的细粒度反馈与全局行为控制，并要求说明用户操作如何影响未来行为。论文修订过程还专门澄清了短期交互记忆与长期行为学习的区别。Guidelines for Human-AI Interaction，表 1 与指南修订讨论

这项研究没有要求所有记忆都必须人工审核。应用到项目知识场景，我得到的判断是：先让用户知道这次操作改变什么，再决定需要多少控制。

以一个解释用场景为例：项目调查发现某次延误与外部依赖有关。用户认可“先核实依赖交付时间”的建议，未必意味着他认可“外部依赖是所有延误的原因”。把有用的排查办法保存为带条件的经验，与把原因写进正式项目知识，需要不同依据。

这是本文整理的决策划分。对简单个人偏好，产品可以合并一些交互；对会影响后续正式判断的项目知识，分开记录能减少授权歧义。

TraceWise 早期 Observation Routing 默认返回 not_observed。普通回答完成后，只有产品显式提供包含主张、适用时间、复用范围、Evidence 身份与指纹的候选，才进入规划。

当时的 a6 受控验收中，合法候选可以得到 planned，但语义权威、配置和操作三类写入标志均为 false；调用前后的权威状态指纹一致。这个历史案例说明，可以先把“值得考虑保留”表达为一个可校验对象，而不用立刻写入长期知识。

可选规划失败时，已经完成的回答可以保留。这条隔离有前提：失败的是可选记忆步骤，而不是本次回答所依赖的证据读取或授权。后两者失败时，不能沿用“记忆是可选的”来声称回答仍有完整依据。

早期零写入规划为后续审核提供了边界，但它本身没有证明记忆可以被真实复用，也没有测量回答质量收益。

a17 的业务服务先检查会话、任务、项目和调用者是否匹配，再为成功返回的任务保存结果确认，记录该次结果的指纹。用户可以确认问题已解决，也可以标记仍需跟进；这个动作本身不执行权威写入。

准备经验候选时，服务要求使用对应任务最新的有效解决确认。如果回答内容变了，或者用户后续表示问题仍未解决，旧的认可就不能继续充当同一个候选的依据。

这个约束针对的是一个容易忽略的情况：界面上都是“这次回答”，但重试或继续调查以后，内容已经不同。确认需要绑定当时的结果，才知道用户究竟认可了什么。仅保存一个点赞布尔值，难以表达这层关系。

准备经验时，当前实现重新检查已引用来源，通过公开客户端以 write_mode='propose' 创建候选，并保留适用条件、限制、来源与确认身份。候选具有独立 Memory 审核；它还明确标记自己不拥有当前事实权威。

正式改图走另一条入口。用户选择服务端已保存的发现与目标节点，产品读取当前摘要，形成可审阅的前后差异。原文观察、反证与假设保持不同标签；选中的假设不能在准备提案时悄悄改成事实。提交之后进入 Graph 审核，批准之后仍要等待执行。

这里最关键的区别是：Memory 审核回答“以后是否允许复用这段经验”，Graph 审核回答“是否同意这次具体修改”。前者不能代替后者；后者也不能把尚未执行的修改提前描述为已生效。

结果复核又是另一件事。当前代码在执行状态为 applied 且具有回执后，读取目标摘要并重新检查引用来源。若读取不可用，保留“已写入、复核不可用”的状态，而不是把已经发生的写入描述为回滚。

截至 2026 年 9 月 13 日，这些控制流已经进入 a17 源码，聚焦业务测试使用公开客户端夹具验证分离、作用域和幂等行为。真实共享服务上的两项目完整业务验收，以及记忆后续复用的效果，仍未完成。这里能讨论的是控制设计与局部检查，不能据此宣布长期记忆闭环已经验证。