7. 复杂任务怎么做的任务拆分为什么要拆分效果如何提升面试官你说说任务拆分是怎么做的为什么要拆分有什么实际收益♂️我就是把大任务切成小步骤每步让 LLM 只做一件事这样准确率高一些……面试官「准确率高一些」太模糊了你能解释一下为什么拆分之后准确率会提升吗背后是什么原因♂️我可能是因为……每步任务简单了LLM 更容易做对面试官有点方向但不够准确。核心原因是 context window 有限任务越大中间状态越多模型很难持续追踪子目标容易「桌面太乱」出错。那你知道任务拆分有哪两种思路吗各自的适用场景是什么♂️我一种是提前写死步骤一种是让 LLM 自己规划步骤面试官对静态拆分和动态拆分。那拆完之后还有一个关键优化点步骤之间有依赖关系识别出哪些可以并行端到端延迟能降很多这你考虑过吗拆分粒度、并行优化、依赖分析这三个点一起答出来才是完整的任务拆分方案。-简要回答我理解任务拆分的原因是 LLM 一次性处理太复杂的任务很容易出错把大任务拆成小步骤每步聚焦一件事准确率会明显提升。拆分方式主要有两种一种是静态拆分提前把步骤写死另一种是动态拆分让 LLM 自己根据目标规划步骤更灵活但也更难控制。拆完之后步骤之间可能有依赖关系我的经验是把能并行的步骤并发跑端到端延迟可以降很多有时能降 40% 到 60%。-详细解析为什么任务要拆分 先从一个具体的失败案例说起感受一下为什么任务拆分是必要的。 你让一个 LLM 一次性完成「帮我写一份竞品分析报告」它需要搜索多家竞品的信息、整理核心功能对比、分析各自优缺点、写结论。听起来是一件事但其实是四件完全不同的事混在一起。LLM 收到这个任务往往会出现这几种毛病在搜索阶段就开始掺杂分析意见在写对比表格时突然引入新的竞品信息报告写到一半忘掉了前面整理的某个关键数据点最后输出一篇结构混乱的文章读下来感觉什么都有、什么都不深。这不是偶发的问题而是有系统性原因的。LLM 的工作台也就是 context window是有大小限制的能同时处理的信息量是有上限的。任务越大中间状态越多桌面就越乱搜索结果、分析意见、写了一半的段落全部堆在一起LLM 很难持续追踪「我现在在做哪个子目标」。就像让一个人同时记住十件事并全部做对比让他每次只专注做一件事出错率高得多。任务拆分要解决的就是这个「桌面太乱」的问题。把一个大目标切成多个小步骤每个步骤只做一件事LLM 的全部注意力都集中在这一件事上桌面保持干净质量自然高。而且还有一个额外的好处每一个步骤都是独立的输出可以被单独检查和验证。某一步出了问题重试那一步就行不需要从头跑整个任务。任务拆分两种思路这里顺便提一下两个常被拿来类比的推理范式CoT思维链是让 LLM 在一个回答内部把推理过程逐步写出来本质上是一次生成里的内部拆分不涉及多步工具调用ToT思维树进一步允许模型同时探索多条推理路径再选优。这些更像LLM 内部怎么把一个复杂问题想清楚的方法下面要讲的静态/动态拆分说的是Agent 怎么把一个大任务切成多个独立执行的步骤两者粒度和目标不同不要混为一谈。静态拆分 是你提前把任务流程设计好固定成一个确定的 Workflow每一步是什么、按什么顺序执行全部事先写死。比如「写一篇技术博客」固定拆成搜索资料 - 整理大纲 - 逐段撰写 - 润色校对四步顺序执行。好处是行为完全可预测出了问题知道是哪一步的问题好排查坏处是灵活性低遇到你没设计进流程的情况就容易卡住。动态拆分 则是把「任务拆解」这件事本身也交给 LLM 来做。你给它一个目标让它先输出一个执行计划再按计划一步步执行这是 Plan-and-Execute 模式的核心思想。用项目管理来类比。一个没有经验的程序员接到任务「开发用户登录系统」可能会直接开始写代码边写边想「接下来要做什么」结果很容易漏掉某个环节比如忘了写错误处理或者到最后才想起来要做密码加密。但一个有经验的工程师会先写项目计划需求分析 - 数据库设计 - 接口设计 - 编码实现 - 安全测试把整体结构想清楚了再开始动手。Plan-and-Execute 就是给 LLM 引入这个「先规划再执行」的习惯把「想清楚要做什么」和「真正去做」分成两个独立的阶段。整个 Plan-and-Execute 流程分三个阶段每个阶段的角色和职责都非常清晰。第一阶段叫「规划」你可以把它理解成项目启动会。把目标告诉 LLM让它像一个经验丰富的项目经理一样输出一份有序的步骤列表。这一步只做规划不做任何实际执行LLM 的全部注意力集中在「想清楚要做什么」上。比如你说「帮我做一份 AI 行业调研报告」规划模块可能会输出这样的计划先调研行业现状和市场规模再分析头部公司的产品和策略接着梳理技术趋势和发展方向然后汇总写结论和建议最后排版润色输出成品。每一步都有明确的目标但不开始干活。第二阶段叫「执行」相当于各部门按照项目经理的分工开始干活。拿着规划好的步骤列表逐步执行每个步骤每一步都要把前面所有步骤的结果作为 context 传进去LLM 始终知道整件事做到哪里了不会「失忆」。这个阶段的关键是每一步只聚焦于自己的任务不会像 ReAct 那样走着走着就被岔路吸引走了。第三阶段叫「汇总」就像项目验收会。所有步骤跑完之后把各步骤的产出整合在一起生成最终输出。这一步的作用不仅是拼接还要解决各步骤之间的衔接问题确保最终输出是一个连贯的整体而不是几段互不相关的内容生硬地拼在一起。动态拆分的优势是灵活性强LLM 可以根据具体任务的特点制定最合适的计划劣势是规划质量不稳定规划一旦出了问题后续所有执行步骤都建立在错误的基础上。步骤拆好之后还有一件重要的事分析步骤之间的依赖关系。有些步骤必须等前一步完成才能开始有些步骤之间没有依赖可以同时进行。识别出可以并行的步骤是降低总耗时的关键。用厨师做饭来建立直觉。你要同时处理三件事烧水、切菜、腌肉。如果傻傻地串行等水烧开了再切菜切完菜再腌肉总时间是三件事之和。但一个有经验的厨师会这样先烧水烧水的同时切菜腌肉水开了三件事都好了直接下锅。总时间由「最长的那条路径」决定也就是烧水的时间因为切菜和腌肉都在等水开的过程中完成了。并行执行降低的不是「每步的时间」而是「关键路径的总时间」。回到 Agent 的场景假设你有步骤 1、2、3、4其中步骤 3 依赖步骤 1 的结果步骤 4 依赖步骤 2 和步骤 3import asyncio async def execute_parallel_steps(independent_steps: list): # asyncio.gather 让多个步骤同时开始执行不等某一个完成再启动下一个 # 这就像厨师烧水的同时切菜两件事并发进行 tasks [execute_step_async(step) for step in independent_steps] results await asyncio.gather(*tasks) # 等所有并发步骤都完成一起拿结果 return results 依赖图步骤 1 和步骤 2 相互独立可以并行 步骤 3 需要步骤 1 的结果才能开始 步骤 4 需要步骤 2 和步骤 3 都完成才能开始 步骤1 ──────────────┐ ├── 步骤3 ──┐ 步骤2 ──────────────┘ ├── 步骤4最终输出 └────────────────────── ┘如果这四步全部串行总时间是四步之和。识别出依赖关系并行执行后关键路径变成「步骤1/2并行- 步骤3 - 步骤4」假设每步各需要 3 秒串行是 12 秒并行之后是 9 秒。步骤越多、可并行的越多节省的时间越可观实际项目里降低 40% 到 60% 的端到端延迟是很常见的数字前提是任务本身的依赖关系稀疏、工具 I/O 占主要耗时如果所有步骤都强依赖上一步并行空间基本为零优化效果也就无从谈起。要让并行真正落地前提是先把依赖关系画成一张有向无环图DAG每个节点是一个步骤边表示「依赖」。没有依赖的节点就能同时跑依赖它们的节点要等父节点完成。这一步做得对不对直接决定了并行优化的天花板。任务不是拆得越细越好粒度的把握很重要。拆太细有两个代价步骤越多LLM 调用次数越多总 token 消耗上升步骤太碎每步只做一件极小的事LLM 看不到全局产出的各部分也容易衔接生硬。但拆太粗又回到了原来的问题每步负责的事太多出错概率上升出了问题也无法定位是哪一步的责任。实践中通常把「原子操作」作为划分单步的标准这个步骤只做一件独立的事边界清晰做完有明确的输出和其他步骤不互相依赖。具体举例感受一下区别。「搜索竞品 A 的产品信息」是原子的只做一件事搜索有明确的输入和输出做完就完了。「整理竞品分析」不是原子的它包含了搜索信息、筛选关键点、格式化输出三件事还没开始就已经有三个子任务了。判断一个步骤是不是原子的有一个简单方法你能给它写一个清晰的函数签名吗能的话它大概是原子的如果你发现函数里还要分好几个阶段、处理好几类情况那大概需要再拆。自适应拆分-做不好就继续拆前面讲的静态拆分和动态拆分都有一个隐含的假设拆分在任务开始时就一次性完成了执行过程中不会再调整拆分粒度。但实际项目中经常遇到这样的情况你提前拆好了三步执行到第二步时发现这一步比预想的复杂得多LLM 一次做不好需要再拆细一些。或者反过来某一步其实很简单拆得太细反而浪费了调用次数。更好的做法是不要在开始时就把所有步骤的粒度定死而是在执行过程中根据每一步的实际难度动态调整。核心逻辑很简单先让执行器尝试完成当前任务如果做得好就继续往下走不做多余的拆分如果明显做不好比如超过了最大步数还没完成或者输出质量不达标就把这个「做不好的任务」交给规划器让规划器把它进一步拆成更小的子任务然后对每个子任务重复同样的流程先试做不好就再拆。用一个生活中的例子来感受。假设你让 Agent 完成「帮我做一份完整的竞品分析报告」。执行器直接尝试一口气写完发现质量很差数据不准、结构混乱。于是规划器介入把任务拆成三步先「搜集各竞品的核心数据」再「做功能对比分析」最后「写总结和建议」。执行器尝试「搜集各竞品的核心数据」发现竞品太多一次搜不完质量还是不行。规划器再次介入把「搜集数据」进一步拆成「搜集竞品 A 的数据」「搜集竞品 B 的数据」「搜集竞品 C 的数据」。这一次每一步都足够简单执行器可以顺利完成了。整个过程就像一棵递归展开的任务树只有真正做不好的节点才会被继续拆分简单的节点一步到位。这个思路有一个很巧妙的特性任务越复杂递归拆分的层数就越深任务越简单可能一层都不拆。计算开销是和任务的实际难度成正比的而不是一刀切地对所有任务都做同样深度的拆分。执行中的 Replan 机制拆分完成只是第一步执行过程中还有一个经常被忽略的关键环节计划需不需要调整前面讲并行优化的时候隐含了一个前提计划一旦定好就按部就班执行。但现实中步骤的执行结果经常会让原来的计划变得不合理。比如你规划了「先查竞品 A 的定价再查竞品 B 的定价最后做对比分析」执行第一步时发现竞品 A 已经停止运营了那后面的对比分析就没意义了整个计划需要重新调整。Replan 机制就是在每个步骤执行完之后把当前步骤的结果和剩余的计划一起交给规划模块让它判断「基于当前的新信息后面的计划还合理吗」。如果合理就继续执行如果不合理就生成一份新的剩余步骤计划。这个机制保证了计划始终和实际情况同步不会出现「死守一份过时计划」的尴尬。代价是每步都多了一次「评估计划」的 LLM 调用token 消耗会增加。实践中的折中做法是不是每步都触发 Replan而是设置触发条件比如当某步的输出和预期差异很大时或者当步骤执行失败时才启动 Replan。这样既能应对意外又不会无谓地增加消耗。拆分结果的验证标准拆完步骤之后怎么判断拆得好不好靠感觉是不行的需要有明确的验证标准。一个好的拆分结果应该满足三个条件。第一个是「完备性」也就是所有步骤加在一起能不能覆盖原始任务的全部要求有没有遗漏。比如用户说「帮我写一份竞品分析报告包含市场份额、产品功能对比和定价策略三个维度」你拆出来的步骤里必须每个维度都有对应的步骤在负责少了任何一个都算拆分不完备。检查方法很直接把所有步骤的描述拼在一起和原始任务描述做逐项对照看有没有某个要求在任何步骤里都没被提到。第二个是「独立性」也就是每个步骤的职责边界是不是清晰有没有两个步骤在做同一件事或者某个步骤的输出和另一个步骤的输出有重叠。举个反面例子步骤 2 是「搜索竞品 A 的产品功能」步骤 3 是「分析竞品 A 的核心能力」这两步的边界就很模糊「产品功能」和「核心能力」大概率会搜到同样的内容导致重复劳动。更好的拆法是步骤 2 只负责「搜索竞品 A 的全部信息」步骤 3 负责「从搜索结果中提炼功能对比表」一个负责搜集一个负责加工各管各的。职责重叠不仅浪费 token还容易导致最终汇总时出现矛盾比如两个步骤对同一个功能给出了不一样的评价。第三个是「可验证性」也就是每个步骤执行完之后能不能用一个简单的标准判断它做对了没有。这一点在实际项目中特别容易被忽视但它直接决定了你能不能做自动重试和质量把控。比如你拆了一个步骤叫「搜索竞品 A 的定价信息」如果没有完成标准执行完之后你只能人工看一眼判断做得好不好。但如果你在拆分时就定义了「输出中必须包含价格数字和计费模式按量/包月/免费增值」执行完之后自动检查输出是否包含这两个要素就行了缺了就自动触发重试。好的做法是在拆分每个步骤时同时写好它的「验收标准」就像写单元测试的断言一样步骤定义和验收标准成对出现。 面试总结回答任务拆分这道题要答出三个层次才完整。第一层是「为什么拆」LLM 的 context window 有上限任务越大中间状态越多、越容易出错而且拆开后每步可以独立验证和重试。第二层是「怎么拆」静态拆分适合流程固定的场景直接写死步骤动态拆分用 Plan-and-Execute 让 LLM 自己规划灵活但规划质量不稳定。第三层是「拆完还要做的事」分析步骤依赖关系把能并行的步骤并发跑关键路径时间可以降 40% 到 60%。最后再补一句「粒度把握很重要以原子操作为标准既不能太细也不能太粗」这道题就回答得很漂亮了。 
长河君 · 2026/10/23 3:05:14 · 阅读 1.2k 7. 复杂任务怎么做的任务拆分？为什么要拆分？效果如何提升？
7. 复杂任务怎么做的任务拆分为什么要拆分效果如何提升面试官你说说任务拆分是怎么做的为什么要拆分有什么实际收益♂️我就是把大任务切成小步骤每步让 LLM 只做一件事这样准确率高一些……面试官「准确率高一些」太模糊了你能解释一下为什么拆分之后准确率会提升吗背后是什么原因♂️我可能是因为……每步任务简单了LLM 更容易做对面试官有点方向但不够准确。核心原因是 context window 有限任务越大中间状态越多模型很难持续追踪子目标容易「桌面太乱」出错。那你知道任务拆分有哪两种思路吗各自的适用场景是什么♂️我一种是提前写死步骤一种是让 LLM 自己规划步骤面试官对静态拆分和动态拆分。那拆完之后还有一个关键优化点步骤之间有依赖关系识别出哪些可以并行端到端延迟能降很多这你考虑过吗拆分粒度、并行优化、依赖分析这三个点一起答出来才是完整的任务拆分方案。-简要回答我理解任务拆分的原因是 LLM 一次性处理太复杂的任务很容易出错把大任务拆成小步骤每步聚焦一件事准确率会明显提升。拆分方式主要有两种一种是静态拆分提前把步骤写死另一种是动态拆分让 LLM 自己根据目标规划步骤更灵活但也更难控制。拆完之后步骤之间可能有依赖关系我的经验是把能并行的步骤并发跑端到端延迟可以降很多有时能降 40% 到 60%。-详细解析为什么任务要拆分 先从一个具体的失败案例说起感受一下为什么任务拆分是必要的。 你让一个 LLM 一次性完成「帮我写一份竞品分析报告」它需要搜索多家竞品的信息、整理核心功能对比、分析各自优缺点、写结论。听起来是一件事但其实是四件完全不同的事混在一起。LLM 收到这个任务往往会出现这几种毛病在搜索阶段就开始掺杂分析意见在写对比表格时突然引入新的竞品信息报告写到一半忘掉了前面整理的某个关键数据点最后输出一篇结构混乱的文章读下来感觉什么都有、什么都不深。这不是偶发的问题而是有系统性原因的。LLM 的工作台也就是 context window是有大小限制的能同时处理的信息量是有上限的。任务越大中间状态越多桌面就越乱搜索结果、分析意见、写了一半的段落全部堆在一起LLM 很难持续追踪「我现在在做哪个子目标」。就像让一个人同时记住十件事并全部做对比让他每次只专注做一件事出错率高得多。任务拆分要解决的就是这个「桌面太乱」的问题。把一个大目标切成多个小步骤每个步骤只做一件事LLM 的全部注意力都集中在这一件事上桌面保持干净质量自然高。而且还有一个额外的好处每一个步骤都是独立的输出可以被单独检查和验证。某一步出了问题重试那一步就行不需要从头跑整个任务。任务拆分两种思路这里顺便提一下两个常被拿来类比的推理范式CoT思维链是让 LLM 在一个回答内部把推理过程逐步写出来本质上是一次生成里的内部拆分不涉及多步工具调用ToT思维树进一步允许模型同时探索多条推理路径再选优。这些更像LLM 内部怎么把一个复杂问题想清楚的方法下面要讲的静态/动态拆分说的是Agent 怎么把一个大任务切成多个独立执行的步骤两者粒度和目标不同不要混为一谈。静态拆分 是你提前把任务流程设计好固定成一个确定的 Workflow每一步是什么、按什么顺序执行全部事先写死。比如「写一篇技术博客」固定拆成搜索资料 - 整理大纲 - 逐段撰写 - 润色校对四步顺序执行。好处是行为完全可预测出了问题知道是哪一步的问题好排查坏处是灵活性低遇到你没设计进流程的情况就容易卡住。动态拆分 则是把「任务拆解」这件事本身也交给 LLM 来做。你给它一个目标让它先输出一个执行计划再按计划一步步执行这是 Plan-and-Execute 模式的核心思想。用项目管理来类比。一个没有经验的程序员接到任务「开发用户登录系统」可能会直接开始写代码边写边想「接下来要做什么」结果很容易漏掉某个环节比如忘了写错误处理或者到最后才想起来要做密码加密。但一个有经验的工程师会先写项目计划需求分析 - 数据库设计 - 接口设计 - 编码实现 - 安全测试把整体结构想清楚了再开始动手。Plan-and-Execute 就是给 LLM 引入这个「先规划再执行」的习惯把「想清楚要做什么」和「真正去做」分成两个独立的阶段。整个 Plan-and-Execute 流程分三个阶段每个阶段的角色和职责都非常清晰。第一阶段叫「规划」你可以把它理解成项目启动会。把目标告诉 LLM让它像一个经验丰富的项目经理一样输出一份有序的步骤列表。这一步只做规划不做任何实际执行LLM 的全部注意力集中在「想清楚要做什么」上。比如你说「帮我做一份 AI 行业调研报告」规划模块可能会输出这样的计划先调研行业现状和市场规模再分析头部公司的产品和策略接着梳理技术趋势和发展方向然后汇总写结论和建议最后排版润色输出成品。每一步都有明确的目标但不开始干活。第二阶段叫「执行」相当于各部门按照项目经理的分工开始干活。拿着规划好的步骤列表逐步执行每个步骤每一步都要把前面所有步骤的结果作为 context 传进去LLM 始终知道整件事做到哪里了不会「失忆」。这个阶段的关键是每一步只聚焦于自己的任务不会像 ReAct 那样走着走着就被岔路吸引走了。第三阶段叫「汇总」就像项目验收会。所有步骤跑完之后把各步骤的产出整合在一起生成最终输出。这一步的作用不仅是拼接还要解决各步骤之间的衔接问题确保最终输出是一个连贯的整体而不是几段互不相关的内容生硬地拼在一起。动态拆分的优势是灵活性强LLM 可以根据具体任务的特点制定最合适的计划劣势是规划质量不稳定规划一旦出了问题后续所有执行步骤都建立在错误的基础上。步骤拆好之后还有一件重要的事分析步骤之间的依赖关系。有些步骤必须等前一步完成才能开始有些步骤之间没有依赖可以同时进行。识别出可以并行的步骤是降低总耗时的关键。用厨师做饭来建立直觉。你要同时处理三件事烧水、切菜、腌肉。如果傻傻地串行等水烧开了再切菜切完菜再腌肉总时间是三件事之和。但一个有经验的厨师会这样先烧水烧水的同时切菜腌肉水开了三件事都好了直接下锅。总时间由「最长的那条路径」决定也就是烧水的时间因为切菜和腌肉都在等水开的过程中完成了。并行执行降低的不是「每步的时间」而是「关键路径的总时间」。回到 Agent 的场景假设你有步骤 1、2、3、4其中步骤 3 依赖步骤 1 的结果步骤 4 依赖步骤 2 和步骤 3import asyncio async def execute_parallel_steps(independent_steps: list): # asyncio.gather 让多个步骤同时开始执行不等某一个完成再启动下一个 # 这就像厨师烧水的同时切菜两件事并发进行 tasks [execute_step_async(step) for step in independent_steps] results await asyncio.gather(*tasks) # 等所有并发步骤都完成一起拿结果 return results 依赖图步骤 1 和步骤 2 相互独立可以并行 步骤 3 需要步骤 1 的结果才能开始 步骤 4 需要步骤 2 和步骤 3 都完成才能开始 步骤1 ──────────────┐ ├── 步骤3 ──┐ 步骤2 ──────────────┘ ├── 步骤4最终输出 └────────────────────── ┘如果这四步全部串行总时间是四步之和。识别出依赖关系并行执行后关键路径变成「步骤1/2并行- 步骤3 - 步骤4」假设每步各需要 3 秒串行是 12 秒并行之后是 9 秒。步骤越多、可并行的越多节省的时间越可观实际项目里降低 40% 到 60% 的端到端延迟是很常见的数字前提是任务本身的依赖关系稀疏、工具 I/O 占主要耗时如果所有步骤都强依赖上一步并行空间基本为零优化效果也就无从谈起。要让并行真正落地前提是先把依赖关系画成一张有向无环图DAG每个节点是一个步骤边表示「依赖」。没有依赖的节点就能同时跑依赖它们的节点要等父节点完成。这一步做得对不对直接决定了并行优化的天花板。任务不是拆得越细越好粒度的把握很重要。拆太细有两个代价步骤越多LLM 调用次数越多总 token 消耗上升步骤太碎每步只做一件极小的事LLM 看不到全局产出的各部分也容易衔接生硬。但拆太粗又回到了原来的问题每步负责的事太多出错概率上升出了问题也无法定位是哪一步的责任。实践中通常把「原子操作」作为划分单步的标准这个步骤只做一件独立的事边界清晰做完有明确的输出和其他步骤不互相依赖。具体举例感受一下区别。「搜索竞品 A 的产品信息」是原子的只做一件事搜索有明确的输入和输出做完就完了。「整理竞品分析」不是原子的它包含了搜索信息、筛选关键点、格式化输出三件事还没开始就已经有三个子任务了。判断一个步骤是不是原子的有一个简单方法你能给它写一个清晰的函数签名吗能的话它大概是原子的如果你发现函数里还要分好几个阶段、处理好几类情况那大概需要再拆。自适应拆分-做不好就继续拆前面讲的静态拆分和动态拆分都有一个隐含的假设拆分在任务开始时就一次性完成了执行过程中不会再调整拆分粒度。但实际项目中经常遇到这样的情况你提前拆好了三步执行到第二步时发现这一步比预想的复杂得多LLM 一次做不好需要再拆细一些。或者反过来某一步其实很简单拆得太细反而浪费了调用次数。更好的做法是不要在开始时就把所有步骤的粒度定死而是在执行过程中根据每一步的实际难度动态调整。核心逻辑很简单先让执行器尝试完成当前任务如果做得好就继续往下走不做多余的拆分如果明显做不好比如超过了最大步数还没完成或者输出质量不达标就把这个「做不好的任务」交给规划器让规划器把它进一步拆成更小的子任务然后对每个子任务重复同样的流程先试做不好就再拆。用一个生活中的例子来感受。假设你让 Agent 完成「帮我做一份完整的竞品分析报告」。执行器直接尝试一口气写完发现质量很差数据不准、结构混乱。于是规划器介入把任务拆成三步先「搜集各竞品的核心数据」再「做功能对比分析」最后「写总结和建议」。执行器尝试「搜集各竞品的核心数据」发现竞品太多一次搜不完质量还是不行。规划器再次介入把「搜集数据」进一步拆成「搜集竞品 A 的数据」「搜集竞品 B 的数据」「搜集竞品 C 的数据」。这一次每一步都足够简单执行器可以顺利完成了。整个过程就像一棵递归展开的任务树只有真正做不好的节点才会被继续拆分简单的节点一步到位。这个思路有一个很巧妙的特性任务越复杂递归拆分的层数就越深任务越简单可能一层都不拆。计算开销是和任务的实际难度成正比的而不是一刀切地对所有任务都做同样深度的拆分。执行中的 Replan 机制拆分完成只是第一步执行过程中还有一个经常被忽略的关键环节计划需不需要调整前面讲并行优化的时候隐含了一个前提计划一旦定好就按部就班执行。但现实中步骤的执行结果经常会让原来的计划变得不合理。比如你规划了「先查竞品 A 的定价再查竞品 B 的定价最后做对比分析」执行第一步时发现竞品 A 已经停止运营了那后面的对比分析就没意义了整个计划需要重新调整。Replan 机制就是在每个步骤执行完之后把当前步骤的结果和剩余的计划一起交给规划模块让它判断「基于当前的新信息后面的计划还合理吗」。如果合理就继续执行如果不合理就生成一份新的剩余步骤计划。这个机制保证了计划始终和实际情况同步不会出现「死守一份过时计划」的尴尬。代价是每步都多了一次「评估计划」的 LLM 调用token 消耗会增加。实践中的折中做法是不是每步都触发 Replan而是设置触发条件比如当某步的输出和预期差异很大时或者当步骤执行失败时才启动 Replan。这样既能应对意外又不会无谓地增加消耗。拆分结果的验证标准拆完步骤之后怎么判断拆得好不好靠感觉是不行的需要有明确的验证标准。一个好的拆分结果应该满足三个条件。第一个是「完备性」也就是所有步骤加在一起能不能覆盖原始任务的全部要求有没有遗漏。比如用户说「帮我写一份竞品分析报告包含市场份额、产品功能对比和定价策略三个维度」你拆出来的步骤里必须每个维度都有对应的步骤在负责少了任何一个都算拆分不完备。检查方法很直接把所有步骤的描述拼在一起和原始任务描述做逐项对照看有没有某个要求在任何步骤里都没被提到。第二个是「独立性」也就是每个步骤的职责边界是不是清晰有没有两个步骤在做同一件事或者某个步骤的输出和另一个步骤的输出有重叠。举个反面例子步骤 2 是「搜索竞品 A 的产品功能」步骤 3 是「分析竞品 A 的核心能力」这两步的边界就很模糊「产品功能」和「核心能力」大概率会搜到同样的内容导致重复劳动。更好的拆法是步骤 2 只负责「搜索竞品 A 的全部信息」步骤 3 负责「从搜索结果中提炼功能对比表」一个负责搜集一个负责加工各管各的。职责重叠不仅浪费 token还容易导致最终汇总时出现矛盾比如两个步骤对同一个功能给出了不一样的评价。第三个是「可验证性」也就是每个步骤执行完之后能不能用一个简单的标准判断它做对了没有。这一点在实际项目中特别容易被忽视但它直接决定了你能不能做自动重试和质量把控。比如你拆了一个步骤叫「搜索竞品 A 的定价信息」如果没有完成标准执行完之后你只能人工看一眼判断做得好不好。但如果你在拆分时就定义了「输出中必须包含价格数字和计费模式按量/包月/免费增值」执行完之后自动检查输出是否包含这两个要素就行了缺了就自动触发重试。好的做法是在拆分每个步骤时同时写好它的「验收标准」就像写单元测试的断言一样步骤定义和验收标准成对出现。 面试总结回答任务拆分这道题要答出三个层次才完整。第一层是「为什么拆」LLM 的 context window 有上限任务越大中间状态越多、越容易出错而且拆开后每步可以独立验证和重试。第二层是「怎么拆」静态拆分适合流程固定的场景直接写死步骤动态拆分用 Plan-and-Execute 让 LLM 自己规划灵活但规划质量不稳定。第三层是「拆完还要做的事」分析步骤依赖关系把能并行的步骤并发跑关键路径时间可以降 40% 到 60%。最后再补一句「粒度把握很重要以原子操作为标准既不能太细也不能太粗」这道题就回答得很漂亮了。