第 10 章：Planning 模式——Agent 的战略指挥部

芋圆ai
0 阅读6分钟

第10章：Planning 模式：Agent 的战略指挥部

Planning 不是“想好了再动手”，而是“边想边做、边做边评估”的持续循环。没有规划的 Agent 只是脚本，有了规划的 Agent 才是大脑。

0001页.png

想象这样一个场景：

你招了一个实习生，让他 “研究一下特斯拉、比亚迪和 Rivian 三家公司的竞争格局” 。

实习生 A（没规划） ： 打开 Google 疯狂搜索，半小时后甩给你一堆链接：Wikipedia 的摘要、几条旧新闻、还有一堆乱七八糟的参数表。信息都有，但没法看。

实习生 B（有规划） ： 他先拿出一张纸，写下大纲：

  1. 财务对比：营收、利润、市值。
  2. 产品矩阵：车型覆盖、价格区间。
  3. 技术护城河：自动驾驶、电池技术。
  4. 最终结论：综合优劣势。 然后他按着大纲去查，最后给你一份结构清晰的报告。

0002页.png

这就是 Planning 的价值。

大多数 Agent 之所以显得“笨”，不是因为模型不够强，而是因为它们像实习生 A 一样，接到任务就闷头干活，完全没有 战略拆解。

本章我们来聊聊 Agent 的大脑 —— 规划（Planning） 。

01. 为什么要规划？（The Why）

面对一个复杂任务（比如“写一份竞品分析”），如果直接把 Prompt 扔给 LLM，通常会发生灾难：

  1. 上下文爆炸：一次性塞入太多搜索结果，Token 瞬间耗尽。
  2. 逻辑混乱：东一榔头西一棒槌，输出缺乏结构。
  3. 死循环：在一个无关紧要的细节上（比如 Rivian 的轮胎供应商）纠缠不清，浪费时间和金钱。

Planning 本质上是项目管理学在 AI 领域的应用： 它把一个 模糊的、巨大的 目标，拆解成一组 具体的、可执行的 小任务。

装修房子的哲学

这就像装修房子。你不会一上来就刷墙。你会自然地进行规划：

  1. 拆解：水电、木工、油漆、软装。
  2. 排序：必须先改水电，再铺地板（依赖关系）。
  3. 并发：厨房贴砖和卧室吊顶可以同时做（并行提效）。

0003页.png

Agent 也需要这种直觉。

02. 任务分解：MECE 原则的数字化

Planning 的第一步是 Decomposition（分解） 。 Shannon 框架遵循咨询行业的 MECE 原则（相互独立，完全穷尽）。

输入与输出

  • 输入：“分析 OpenAI 的竞争对手。”
  • Agent 思考：“这个任务太大了，我需要拆解。”

分解结构（伪代码）

Task: "分析 OpenAI 竞品"

Subtasks:
  1. [ID: T1] "识别主要竞争对手" 
     - 产出: [Competitor_List]
     - 范围: 仅限基础大模型公司
  
  2. [ID: T2] "收集 Google Gemini 的技术参数"
     - 依赖: [T1] (必须先知道对手是谁)
     - 产出: [Gemini_Specs]
  
  3. [ID: T3] "收集 Anthropic Claude 的技术参数"
     - 依赖: [T1]
     - 产出: [Claude_Specs]
  
  4. [ID: T4] "撰写对比报告"
     - 依赖: [T2, T3] (必须等资料都齐了才能写)
     - 产出: [Final_Report]

关键点：

  • 依赖声明（Dependencies） ：T2 和 T3 必须等 T1 做完才能做；T4 必须等所有都做完才能做。
  • 范围边界（Boundaries） ：明确告诉 T2 “只查参数，别查花边新闻”，防止子任务越界。

03. 执行策略：指挥交通的艺术

任务拆好了，怎么执行？ 这涉及到了计算机科学中的 图论。

策略 A：并行执行 (Parallel)

适用：子任务互不相干。 例子：“帮我生成 5 个不同风格的 Logo 提示词。” 操作：Agent 同时开启 5 个线程，效率最高。

