你在 Codex 里排查一个 bug。问题找到了，代码也改了几处，正准备补测试，发现额度快用完了。

于是，你打开 Claude Code 或 ZCode 或 KIMI code，想接着做。

代码还在，但前面为什么这样改、哪些地方已经检查过、还有什么没验证，新会话并不知道。你又翻回旧对话，把任务背景和当前进度整理一遍，再贴过去。

如果直接复制整段聊天，里面还夹着已经放弃的方案和没确认的猜测。接手的 Agent 还得重新分辨哪些内容能用。

但需要交过去的东西并不复杂：现在要解决什么，做到了哪一步，下一步先检查什么。

PowerContext 已有 Handoff 工作交接机制。v1.4.0 新增的 Working Notes，让开发过程中的进度和待办可以单独保存，并作为交接依据；Dream 则用来修订开发中发现已过时的项目知识。下面先把手上的工作交清楚，再看已经保存的经验怎么更新。

本文使用演示记录说明流程，完整安装、配置和脚本详见：配套实践步骤 ^[1]。

欢迎大家关注 OceanBase 社区公众号“老纪的技术唠嗑局”。在这里，我们会持续为大家更新与   和  #Data 相关的技术内容~

切换之前，先留下“做到哪了”

趁当前会话还能工作，把进度保存下来。比如这次要修复空输入时报错的问题，可以留这样一张便签：

目标：修复空输入时的报错。
已完成：确认触发条件，补了判空逻辑。
待验证：空输入不再报错，正常输入不受影响。
下一步：检查代码改动，运行对应测试。

这里没有把代码写完记成问题已经解决。 接手时先看改动、继续测试，工作就有了明确的起点。

Working Notes 用来保存这种短期记录。配套脚本通过  capture_working_note 保存便签，并返回精确的记录引用。他不会自动生成长期记忆，也不会仅因为写下了已完成就替你验证代码。相关改动详见：PR ^[2]。

在已经配置 PowerContext、支持 Handoff 的宿主中，可以用这样的要求准备交接：

为当前任务准备 PowerContext Handoff，引用这张便签，写清目标、已经完成的检查和下一步。供我核对后提交。

检查内容并提交后，把 Handoff 的精确引用交给接收方。另一个已接入的 Agent 需要访问同一份项目数据，读取交接记录，并先核对当前代码，再继续工作。Handoff 和便签提供的是历史信息，当前用户要求和仓库状态仍要检查。

配套示例给便签设置了七天有效期。过期后，原始记录仍保留，但不能再作为新的 Handoff 的有效依据；没设置有效期时，也不会因为关闭会话而自动失效。

开发中确认了新做法，再更新项目记忆

当前进度交代清楚后，还有一类内容值得留给后续开发：项目已经确认、以后还要沿用的做法。如果以前的记忆与当前项目说明不一致，需要修订旧记录。

为了把操作讲清楚，配套实验只选一条测试命令。假设之前保存的是：

本项目运行测试使用  npm test。

现在，项目说明已经更新为：

本项目已改用 pnpm 管理依赖，测试命令统一为  pnpm test。旧说明中的  npm test 不再作为本项目推荐入口。

这就有了明确的修改对象和依据。用 Dream 指定那条旧记忆，把当前项目说明作为依据提交，模型会生成一份修改建议。你检查后批准，新内容才会保存成新的版本。相关改动详见：PR ^[3]。

实际操作时，先运行配套脚本，保存旧记忆和当前项目说明，并生成  dream.json。配置好模型和后台执行能力后，用脚本返回的  SCOPE_ID 提交请求：

powercontext dream run --scope-id "$SCOPE_ID" --request-file dream.json

SCOPE_ID 指定这组项目记录所属的数据范围。提交后，把返回的运行 ID 保存为  RUN_ID，查询进度：

powercontext dream show --scope-id "$SCOPE_ID" "$RUN_ID"

运行完成后，先确认是否生成了修改建议。模型也可能判断不需要修改，或认为依据不足。 请求被受理，不代表记忆已经更新。

如果生成了建议，将他的 ID 保存为  CANDIDATE_ID，查看内容：

powercontext candidate show --scope-id "$SCOPE_ID" "$CANDIDATE_ID"

这个例子主要核对两件事：测试命令是否改成了  pnpm test，引用的依据是否就是刚保存的项目说明。建议里如果多出“测试已经全部通过”，先别批准，因为项目说明没有提供这个结论。

有相应权限的审核者确认后，将建议的版本号保存为  REVIEWED_VERSION，批准刚检查过的这一版：

powercontext candidate approve \
  --scope-id "$SCOPE_ID" \
  --expected-version "$REVIEWED_VERSION" \
  "$CANDIDATE_ID"

如果审核期间原记忆已被其他操作修改，系统会检查当前版本并拒绝过时的批准请求。批准成功后，按返回的引用读回新记忆，确认命令已经更新。

