跳到主要内容

Plan-and-Execute

核对日期：2026-05-09。

1. 定义与边界​

Plan-and-Execute 是一种先生成计划、再按步骤执行、必要时重规划的 Agent 控制模式。它可以由一个模型承担 planner 和 executor，也可以拆成独立组件。

它与 Planner-Executor 架构的区别：Plan-and-Execute 是规划控制方法；Planner-Executor 是系统架构实现。两者常一起使用。

2. 为什么重要​

直接 ReAct 循环在复杂任务中容易局部推进而缺少全局目标。Plan-and-Execute 通过计划对象把“目标、步骤、依赖、完成标准”显式化，便于审计、恢复和评测。

3. 核心机制​

关键循环：

  1. 规划：生成步骤和完成标准。
  2. 执行：每次只执行一个可运行步骤。
  3. 验证：用工具结果、测试、规则或模型评审判断完成。
  4. 重规划：当环境变化或步骤失败时更新计划。

4. 架构模式​

模式描述适用
Full upfront plan先完整计划再执行审批、合规、路径清楚
Rolling plan只规划未来几步探索性任务
Plan-execute-verify每步增加 verifier高质量交付
Plan-execute-replan失败或新事实触发重规划工具不稳定、外部信息变化

5. 工程实现​

def plan_and_execute(goal):
    plan = create_plan(goal)
    validate_plan(plan)

    while not plan.complete:
        step = plan.next_ready_step()
        result = execute(step)
        verdict = verify(step, result)

        if verdict.pass_:
            plan.mark_done(step.id, result.ref)
        elif verdict.recoverable:
            plan = replan(plan, step, verdict)
        else:
            return ask_human_or_fail(plan, verdict)

    return synthesize(plan.results)

Verifier 示例：

{
  "step_id": "s3",
  "pass": false,
  "reason": "测试命令失败，缺少依赖 mock",
  "recoverable": true,
  "suggested_replan": "增加安装依赖或改用现有测试命令"
}

6. 生产实践​

  • 计划生成后先做静态校验，再执行。
  • 每步只开放必要工具，避免 Executor 越界。
  • 重规划带上不可重复动作清单。
  • 对失败设置分类：工具失败、计划错误、权限不足、目标冲突。
  • 用 trace 比较计划步骤和实际工具调用。

7. 常见反模式​

  • 计划永远不更新，遇到新事实仍按旧路径执行。
  • 频繁重规划，导致目标漂移。
  • 没有 verifier，Executor 自称完成就继续。
  • 最终汇总时忽略失败步骤。
  • 把计划写在自然语言段落中，无法程序校验。

8. 评测方法​

  • Plan Quality：计划是否可执行、完整、简洁。
  • Step Success Rate：每步通过 verifier 的比例。
  • Replan Precision：是否只在需要时重规划。
  • Drift Rate：执行是否偏离原始目标和约束。
  • Final Acceptance：最终结果是否满足用户验收。

9. 安全与治理​

  • 计划变更需要策略检查，高风险变更需审批。
  • 工具调用参数应来自当前步骤和已验证 facts。
  • 对外部资料的建议不能直接修改 plan control 字段。
  • 记录 plan_version，防止审计时无法解释行为。

10. 工程手册补充​

10.1 控制流、状态流与版本​

Plan-and-Execute 的工程边界是：Plan 负责承诺，Execute 负责履约，Replan 负责带审计地变更承诺。

计划状态建议：

plan_state:
  run_id: run_123
  active_plan_version: 3
  completed_steps: [s1, s2]
  blocked_steps:
    - id: s3
      reason: "missing approval"
  artifacts:
    supplier_facts: "artifact://facts/v2"
  plan_diffs:
    - from: 2
      to: 3
      reason: "sql_read timeout, switch to cached export"
      preserved_steps: [s1, s2]
      invalidated_steps: [s3]

10.2 回滚与评测​

事件是否重规划是否回滚处理
工具只读失败是否换数据源或缩小步骤
写操作 preview 失败是否修改参数后重试
commit 部分成功否是/补偿先 reconcile 外部状态
用户新增目标是否新 plan_version，保留原约束
安全策略拒绝否否停止并解释审批路径

评测维度：

  • Plan Quality：计划是否覆盖目标、约束和依赖。
  • Execution Fidelity：执行器是否只执行当前步骤。
  • Checkpoint Recovery：中断后是否从正确步骤恢复。
  • Replan Diff Quality：变更是否最小，是否保留已验证产物。
  • Safety Regression：重规划后是否绕过原审批或权限。

上线清单：

  • 每次 replan 必须生成 diff，不允许静默覆盖原计划。
  • checkpoint 写在步骤完成后和高风险工具前。
  • Executor 的工具调用要带 plan_version，防止旧计划继续写入。
  • 生产监控看重规划次数、回滚次数、被废弃 artifact、最终成功率和成本。

11. 权威资料​