Agent中的Planning到底是什么

发表于 更新于
当开发者第一次接触Cursor、Claude Code、Codex或Manus等现代Agent产品时，往往会产生一种误解。既然这些系统在任务开始时会生成一份包含多个步骤的执行计划，那么Agent的Planning是否就是先生成计划，再按照计划执行？答案是，并不完全如此。

现代Agent确实会生成计划，但这份计划更多承担的是任务拆解和进度管理的作用，而不是真正意义上的执行控制逻辑。如果将现代Agent理解为“先规划后执行”的流水线系统，往往会导致对其内部工作机制产生错误认识。
真正的现代Agent通常采用的是一种混合式规划架构：系统首先生成一个高层计划（High-Level Plan）用于描述整体方向和主要阶段，而在实际执行过程中，则持续基于当前状态动态决定下一步动作。这种模式可以概括为：

1
2
3
4
5
6
7
8
9
High-Level Plan
        ↓
Execute
        ↓
Observe
        ↓
Replan
        ↓
Execute

也就是说，计划存在，但计划并不是绝对权威；状态始终优先于计划。

为什么固定计划并不可靠

假设用户提出一个任务：

1
帮我修复登录模块中的Bug

一个典型的Planner可能会生成如下计划：

1
2
3
4
5
1. 阅读登录模块代码
2. 定位异常逻辑
3. 修改代码
4. 运行测试
5. 验证修复结果

从人类角度来看，这是一份合理的计划。但问题在于，当Agent真正开始执行时，它获得的信息会不断变化。
例如在第二步分析代码时，它可能发现：

1
2
登录逻辑本身没有问题
真正的问题来自Session中间件

这时原来的计划立即失效。
如果系统坚持按照既定步骤继续执行：

1
继续修改登录模块

那么最终很可能修错地方。
因此，现代Agent几乎不会把计划当作不可变的执行脚本。相反，它们会把计划视为一种当前认知下的最佳猜测。当新的信息出现时，计划本身也必须随之调整。
于是：

1
2
3
4
5
1. 阅读登录模块代码
2. 定位异常逻辑
3. 分析Session中间件
4. 修改Session逻辑
5. 重新测试

新的计划会动态生成。
这也是为什么会在Cursor中经常看到这样的现象：Agent一开始展示了一份计划，但执行到中途时又主动修改了自己的执行路线。

现代Agent：两层规划机制

从工程实现角度来看，现代Agent通常同时存在两层规划机制。

（1）高层规划（High-Level Planning）

当用户给出目标后，系统首先要求模型将目标拆解为若干阶段：

1
2
3
plan = llm("""
请根据目标生成执行计划
""")

例如：

1
2
3
4
5
6
7
8
9
10
目标：
研究AI摄影市场

计划：

1. 收集主要竞品
2. 分析产品功能
3. 调研用户评价
4. 研究商业模式
5. 输出报告

这一步的主要作用并不是控制执行，而是帮助Agent理解任务结构，同时向用户展示系统准备如何开展工作。
从产品设计角度看，高层计划还有一个重要作用：降低用户的不确定感。相比一个什么都不说就开始工作的黑盒系统，用户通常更愿意信任一个能够明确展示行动路线的Agent。
但真正决定Agent行为的并不是这份计划。

（2）动态规划（Dynamic Planning）

在执行过程中，系统会不断维护当前状态：

1
2
3
4
5
6
7
state = {
    "goal": "...",
    "completed_tasks": [...],
    "known_facts": [...],
    "missing_information": [...],
    "artifacts": [...]
}

每完成一步动作之后，状态都会发生变化。
此时Planner并不是重新生成完整计划，而是回答一个更简单的问题：

1
在当前状态下，下一步最有价值的动作是什么？

例如：

1
2
3
4
5
6
next_action = llm(
    goal,
    current_state,
    memory,
    recent_results
)

模型可能返回：

1
2
3
4
5
6
7
8
{
  "action": "search",
  "query": "Bestie Cam user reviews"
}
``

或者：

{
“action”: “edit_file”,
“target”: “session.py”
}

1
2
3

系统执行动作，更新状态，然后再次提出同样的问题：

下一步应该做什么？

1
2
3
4
5
6
7
8
9
10

整个过程不断循环。
因此，从本质上讲，现代Planner并不是一个“生成计划”的模块，而更像一个“下一步决策器（Next Action Predictor）”。

## Planning的真实核心：状态驱动决策

很多开发者第一次研究Agent时，会把注意力集中在Planner Prompt本身，试图设计更复杂的任务拆解逻辑。但在实际工程中，Planner往往是整个系统里最简单的部分。

真正困难的问题并不是：

next_action = llm(…)

1
2
3

而是：

context = build_context(…)

1
2
3
4
5
6
7
8
9
10

因为模型能否做出正确决策，完全取决于它看到什么信息。

如果当前状态缺失关键事实；
如果历史动作被错误压缩；
如果长期记忆没有被正确召回；
如果工具执行结果没有被纳入上下文；
那么即使模型本身能力再强，也无法做出正确判断。
因此，现代Agent的Planning能力实际上建立在三个更底层的能力之上：

State
+
Memory
+
Context Engineering

```

Planner只是利用这些信息做出下一步决策。
换句话说，Planning本身并不神秘。现代Agent之所以能够持续完成复杂任务，并不是因为拥有某种特殊的规划算法，而是因为系统能够持续维护状态、组织上下文，并基于当前认知不断重新决定下一步行动。
这也是为什么近年来Agent系统的研究重点逐渐从Planner本身转向Memory、State和Context Engineering。
对于现代Agent而言，真正困难的从来不是“制定计划”，而是“知道自己现在处于什么状态，以及接下来最应该做什么”。