用精简交接记录延续 AI 编程上下文

你刚纠正过 AI Agent 的实现方向，换个会话，它又准备从头改一遍。原文给出的办法很朴素：把需要延续的决定写成交接文档，让下次会话先读，再检查它是否真正用上。重点不在保存聊天记录，而在留下足以指导下一步的证据。

这套流程值得关注，因为它把「记住了」拆成三个独立问题：信息有没有保存、有没有被取回、有没有被正确执行。文件落盘，只完成了第一步；换模型或接入记忆工具，也不能省掉后两步的验证。

交接该留下什么，才能少解释一遍

原文建议把信息分成三类：

• 持续约束：项目规范和任务边界，在明确修改前继续有效。
• 当前决策：选了什么方案、为什么选、排除了哪些替代方案。
• 未完成工作：下一步做什么，需要什么证据才能确认完成。

这不是一套通用的记忆理论，而是便于人工检查的整理方式。原文提到的 CoALA 论文讨论了语言 Agent 的模块化记忆、行动和决策过程，并没有规定这份交接模板。

交接记录要回答下次会话可能遇到的问题。「处理了认证」几乎不能指导行动；「保留现有 session-cookie 流程，更换登录机制不在本次任务范围内」才划清了边界。

作者给出的模板可以直接放进项目的 SESSION-HANDOFF.md：

## Session handoff

### Goal
Add account settings without changing the login mechanism.

### Constraints
Keep the existing session-cookie flow.
Do not modify the billing integration for this task.

### Decisions and evidence
Use the existing settings layout.
Evidence: the owner approved reuse in the current task.
Check the layout component before editing; paths may have changed.

### Verified progress
Settings fields are rendered.
Validation and save behavior are not yet verified.

### Next action
Inspect the save handler, then test an invalid email address.

### Revisit when
The owner changes the authentication requirement.

这里最该保留的是 Verified progress 中的区分：字段已经渲染，不代表校验和保存行为已经验证。计划运行的测试，不能写成已经通过。

决策也需要证据。可以指向工单、源文件或明确的任务确认，让下次会话有东西可查。模板还提醒先检查布局组件，因为文件路径可能已经变化。交接记录应当帮助重新确认现场，而不是让旧信息变成不可质疑的指令。

让下次会话读到，还要检查它怎么用

SESSION-HANDOFF.md 只是约定的文件名，不会因此自动进入模型上下文。新会话开始时，需要明确要求 Agent 先读交接，再改代码；运行环境支持持久指令或启动钩子时，可以配置同样的行为，但仍要验证。

原文建议让 Agent 先复述两件事：当前任务有哪些约束，以及下一项尚未验证的动作是什么。然后拿复述内容和文档对照。

文件存在不等于模型读过，复述正确也不等于后续执行正确。

接着还要区分长期纠正和临时进度。「本项目复用现有设置页布局」可能需要跨任务保留；「接下来检查保存处理函数」通常只属于当前交接。判断标准很直接：这条信息是否应该活得比任务更久？

PLUR 是原文给出的一种实现。按原文描述，它默认在本地用 YAML 保存学到的知识，核心 API 支持学习、按项目组织信息以及请求注入上下文。在已经安装 @plur-ai/core 的应用中，示例是：

import { Plur } from '@plur-ai/core'

const plur = new Plur()

await plur.learn('Use the existing settings layout for this project.', {
  type: 'behavioral',
  scope: 'project:settings-demo',
  domain: 'dev/ui'
})

const context = await plur.inject('Implement account settings', {
  scope: 'project:settings-demo',
  budget: 1000
})

// 将返回的上下文块传给 Agent 的提示词组装流程。
console.log(context.directives, context.constraints, context.consider)

要盯住的是最后一行：拿到 directives、constraints、consider，还需要把它们接进 Agent 的提示词组装流程。这段代码不会自动完成连接，也不能证明纠正内容被选中或执行。budget: 1000 的具体计量单位，原文没有说明；项目 scope 也只是组织设置，不能据此当作权限隔离边界。

验证时，作者建议先保存一条无害约定：「演示环境叫 cedar」。结束会话后重新开始，不重复约定，直接询问环境名称。随后通过所用机制支持的更新流程，把名称改成「birch」，再测一次，观察旧信息是否仍然出现。

失败就沿链路排查：是否保存、是否选对存储或文件、是否读取、返回内容是否进入提示词。这个测试检查的是交接链路，不是性能基准。

我的判断

我认同原文把「记忆」拆成可检查步骤。对日常 AI 编程，任务边界、已确认决策和未验证行为，比整段聊天记录更容易审阅，也更容易发现过期内容。

但它的效果依赖维护。会话结束时，需要先让 Agent 提出交接更新，由人审阅后保存确认过的变化，并清理过时进度。否则文档越积越长，旧决定和新要求打架，反而增加误导。

原文没有给出跨会话成功率、节省时间或不同工具的对照数据，因此这是一套工作流建议，不能当作已经证明有效的记忆方案。它还注明由参与 PLUR 传播工作的 AI Agent Data 撰写并核查，PLUR 的介绍带有产品相关视角。

普通项目可以先用一份 Markdown 文件验证流程。相比保存完整对话，它更便于检查；相比直接接入记忆层，它少了检索和提示词集成环节。需要管理更多跨任务纠正时，再评估工具更合理。

能拿来做什么

• 做前端设置页任务时，把「复用现有布局」「保留 session-cookie 登录」「本次不改计费集成」写成明确约束，并附上可检查的依据。
• 结束会话前，要求 Agent 分开列出已验证进展和未验证行为。保存逻辑没测过，就继续标成未验证，并写清下一步要检查的处理函数和无效邮箱用例。
• 新会话先让 Agent 读取交接并复述约束，再开始改代码；后续审阅时继续核对实际修改有没有越过边界。
• 自己组装 Agent 上下文时，先用 cedar 改为 birch 的小测试检查保存、更新和提示词接入，确认链路通畅后，再扩展到更多项目知识。