让智能体跨会话接续工作的交接清单

AI Agent 总追问已经定好的事，问题可能出在会话交接：决策没有保存、存错了项目，或者虽然检索到了，回答时却用错了。作者提出了一套轻量检查流程，把这些环节逐个验收。

它没有证明某个记忆工具能彻底解决重复解释，而是给出一种可复现的排查办法。对经常跨会话使用 AI 编程的程序员，这比一句「帮我记住」更有用：你能检查下一次会话究竟接住了什么。

接着聊和记住决策，是两件事

恢复原来的对话，和新开对话后调用旧知识，测试的是不同能力。

作者借用 LangChain 文档的区分：线程内状态（thread-scoped state）服务于当前对话，跨线程的长期记忆（long-term memory）负责让知识在不同对话之间复用。即使不用 LangChain，也应该先分清：你要继续某项任务，还是让一个决定约束后续任务。

交接时，作者建议维护两份小记录：

• 任务状态：已经完成什么、下一步做什么、相关工作在哪里。
• 长期知识：已经确认、以后仍适用的偏好、约束和决策。

例如，「检查失败的重试路径」是待办；「重试必须复用原来的幂等键」才可能成为长期规则。幂等键用于识别同一次业务请求，避免重试被当作新的操作。

待办需要被接着执行，决策需要在适用范围内被遵守。

讨论中出现过的方案，不能一律升级为长期指令。尝试过、否决过、正式确认过，三种状态必须保留区别。

怎样证明交接真的保存并生效了

作者建议先让 Agent 提出简短交接记录，再审查其中含糊的决定。下面的模板用于把进度、规则、证据和疑问分别写清；它只是示例，不是 PLUR schema，也不是可执行配置。

Project: checkout-service
Completed: added a regression case for duplicate requests
Next step: inspect the failing retry path
Decision: retries must reuse the original idempotency key
Evidence: decision note in the repository
Applies to: checkout-service retry handling
Still uncertain: whether the upstream timeout is configurable

要留意 Applies to 和 Still uncertain：前者限定规则只适用于该服务的重试处理，后者防止摘要把尚未确认的超时配置能力写成事实。实际使用时，证据位置也应写到后续能找到的程度。

保存后，不要只看 Agent 回复「已记住」。应该查看存储记录，或者调用记忆系统支持的读取操作，核对写入是否成功、内容是否准确、目标项目或用户是否正确，以及证据和不确定性是否还在。

原文以 PLUR 为例：plur_learn 用来保存纠正、偏好和约定，plur_recall 用来检索相关记忆，默认本地记忆格式使用 YAML engrams。这些工具提供了检查入口，但工具存在不代表交接已经通过验收。

接下来，使用相同的目标项目和记忆配置，新开一个真正独立的会话，提问：

「我要修改 checkout-service 的重试处理，应该遵守哪条已有决策？它来自哪里？」

不要把答案一起贴进去，否则只能证明 Agent 会读取当前提示。验收应看两件事：有没有找对规则，以及有没有正确说明规则的来源。检索成功后附上一段无依据的解释，仍然需要单独记录为问题。

为什么还要测其他项目和旧规则

只在目标项目里问对一次，还不足以放心使用。

先在无关项目里重复提问。checkout-service 的重试约束，不应该自动变成所有服务的通用规定。

PLUR 文档提供了 project:myapp 这样的作用域，以及 plur_learn 的单条记忆作用域；原文还提醒，项目检索可能包含全局知识。因此，项目规则应该选择项目作用域，不能把「global」理解成当前任务私有。最终仍要在实际运行环境中验证。

然后，在可丢弃的测试项目里修改示例规则，按系统文档规定的流程纠正或退役旧记忆，再开新会话查询。

纠正成功的标准，是旧规则不再被当作当前决策。

新文本已经存在，远远不够。如果新旧版本同时出现，需要有证据说明谁替代了谁。

这里还有一个容易误解的细节：PLUR 的 plur_forget 被描述为让记忆退役，涉及激活度衰减和最终清理。不能据此宣称所有副本、备份都已立即物理删除。

我的判断

这套方法最有价值的地方，是把「记住了没有」拆成可定位的失败环节：信息提取、存储、作用域、检索，以及回答中的使用。哪一步失败，就修哪一步，再用相同的小场景复测。

但它是一份工作流建议。作者没有给出重复解释次数、检索准确率或团队效率的对照数据，也没有证明 PLUR 比仓库里的决策文档更有效。文末披露内容由 AI Agent Data 撰写并核查，这也不能替代实际运行记录。

对一般团队，难点还在于谁有资格确认决策、规则何时过期、证据能否持续找到。这份清单要求保留证据和修订关系，却没有展开完整的治理办法。

如果决策很少，把规则写进可版本管理的仓库文档，再让 Agent 按需读取，也值得采用。记忆工具能辅助跨会话检索，但是否优于这类简单做法，仍要用自己的项目验证。

能拿来做什么

• 结束一次 AI 编程会话前，让 Agent 分别列出任务状态和已确认决策；审查后再保存，尤其检查被否决的方案有没有混进规则。
• 修改 Node 服务的重试逻辑时，用一个已确认的项目约束做交接测试，新开会话要求 Agent 给出规则和证据，提问时不要透露答案。
• 同时维护多个仓库时，在无关项目里重复测试，确认某个项目的技术约定没有被套用到其他项目。
• 调整既有约定后，补测一次旧规则退役，并保留一个未解决的问题，检查 Agent 是否仍明确承认未知。