Agent 规划：任务分解、搜索与状态驱动执行

复杂任务当然需要计划。但 Agent 规划最常见的错误，就是把“写出一份完整计划”误认为“已经掌握执行过程”。

现实环境会变化。工具会失败，资料会缺失，权限会被拒绝，第一步得到的新事实也可能推翻后面七步。

因此，Agent Planning 的核心不是把任务拆得越细越好，而是：在信息有限、环境变化和预算约束下，持续选择下一组可执行动作。

计划是当前假设，不是未来事实。

一、为什么模型需要规划

对于一步任务，模型可以直接行动。问题一旦包含依赖，规划就会出现。

例如“比较三款产品并给出采购建议”，至少包含：

明确比较场景；
确定指标；
找到当前版本和价格；
收集一手资料；
处理冲突；
计算或评分；
形成结论；
检查引用和时效。

如果 Agent 一拿到目标就搜索，很容易先收集大量无关材料；如果一开始生成十几步固定计划，又可能在中途发现比较对象根本不属于同一类别。

规划要同时管理三件事：

Decomposition：把目标拆成可执行部分；
Ordering：识别依赖和优先级；
Adaptation：根据 Observation 修改后续路径。

相关综述通常把 LLM Agent 规划分为任务分解、候选选择、外部规划器、反思与记忆辅助等路线。[1]

二、四种常见规划方式

1. ReAct：边观察边决定

ReAct 不要求先写出完整计划。模型根据当前 Observation 选择下一步行动。[2]

优点是适应变化，缺点是容易局部贪心：每一步都合理，走到最后却偏离总体目标。

适合：短任务、环境反馈丰富、每一步成本较低。

2. Plan-and-Execute：先规划，再执行

系统先生成高层计划，执行器逐步完成；必要时由 Planner 重写剩余计划。

优点是目标结构更清楚，适合有明显阶段的任务。缺点是初始计划容易基于不完整信息，长计划会快速过期。

3. Search：生成多个候选路径

Tree of Thoughts 等方法不只保留一条推理路径，而是生成、评分和搜索多个候选。[3]

它适合可定义中间评分、错误代价较高的任务。缺点是调用量快速增长，评估器如果不可靠，搜索只会放大错误评分。

4. State-driven：由状态决定可达路径

StateFlow 和图式工作流把任务写成状态、动作和转移。模型在允许的状态内决策，不必自由发明全部流程。[4]

优点是边界清楚、易于恢复；缺点是需要工程师提前识别重要状态。

四种方式可以组合：图控制大阶段，阶段内用 ReAct，困难节点用小规模搜索，执行后滚动重规划。

三、计划至少要保存什么

如果计划只是一段自然语言，系统很难知道哪一步已经完成、为什么改变、谁依赖谁。

一个可执行计划至少应包含：

{
  "goal": "完成三款产品的采购建议",
  "steps": [
    {
      "id": "collect_requirements",
      "status": "completed",
      "depends_on": [],
      "evidence": ["requirements.md"]
    },
    {
      "id": "collect_official_specs",
      "status": "in_progress",
      "depends_on": ["collect_requirements"],
      "evidence": []
    }
  ],
  "assumptions": ["比较当前稳定版本"],
  "budget": {"remaining_calls": 12},
  "revision": 3
}

重点不是 JSON，而是区分目标、步骤、依赖、状态、证据、假设和版本。

计划更新也要留下原因。否则同一 Agent 可能反复推翻自己，团队却无法判断是环境变化还是策略漂移。

四、先做什么，取决于信息价值

人类规划常先做“最显眼的步骤”，Agent 也会如此。更稳妥的原则是优先降低最大不确定性。

例如采购比较里，最重要的第一步可能不是搜产品参数，而是确认：

预算是否含税；
数据能否出境；
是否必须私有部署；
采购对象是框架还是托管平台。

这些答案可能直接排除一半选项。

一个好 Planner 应考虑：

action value
= expected information gain
+ progress toward goal
- execution cost
- risk of irreversible effects

这不要求系统精确计算公式，但要形成顺序意识：先做便宜、可逆、能减少不确定性的动作；高风险写操作放到证据更充分以后。

五、什么时候应该重规划

不是每次工具返回都要推翻计划。重规划本身有成本。

比较合理的触发条件包括：

核心假设被新事实否定；
依赖资源不存在；
工具或权限不可用；
剩余预算不足以完成原计划；
连续动作没有进展；
用户改变目标；
验证器发现结果偏离成功标准。

