Coding Agent 的 Plan Mode 📝 到底在「计划」什么？
什么是 Plan Mode？
如果你正在使用 Claude Code、Codex 或者 OpenCode 这些 AI Coding Agent，你大概率遇到过、用过 “Plan Mode” 这个功能。
但你真的知道它是什么吗？不是”怎么用”，而是它到底是什么。
- 它是不是一种更会规划的高级模型人格？
- 它是不是一个更安全的只读模式？
- 它是不是一种能自动把需求拆成方案和任务的神秘工作流？
我最近系统地拆解了三个主流 Coding Agent 的 Plan Mode 实现——Claude Code、Codex CLI 和 OpenCode。越看越觉得有意思，因为发现了一件事：
把 Claude Code、Codex 和 OpenCode 这三套主流 Coding Agent 的实现和行为都拆开看完之后发现，Plan Mode 并没有想象中那么玄。
它最核心的一句话，其实非常朴素：
先写计划，不要改代码。
就这么简单。
Plan Mode 做的事情，就是让 AI Coding Agent 在动手之前，先把”打算怎么做”说清楚，等你确认了再去执行。
听起来很平凡，对吧？但这背后有一个更关键的问题值得追问：它靠什么来保证 Agent 真的乖乖”先写计划、不改代码”？
答案是：模型本身的指令遵循能力。
不是什么复杂的工程机制，不是把编辑权限从底层锁死，更不是换了一个”更会规划的特殊模型”。
Plan Mode 的核心，是通过在当前轮次发送出去的用户消息中附带一段提示词，告诉模型：“现在你处于规划阶段，你只能读代码、问问题、写计划，不能修改任何文件。“
Plan Mode 为什么能成立
如果只看产品表面，很容易以为是 Agent 框架本身做了什么特别复杂的事，才让 Plan Mode 成立。
但拆完三套系统之后，我的判断恰恰相反：
Plan Mode 之所以能成立，首先是因为模型本身已经足够强，而不是因为 Agent 外面包了一层很复杂的 Harness 工程系统。
第一层：真正起作用的，是模型的指令遵循能力
Plan Mode 本身不会神奇地让模型变聪明。
一个模型如果本来就不擅长理解约束、不擅长延迟执行、不擅长在不动手的前提下做调研和方案收敛，那你给它挂一个 “Plan Mode” 的名字也没有意义。
Plan Mode 真正依赖的，是模型至少具备下面这些能力：
- 听得懂“现在先不要改代码”
- 能区分“调研”和“实现”
- 能在没有立即执行的情况下，先把问题讲清楚
- 能承受一点“延迟满足”，不一上来就急着做事
- 能把最后的方案整理成相对完整、可继续执行的计划
换句话说，Plan Mode 的底座不是 mode，而是 model。
这也是为什么这两年随着模型能力提升，越来越多产品开始认真做 Plan Mode。不是因为大家突然都想到了这个交互，而是因为模型终于强到可以比较稳定地跑这条轨道了。
第二层：Plan Mode 本质上是一种软约束
如果继续往下拆，你会发现 Plan Mode 的第一性原理，并不是“物理上不能写代码”，而是“行为上先不要写代码”。
这句话看起来只差几个字，但含义完全不同。
前者强调的是能力剥夺，后者强调的是行为约束。
而目前主流 Coding Agent 的 Plan Mode，核心更接近后者。
它们通常会通过这些方式来告诉模型当前应该怎么做：
- 切到一个正式的 mode
- 注入一段更强的提示词或 developer instructions
- 明确要求先探索、先提问、先收敛方案
- 要求最后输出一份计划，而不是直接开始实现
- 在交互上加入一个“是否批准进入执行”的节点
这些机制当然不是一句普通 prompt 那么简单，但它们的核心逻辑，其实非常接近 prompt 约束。
也就是说，从能力本质上看，Plan Mode 更像一套被产品化的行为协议。
它要求模型遵守一套节奏：
先研究，后决策；先计划，后施工。
第三层：工程硬限制更多是兜底，而不是主角
很多人一听到 Plan Mode，直觉上会以为它肯定做了很多底层的硬限制，比如彻底禁掉编辑工具、禁掉执行命令、禁掉一切可能引发变更的能力。
但从实际拆解来看，更接近事实的情况是：
- 有些系统会做一定的工程兜底
- 有些系统只做很少量的模式级特殊处理
- 真正主导 Plan Mode 行为的，往往还是模型对规则的遵守
这也是我对三套系统看完之后最深的感受：
Plan Mode 不是先有一套完美的工程限制，再让模型进去工作；更多时候是先相信模型能遵守“先别动手”的规则，再视情况补一点工程兜底。
工程限制当然有价值，但它通常不是故事的主角。
三套主流 Coding Agent，为什么都做出了 Plan Mode
如果只看界面，Claude Code、Codex、OpenCode 的 Plan Mode 长得并不一样。
但如果你看它们背后的设计思路，会发现三家其实都在回答同一个问题：
怎么让 Agent 先别急着写代码。
只是它们落地的方式不一样。
Claude Code
在 Claude Code 这条线上，Plan Mode 很明显不是一句临时 prompt。
它已经被做成了正式的权限模式和工作流状态：进入这个模式后，系统会明确要求 Claude 先分析、先规划、必要时先提问；规划完成后，再通过一个显式的退出和确认动作，把执行权交还回来。
Claude Code 的 Plan Mode 是三层机制叠加的结果。
第一层，也是最重要的一层：系统提示注入。 进入 Plan Mode 后，Claude Code 会往系统提示里塞一段强约束说明，核心意思是”现在是规划阶段，禁止任何非只读操作，研究完成后调用 ExitPlanMode 请求用户确认”。这是 Plan Mode 真正”生效”的原因。
第二层：专用工具协议。 Plan Mode 配套了几个专用工具：
EnterPlanMode（进入规划）、AskUserQuestion（向用户问澄清问题）、ExitPlanMode（提交计划并申请批准）。这些工具把”规划”这个流程做成了显式的节点，而不只是一段对话气泡。第三层：计划文件外化。 Plan Mode 的产出不只是聊天框里的一段文字，而是写入一个可编辑的 Markdown 文件。用户可以直接在终端里打开它、修改它，然后批准或拒绝。
但需要注意的是：这三层里，并没有把编辑工具从底层彻底拿掉。从公开的逆向材料和历史 Bug Report 来看，Plan Mode 下的编辑能力大概率仍然存在于运行时，只是模型被强烈告知不要去调用它。这也导致历史上出现过在 Plan Mode 下仍然发生写文件行为的 Bug。
从产品设计上看，这很像把“先想清楚再动手”做成了一条正式流水线。
但关键在于，Claude Code 的力量并不主要来自“强行把所有能力都物理剥夺掉”，而是来自模型本身足够强，能够稳定遵守这套 workflow。
也就是说，Claude Code 这条路线，给我的感觉更像是：
- 系统负责定义阶段
- UI 负责承接阶段切换
- 模型负责真正执行“不要急着写代码”这条规则
所以 Claude Code 更像是在证明一件事：当模型足够强的时候，Plan Mode 可以主要靠流程约束跑起来。
Codex CLI
Codex 的思路和 Claude Code 相近，但在一个地方做得更精细：结构化输出。
模型被要求把最终计划包在 <proposed_plan>...</proposed_plan> 这个 XML 标签里输出。运行时有专门的流式解析器把这段内容从普通文本流里剥离出来，当成一个”计划对象”单独展示，而不是普通的 assistant 回复。
等计划产出，UI 会弹出确认框：“Implement this plan？“——点 Yes，自动切回执行模式；不满意，继续沟通。
Codex 不只是限制模型行为，它还为”计划”这个概念在系统里专门建模，让它成为一个可以被渲染、可以被交互的正式对象。
但和 Claude Code 一样，Codex 对于”不要修改代码库”的约束，主要靠的也是 developer instructions 驱动模型自己遵守，并没有把所有可变更工具从底层彻底移除。
OpenCode：在软约束之外补上工程兜底
OpenCode 这条路线又更务实一点。
它同样强调先 Plan、再 Build，也会把计划写成文件、在 Plan 阶段明确提示模型应该先做什么、最后再切到执行阶段。
但和 Claude Code、Codex 相比，OpenCode 更明显地在软约束之外补了很多工程层兜底。
OpenCode 的 Plan Mode 除了系统提示约束之外，还在权限层做了硬拦截：Plan Agent 默认禁止对普通代码文件进行 edit / write / apply_patch 操作，只对白名单中的 plan 文件放行。也就是说，即使模型不遵守提示词指令，硬要调用编辑工具去改普通文件，权限系统也会在工具执行前把请求拦住。
它会更认真地处理权限规则、计划文件白名单、工具级权限检查、Plan Agent 和 Build Agent 的职责分离。这种设计说明它并不完全信任模型，而是希望系统本身也能对“什么时候允许动手、允许改什么”做更多控制。
这背后其实对应着一个非常现实的产品前提：
OpenCode 支持的模型范围更杂，能力差异也更大。既然你面对的不是单一的顶级自有模型，而是一大堆表现并不稳定的模型，那你就很难只靠 prompt 和行为约束把 Plan Mode 跑稳。
所以它不得不在工程上补更多兜底。
这并不是说 OpenCode 更先进，或者它对 Plan Mode 的理解更深。更准确地说，这是不同产品现实约束下的自然结果。
如果你的系统默认运行的是自家最强的 SOTA 模型，你当然更愿意相信模型本身。
如果你的系统要兼容一大批质量参差不齐的模型，你就不得不更相信系统本身。
所以 OpenCode 这条路线更像是在证明另一件事：
当模型能力不能完全被信任时，Plan Mode 就会从“主要靠软约束”往“软约束加硬兜底”迁移。
OpenCode 为什么要做工程层面的兜底？
因为 OpenCode 需要支持市面上所有主流大模型。
Claude Code / Codex 默认都是用自家的模型。目前这些 SOTA 模型的指令遵循能力极强，你告诉它”不要改文件”，它基本上就不会改。软约束足够了。
但 OpenCode 作为一个开源项目，用户可以接入任何模型——包括各种能力参差不齐的开源模型、小模型、本地部署的模型。这些模型的指令遵循能力无法保证，如果只靠提示词约束，可能根本不管用。
所以 OpenCode 不得不在工程层面加一道安全网：就算模型不听话，权限系统也能兜住它。
这恰好从反面证明了我最初的那个判断：Plan Mode 靠的核心，是模型能力，而不是框架有多精妙。模型足够强，一段提示词就够；模型不够可靠，才需要工程层面的硬兜底。
三家实现不同，但本质上都在做同一件事
如果把上面三条路线放在一起看，会发现一个很有意思的统一视角。
Claude Code 和 Codex 代表的是一种更偏“信模型”的路线。
它们当然也有 mode、workflow、approval、结构化输出这些产品机制，但总体上，它们更相信模型本身已经足够强，可以理解并遵守“先 plan、后 execute”这套节奏。
OpenCode 代表的则是一种更偏“信系统”的路线。
因为它要面对更多元、更不稳定的模型能力，所以不得不在权限和工具层上补更多兜底。
但无论路线怎么不同，三者做的其实都是同一件事：
把原本应该由用户口头强调的“先别写代码，先把方案想清楚”，变成系统里的正式阶段。
所以 Plan Mode 不是一项突然冒出来的新能力，而是一个被产品化的工程协作原则。
Plan Mode 不神秘，但它也绝不只是“一句提示词”
说到这里，很容易滑向另一个极端：既然它的本质这么接近 prompt 约束，那是不是可以直接说，Plan Mode 根本没什么新东西，就是一句提示词？
我觉得不能这么粗暴地下结论。
从能力来源上说，这个判断确实有相当强的真实性。
很多重度用户确实不会专门去点 Plan Mode。他们会直接在 prompt 里要求 Agent：
- 先读代码
- 先调研
- 先提方案
- 不要动文件
- 等我确认后再开始改
如果模型足够强，比如 GPT 5.4 / Claude Opus 4.6，这一套完全是能跑起来的。
比如 @boristane 就直接说 “plan mode sucks, across all coding agents”——他的做法是在外部维护一个独立文档，在里面写计划、标注、迭代，用一个”不会被上下文压缩掉的持久化 artifact”来管理整个规划过程，效果一样好。
https://x.com/boristane/status/2021628652136673282
他不用 Plan Mode，但他做的事情，和 Plan Mode 要解决的问题完全一样：先规划，再执行。
这说明 Plan Mode 本质上是一个被产品化的提示词。它封装的不是什么新的 AI 能力，而是一套工作流最佳实践——先别动手，先把计划想清楚，拿给人确认了再执行。有足够提示词工程经验的开发者，不需要任何产品的 Plan Mode 开关，自己就能实现同样的效果，甚至做得更定制、更灵活。
从这个角度看，Plan Mode 的本质就是：把”先写计划，不要改代码”这句话，包装成了一个对普通用户友好的产品功能。
从这个意义上说，Plan Mode 的底层逻辑，确实非常像一套被官方内置、被产品包装过的高质量 prompt 工作流。
但如果因此得出“Plan Mode 没有价值”，我觉得又错了。
Plan Mode 的价值点不在于它”让 AI 更会规划”，而在于它的 UI 交互体验——尤其是在并发多 Agent 的工作场景下。
假设你现在同时启动了 4 个甚至 10 个 Coding Agent 在并行工作。你不会有时间自己维护 plan.md，跳到 IDE 上手工修改或批注文档，或者是用 Spec Coding 框架走 SDD 流程，打开一堆 proposal.md、design.md、spec.md 文档去手动维护和 Review 每一个 Agent 的计划。这太低效了。
但 Plan Mode 不一样：你不需要跳出终端，计划就在眼前；看完了，一键批准，立刻继续；觉得哪里不对，直接在同一个会话里直接提出 Review 建议，Agent 当场修改再给你看新的 Plan。整个 Review 过程不打断心流，也不需要你在多个应用之间来回切换。
这种沉浸式 Review 体验，在批量并发场景下，是效率上的真实提升。这是外部文档工作流在高并发场景下很难做到的事。
所以 Plan Mode 的价值，更多在于降低认知切换成本，而不是提升 AI 的规划能力。
Plan Mode 没有创造新的智能能力，但它把一种本来就成立的协作方式，做成了低摩擦、高沉浸、不打断心流的终端体验。这件事不是模型能力，而是产品能力。
所以，Plan Mode 的本质到底该怎么理解
如果要把前面的讨论再压缩成几句话，我会这样总结。
把上面的内容收拢成几句话：
Plan Mode 的本质，是把”先写计划，不要改代码”这个工作流最佳实践，做成了产品。
它不是某种神秘的 AI 能力，底层靠的是模型自己的指令遵循能力。
对于 SOTA 模型来说，一段系统提示词就足够了；对于需要兼容弱模型的产品（比如 OpenCode），才需要在工程层面再加一道兜底。
说到底，它讲的还是那句再朴素不过的话：先想清楚，再动手。
理解这一点，能帮你更清醒地看待 Coding Agent 的各种功能宣传。很多看起来复杂的 agent 特性，底层往往相当朴素。