规划Agent总抢活干？解决方案：让它一个文件都写不了

多Agent协作架构中，规划者（Planner）和工作者（Worker）的职责分离是常见设计。但一个尴尬的现实是：规划Agent经常忍不住自己把活干了。开源项目 Atomic Agent 的作者在 Reddit 上分享了这个问题的完整解决过程，方案出人意料——彻底禁止规划者写入任何文件。

Fusion架构：规划与执行的分离设计

Atomic Agent 是一个 MIT 协议的开源项目，其 Fusion 模式采用规划者-工作者架构：一个模型负责任务规划、拆分和审核，多个 Worker 模型并行执行具体工作。典型配置是云端模型做规划、本地模型做执行，这样只有规划环节消耗 API token。

这个架构的核心挑战不在于模型能力，而在于权限边界的设计——规划者到底被允许操作什么。作者团队试了多种方案后，最终给出了一个极端的答案：什么都不允许。规划者只能读、委派、回复。

三道失守的防线

作者详细披露了权限管控的三次失败尝试，每一次都暴露了不同的设计缺陷。

软门控的虚假成功。 最初的设计是：规划者在首次委派成功前禁止写入。但问题出在 fusion.delegate 即使所有 Worker 都失败了也返回 ok 状态。规划者看到成功信号，门控打开，结果它自己写了15个文件、执行了5条命令。整个流程"看起来正常"，但 Fusion 模式形同虚设。

需求回传的漏洞。 团队允许 Worker 在任务过大或不清晰时通过 needs_orchestrator 将任务退回。这个机制为规划者开了一个例外通道，13次写入从这个缺口溜了过去。在一次运行中，6个任务里有4个走了这条路径。

死代码门控。 更早的版本中，门控逻辑根本没有被执行器调用——步骤执行器只转发了 plan-mode 参数，权限检查从未被触发。一次驱动测试中，规划者毫无阻碍地写完了全部四个文件，零次拒绝。单元测试全部通过，但生产路径上这道门从未被查询过。

MCP（模型上下文协议） 是 Anthropic 于 2024 年底提出的开放标准，用于让大语言模型以统一方式调用外部工具和数据源，可类比为「AI 应用的 USB-C 接口」。在本案例中，规划者的所有工具调用都经由 MCP 服务器暴露，因此作者将「所有 MCP 工具」一刀切地视为变更操作。这种保守策略源于一个关键判断：MCP 服务器往往是第三方代码，其声明的权限提示（如 readOnly）只是自我描述，无法被宿主程序强制验证。一个声明为只读的工具完全可能在内部执行写操作，所以信任其元数据等于把安全边界交给了不受控的代码，这也是架构上选择「默认有罪」而非「默认无害」的根本原因。

当前方案：整轮对话禁止变更操作

现行规则非常简洁：在规划者的整个回合内，它不能执行任何变更操作。

所有 MCP 工具都被视为变更操作，不论其声明了什么权限提示——因为它们是第三方代码，无法信任其自我描述。Worker 负责写文件，规划者只能读取文件、运行只读检查、重新委派任务。

拒绝的方式也经过考量：不是在规划者的工具目录里移除写工具，而是在工具调用返回结果中附带一条简短消息——"你负责规划，Worker 负责写入"。这样做是为了保护本地规划模型的 KV 缓存：如果动态移除工具，prompt 前缀会改变，每次规则触发都会导致缓存失效，性能损失显著。

KV 缓存（Key-Value Cache） 是 Transformer 推理中的关键优化：自注意力机制在生成每个 token 时都要重新计算此前所有 token 的键值向量，缓存这些中间结果后，连续生成新 token 的代价会大幅下降。其代价是缓存与前缀严格绑定，一旦 prompt 开头的系统提示或工具定义发生变化，整段缓存即告失效、需要全量重算。这正是作者不在规划者工具目录里动态移除写工具、而选择在工具调用返回值里附带拒绝消息的原因——前者会改变 prompt 前缀导致每次规则触发都击穿缓存，后者把提示放在调用结果中，前缀保持稳定，本地模型的推理性能得以维持。

plan-mode（规划模式） 在许多 Agent 框架中是一种运行状态标识：开启后仅允许只读操作、生成计划而不落地改动。本案例中「死代码门控」的失败正暴露了这种状态传递的脆弱性——执行器只是把 plan-mode 参数往下转发，却没有真正在工具调用链路上查询该标志，于是权限检查成了从未被触达的悬空逻辑。单元测试通过而生产路径失守，说明测试覆盖的是门控函数本身，而非「执行器是否调用了门控」这一集成事实。这也提示多 Agent 系统需要针对权限路径做端到端的驱动测试，而不仅是函数级断言。

最痛的护栏：22分钟的"纸上谈兵"

作者坦言，在所有测量指标中，这条规则是最"伤"的一个。

一次运行中，本地规划模型发现了一个真实 bug，诊断完全正确，然后花了22分钟把修复方案写进了拒绝消息的文本里——因为它不被允许写入文件。

团队仍然保留了这个规则。理由很直接：规划者自己动手，正是 Fusion 模式两次悄悄退化的根源。规划者交接慢一点至少会出现在 trace 里，而对应的修复手段是给 Worker 更好的任务简报。

迁移其他Agent配置

Atomic Agent 提供了六个 Agent 的导入器，每个都支持 --dry-run 模式不写入任何内容。API 密钥仅在显式使用 --migrate-secrets 时才会迁移。

支持的导入来源包括 Claude Code、Codex、Hermes、OpenClaw^广告、Pi 和 Oh-My-Pi，涵盖技能、记忆、MCP 服务器和会话记录等维度。需要注意的是，Hermes 和 OpenClaw 的记忆数据无法迁移——两者的存储格式不同且没有交换标准，作者选择直接说明而非让用户面对一个空的记忆面板。

项目以终端 Agent 形式运行，近期新增了桌面应用（支持 Mac、Windows、Linux）。桌面端的审批选项包括"允许一次"和"拒绝/中止运行"，用户可以在编辑器中切换模式来减少确认频率。

对规划者-工作者架构的启示

Atomic Agent 的实践揭示了一个反直觉的结论：规划者-工作者架构中最难设计的不是任务拆分算法，而是权限边界的严格执行。三次失败都源于"留有余地"——软门控、例外通道、未调用的检查——每一次余地的存在都导致架构退化。

作者在帖子最后向社区提问：如果你也在运行规划者-工作者架构，你会让规划者写入吗？还是最终也选择了零权限？

对于正在构建多Agent系统的开发者，这个案例的价值在于：权限设计中的每一个"万一"都可能成为系统退化的入口，而彻底的禁止虽然会带来效率上的摩擦，但至少让问题可见、可追踪。