这次演示修订的是一条 Memory。1.4.0 的 Dream 还支持 Profile、Prompt 等类型，完整范围见配套教程。 修订需要显式发起并经过审核；日常聊天中的一句纠正，不会因此自动改写所有记录。

改了哪句话，打开历史看一眼

修改通过后，有时还需要回头确认：旧版本具体写了什么，这次又改了哪里。

在 Dashboard 中选择相同的 Scope，找到测试命令这条记忆，打开历史版本并进行对比。旧版本写的是  npm test，检查新版本是否已经改成  pnpm test，有没有多出未经确认的内容。

这里查看的是记忆的修改历史。修 bug 的代码改动，仍在 Git 中查看。

历史查看、对比和回退的支持范围如下：

支持回退的类型在恢复旧内容时，会追加一个新版本，并保留恢复来源和原因。旧历史不会被覆盖。执行回退需要相应权限，也要通过当前版本等条件检查。相关改动详见：PR ^[4]。

Kimi Code 也能读取已经保存的记忆

v1.4.0 还增加了一个接入入口：Kimi Code。它的试验性最小接入支持保存、搜索和读取指定版本的记忆。前面更新的测试命令，就可以用它读回检查。相关改动详见：PR ^[5]。

这个最小接入尚不包含 Handoff，因此这里演示的是读取项目记忆。

准备好 Kimi Code、Node 24+、已启动的 Server 和已有 Scope。在与 CLI 版本一致的 PowerContext 源码目录中，使用配套步骤设置的地址和 Scope 安装：

powercontext setup kimi-code \
  --source "$PWD" \
  --server-url "$POWERCONTEXT_CLIENT_SERVER_URL" \
  --scope-id "$SCOPE_ID"
powercontext doctor kimi-code

安装后开启新会话，直接问：

这个项目现在怎么跑测试？请搜索 PowerContext，给出记录引用，再读取原文。

先查询，不要把新命令再存一遍，否则可能读到另一条新建的记录。检查返回的记录 ID 和版本，是否与刚才批准后的结果一致，再看正文里的命令。

这样才能确认读到的是修订后的记忆。如果仍然返回旧版本，就检查项目的数据范围、批准结果和检索结果。配套教程列出了具体字段。

同一个 Kimi home 使用一个配置好的 Scope。自动从原始材料生成记忆，还需要 Server 的模型和调度配置。安装检查通过后，仍要实际搜索和读取一次。

换环境时，保留这次修改的来龙去脉

换台机器继续开发时，除了同步代码，还可以把 PowerContext 中的项目记录迁过去，包括测试命令的历史版本和修改依据。

v1.4.0 的  .pcb 逻辑归档支持选择完整 Scope，导出所支持的内容、版本和证据关系。归档命令通过离线 CLI 直接访问数据库，不经过 Server HTTP 接口。相关改动详见：PR ^[6]。

使用配套实践中的  source.env、 target.env 和  SCOPE_ID，先导出并检查：

mkdir -p backups
powercontext archive export --env-file source.env \
  --scope-id "$SCOPE_ID" --output backups/bugfix-context.pcb
powercontext archive inspect backups/bugfix-context.pcb
powercontext archive restore backups/bugfix-context.pcb \
  --env-file target.env --dry-run

inspect 检查归档文件， --dry-run 检查目标环境能否接收这份数据。确认结果后，停止目标数据库的写入进程，再执行恢复：

powercontext archive restore backups/bugfix-context.pcb \
  --env-file target.env --yes

恢复响应中的  projections_ready: true 表示搜索投影已就绪。随后按原来的精确引用读取记录，并检查检索结果。

源代码和未提交的修改需要另外同步。 归档也不包含凭据、权限绑定等全部部署状态，不能替代数据库原生备份。当前不支持 Tag 变更候选；配套示例使用 SQLite，远端 OceanBase 恢复需要另行验证。

回到开头，切换 Agent 前留下当前进度和依据，接手后先核对记录与代码，再完成未做的验证。工作交接到这里才算有了可执行的下一步。 至于 bug 是否修好，仍以实际检查和测试为准。

使用与升级

配套步骤使用全新的演示数据库。已有部署需要按正式发布的迁移说明处理数据库，并配套升级 Server、Client、SDK、CLI 和宿主集成。 本次 Candidate 接口有不兼容变更，旧的  /v1/artifact-candidates/* 路径已移除。

贡献者致谢

感谢参与 v1.4.0 开发的贡献者，以及参与设计讨论、代码审阅、测试和问题反馈的社区成员。

相关工作和 PR 详见：贡献明细 ^[7]。

配套实践步骤:  powercontext-1-4-practice-lab.md

PR :  https://github.com/oceanbase/powercontext/pull/1949

PR :  https://github.com/oceanbase/powercontext/pull/1716

PR :  https://github.com/oceanbase/powercontext/pull/1813

PR :  https://github.com/oceanbase/powercontext/pull/1964

PR :  https://github.com/oceanbase/powercontext/pull/1561

贡献明细:  powercontext-1-4-practice-lab.md

立即试用 OceanBase 企业版，体验国产数据库能力 立即试用