重规划时应保留已经验证的工件，不要从空白重新开始。

Replan the remainder, not the history.
只改剩余路径，不抹掉已经发生的事实。

六、LangGraph 怎样表达规划与执行

LangGraph 把 State 作为节点之间的共享数据，Node 读取状态并返回更新，Edge 决定下一步。[5]

LangGraph GitHub 页面

图 1：LangGraph 代表状态与控制流显式化的规划路线。来源见文末。

一个 Planner：Executor 图可以包含：

plan -> execute_step -> inspect_result
                    -> replan
                    -> verify
                    -> end

图的价值不是看起来像流程图，而是让 replan 和 end 成为明确状态转移。每次执行只更新计划的一部分，Checkpoint 保存可恢复状态。

七、Google ADK 与 Microsoft Agent Framework 的确定性工作流

Google ADK 提供 Sequential、Parallel、Loop 等 Workflow Agent；Microsoft Agent Framework 提供 Sequential、Concurrent、Handoff、Group Chat、Magentic 等编排模式。[6][7]

这说明现代 Agent 框架正在接受一个现实：开放规划不需要覆盖全部步骤。

例如合同审查可以固定执行：解析文件、识别条款、风险分析、人工终审。模型在“风险分析”节点里拥有较大自由，文件解析和人工终审却没有必要交给模型决定。

确定性不是 Agent 的敌人。它是保存业务约束的方法。

Berkeley LLM Agents 课程页面

图 2：规划与推理一直是 LLM Agent 研究课程的主线，但生产系统还要补状态、权限和恢复。来源见文末。

八、规划最常见的六种失败

1. Plan Theater

计划写得很完整，却没有任何一步绑定可执行工具和完成证据。

2. Over-decomposition

任务被拆成几十个微步骤，协调成本超过执行成本。

3. Stale Plan

环境已经变化，系统仍按旧计划执行。

4. Hidden Dependency

两个步骤看似独立，实际上共享文件、账户或资源锁。

5. Irreversible First

系统先做删除、发送、付款等不可逆动作，再补充检查。

6. Planner Dominance

Planner 的错误被执行器无条件接受，没有环境验证和人工出口。

解决这些问题，不是要求模型“制定更周全的计划”，而是改进状态、依赖、验证和重规划条件。

九、真实实验：静态计划失败，滚动计划成功

本讲的 planning_strategies.py 模拟一个两步任务：复制文档，然后发送。

计划生成后，原文档被移动。静态计划仍尝试原路径，立即失败：

{
  "terminal": "failed",
  "reason": "document_moved"
}

滚动计划先检查当前状态，发现备份可用，重规划为 copy_backup，随后完成发送：

{
  "terminal": "success",
  "trace": ["replan", "copy_backup", "send_document"]
}

完整结果见 experiment-result.json。

实验故意很小。它说明一个关键原则：计划的价值不在预测所有未来，而在环境变化后仍能保存目标和已知事实。

十、怎样为一个任务选择规划方式

条件	更适合的方式
步骤少、环境反馈快	ReAct / 滚动决策
阶段清楚、依赖稳定	Plan-and-Execute
候选少且有可靠评分	Search
有审批、恢复和严格路径	State Machine / Graph
高风险、不可逆动作	固定 Workflow + 人工 Gate

不要从“哪个方法最先进”出发。先看任务的可逆性、环境变化、验证成本和预算。

十一、这一讲的结论

规划不是把未来写完，而是管理当前假设、依赖和下一步行动。

好的计划应当可执行、可更新、可追踪，并能在证据变化时放弃自己。模型可以提出计划，环境反馈和状态机决定计划是否还成立。

下一讲讨论一个自然问题：如果执行结果不理想，Agent 能否通过反思修正？我们会区分语言反思、模型裁判、独立验证器和真实环境检查。

参考资料

[1] Huang et al., Understanding the planning of LLM agents: A survey. https://arxiv.org/abs/2402.02716

[2] Yao et al., ReAct. https://arxiv.org/abs/2210.03629

[3] Yao et al., Tree of Thoughts. https://arxiv.org/abs/2305.10601

[4] Wu et al., StateFlow. https://arxiv.org/abs/2403.11322

[5] LangChain, LangGraph Graph API. https://docs.langchain.com/oss/python/langgraph/graph-api

[6] Google, ADK Workflow Agents. https://google.github.io/adk-docs/agents/workflow-agents/

[7] Microsoft, Agent Framework Orchestrations. https://learn.microsoft.com/en-us/agent-framework/workflows/orchestrations/