拆解 orca-agent v0.3.9 的 plan-then-execute 升级：Plan 从「禁止写入的权限门」变成完整工作流——只读探索、结构化 plan 标记、审批弹窗、每轮模式注入。公开 release 依据：github.com/echoVic/orca-agent v0.3.9。
权限门的问题
早期版本的 Plan 模式是个权限开关：切进去之后，写入被拒绝。设计意图是「先想清楚再动手」。
但实际跑起来有个尴尬：Agent 在 Plan 模式里尝试写文件，被静默拒绝——它不知道自己为什么失败，可能重试、可能换个路径再试、可能陷入困惑的循环。用户看到的是「Agent 卡住了」，不是「它在规划」。
权限门只解决了「不让它写」，没有解决「让它知道自己该干什么」。
从门到工作流
v0.3.9 把 Plan 从权限门升级成完整的 plan-then-execute 工作流，对齐 Codex 和 Claude Code 的交互模型。
核心变化是协议层信号：Plan 模式下 Agent 做只读探索，探索完成时发出一个正式的 <proposed_plan> 块。它不再尝试会被拒绝的写入，而是用结构化标记告诉宿主「计划好了」。
这个标记是协议级的——不是用户界面上的一段文字，而是可以被程序识别的完成信号。宿主收到它，就知道该弹审批了。
审批弹窗的交互细节
proposed_plan 就绪后，底部出现一个锚定的审批弹窗。几个细节值得说：
- 批准：恢复进入 Plan 之前的审批模式，并自动提交一个实施轮——用户不需要手动切回
- 拒绝：保持 Plan 模式，用户可以继续迭代计划
- 浏览：PageUp/PageDown、鼠标滚轮、方向键切换选项、Enter 确认——长计划也能翻
这些不是花活。拒绝后留在 Plan 模式意味着「迭代计划」是一条完整回路；批准后自动提交实施轮意味着「批准」直接衔接执行。每个状态转移都有明确的下一步。
模式注入：从会话级到轮次级
旧实现把 Plan 的系统提示在会话创建时写死。中途切 Plan，提示不更新——Agent 实际还是旧模式在跑。
v0.3.9 改成每轮注入模式上下文：切进 Plan 的下一轮就生效，切走立即移除只读约束。这不是实现细节，是语义差异：模式是运行时状态，不是会话配置——正好对应 pi 系列里「修改立即可见于内存、只对下一轮生效」的同一原则。
边界：什么不触发审批
还有一个容易误伤的边界：update_plan 任务清单的更新不触发正式审批流程。只有 Plan 模式下成功的前台轮产生 ChatMessage::ProposedPlan 才打开审批弹窗。
这个区分很实际：任务清单更新是执行中的常态，不该每次都打断用户；真正的计划提交才值得一次审批。
拆完这章，我的感受是：Plan 模式的本质不是「禁止写入」，而是给规划一个可识别的完成信号和一条可迭代的回路。权限门是最省事的实现，但它把「规划完成」这个关键状态留给了猜测；协议标记 + 审批弹窗 + 每轮注入，才让「先计划后执行」成为真正的工作流——用户看到的不再是「Agent 卡住」，而是「计划好了，你来决定」。
Orca 是 DeepSeek 原生的终端 Coding Agent（开源：github.com/echoVic/orca-agent），v0.3.9 完整 release notes 见仓库 Releases。
