Agent 的任务规划怎么做？为什么要先拆解再执行

先这样答

先答为什么要拆。模型一次能可靠处理的内容有限，一个「分析这份财报并写出报告」的任务直接丢给模型，它要在单次生成里同时记住目标、已做步骤和中间结果，任何一处出错都会往后传染。拆解之后每一步只面对一个小问题，可验证、可重试，失败也只需重跑那一步，不用整个任务重来。

怎么做。基本流程是先计划后执行：让模型先列出子步骤清单，写明每步的输入输出和依赖关系，然后逐个执行，每步产出喂给下一步。但一次性计划有盲区，做到第三步才发现第二步的假设不成立是常事，所以工程上常见两种改进。一是边做边重排：每步执行完重新评估剩余计划，发现走偏就修改后续步骤。二是分层规划：先定大阶段，阶段内部再展开细节，计划粒度随执行推进才细化，避免一开始就规划到无法验证的细枝末节。

总结：规划的价值不是显得有条理，是把一个难控制的长任务变成一串可控的短任务。主动提「计划一定会失效，重排比制定更重要」，是区分做过和没做过 Agent 的分界线。

面试官会怎么追问

• 「规划用单独的模型还是同一个模型多轮提示词？」 都可以。简单任务同一个模型先出计划再执行就够；复杂或对成本敏感的场景，可以用小模型做拆解、大模型做执行，按环节分配能力。
• 「计划粒度多细合适？」 细到每步可验证：执行完能明确判断成了还是没成。太粗等于没拆，太细会让规划本身烧掉大量 token，而且前面的细步骤常因后续变化作废。
• 「执行中发现计划错了怎么处理？」 把重排做成常规环节而不是异常处理：每步结束后把目标、已完成、剩余计划一起交给模型重新评估，允许修改、跳过甚至推翻剩余步骤，日志记录每次重排的原因。

回答的坑

• 把规划讲成「先想好一切再动手」。真实任务的信息是逐步到位的，一次性详细计划必然过时，能讲清「计划加重排」才说明真的跑过。
• 拆完不给每步设验证标准。没有验证的子步骤只是把一个大黑盒切成几个小黑盒，失败照样发现不了。