我们的规划智能体总是自己动手完成工作，所以现在它在自己的回合中连一个文件都不能写入了

Atomic Agent（开源，MIT 许可证）有一种叫 Fusion 的模式：一个模型负责规划、把任务拆成多个部分并审核；工作模型负责构建各个部分，同时处理多个部分。通常由云端模型规划，本地模型执行，因此只有规划模型会消耗 API token。也可以反过来。我们花了最长时间才定好的规则，是规划模型可以动什么。我们最终得出的答案是：什么都不能动。读取、委派、回复。我们是怎么走到这一步的 最初的限制比较宽松。在一次委派成功之前，禁止规划模型写入；成功之后，就放开限制。有两件事打破了这道限制。第一，即使所有工作模型都失败了，fusion.delegate 仍然会返回 ok。规划模型看到 ok，限制就解除了，于是它自己写了 15 个文件，还执行了 5 条命令。那次运行“成功”了。但 Fusion 并没有发生。第二，我们允许工作模型在任务太大或不明确时，通过 needs_orchestrator 把任务交回来，这就给规划模型开了一个例外。13 次写入从这个漏洞溜了过去。在那次运行中，6 个任务里有 4 个以这种方式被退回。更早之前，还有一个版本里的限制检查是死代码：步骤执行器只转发 plan-mode，所以检查从未执行。一次实际驱动执行的测试中，规划模型写入了全部四个文件，没有遇到任何拒绝。限制逻辑已经启用，也通过了单元测试，只是从来没有被调用。现在如何运作 在整个回合中，规划模型都不能修改任何东西。无论 MCP 工具的提示怎么说，都将它们视为会修改状态的工具，因为它们是第三方代码。工作模型写入文件，规划模型读取文件、执行只读检查，然后再次委派。拒绝信息会出现在工具返回结果中，而不是把工具隐藏起来。如果我们从规划模型的工具列表中移除工具，提示词前缀就会变化，本地规划模型每次触发这条规则时都会丢失 KV 缓存。因此工具仍然可见，只是调用它时会收到一句简短的“你负责规划，工作模型负责写入”。讽刺之处 在我们的测量中，造成最大拖累的防护规则恰恰就是这一条。一个本地规划模型发现了真实的 bug，正确诊断了问题，然后花了 22 分钟，把修复方案写进拒绝信息的文本里，因为它不被允许写入文件。我们还是保留了这条规则。允许规划模型写入，已经两次让 Fusion 悄悄失去了 Fusion 的本质。规划模型迟迟不交接，至少还会在执行轨迹中显现出来，而解决方法是给工作模型一份更清楚的任务说明。迁移你现有的配置 运行其他智能体的人还经常问我们另一个问题：哪些东西可以迁移过来。我们为六种智能体提供了导入器。每个导入器都有 --dry-run，不会写入任何内容；只有显式使用 --migrate-secrets，才会迁移 API 密钥。来源 导入内容 使用 --migrate-secrets 迁移的密钥 Claude Code 技能、记忆、MCP 服务器、会话 ANTHROPIC_API_KEY Codex 技能、AGENTS.md 指令、会话 OPENAI_API_KEY（使用 ChatGPT 登录时为空）Hermes 会话、定时任务 OpenRouter / AI/ML API 密钥 OpenClaw 会话、定时任务 无 Pi 技能、会话 无，不在迁移范围内 Oh-My-Pi 技能、MCP 服务器、会话 无，不在迁移范围内 Hermes 和 OpenClaw 的记忆不会迁移过来。它们的存储方式不同，也没有交换格式，所以我宁愿提前说明，也不想让你打开记忆标签页时发现里面是空的。它可以作为终端智能体运行，从本周起也可以作为桌面应用运行（Mac、Windows、Linux）。桌面端的审批选项是“允许一次”“拒绝”或“中止运行”；如果想减少询问，可以在输入框中切换模式。仓库链接在评论里。如果你在使用规划模型／工作模型的组合：你会允许规划模型执行任何写入吗，还是最终也把写入权限降到了零？