Agent 是怎么规划和拆任务的？把它的大脑拆开给你看
Agent 是怎么规划和拆任务的？把它的“大脑”拆开给你看
很多人觉得 Agent 厉害，是因为它能回答问题。但如果你再往下看一步，真正拉开差距的，其实不是“会不会答”，而是它能不能先想清楚怎么做，再把任务一步步拆开推进。
前面几篇我们已经把几个关键问题讲清楚了：
- Agent 能做什么
- 它为什么容易跑偏
- 怎么下任务会更稳
- 为什么提示词写对了，结果还是可能不稳定
- 一个可执行 Agent 是怎么从目标一路跑到交付的
如果接下来继续往底层能力走，有一个问题必须讲透：
Agent 到底是怎么规划和拆任务的？
因为很多人现在对 Agent 的理解，还停在一个比较模糊的层面：
我给它一句话，它就帮我做。
这句话不算错。
但如果你真的想把 Agent 用到工作里，只知道这一层远远不够。
真正决定它能不能把事情做成的，不只是理解你的话，而是它有没有能力把一个目标变成一串可执行的动作。
这就是规划和任务拆解。
说得更直接一点：
规划决定它是不是知道先做什么、后做什么；拆解决定它能不能把大问题变成能推进的小步骤。
一、为什么 Agent 需要规划，而不是直接开做
如果任务特别简单，当然可以一步到位。
比如：
- 帮我润色这段话
- 帮我列 3 个标题
- 帮我翻译成英文
这种任务本身就很短，目标也明确，Agent 不太需要复杂规划。
但真实工作里，很多任务都不是这种“一步出结果”的类型。
比如：
- 帮我调研一下这个方向，并整理成可读结论
- 帮我分析这个仓库，找出接下来最该改的地方
- 帮我把一篇原稿改成适合公众号发布的成稿
- 帮我排查这个流程为什么失败，并给出修复建议
这些任务有一个共同点：
它们不是一个动作，而是一串动作。
如果 Agent 不先规划，最常见的问题就是两种：
- 一上来就急着给结论，中间必要步骤没做
- 做了很多动作，但顺序混乱，最后结果不收敛
所以规划的价值，不是让它“看起来更聪明”，而是让执行有路径。
二、规划到底在规划什么
很多人一听“规划”，会下意识想到很复杂的路线图。
但对 Agent 来说，规划通常没有那么玄。
它本质上是在回答 4 个问题：
- 目标到底是什么
- 要先做哪些前置动作
- 哪些步骤存在依赖关系
- 做到什么程度才算完成
比如你给它一个任务：
帮我做一份关于 Agent 评估的入门资料。
一个没有规划的 Agent，可能会直接开始写。
但一个更靠谱的 Agent，会先在内部想清楚：
- 先确认目标读者是谁
- 再决定这份资料要写到什么深度
- 然后补必要背景信息
- 再组织结构
- 最后检查有没有超出范围
你会发现，规划不是“想很多”，而是“先把动作顺序理顺”。
三、任务拆解到底在拆什么
如果说规划解决的是“路径”，那任务拆解解决的就是“颗粒度”。
因为很多目标本身太大，不能直接执行。
比如：
帮我把这个项目梳理清楚。
这句话听起来没问题，但对执行来说太大了。
它至少可以继续拆成：
- 先看目录结构
- 再找核心模块
- 再读关键文档
- 再总结模块关系
- 最后输出一版梳理结果
拆解的意义在于，把一个抽象目标变成具体动作。
否则 Agent 很容易停留在一种很空的状态：
- 知道大概要做什么
- 但不知道下一步先做哪件事
一旦出现这种情况，它就容易靠感觉走，最后越来越散。
所以任务拆解不是形式动作，而是执行起点。
四、一个更像样的 Agent，通常怎么拆任务
在真实系统里，Agent 的拆解不一定会把每一步都完整展示给你，但底层通常都在做类似的事情。
一个比较常见的拆解逻辑，大概是这样：
- 识别目标
- 找约束条件
- 判断是否需要补信息
- 把任务拆成若干步骤
- 判断步骤之间的依赖
- 逐步执行并根据结果调整
这里面最关键的，不是“拆得多细”，而是“拆得能推进”。
比如有些拆解看起来很多，但其实没什么执行价值：
- 第一步：理解问题
- 第二步：深入思考
- 第三步：给出答案
这类拆解像写了 3 步，实际等于没拆。
真正有价值的拆解，应该尽量接近可操作动作。
比如：
- 读取指定目录下的文档
- 提取用户已经明确确认过的约束
- 先产出提纲，再补充正文
- 用验收条件检查结果是否达标
这类步骤才会真正帮助它往前走。
五、规划和拆解做不好，通常会出现什么问题
如果你在用 Agent 时，常看到下面这些现象，十有八九就是规划或拆解出了问题：
1. 一开口就直接给结论
任务还没看清楚，它已经开始回答了。
这类问题往往意味着：
- 目标识别过快
- 前置步骤没建立
- 不知道哪些信息必须先确认
2. 做了很多事，但没有顺序
它可能查了一些资料，也写了一些内容，但整体看起来很乱。
这通常说明：
- 有动作，但没有路径
- 步骤之间缺少依赖关系
- 没有把结果逐步收敛到同一个目标上
3. 大任务能懂，小任务不会拆
你给它一句大目标，它好像明白。
但真到执行时，它不知道先做什么。
这说明它有理解能力，但缺少从目标到动作的中间层。
4. 遇到变化后不会重排计划
比如中途发现信息不全、工具失败、约束变化，它还按原路线硬跑。
这说明它不是在动态规划，而只是在机械执行。
六、规划不是一次性的，而是边做边修
很多人会误以为规划是任务开始前做一次，然后就固定了。
但真实任务里，规划往往是动态的。
因为执行过程中经常会出现新信息：
- 查到的资料和预期不一样
- 目录结构和原来猜的不一致
- 用户补充了新约束
- 某个工具不可用
- 前一步的结果暴露出新问题
这时候，更成熟的 Agent 不会死守原计划，而会做两件事：
- 判断原计划哪里需要调整
- 重新安排后续步骤
这就是为什么真正好用的 Agent，看起来不像在“照剧本演”，而更像在“边做边校正”。
所以规划的本质不是把未来一次想完，而是给执行留出可调整的骨架。
七、你可以把 Agent 的“大脑”理解成两层
如果想用最简单的话理解规划和拆解，我建议你把 Agent 的“大脑”看成两层：
第一层：决定方向
这一层解决的是：
- 目标是什么
- 边界在哪里
- 先做哪类事情
- 最终要交付什么
第二层：把方向变成步骤
这一层解决的是：
- 当前先做哪一步
- 下一步依赖什么结果
- 哪一步需要工具
- 什么时候该停下来检查
前一层更像定路线，后一层更像排执行顺序。
两层缺一不可。
如果只有方向，没有拆解，它会想得明白但推进不动。
如果只有拆解，没有方向，它会一直做事但容易做偏。
八、在日常使用里，怎么判断一个 Agent 的规划能力够不够
你不需要看很底层的模型细节，也能大致判断它有没有规划能力。
可以直接观察 4 件事：
- 面对复杂任务时，它会不会先澄清目标和边界
- 它会不会自然拆出中间步骤，而不是直接跳结论
- 中途信息变化后，它会不会调整路径
- 最终结果能不能看出是按步骤收敛出来的
如果这 4 点基本都做不到，那它更像是“会说的模型”，还不是“会推进任务的 Agent”。
如果这 4 点已经比较稳定，说明它至少具备了比较像样的规划骨架。
九、为什么规划与拆解是 Agent 底层能力的起点
后面我们会继续讲记忆、评估、调试这些更底层的能力。
但规划与拆解之所以要先讲，是因为它几乎决定了后面所有能力怎么接上去。
你可以这么理解：
- 没有规划，工具不知道什么时候用
- 没有拆解，记忆不知道该记哪些状态
- 没有步骤，评估不知道该评哪一环
- 没有路径，调试也很难定位到底错在哪
所以它不是某个可有可无的附加能力。
它更像 Agent 执行系统的起点。
很多看起来“不稳定”的问题，往回追一层，最后都会追到这里。
总结
很多人觉得 Agent 的核心是“能不能回答好”。
但再往底层走一步，你会发现更关键的是：
它能不能先规划，再拆解，再一步步推进。
规划解决的是路径问题。
拆解决定的是执行颗粒度。
两者一起，才让 Agent 从“会说”变成“会做”。
理解了这一层，你就会更容易看懂 Agent 为什么有时像在认真工作，有时却像在随机发挥。
因为真正的差别，往往不在输出那一刻，而在它开始输出之前，有没有先把路想清楚。
下一篇，我们继续往下讲另一个很核心但也最容易被误解的能力：
Agent 为什么需要记忆？不是记住聊天，而是记住任务状态。