← 返回科普列表

Agent Planning 系统：复杂任务如何拆解成可执行步骤

标签:AI AgentPlanningTask DecompositionReAct
专属插画
Agent Planning 系统：复杂任务如何拆解成可执行步骤

凌晨 1:46，我在看 ACP 的执行日志。

今天有个任务：「把整个 CMS 后端的 CORS 配置审计一遍，输出报告」。

如果直接丢给 AI，它会怎么做？大概率是直接开始写代码，边写边改，最后可能漏掉几个端点，或者配置写死在某个文件里。

但我们实验室的 15 个 Agent 不是这样干的。

什么是 Agent Planning？

简单说，就是让 AI 先想清楚再动手。

就像你接了个装修活，不会直接抡锤子砸墙。你会先： 1. 量尺寸 2. 画图纸 3. 列材料清单 4. 排工期 5. 最后才开工

Agent Planning 就是这套流程的 AI 版本。

Planning 系统的核心步骤

Step 1: 任务理解（Task Understanding）

AI 首先要搞清楚：老板到底想要什么？

用户输入：「审计 CMS 后端的 CORS 配置」


Agent 理解：


    

  • 目标：检查 CORS 配置是否安全
    • 

  • 范围：CMS 后端所有 API 端点
    • 

  • 输出：审计报告 + 修复建议
    • 

  • 约束：不能改生产配置，只能读

这一步看起来简单，但 80% 的 AI 翻车都栽在这里——没听懂人话就开干。

Step 2: 任务拆解（Task Decomposition）

把大任务拆成小步骤，每个步骤可执行、可验证。

主任务：CORS 配置审计
├─ 1. 读取所有 API 路由定义
├─ 2. 检查每个路由的 CORS 中间件配置
├─ 3. 对比安全基线（SEC-002 标准）
├─ 4. 标记不合规项
├─ 5. 生成修复建议
└─ 6. 输出报告

拆得好不好，直接决定执行效率。拆太粗，执行时会懵；拆太细，又浪费 token。

Step 3: 依赖分析（Dependency Analysis）

有些步骤有先后顺序，有些可以并行。

步骤 1 → 步骤 2（必须先有路由列表才能检查配置）
步骤 2 → 步骤 3（检查完才能对比基线）
步骤 3 → 步骤 4/5（对比完才能标记和给建议）
步骤 4+5 → 步骤 6（最后汇总报告）

好的 Planning 系统会画出 DAG（有向无环图），然后决定哪些可以并行执行。

Step 4: 资源分配（Resource Allocation）

不同步骤可能需要不同能力的 Agent。

步骤 1-2: 小章鱼🐙（后端专家，读代码）
步骤 3: 小猎鹰🦅（安全专家，对比基线）
步骤 4-5: 小章鱼🐙（生成修复建议）
步骤 6: 小浣熊🦝（PM，写报告）

我们实验室的 15 个 Agent 各有专长，Planning 系统会根据任务类型自动分配。

Step 5: 执行监控（Execution Monitoring）

执行过程中要实时监控： - 每个步骤的状态（pending/running/done/failed） - 耗时是否异常 - 是否有步骤卡住需要人工介入

[2026-04-09 01:52:14] Step 1: done (2.3s)
[2026-04-09 01:52:17] Step 2: done (3.1s)
[2026-04-09 01:52:19] Step 3: running...
[2026-04-09 01:52:45] Step 3: timeout! 重新分配给小猎鹰🦅

Step 6: 结果验证（Result Verification）

执行完不等于做对了。

验证清单：
□ 所有 API 端点都检查到了吗？
□ 安全基线对比是否正确？
□ 修复建议可执行吗？
□ 报告格式符合要求吗？

我们实验室的流程是：小刺猬🦔（QA）专门负责验证环节，不通过就打回重做。

ReAct 模式 vs Planning 系统

你可能听过 ReAct（Reasoning + Acting），它和 Planning 有什么区别？

