Plan Mode 与执行模式的本质区别及工具权限差异是什么？
未标记
考查重点：读写能力与模式落实。计划模式只读证据和形成方案，执行模式可按授权改动；差别由实际工具权限落实，非Prompt里自称模式
本题目录
参考答案
核心回答
Plan Mode 把当前任务限制在理解需求、读取证据和形成方案；执行模式允许在授权范围内真正修改代码、运行任务并交付结果。两者可以使用同一个模型和规划能力，核心差别是运行时允许发生哪些动作，以及何时把计划变成副作用。
实现时通常同时调整工具可见性与执行器权限：计划阶段开放代码搜索、文件读取、需求澄清等能力；编辑文件、安装依赖、发消息等动作由策略阻止或要求切换模式。执行阶段按已确定的范围开放相应能力，仍然检查路径、参数和操作权限。仅在提示词中写“不要修改”不能构成可靠隔离。
权限边界怎样落到工具层
工具注册表应记录工具用途、输入结构及副作用。模型看不到某个工具，可以减少误选，但执行器仍要独立校验模式，防止通过通用终端或另一个工具绕过限制。
“命令看起来像检查”也不等于只读。例如测试可能写缓存、启动服务，构建可能生成文件。是否允许运行，取决于具体命令、运行目录及隔离环境，而不是把全部 Shell 命令归入读或写。系统可以允许保存指定计划文件，但这属于明确例外，不能据此放开任意文件编辑。
Claude Code 当前官方文档将 Plan Mode 作为一种权限模式；具体允许哪些命令、如何审批还受配置影响。设计自有 Agent 时应定义自己的工具策略，不能直接把某个产品的快捷键或默认权限当成通用标准。
模式切换怎样保证连贯
例如要重构订单查询接口，计划阶段先读入口、调用方和测试，产出涉及文件、兼容约束、步骤和验证方法。切换后执行器携带这份计划及其版本，逐步记录实际修改与验证结果。
计划不是冻结所有细节。定位到同模块的新调用点时可以在授权范围内补充；发现要更改公共接口、扩大目录范围或触及新的业务对象时，应重新评估对应决策。执行模式也可以继续搜索和规划，Plan Mode 也可以调用读取工具，区别不在于“会不会思考”。
常见追问
有 Todo 工具就算 Plan Mode 吗？ Todo 保存步骤和进度，但不会自动限制写操作；模式边界由运行时策略保证。
执行模式是否意味着无需确认？ 它表示具备执行能力，具体动作仍服从用户授权、工具权限和业务约束。简单、已明确授权的局部任务可以直接完成，无需把每一步都变成确认流程。
对应教程
- 21-Agent智能体：回看Agent决策与工具执行的职责区别。
参考资料
- 国内：JavaGuide：Harness Engineering：采用模型与 Harness 的职责划分，解释正文中模式权限为何必须在模型外执行。
- 国内：zero2Agent：Agent架构与规划设计：借鉴 Plan／Solo 的计划版本、步骤状态与模式切换设计，说明正文中规划状态和权限模式如何衔接。
- 国内：WeThinkIn：Agent Harness工程：依据 Task Spec 与 Environment Spec 的区分，说明正文中允许工具、操作范围和预期验证结果应分别定义。
- 国外：Claude Code：Choose a permission mode：依据 Plan mode 一节，说明正文中 Claude Code 的实际计划权限与审批配置。
- 国外：Anthropic：Building effective agents：采用工作流与 Agent 的控制区别，说明正文中规划能力和运行时权限为何可以分别设计。
OpenCodeTypeScript
基于 OpenCode核心回答
OpenCode 的 Plan 和 Build 都可以读取代码、调用模型和使用工具，区别在于任务目标及有效工具权限：Plan 用于分析和形成方案，默认限制普通文件编辑；Build 用于实施，但具体操作仍要通过权限检查。切换模式改变的是 Agent 配置和行为约束，并不会自动把进程变成操作系统级只读沙箱。
实现上有三层：模式提醒告诉模型当前应做什么；工具注册表过滤被整体禁用的工具；真正读取、编辑或执行命令时，再按动作和资源调用 Permission.assert()。最后这一层决定操作是否允许、需要确认，或直接拒绝。
Plan 默认限制了什么
在 OpenCode 2.1.2 中，Plan 插件为 plan Agent 追加普通 edit 拒绝规则，并为用户主目录下的 .opencode/plan 计划目录保留编辑例外。提示词同时要求默认在对话中讨论计划，只有用户明确要求时才保存计划文件；实现任务应由用户切换 Agent 后继续。Plan 配置与提醒。
例如用户要求“先分析重构方案”，模型可以读取调用链、整理涉及文件；按默认 Plan 编辑规则，直接改普通源码文件会被拒绝，而计划目录是明确例外。切换到 Build 后，默认 Agent 可以按配置执行工具，仍需检查当前会话和目标资源的权限。Build 定义。
这里的 edit 限制不能推成“任何途径都无法写文件”：Shell 命令、插件和外部工具有各自的动作权限，最终还取决于合并后的配置。若要求严格只读，需要同时收紧这些入口；文件系统或进程隔离承担的又是另一层职责。
为什么隐藏工具还不够
Tool.snapshot() 会根据权限过滤被整体禁用的工具，但可见性无法表达某次调用的全部条件。同一个编辑工具可能只允许操作计划目录，因此工具仍可见，普通源码路径却不允许写。工具可见性过滤。
实际授权以动作和资源匹配规则。规则求值采用最后匹配项；权限服务合并 Agent 与会话规则后，先检查明确拒绝，再处理保存的允许规则及需要确认的请求。deny 返回拒绝，allow 继续，ask 则建立待处理请求并等待决定。这样模型即使提出了一个可见工具的调用，也不能只凭工具名取得任意资源的访问权。规则匹配、权限求值与确认。
权限检查怎样落到真实操作
- 读取文件：读取工具先调用
FileAccess.authorizeRead()，解析目标路径，必要时检查工作目录外访问，再以read动作和目标资源调用Permission.assert()，通过后才交给读取器。读取入口、路径与读取授权。 - 编辑文件：编辑工具解析匹配位置、准备差异预览，再用
edit动作对目标路径申请权限；通过后还会检查匹配是否唯一等编辑条件，才进入写入。权限允许与补丁可正确应用是两个判断。编辑授权。 - 执行命令：Shell 工具扫描命令和涉及目录，检查外部目录访问，并按命令资源申请权限；确认后还会重新核对工作目录，再启动进程。因此允许
read不等于允许执行所有命令，禁止edit也不会自动禁止所有可能写文件的命令。Shell 执行前检查。
模式切换与方案取舍
切换 Agent 时，Plan 插件注入进入或退出提醒，并在后续上下文中补齐缺失提醒，避免压缩后模型仍受旧模式提示影响。它负责行为连贯性，具体动作仍由权限服务判断。模式提醒维护。
这种设计能复用同一套模型与工具，在分析和实施之间调整能力范围，也支持路径级例外。代价是需要逐个工具落实授权，并分别验证直接编辑、Shell 写入、外部目录和模式切换；不能只看到界面显示 Plan 就认定所有副作用已被隔离。
参考资料
- 国内：JavaGuide：Harness Engineering：参考模型提出动作、运行系统负责工具和约束的职责划分，解释权限为何不能仅由提示词保证。
- 国内：zero2Agent：Agent 架构与规划设计：参考计划与实施共享任务信息、切换后继续处理既定目标的组织；具体默认权限以本文源码为准。
- 国内：WeThinkIn：Agent Harness 工程：参考任务允许动作与运行环境分别定义，解释权限模式和执行环境不是同一层能力。
- 国内：WeThinkIn：工具权限、沙箱和人工审批：参考工具策略、用户确认和沙箱分别解决的问题，说明应用授权与操作系统隔离的区别。
- 国外：Claude Code：Choose a permission mode：以另一产品的 Plan 权限及命令审批作为对照，说明具体能力由产品版本与配置决定。
- 国外：Anthropic：Building effective agents：参考模型按反馈选择工具的运行方式，解释规划能力与运行时允许动作可以分别设计。
