💡 核心摘要 ：Planning 是 Agent 面对任务时，决定"怎么做""先做什么后做什么""用什么工具做"的核心过程。本文系统梳理 8 种纯 LLM 规划范式与 8 种混合规划模式，每种均配有直观流程图、适用场景与工程实现要点，助你根据实际需求选择最合适的方案。
上一篇文章讲解了Planning 的LLM-based Planning：纯大模型规划 内容，这一篇接着讲它的第二种实现方式，Hybrid Planning：混合规划 内容。 感兴趣可以在专栏中查看上一篇内容。
混合规划的核心思想是：代码控制流程框架，LLM 处理具体内容 。这种方式在当前企业级落地中最为常见，因为它用代码的确定性约束了 LLM 的不确定性。
1. 静态主干：代码完全控制流程
代码预定义固定步骤序列，LLM 仅负责每个步骤的内容生成，不参与流程决策。
案例 ：标准化报告生成步骤 A（提取关键词）→ 步骤 B（查阅资料总结）→ 步骤 C（撰写报告）
bash
用户输入
↓
┌─────────────────┐
代码：启动步骤A
"请从以下文本提取
关键词：「文本内容」"
└────────┬────────┘
↓
┌─────────┐
LLM生成 ← 关键词列表
└────┬────┘
↓
┌─────────────────┐
代码：传递结果到步骤B
"请基于关键词[关键词列表]
查阅相关资料并总结"
└────────┬────────┘
↓
┌─────────┐
LLM生成 ← 资料摘要
└────┬────┘
↓
┌─────────────────┐
代码：传递结果到步骤C
"请基于[资料摘要]撰写
500 字报告"
└────────┬────────┘
↓
┌─────────┐
LLM生成 ← 最终报告
└────┬────┘
↓
代码输出| 维度 | 说明 |
|---|---|
| 适用场景 | 标准化报告、固定流程文档处理、合规严格任务 |
| 优点 | 流程稳定、可控、可预测 |
| 缺点 | 不灵活，无法处理异常或分支 |
2. 意图路由：代码做分类判断
代码（或轻量分类模型）对用户输入进行意图识别，根据意图类型调度到不同的处理链。
案例 ：客服系统分流
- "咨询产品" → 产品知识库链
- "投诉服务" → 投诉处理链
- "查订单" → 订单查询接口
bash
用户输入："分析这份水质数据"
↓
┌─────────────────┐
代码：意图分类
- 代码规则匹配："分析" → 分析类
- 或轻量LLM判断，"请根据用户输入内容进行分类 A:查询 B:分析"
└────────┬────────┘
↓
┌────┴────┐
↓ ↓
┌───────┐ ┌───────┐
查询类 分析类 ← 匹配到
(代码处理) (LLM处理)
└───────┘ └───┬───┘
↓
┌─────────┐
LLM深度
分析数据
└────┬────┘
↓
输出结果| 维度 | 说明 |
|---|---|
| 适用场景 | 客服分流、多类型任务入口、权限控制 |
| 优点 | 路由清晰、效率高、易于扩展 |
| 缺点 | 需要预先定义所有意图类别 |
3. 检查点：代码检测关键条件
代码在流程关键节点插入检查逻辑，命中条件时暂停流程，等待人工审核或自动拦截，通过后再继续。
案例 ：高风险治理方案审批检测条件："涉及关停企业？""预算 > 100 万？""风险等级 = 高？"命中任一条件 → 暂停 → 弹出确认 → 人工批准后继续
bash
**LLM生成方案"请制定xx污水治理方案"
↓
┌─────────────────┐
代码：检查点检测
"涉及关停企业？"
"预算>100万？"
"风险等级=高？"
└────────┬────────┘
↓
┌────┴────┐
↓ ↓
否 是
│ ↓
│ ┌─────────┐
│ 暂停流程
│ 弹出确认"AI建议关停 xx 企业，是否批准？"
│ └────┬────┘
│ ↓
│ ┌─────────┐
└──── 人工审核
[批准/拒绝/修改]
└────┬────┘
↓
┌────┴────┐
↓ ↓
批准 拒绝
↓ ↓
继续执行 重新生成**| 维度 | 说明 |
|---|---|
| 适用场景 | 高风险决策、合规审计、关键操作确认 |
| 优点 | 安全可控，满足合规要求 |
| 缺点 | 增加人工成本，降低自动化程度 |
4. 降级机制：代码捕获 LLM 失败
代码监控 LLM 调用状态，当出现超时、报错、低质量输出时，自动切换到规则引擎或备用方案，保障服务可用性。
案例 ：水质分析降级LLM 超时/报错 → 代码检测失败 → 触发降级："按历史经验，COD+氨氮双高属于生活污水" → 输出保底方案
bash
┌─────────────────┐
尝试用LLM解决
（ReAct/ToT等）
└────────┬────────┘
↓
┌─────────┐
LLM处理
└────┬────┘
↓
┌─────────────────┐
代码：检测成功？
- 超时？
- 报错？
- 质量分<阈值？
└────────┬────────┘
↓
┌────┴────┐
↓ ↓
成功 失败
↓ ↓
输出结果 ┌─────────┐
降级处理
"按历史经验，COD+氨氮双高属于生活污水"
└────┬────┘
↓
输出保底方案| 维度 | 说明 |
|---|---|
| 适用场景 | 生产环境、高可靠性要求的服务 |
| 优点 | 保障服务可用性，避免单点故障 |
| 缺点 | 保底方案可能不是最优解 |
5. 记忆增强：代码管理记忆存储和检索
代码负责记忆的写入、检索、过期清理等生命周期管理，LLM 仅消费记忆内容生成回答，不参与记忆管理逻辑。
案例 ：多轮对话上下文用户问："上次说的茅洲河怎么样了？"代码检索记忆 → 找到"上周关注共和村断面 COD 超标" → 拼接 Prompt → LLM 基于记忆回答
bash
用户输入："上次说的茅洲河怎么样了？"
↓
┌─────────────────┐
代码：检索记忆
- 查user_id=123
- 最近对话：茅洲河
- 相关文档：上次报告
└────────┬────────┘
↓
┌─────────┐
记忆内容
"上周关注共和村断面COD超标"
└────┬────┘
↓
┌─────────────────┐
代码：拼接Prompt
"历史：{memory}
当前：{input}"
└────────┬────────┘
↓
┌─────────┐
LLM生成
"您上周关注的茅洲河的共和村断面COD已下降..."
└────┬────┘
↓
代码存储新对话到记忆库| 维度 | 说明 |
|---|---|
| 适用场景 | 多轮对话、个性化推荐、长期任务跟踪 |
| 优点 | 记忆管理专业化，支持复杂检索策略 |
| 缺点 | 需要额外存储与检索基础设施 |
6. 工具编排：代码预定义工具调用 DAG
代码预定义工具调用的有向无环图（DAG），LLM 仅决定每个节点的参数，不决定调用顺序与依赖关系。
案例 ：Q3 销售分析DAG：query_orders → calculate → llm_analyze用户输入："分析 Q3 销售趋势" → 代码按 DAG 顺序执行，LLM 仅生成查询参数与解读内容
bash
用户输入："分析Q3销售趋势"
↓
┌─────────────────┐
代码：加载预设DAG
步骤1: 查数据库
↓
步骤2: 计算环比
↓
步骤3: LLM解读
└────────┬────────┘
↓
┌─────────────────┐
代码：执行步骤1
调用database_query数据库查询
参数：LLM生成
"表=orders,时间=Q3"
└────────┬────────┘
↓
数据库返回数据
↓
┌─────────────────┐
代码：执行步骤2
调用calculate进行计算
参数：代码自动传递
"数据={步骤1结果}"
└────────┬────────┘
↓
计算结果：环比+15%
↓
┌─────────────────┐
代码：执行步骤3
调用LLM
参数：代码拼接
"基于{步骤2结果}进行解读"
└────────┬────────┘
↓
LLM生成："Q3销售增长强劲，主要因为..."| 维度 | 说明 |
|---|---|
| 适用场景 | BI 分析、运维诊断、金融报表等固定流程 |
| 优点 | 流程稳定、效率高、可监控 |
| 缺点 | 不够灵活，难以处理动态分支 |
7. 状态机驱动：代码维护显式状态
代码定义合法的状态转移图，LLM 只能触发预定义的状态跳转，非法转移被强制拦截。
案例 ：工单系统IDLE → COLLECTED → ANALYSIS → APPROVAL → EXECUTE → DONE禁止 COLLECTED → DONE（跳过分析）、APPROVAL → IDLE（未经执行结束）等非法转移
bash
┌─────────┐
状态码：IDLE(空闲) ← 初始状态
└────┬────┘
↓ 用户提交申请
┌─────────┐
状态码：COLLECTED(数据收集)
[LLM提取]
└────┬────┘
↓ 数据完整？
┌─────────┐
状态码：ANALYSIS (分析中)
[LLM分析]
└────┬────┘
↓ 分析完成
┌─────────┐
状态码：APPROVAL(待审批) ← 代码强制暂停
[人工审核]
└────┬────┘
↓ 人工批准
┌─────────┐
状态码：EXECUTE(执行中)
[代码执行]
└────┬────┘
↓ 完成
┌─────────┐
状态码：DONE(完成)
└─────────┘
非法转移（LLM不能跳）：
COLLECTED → DONE（跳过分析）
APPROVAL → IDLE（未经执行直接结束）| 维度 | 说明 |
|---|---|
| 适用场景 | 工单系统、法律合同、医疗问诊、审计追踪 |
| 优点 | 流程安全、可追溯、合规性强 |
| 缺点 | 实现复杂，灵活性受限 |
8. 成本感知路由：代码根据复杂度选择模型
代码评估任务复杂度，自动路由到不同成本的模型或策略，实现成本与效果的平衡。
案例 ：多级任务路由
- "COD 多少" → 规则引擎（$0.00）
- "分析趋势" → 小模型 GLM-3.5（$1）
- "预测污染" → 大模型 GLM-4（$2）
- "关停工厂" → 大模型 + 人工审核（$3+）
bash
用户输入
↓
┌─────────────────┐
代码：复杂度评估
- 长度？
- 关键词？
- 历史模式？
└────────┬────────┘
↓
┌────┴────────┬────────────┬────────────┐
↓ ↓ ↓ ↓
┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐
简单查询 标准任务 复杂推理 高风险
"COD多少" "分析趋势" "预测污染" "关停工厂"
成本$0.00 成本$1 成本$2 成本$3+人工
规则引擎 小模型 大模型 大模型+审核
(无LLM) (GLM-3.5) (GLM-4) (GLM-5+人)
└───┬───┘ └───┬───┘ └───┬───┘ └───┬───┘
└───────────────┴────────────┴──────────┘
↓
输出结果| 维度 | 说明 |
|---|---|
| 适用场景 | 企业级 SaaS、高并发客服、多层级用户 |
| 优点 | 成本优化，效果与成本平衡 |
| 缺点 | 增加评估开销，需维护多级模型 |
混合规划选型速查表
| 业务需求 | 推荐模式 | 核心理由 |
|---|---|---|
| 流程稳定、合规严格 | 静态主干 / 状态机 | 代码完全控制，杜绝意外 |
| 灵活路由、多类型入口 | 意图路由 / 成本感知路由 | 按需分发，效率与成本兼顾 |
| 安全控制、高风险操作 | 检查点 | 关键节点人工介入 |
| 高可用、生产环境 | 降级机制 | 失败时自动兜底 |
| 多轮对话、个性化 | 记忆增强 | 专业记忆管理 |
| 固定分析流程 | 工具编排 | DAG 保证执行顺序 |
💡 实践建议 ：实际系统往往需要组合多种模式 。例如：意图路由 + 状态机 + 检查点 + 降级机制，每层选择最适合的模式，构建稳健的生产级 Agent。
Planning 的目标是"有效"，而非"完美"
Planning 容易陷入"过度设计"的陷阱。请记住以下原则：
- 简单任务优先用简单方案 ：CoT 或 ReAct 足够应对大多数场景，不要为了炫技上 ToT/LATS。
- 生产环境首选混合规划 ：代码控制框架，LLM 处理细节，分工明确，稳定性远高于纯 LLM 规划。
- 以解决问题为导向 ：Planning 的目标不是"完美"，而是"有效"。能稳定、低成本地解决问题的 Planning，就是最好的 Planning。
我刚开源的 ThinkLoop 工具就是采用了 Reflexion 的设计思路，让各大厂商的 web 端大模型问答更加精准，降低 web 端单模型的幻觉问题，感兴趣可以看一下这篇文章。