六种计划模式在结构上达成一致，但在上下文处理上分歧

在我所检查的编码代理中，计划模式普遍具有相同的结构：首先读取，编写计划，等待批准。在文档明确描述的情况下，它是一个权限设置。在 Claude Code 的文档中，它实际上与 acceptEdits 和 bypassPermissions 位于同一权限表中：它可以读取并运行只读的 shell 命令，任何写入操作都需等待您批准计划。写入工具被禁用，提示中添加了一行指示以写下提案，批准成为一个必须点击的步骤。2025年7月，Claude Code 发布了一个修复程序，因为计划模式曾未经询问就运行 touch 和 rm（是的，rm）。六种工具在2025年1月至2026年3月期间发布了这种结构：Cline、Claude Code、Cursor、VS Code 的 Copilot、Codex CLI、Gemini CLI。其中四种默认将计划写入文件。大多数可以在规划阶段暂停并询问您问题。四种可以使用一个模型进行规划，另一个模型执行。分歧出现在批准后会发生什么：Cline 保留整个规划上下文，VS Code 将其延续，Claude Code 有一个设置增加了清除上下文并仅使用计划开始执行的选项。没有人公布过这两种选择的量化数据。我找到的最接近测量的是一项针对21,120次 SWE-agent 运行的研究，涉及四种模型、八种计划设置，其中计划是系统提示中的 navigate-reproduce-patch-validate 工作流。移除该计划降低了所有四种模型的成功率。跳过一个阶段比没有计划更糟。计划模式的核心要点是：代理会漂移，因为随着运行时间的延长，计划的重要性降低。每五步将计划重新放入上下文在所有模型中都带来了一致的收益。计划只是更多的指令，而随着转录运行时间的延长，指令会变得越来越不明显。磁盘上的计划文件就是那个解决方案，就在一步之遥；我读到的任何资料都没有表明任何工具会自行重新读取它。有一个关键点：他们的计划来自脚手架的系统提示，而变体是研究者设置的。在计划模式中，模型自行编写计划并由您批准，而没有人进行过这种比较。当您批准计划时，您是先阅读计划，还是批准后再阅读差异？