Plan Mode 如何设计，怎样拆解任务与组织执行？

核心回答

Plan Mode可以设计成“先形成可检查计划，再把计划交给受约束执行器”的工作阶段。以编码Agent为例，先明确需求和验收方式，读取相关代码，拆出有输入输出与依赖的子任务；执行时选择前置条件已满足的步骤，调用工具并保存结果，再根据反馈决定继续、局部调整还是重新规划。

项目设计示例中，规划器生成步骤，调度器维护依赖与状态，执行器处理工具调用，验证器检查结果。计划阶段还应限制实际修改能力；这样计划不只是给用户看的说明，也能成为后续执行的依据。

拆到什么粒度

子任务要能独立解释目的、输入、产物和完成依据，例如“找到订单查询入口与调用方”“增加筛选参数并保持默认行为”“验证筛选与分页”。“优化系统”过大，“读取第20行”又过细，前者无法验收，后者把工具动作错当业务计划。

计划条目可以保存step_id、依赖、预期产物、状态和证据引用。编排器检查依赖是否存在、是否成环、所需工具是否可用。独立读取可以并行；写同一文件或依赖前一步结果的任务，需要串行或显式归并。计划状态变化应关联执行结果，不能仅靠模型把Todo勾上。

执行和重规划如何衔接

执行器只选择就绪步骤，处理参数校验、超时、错误分类与结果记录。步骤完成后，验证实际产物是否达到该步骤目的；最终再检查所有验收条件是否覆盖。

新观察通常只影响当前步骤。例如发现测试命令不同，修正验证方式即可；发现原设计依赖不存在、关键接口无法兼容，才需要修改更大的计划。保留已完成证据和失败原因，避免每轮从头生成计划导致路径震荡。用户目标变化则生成新的目标或计划版本，使旧结果与新要求的关系清楚。

一个完整例子

给后台列表增加已有字段时，计划可以只有“检查列定义、沿用现有模式增加列、验证排序和显隐”三步，不需要再拆成多角色项目。跨服务订单流程改造才值得增加接口契约、迁移和联调等阶段。规划的成本要与问题范围相称。

常见追问

如何验证计划本身？ 检查需求覆盖、步骤依赖、资源可用性与验证方式；不能仅用另一次模型评分证明计划可执行。

Plan-and-Execute与Plan Mode相同吗？ 前者描述规划器和执行器的组织方式；后者常是产品交互与权限阶段，两者可以组合，但并非同义词。

对应教程

参考资料