痛点一的观点是，Agent 在 Plan 模式里卡住使用者无从知晓原因

在早期实现中。进入 Plan 模式后所有写操作都会被静默拒绝。Agent 试图写文件时根本不知道为什么失败。可能会无限重试、尝试其他方法，最终陷入迷茫的循环。使用者看到的只是“Agent 卡住了”，而不是“它正在规划”。这让调试变得极其困难，也导致了大量无意义的日志噪音。

说到痛点二。缺乏明确的规划完成信号

Permission Gate 只做了“禁止写”，没有告诉宿主“我已经完成规划”。按理说，宿主无法区分是因为 Agent 写入被拒绝导致的停滞。还是 Agent 已经准备好执行接下来。这种模糊状态导致审批流程无法触发，也让使用者难以判断接下来该怎么做。

从从门到工作流来看，协议层信号的引入

v0 把 Plan 从单纯的权限门升级为完整的 plan‑n‑execute 工作流。对齐 Codex 和 Claude Code 的交互模型。主要变化是协议层信号在只读探索完成时Agent 会发送一个正式的 块，而不是继续尝试被拒绝的写入。说起来，这个标记是协议级别、可被程序识别的完成信号。宿主收到后即可弹出审批窗口。

只读探索与

• 只读探索: Agent 在 Plan 模式下仅查询信息，不尝试任何写操作。
• : 探索结束后生成结构化标记，告知宿主“计划已完成”。
• 协议级识别: 宿主通过解析此块触发后续流程，而非依赖 UI 文本提示。

再看A审批弹窗，交互细节与使用者体验改进

就绪后在界面底部会出现一个锚定审批弹窗。以下细节直接解决了使用者痛点：

• 批准 : 自动恢复之前的审批模式，并立即提交实施轮；无需手动切回执行模式，
• 拒绝 : 保持在 Plan 模式，让使用者继续迭代计划；避免因误判而提前执行，不过，
• 浏览 : 支持 PageUp/PageDown、鼠标滚轮、方向键切换选项、Enter 确认等多种翻页方式；长计划也能轻松翻阅，
• 状态清晰化: 每个状态转移都有明确接下来，从而消除“卡住”或“不知道是否提交”的疑惑。

再看模式注入。从会话级到轮次级

旧实现将 Plan 的程序提示硬编码在会话创建时一旦切换到 Plan，提示并未更新，使得 Agent 仍在旧模式运行。v0 将程序提示改为每轮注入模式上下文

• "Plan" 切进下一轮即生效；切走立即移除只读约束，
• "Mode" 是运行时状态，而非会话配置；符合 pi 系列中“修改立即可见于内存，只对下一轮生效”的原则。

User Scenario: 切换到 Plan 时的不一致感受消失

User 不再需要担心 “进入 Plan 后仍然按旧策略执行” 的问题；程序即时反馈当前模式，让流程更透明、更可控。

B 边界控制：何时触发审批？

An often-overlooked boundary is that updates to task list via

• This does **not** trigger formal approval flow.
• { ChatMessage::ProposedPlan },approval popup appears.

# & 感悟：Plan 不是禁用写。而是给规划提供可识别信号和迭代回路

The essence of new Plan mode lies in providing a recognisable completion signal and an explicit iterative loop . The old Permission Gate was merely a stop‑gap—no feedback,no clear next steps. With protocol markers,approval dialogs,and per‑round context injection,“plan first n execute” becomes a true workflow that users can follow without getting lost in silent failures.

。

---