策略 B：串行执行 (Sequential)

适用：严格的步骤流程。 例子：“打开文件 -> 读取内容 -> 总结 -> 发邮件。” 操作：一步一步来，最稳，但最慢。

策略 C：DAG（有向无环图）执行

适用：大多数复杂任务。 逻辑：这是最聪明的执行方式。Agent 会构建一张 依赖关系图。

就像做饭： “煮饭”和“炒菜”可以 并行。 但“切菜”必须在“炒菜” 之前。 “吃饭”必须在“煮饭”和“炒菜”都 结束 之后。

0006页.png

Shannon 的调度器会自动分析依赖，能并行的并行，该等待的等待。

04. 覆盖度评估：知道何时“收手”

这是 Planning 模式中最容易被忽视，但也是最昂贵的一环。

很多 Agent 会陷入 完美主义陷阱：查完资料觉得不够，继续查，查了又觉得还不全，无限循环，直到把你的钱烧光。

我们需要一个 评估者（Evaluator） 角色。

评估流程

初始分解 -> 执行子任务 -> [评估点] -> 够了吗？
                           ↓
                        不够 -> 生成补充任务 -> 继续执行
                           ↓
                         够了 -> 结束

0007页.png

确定性护栏：给 LLM 上锁

千万不要完全信任 LLM 的判断（它通常倾向于继续干活）。必须加上硬规则：

  1. 最大迭代次数（Max Loops） ：最多循环 3 次，不管做没做完，必须停。这是 成本底线。
  2. 覆盖度阈值：让 LLM 给当前结果打分（0-100）。如果超过 85 分，强制结束。
  3. 信息增量检查：如果这一轮查到的信息和上一轮差不多，说明在做无用功，强制结束。

0008页.png

05. 动态规划：计划赶不上变化

现实世界是复杂的。 Agent 刚开始规划的是“查 Google 的财报”，结果发现 Google 没发财报，或者网页打不开。

死板的 Agent 会报错停止。 聪明的 Agent 会 动态调整（Re-planning） 。

逻辑：

  1. T2 任务失败（网页 404）。
  2. Agent 捕获错误。
  3. 触发 Re-planning：生成替代任务 T2-b “去搜索相关新闻报道代替财报”。
  4. 继续执行。

这就像导航软件，发现前方堵车（任务失败），立刻计算一条新路线（新计划），而不是让你把车停在路中间。

06. 常见的坑

坑 1：过度分解（Micro-management）

现象：把“查天气”拆解成“打开浏览器、输入网址、找到搜索框、输入城市...”。 后果：执行成本远高于任务本身，慢且贵。 建议：一个子任务应当是一个完整的动作（如“搜索并总结天气”），粒度要适中。

坑 2：范围重叠

现象：T1 查“产品”，T2 查“服务”，结果两个任务都把“售后服务”查了一遍。 后果：Token 浪费，最后汇总时还得去重。 建议：在 Prompt 里明确 Out of Scope（不包含什么）。

坑 3：死锁

现象：A 等 B，B 等 A。 后果：程序卡死。 建议：在 DAG 调度器中加入环检测算法，确保依赖关系是单向的。

0010页.png

0012页.png

总结

Planning 模式是 Agent 迈向 通用人工智能（AGI） 的雏形。

  • 分解（Decomposition） ：把大象装进冰箱分几步？
  • 调度（Scheduling） ：哪些并行，哪些串行？
  • 评估（Evaluation） ：做完了吗？做得好吗？
  • 动态调整（Re-planning） ：路不通，换条路。

0013页.png 掌握了 Planning，你的 Agent 就不再是一个只会听指令的 操作工，而是一个能独当一面的 项目经理。

下一章预告

Agent 学会了规划和执行，但它怎么知道自己做得对不对？ 如果写出的代码跑不通，或者查到的资料是错的，它能自己发现并改正吗？

下一章，我们来聊 Reflection（反思）模式：这是让 Agent 产生“自我意识”、实现自我进化的关键一步。 0015页.png

avatar
文章
阅读
粉丝