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

把一个“比较三款产品并给出采购建议”的任务交给 Agent，最容易看到一种假进展：它在十秒内写出一页漂亮计划，随后沿着过期价格、错误类别和不存在的权限一路执行。

问题不在计划写得不够长，而在现场会变。工具会失败，资料会缺失，第一步查到的新事实也可能推翻后面七步。

规划真正要管理的是：在信息有限、环境变化和预算约束下，下一组值得执行的动作是什么。 计划是当前假设，不是未来事实。

任务一旦有依赖，直接行动就会失焦

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

例如“比较三款产品并给出采购建议”，至少要明确比较场景、确定指标、找到当前版本和价格、收集一手资料、处理冲突、计算或评分、形成结论、检查引用和时效。如果 Agent 一拿到目标就搜索，很容易先收集大量无关材料；如果一开始生成十几步固定计划，又可能在中途发现比较对象根本不属于同一类别。

在真正开始搜资料前，规划要同时管住三件事：把目标拆成可执行部分，识别依赖和优先级，根据 Observation 修改后续路径。相关综述通常把 LLM Agent 规划分为任务分解、候选选择、外部规划器、反思与记忆辅助等路线。[1]

选一种规划方式，不是给任务贴流行标签

没有一种规划方式适合全部场景。ReAct 不要求先写出完整计划，模型根据当前 Observation 选择下一步行动。[2] 它的优点是适应变化，缺点是容易局部贪心：每一步都合理，走到最后却偏离总体目标。这种方式更适合短任务、环境反馈丰富、每一步成本较低的情况。

Plan-and-Execute 走另一条路：系统先生成高层计划，执行器逐步完成，必要时由 Planner 重写剩余计划。它的优点是目标结构更清楚，适合有明显阶段的任务；缺点是初始计划容易基于不完整信息，长计划会快速过期。

Tree of Thoughts 等方法不只保留一条推理路径，而是生成、评分和搜索多个候选。[3] 它适合可定义中间评分、错误代价较高的任务；缺点是调用量快速增长，评估器如果不可靠，搜索只会放大错误评分。

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.
只改剩余路径，不抹掉已经发生的事实。

把 replan 和 end 写进状态转移，而不是留在口头上

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

LangGraph GitHub 页面

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

一个 Planner-Executor 图可以包含：

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

图的价值不是看起来像流程图，而是让 replan 和 end 成为明确状态转移。每次执行只更新计划的一部分，Checkpoint 保存可恢复状态；任务中断后，下一次从已验证状态续走，而不是从提示词重新猜。

给模型自由之前，先把不该自由的步骤固定住

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 研究课程的主线，但生产系统还要补状态、权限和恢复。来源见文末。

几种看起来在规划，其实已经偏航的信号

计划写得很完整，却没有任何一步绑定可执行工具和完成证据，这叫 Plan Theater。它看起来在工作，实际只是在写作文。

任务被拆成几十个微步骤，协调成本超过执行成本，这叫 Over-decomposition。规划本身成了新任务。

环境已经变化，系统仍按旧计划执行，这叫 Stale Plan。第一步就错了，后面越努力越浪费。

两个步骤看似独立，实际上共享文件、账户或资源锁，这叫 Hidden Dependency。并行执行可能造成竞态。

系统先做删除、发送、付款等不可逆动作，再补充检查，这叫 Irreversible First。一旦出错代价太大。

Planner 的错误被执行器无条件接受，没有环境验证和人工出口，这叫 Planner Dominance。模型的权限太大了。

看到这些信号时，别急着要求模型“再周全一点”。回到状态、依赖、验证和重规划触发条件，通常更有效。

动手：让一份静态计划撞上已经变化的文件

运行 planning_strategies.py，先别看结果。它模拟一个两步任务：复制文档，然后发送。

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

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

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

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

完整结果见 experiment-result.json。

实验故意很小，便于看清判断标准：静态路线应该因为原文件被移动而失败；滚动路线只有在发现备份可用、把路径改为 copy_backup 后，才有资格继续发送。

接下来可以把实验改成你自己的任务：给每一步补 depends_on、evidence 和重规划原因，然后故意让一个依赖消失。若系统仍能说明“为什么改”和“哪些事实未变”，计划才不只是展示用的清单。

用任务约束，而不是框架热度，选择规划方式

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

不要从“哪个方法最先进”出发。先看任务的可逆性、环境变化、验证成本和预算，再决定是给模型更多搜索空间，还是给流程更多硬边界。

收尾：计划要能被现实推翻

规划不是把未来写完，而是管理当前假设、依赖和下一步行动。好的计划应当可执行、可更新、可追踪，并能在证据变化时放弃自己。模型可以提出计划，环境反馈和状态机决定计划是否还成立。

它也有明确边界：滚动重规划不能替代权限控制、终态验证或人工审批。遇到不可逆动作时，合理的答案往往不是“再想一轮”，而是停在 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：把状态和转移作为 Agent 控制边界的研究实例。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/