Planning 任务规划：Agent 的「思考—拆解—执行」决策机制#

📌 今日速览#

模型会推理、会调工具，但谁来决定下一步该做什么？答案就是 Planning（规划）。规划是 Agent 的「大脑中枢」——把模糊的宏观目标拆成结构化的原子步骤，并按依赖关系编排执行顺序。今天从 4 篇文章里梳理出规划的三层演进路径（ReAct 反应式 → Plan-and-Execute 规划式 → Proactive 主动式），以及生产级 Agent 的「规划-执行分离」架构共识。最核心的反共识观点是：规划不是「写个 JSON 数组就完事」，而是要解决”何时介入（行动阈值）”、“何时调整（动态重规划）”、“如何协同（黑板+协议）“三个深水区问题。

一、为什么今天聊这个？#

过去 30 天我们学完的脉络是：

• 7-23 架构演进：Prompt → Context → Harness → Loop → Graph
• 7-24 记忆系统：Memory 分层与复用
• 7-27 Skill 技能系统：能力封装与可治理
• 7-28 Context Engineering：上下文决定单次决策
• 7-29 Multi-Agent：多智能体协作模式
• 7-30 / 7-31 评估与可观测性：怎么判断 Agent「能信」
• 8-3 Tool Use 工具调用：怎么「动手」

但始终有一个中枢问题没正面回答：模型怎么决定”下一步做什么”？

所有的架构、记忆、Tool Use、Multi-Agent，最终都要靠一个”决策器”来调度——是”先想清楚再动手”（Plan-and-Execute），还是”边做边想”（ReAct）？是”等用户指令再行动”（Reactive），还是”持续监测主动触发”（Proactive）？这个”决定下一步做什么”的能力，就是 Planning。它是 Agent 的”大脑中枢”，是连接”想”和”做”的关键桥梁。

今天 4 篇文章从 4 个不同视角把这件事讲透了：

1. Proactive Agent 视角：规划是”长期意图→持续监测→阈值触发”的主动决策
2. Skill 模块化架构视角：规划是”任务分解→结构化输出→动态重规划”的工程流程
3. 深度研究智能体视角：规划是”Planning-Only / Intent / Unified”三种范式的选择
4. OpenClaw 系统视角：规划是”任务图→状态机→可恢复执行”的系统设计

二、规划的三层演进路径#

把今天学到的内容压成一条演进主线：

1
第一层：Reactive（被动响应）
2
   └─ 模式：单次请求-响应闭环，任务随指令结束
3
   └─ 代表：传统 ChatBot
4

5
第二层：Proactive Planning（主动规划）
6
   └─ 模式：先想清楚再动手，结构化分解子任务
7
   └─ 代表：Plan-and-Execute、ReAct、Reflexion
8

9
第三层：Proactive Agent（主动预见）
10
   └─ 模式：长期意图 + 持续监测 + 阈值触发
11
   └─ 代表：DevOps 主动运维、京东 Themis-GPT

核心洞察：三层不是替代关系，而是适配不同场景。简单任务用 Reactive 就够；复杂任务必须用 Plan-and-Execute；长周期、需主动服务的任务用 Proactive。

三、生产级规划的四大核心机制#

1
┌─────────────────────────────────────────────┐
2
│  规划层（Planner）                           │
3
│    ├─ 输入：用户需求 + 技能空间 + 执行上下文    │
4
│    ├─ 输出：结构化执行计划（JSON 数组/DAG）   │
5
│    └─ 职责：只输出"做什么"，不关心"怎么做"    │
6
├─────────────────────────────────────────────┤
7
│  共享工作区（黑板系统）                        │
8
│    └─ 单一事实来源，事务性状态写入             │
9
├─────────────────────────────────────────────┤
10
│  执行层（Executor）                          │
11
│    ├─ 解析参数 → 创建工作空间 → 沙箱执行       │
12
│    └─ 结果写回 state_delta（遵循 CQRS 思想）  │
13
└─────────────────────────────────────────────┘

1
┌─────────────────────────────────────────────┐
2
│  ① 异常监控                                  │
3
│     └─ 协调者捕获 Skill 失败/超时/反馈异常     │
4
├─────────────────────────────────────────────┤
5
│  ② 触发重规划                                │
6
│     └─ 规划模块被再次激活                      │
7
│     └─ 输入：原始任务 + 共享工作区完整上下文     │
8
├─────────────────────────────────────────────┤
9
│  ③ 生成新计划                                │
10
│     └─ 基于新上下文重新分析                    │
11
│     └─ 可能跳过/修改/增加步骤                  │
12
├─────────────────────────────────────────────┤
13
│  ④ 继续执行                                  │
14
│     └─ 新计划写入共享工作区                    │
15
│     └─ 协调者从断点处继续调度                  │
16
└─────────────────────────────────────────────┘

1
任务清晰度判断
2
    ├─ 高 ─→ Planning-Only（节省交互成本）
3
    ├─ 中 ─→ Unified（边规划边确认）
