把“先做后看”的高风险 AI 编码流程升级为“先看后做”的工程级对齐系统。阅读提醒这份长文不讲空概念重点讲清楚四件事为什么要先规划、进入与退出怎么做、计划文件为什么必须落盘、以及这套模式怎样真正落到企业级 Agent 系统里。一、为什么真正能上线的 Agent一定要有“先看后做”能力很多人以为AI 编码最难的是“会不会写代码”。其实在真实研发环境里更难的问题往往是它是不是理解对了要做什么。比如用户说“重构认证模块”模型可能脑子里想到的是 JWT也可能理解成 OAuth2还可能把登录、会话、权限校验、回调处理全部搅在一起。要是它一上来就开始改文件最后极有可能出现一种特别尴尬的局面技术上写得没错业务方向却从一开始就偏了。计划模式要解决的正是这个最值钱的问题——先把方向对齐再开始落盘执行。它不是单纯多问一句‘你确定吗’而是把探索、归纳、提案、审批、恢复执行做成一套有约束、有状态、有持久化载体的完整机制。从产品视角看这能减少返工从工程视角看这能把权限、安全、上下文成本、用户确认全部串起来从团队视角看这还给多人协作、多 Agent 协同留出了清晰的审批边界。一句人话总结计划模式不是为了让 Agent 变慢而是为了避免它“很快地把错误的东西做对”。二、进入与退出最难的不是开关而是状态恢复很多系统会把计划模式做成一个布尔值开就是 planning关就是 executing。看起来简单实际上这种设计很容易出事故。因为一个成熟的 Agent 通常不止一种权限状态它可能有默认确认模式也可能有自动批准模式还可能存在‘接受编辑’之类的半自动状态。所以更靠谱的做法不是记一个 isPlanMode而是在进入计划模式时先把“进入前的权限模式”保存下来退出时再精确恢复。这样计划模式就不是粗暴地覆盖当前状态而是一次可逆的临时切换。这里最关键的字段可以理解为 prePlanMode。它的价值很大• 进入计划模式前先记住原来处于 default、auto还是 acceptEdits。• 退出计划模式时优先恢复到原来的状态而不是无脑回到 default。• 如果外部条件已经变了比如 auto 已经触发熔断就不能硬恢复而要安全降级。这最后一点非常重要。很多系统只做了“保存—恢复”却没做“恢复前重新校验”。结果就是计划模式本来是为了更安全退出以后反而把原来已经失效的自动权限偷偷恢复了。成熟系统绝不会允许这种行为。少量代码说明保存与恢复权限模式的最小模型type Mode default | auto | acceptEdits | planinterface PermissionContext {mode: ModeprePlanMode?: Mode}function enterPlan(ctx: PermissionContext): PermissionContext {if (ctx.mode plan) return ctxreturn { ...ctx, prePlanMode: ctx.mode, mode: plan }}function exitPlan(ctx: PermissionContext, autoGateEnabled: boolean): PermissionContext {const restore ctx.prePlanMode ?? defaultconst safeRestore restore auto !autoGateEnabled ? default : restorereturn { ...ctx, mode: safeRestore, prePlanMode: undefined }}你会发现这段逻辑真正体现出来的并不是“计划模式”四个字而是一个非常通用的工程思想• 临时进入受限状态时要记录进入前上下文。• 离开受限状态时要做条件检查而不是机械恢复。• 一切恢复动作都应该是显式、可追踪、可回退的。三、为什么计划一定要写成文件而不是只停留在对话里如果计划只存在于聊天记录中它有三个天然短板。第一用户很难在熟悉的编辑器里改。第二一旦上下文被压缩早期计划可能被裁掉。第三远程协作或跨端协作时这份计划不容易作为独立对象被回看和传递。把计划写成 Markdown 文件本质上是在做一件非常聪明的事把“临时对话里的共识”升级成“可编辑、可存档、可恢复、可复核”的持久化资产。一旦计划落成文件就会立刻带来几个收益• 用户可以直接打开文件修改而不是只能在聊天里说“你改一下第三条”。• 对话历史被压缩后计划依然在磁盘上关键结论不会随轮次消失。• 本地与远程界面都能围绕同一份计划协作而不是各说各话。• 计划可被纳入后续的审批、执行、审计流程。不过计划落盘也不是随便找个目录写进去就完事。真正做上线系统时这里至少要处理四类问题• 路径要受限不能让配置把计划写到项目外的危险位置。• 文件名要可读便于人工识别不宜全是 UUID。• 同一会话、不同子代理最好有隔离命名防止互相覆盖。• 路径解析和目录准备最好做缓存减少每轮都打文件系统的浪费。少量代码说明计划目录要做路径约束防止逃逸from pathlib import Pathdef get_plan_dir(project_root: str, configured: str | None) - Path:base Path(project_root).resolve()target (base / configured).resolve() if configured else Path.home() / .claude / plansif configured and target ! base and base not in target.parents:# 路径逃逸回退到安全目录return Path.home() / .claude / planstarget.mkdir(parentsTrue, exist_okTrue)return target这类防御看起来很细但恰恰决定了一套功能能不能进生产环境。一个真正成熟的计划系统绝不会只想着“写进去就行”而是会提前想好目录安全、冲突处理、命名可读性与性能成本。四、提示词工作流为什么不是每一轮都塞一整份长指令计划模式还有一个特别值得学的点它不是只靠工具权限限制模型‘不能做什么’还会通过附加提示持续提醒模型‘现在应该怎么做’。这两层结合起来行为才会稳定。但问题也很现实如果每一轮都把完整工作流说明重新塞给模型token 成本会非常高用户轮次一多系统自己就先把成本打爆了。于是一个非常工程化的策略就出来了• 第一次进入计划模式时给完整工作流说明。• 后续大多数轮次只给一句精简提醒你仍在计划模式只能读只有计划文件可以写。• 隔若干轮再重新补一次完整说明防止模型长期偏航。• 一旦退出并再次进入计数器重置重新从完整说明开始。这套机制看似只是省 token实际上还有更深一层价值它把提示词从‘固定大段说明’变成了‘按状态和轮次动态注入的控制信号’。也就是说提示词开始像状态机的一个组件而不是普通静态文案。五、标准 5 阶段为什么一份好计划不能一步写完成熟的计划流程通常不会让模型一进来就直接写最终计划。更稳妥的方式是分成几个阶段让它先摸清情况再逐步收敛。这套五阶段流程可以理解成下面这五步• Phase 1理解需求。先弄清楚用户到底要什么。• Phase 2设计方案。用专门的规划能力提出可行实现路径。• Phase 3复核关键文件。不能只听子代理汇报主线程还得自己读重点。• Phase 4写入计划文件。把前面收敛下来的内容落到唯一允许写的那份文件里。• Phase 5提交审批。由用户决定是否从‘先看’切换到‘开始做’。这里面最容易被忽略的是第三步——复核关键文件。很多人做多 Agent 系统时一看到子代理已经返回总结就直接把总结当真了。这样效率看着很高风险其实很大。真正稳的系统一定会让主线程在最后阶段亲自再读一遍最关键的文件把‘别人说的’变成‘自己确认过的’。很值钱的一点计划模式不是为了把所有事都交给子代理而是为了让子代理帮助主线程省上下文同时把最终判断权留在主线程手里。六、还有另一种节奏边探索、边提问、边改计划并不是所有任务都适合“全部探索完再一次性交计划”。当需求本身还模糊、方案选择很多、用户又愿意参与时另一种更像结对讨论的迭代节奏往往更合适。这种方式最像真实团队里的高级工程师与需求方一起梳理方案• 先快速读一批关键代码得到第一轮判断。• 把当前发现直接写进计划文件而不是攒到最后一次性落盘。• 遇到只有用户才能回答的分歧再主动发问。• 拿到补充信息后继续读、继续改、继续收敛。它的好处非常明显不会把误解一直积累到最后一刻才暴露用户也能更早看到计划骨架及时打断方向错误的部分。从体验上说标准五阶段更像“我先研究完给你一版完整提案”迭代式流程更像“我们一边看一边把计划磨清楚”。两者没有绝对谁更高级关键看你的用户群、任务复杂度以及对交互频率的容忍度。七、审批流个人场景是一层确认团队场景往往是两层治理计划模式真正有价值的一点在于它把“是否开始动磁盘”从模型自己决定变成了显式审批。这样一来执行权就不是隐藏在模型内部而是暴露成一个明确的状态转换。在个人场景里流程比较直接模型写好计划调用退出计划模式用户点击批准系统再恢复到可执行状态。但在团队场景里事情会更复杂。因为不是所有成员都应该拥有‘我想好了就直接执行’的权限。更合理的做法是把计划打包成一条审批消息发给 team lead 或主会话再由带队角色决定是否放行。这背后体现的是很成熟的组织治理思路• 研究可以并行分散执行权限却可以集中管理。• 计划可以由子角色写批准必须由更高责任角色给。• 审批对象最好是结构化内容而不是一段散乱对话。如果你想把自己的 Agent 体系做成多人协作产品这条线一定值得抄。因为一旦进入多角色、多会话、多终端协同‘谁能开工’这件事必须被写进机制而不能靠口头约定。八、Auto Mode 和计划模式为什么会是最复杂的一组组合当系统里已经存在自动批准或分类器辅助批准能力时计划模式就不再只是一个简单的只读限制而是要和自动权限体系发生联动。这里最难处理的是两件事• 进入计划模式时要不要继续保留 auto。• 退出计划模式时之前的 auto 还能不能恢复。如果计划期间仍保留 auto优点是只读探索会更顺滑用户少点很多确认但缺点是退出时必须重新检查 auto 是否仍可用。因为计划期间可能已经触发了熔断、策略变更或其它门控逻辑这时继续恢复 auto 就不安全了。如果进入计划模式时关闭 auto那么计划期会更保守很多动作都会回到人工确认成本是流畅性下降但安全边界更清楚。不管你选哪条路有一条红线不能碰红线规则只要自动权限在计划期间已经失效退出计划模式时就必须降级绝不能悄悄恢复到原先的 auto 状态。九、Plan Agent 为什么要做成“只读架构师”计划阶段通常会启用专门的规划子代理。它的定位非常清晰不是程序员不是执行器而是只读架构师。一个靠谱的 Plan Agent至少要有四层控制• 工具层直接禁掉 Write、Edit、NotebookEdit 这类会改状态的能力。• 代理层不允许它再无限派生更多代理防止递归失控。• 提示层在系统提示里重复强调‘只读、不得落盘’。• 成本层可按需省略非必要长说明减少上下文负担。为什么一定要双保险因为只靠提示词模型可能忘只靠工具约束模型虽然改不了但仍可能不断尝试、浪费回合。两者叠加以后系统既能从能力侧拦截也能从行为侧引导稳定性会高很多。这套设计对任何想做企业 Agent 的团队都很有启发• 负责探索的代理不一定也要负责写代码。• 负责任务规划的代理最好天然只读。• 不同代理的工具权限应该和它的角色职责直接对应。十、这套机制里最值得你复用的 6 个工程模式• 模式 1保存 / 恢复 权限模式。任何临时受限状态都应该可逆。• 模式 2计划文件持久化。让重要共识脱离聊天成为可编辑对象。• 模式 3Full / Sparse 节流。完整指令和精简提醒交替出现兼顾成本与稳定。• 模式 4审批前只读。把‘开始执行’做成显式批准而不是默认继续。• 模式 5多角色审批。研究权与执行权分层治理适合团队协作。• 模式 6双层防线。工具约束和提示词约束一起上别押宝单点机制。把这些模式拿出来看你会发现它们并不只服务于代码生成。任何会触发外部副作用的 Agent 系统——例如运维 Agent、数据分析 Agent、客服知识改写 Agent、自动工单处理 Agent——其实都适用。十一、如果让你自己落地一套计划模式建议这样搭我更建议把它拆成四层• 交互层负责 /plan 命令、模式切换、审批弹窗、编辑器打开等体验。• 权限层负责只读工具白名单、写操作拦截、恢复前校验、熔断器。• 状态层负责 prePlanMode、计划文件路径、附件注入计数、reentry / exit 标志。• 执行层负责 Explore 子代理、Plan 子代理以及批准后的正式执行链路。这样拆的好处是后续你无论要接 MCP、接企业权限策略、接审计日志、接远程协作入口都不会推翻整个系统。少量代码说明推荐的实现顺序# 一个很实用的落地顺序1. 先做只读工具集合 写操作统一拦截2. 再做 prePlanMode 保存/恢复3. 再把计划改成 Markdown 文件落盘4. 加上审批动作批准后才允许恢复执行5. 最后再做多 Agent 探索、Full/Sparse 节流、多人审批很多团队会反过来先追求多 Agent 很炫、界面很花结果最基础的权限恢复、路径约束、审批边界没打牢。那样系统看起来聪明实战却不稳。计划模式最怕的不是功能少而是边界虚。十二、总结计划模式真正厉害的地方不是会写计划而是会“管住执行”很多人看到计划模式第一反应是哦就是先让模型列一个待办清单。其实远不止这样。它真正厉害的地方在于它把 AI Agent 里最危险、最模糊、最容易出返工的那一段流程拆成了可控的几个组件• 进入前保存旧状态退出时精确恢复。• 执行前强制只读把探索与落盘隔开。• 计划写成文件让共识能编辑、能恢复、能审批。• 用 Full / Sparse 提示维持流程记忆控制 token 成本。• 在个人与团队场景里分别建立明确审批边界。• 让规划代理专注做架构师而不是顺手就开始改代码。说到底这套设计回答的是一个特别现实的问题当 Agent 变得越来越会做事时我们怎么确保它不是‘一冲动就开始做’而是‘先对齐、再行动’。谁能把这件事做扎实谁的 Agent 才更像真正能进入生产环境的系统。参考资料https://pan.baidu.com/s/1Fm6rZSZkY3q2NcrmTfTMeQ?pwd6fkr