4. 让 Codex 修改 Memory

Codex 已经读到了部署回滚检查单。假设你在工作中发现：文档说明了如何恢复上一版，却没有要求验证回滚结果。本篇把这个发现保存为一处待审修改。

开始前

继续使用上一页绑定到 Payments 的 Codex 任务。你需要有权访问这个 Project，并使用自己的 Clumsies 账号提出草稿。

先确认检查单尚未包含下面的验证步骤。如果真实文档已经有相同要求，选择另一处确实需要完善的内容，不必重复添加。

1. 明确要求更新团队知识

向 Codex 提出具体修改要求：

请更新 Clumsies 中的 deployment-rollback.md。先读取全文和适用的记忆维护规则，在回滚要求中补充：“回滚后验证健康检查和关键业务请求，并记录结果。”保留其他已有内容，将修改保存为待审草稿，然后告诉我修改摘要和保存结果。本次不修改仓库里的文件。

普通编码任务、一次聊天反馈或一句“以后注意”不一定是维护 Memory 的授权。当前集成要求你明确提出这类修改后，Agent 才调用 memory.store。

这是对 Clumsies 知识库的修改。它不会自动变成代码仓库中的文件变更，也不会创建 GitHub Pull Request。

2. 检查 Codex 保存了什么

正常情况下，Codex 会先用 load 读取完整文档，再用 store 保存精确修改。完整读取使它能够保留其他内容，并检查修改所基于的版本。

核对工具返回结果和摘要：

• 目标是同一篇 deployment-rollback.md。
• 新增的是回滚后的验证要求，原有检查项保留。
• 返回了草稿或本地操作标识；没有把“已保存”描述为“已经向全组织发布”。

如果版本校验失败，让 Codex 重新读取当前正文、检查差异后再修改。不要要求它忽略冲突或覆盖其他人的更新。工具参数的详细含义见 MCP 参考，跟随本教程无需自己填写哈希或资源 ID。

3. 在 App 中查看草稿

回到 Clumsies，打开 Memory，选择 Payments，打开 deployment-rollback.md 的 Diff。应能看到新增的验证句，其他内容保持原样。

保存后，daemon 会在后台把草稿同步到 Server。当前 Project 的 Agent 可以提前读到这处待审修改，组织的正式版本仍保持原样。这正是本地试用与团队发布之间的边界。

当前结果	能说明什么
store 成功	修改已在本机持久化，并排入同步队列。
草稿已同步，Request Review… 可用	可以把自己的修改提交审阅。
当前 Project 能读到新增句子	本地待审内容已经生效；仍不能据此判断组织已发布。

完成结果： Payments 中有一处经过核对、等待审阅的修改。

下一篇：提交 Review，审阅并发布。