4
    └─ 低 ─→ Intent-to-Planning（先澄清再规划）

1
[长期意图层] (用户设定)
2
    ↓
3
[持续监测层] —— 监听：代码提交、CI/CD 状态、监控数据…
4
    ↓
5
[变化判断与决策层] —— 判断：技术债？安全漏洞？性能瓶颈？
6
    ↓
7
[行动阈值] —— 评估：严重度、紧迫性、影响范围
8
    ↓
9
[主动执行层] —— 行动：创建 Issue、提交 PR、发送通知
10
    ↓
11
[反馈与学习层] —— 根据结果优化意图理解与决策阈值

四、状态管理：规划-执行的”骨架”#

OpenClaw 明确提出：很多人以为 Agent 的连续性来自”对话历史”，但真正可交付的连续性，来自状态。

1
Agent 当前状态：空闲 / 执行 / 等待 / 中断 / 恢复
2
任务生命周期：创建 / 规划 / 执行 / 校验 / 完成 / 失败
3
异常状态：超时 / 权限不足 / 工具不可用

五、规划的结构化输出契约#

Skill 模块化架构给出了规划输出的标准契约：

1
[
2
  {
3
    "step": "步骤名称",
4
    "skill": "需要激活的 Skill 名称",
5
    "inputs": "该步骤需要的关键输入字段",
6
    "expected": "该步骤预期产出"
7
  }
8
]

关键约束：

1. 覆盖关键步骤序列：必须包含业务关键路径（如”生成蓝图 → 处理蓝图 → … → 持久化”）
2. 明确依赖关系：复杂系统中是包含依赖边、并行/串行关系的 DAG
3. 支持动态组装：分解时需考虑 Skill 空间，输出可被协调者用于动态调度

OpenClaw 的进一步设计：

• 用户目标 → 拆成子任务图（Task Graph）
• 支持串行、并行、条件分支
• 任务执行中可以 Re-plan：某条路不通就换路，而不是卡死

六、分歧与讨论#

七、与已学内容的联系#

💡 思考题#

1. 架构选择题：你要开发一个”多步骤数据分析 Agent”，需要从数据库取数、清洗、建模、可视化、生成报告。你会选择 ReAct、Plan-and-Execute 还是分层规划器架构？为什么？动态重规划的触发条件应该怎么设计？
2. 边界判断题：Proactive Agent 在 DevOps 运维中效果显著（70% 故障自愈），但主动重构代码风险极高。如何设计”行动阈值”才能既不过度干预（导致误操作）又不反应迟钝（错过最佳修复窗口）？请结合京东 Themis-GPT 和阿里 LLM 故障预测的案例思考。
3. 协议协同题：MCP（工具调用）和 A2A（智能体协同）共同构成现代 Agent 的协议层。在一个”金融研报生成”场景中，规划器需要协调 5 个专业 Agent（数据采集/财务分析/行业研究/风险评估/报告撰写），MCP 和 A2A 分别承担什么角色？状态如何在两层协议间流转？

🎯 行动项#

1. 动手实践：用 LangGraph 实现一个”规划-执行分离”的多步骤任务 Agent，体验动态重规划机制（建议参考 LangGraph 官方文档的 Plan-and-Execute 示例）
2. 架构对比研究：阅读 [深度研究智能体<系统性的检查和路线图>] 中关于 OpenAI DR / Gemini DR / Manus 的规划策略对比，整理成一张”三种范式对比表”加深理解
3. 协议层探索：分别调研 MCP（Model Context Protocol）和 A2A（Agent-to-Agent）协议的当前生态支持情况——MCP 已支持 200+ 外部 API，A2A 还在早期阶段，画一个时间线预测两者在未来 2 年的发展轨迹
4. 延伸思考：在 7-30/7-31 学过的 Agent 评估体系中，“动态重规划的成功率”应该作为一项关键评估指标吗？如何量化？请设计 3-5 个评估维度

参考文章#

• 《Proactive Agent：从被动响应到主动规划的 AI 范式》（note_74128814149592887307200439519008）— 贡献了规划的三层演进路径、Proactive Agent 五大核心要素、DevOps/测试自动化等量化案例
• 《面向项目开发的 Skill 模块化架构设计、工作流程与持续学习机制》（note_74398892766048687307200439519008）— 贡献了规划-执行分离的完整工程实现、动态重规划的四步流程、JSON 数组输出契约
• 《深度研究智能体：系统性的检查和路线图》（wechatarticle_a020c3340373aaaa788aba07b7cf588e7307200439519008）— 贡献了 Planning-Only / Intent-to-Planning / Unified 三种规划范式的对比、动态工作流 vs 静态工作流的分析
• 《深度解析 OpenClaw 底层架构》（wechatarticle_33c04193f06cc1198de22b6ec78bf2767307200439519008）— 贡献了六层架构中的认知与决策层设计、状态机设计、动态重规划的系统级实现、协议层（MCP/A2A）的协同关系