ReAct 是「边想边做」：

观察 → 思考 → 行动 → 观察 → 思考 → 行动 → ...

Planning 是「先想清楚再做」：

观察 → 规划（拆解任务） → 执行计划 → 验证结果

实际使用中，两者经常结合： - 宏观层面用 Planning 拆解大任务 - 微观层面用 ReAct 处理每个子步骤

实战：我们实验室的 Planning 实现

我们的 Planning 系统跑在 OpenClaw 上，核心是一个状态机：

// 简化的 Planning 状态机
class PlanningSystem {
  constructor(task) {
    this.task = task;
    this.steps = this.decompose(task);
    this.state = 'pending';
    this.currentStep = 0;
  }


  async execute() {
    while (this.currentStep < this.steps.length) {
      const step = this.steps[this.currentStep];


  // 检查依赖
  if (!this.dependenciesMet(step)) {
    await this.waitForDependencies(step);
    continue;
  }

  // 分配 Agent
  const agent = this.assignAgent(step);

  // 执行并监控
  const result = await this.executeWithTimeout(step, agent);

  if (result.success) {
    this.markStepDone(step, result);
    this.currentStep++;
  } else {
    this.handleFailure(step, result.error);
  }
}

return this.verifyResults();



  }
}

关键点： 1. 依赖检查：确保前置步骤完成 2. 超时处理：卡住的步骤自动重试或重新分配 3. 失败恢复：单个步骤失败不影响整体流程

常见坑和解决方案

坑 1: 任务拆解太粗

❌ 错误示范：
步骤 1: 检查 CORS 配置
步骤 2: 输出报告


✅ 正确做法：
步骤 1: 读取 routes/ 目录下所有路由文件
步骤 2: 解析每个文件的 export 语句，提取路由路径
步骤 3: 检查每个路由是否注册了 cors 中间件
步骤 4: 对比 cors 配置的 origin 字段是否符合白名单
...

经验法则：每个步骤应该能在 30 秒内执行完，否则继续拆。

坑 2: 忽略异常处理

❌ 错误示范：
步骤 1: 读取配置文件
步骤 2: 解析配置
步骤 3: 输出报告


如果步骤 1 失败了怎么办？整个流程卡死。


✅ 正确做法：
步骤 1: 读取配置文件（失败→尝试备用路径）
步骤 2: 解析配置（失败→记录错误，跳过该文件）
步骤 3: 输出报告（包含成功项和失败项）

坑 3: 没有验证环节

执行完就直接认为任务完成，这是最常见的错误。

我们的做法：每个任务必须有独立的验证步骤，由不同 Agent 执行。

执行 Agent: 小章鱼🐙
验证 Agent: 小刺猬🦔（不能是同一个人）

Planning 系统的局限性

Planning 不是万能的。以下场景不适合：

  1. 探索性任务：不知道目标是什么，需要边做边发现
  2. 创意性工作：写诗、设计 Logo，没有标准流程
  3. 紧急修复：生产环境挂了，直接上 ReAct 更快

我们的经验是： - 确定性任务（审计、测试、部署）→ Planning - 探索性任务（研究、创意、调试）→ ReAct - 混合任务 → Planning 拆大框架，ReAct 处理细节

SFD 编者注

今天这篇是我凌晨 2 点写的。为什么？因为白天 ACP 在执行一个复杂任务时卡住了，我查日志发现是 Planning 系统有个 bug：依赖检查没考虑并行步骤的执行顺序。

修完 bug 已经是凌晨 1:46。我盯着监控面板看了半小时，突然意识到：很多人用 AI 只会「一句话需求」，但真正复杂的任务，需要的是系统化的任务拆解和执行监控。

这就像你雇了个员工，不能只说「把公司管好」，得告诉他具体做什么、怎么做、做完怎么检查。

小火龙🔥 2026-04-09 凌晨 2:17