大模型不是万能工作台。复杂任务如果一次性塞进去，模型会在搜索、分析、写作、校验之间来回跳，最后输出看似完整，实际经不起检查。任务拆分要解决的，就是让 Agent 每一步只专注一件事。

如果把 Agent 比作一个会干活的助理，任务拆分就是给它安排工作的方法。真正难的不是“让模型多想几步”，而是把一个复杂目标拆成一组可执行、可验证、可重试的小任务，并且知道哪些可以并行，哪些必须等待。

这一章的重点不是堆概念，而是回答三个工程问题：为什么拆分能提高质量？任务应该怎么拆？拆完之后如何调度、校验和重规划？

一、为什么任务要拆分？核心是降低上下文混乱

很多人第一次做 Agent，会把需求直接丢给大模型：帮我写一份竞品分析报告、帮我做一次代码改造、帮我生成一套旅游攻略。模型确实能给出结果，但问题也很明显：内容看着长，结构却容易散；前面查到的数据，后面可能忘；中间某一步错了，也不知道从哪里开始修。

原因并不玄学。LLM 的上下文窗口再大，也不是无限工作台。任务越复杂，中间状态越多：搜索结果、临时判断、待验证事实、半成品段落、工具返回值都会堆在一起。模型要同时记住“当前在做什么”“前面做过什么”“最终要交付什么”，出错概率自然会上升。

任务拆分的价值，就是把“一个难以控制的大动作”变成“一串可管理的小动作”。每一步只负责一个目标，输入和输出更清楚，失败后也能只重试失败步骤，而不是从头再跑一遍。

拆分不是为了让流程看起来复杂，而是为了让模型的注意力更干净，让工程系统更可控。

二、任务拆分的本质：把需求变成可执行函数

大目标要拆成输入清楚、输出清楚、边界清楚的小任务

好的任务拆分，有点像写函数。一个函数不应该又查数据库、又做业务判断、又发消息、又拼页面；一个 Agent 子任务也不应该同时搜索、分析、写作、校验。

判断一个步骤拆得是否合理，可以看它能不能写成一个清晰的函数签名。比如“搜索竞品 A 的定价信息”就比较清楚：输入是竞品名称，输出是价格、计费模式、来源链接；而“整理竞品分析”就太大了，它里面至少包含搜索、筛选、分析、写作几件事。

所以，任务拆分不是简单把一句话切成几段，而是要给每个步骤明确三件事：输入是什么，输出是什么，验收标准是什么。

三、两种拆法：静态拆分和动态拆分

静态拆分和动态拆分的核心区别

静态拆分，是开发者提前把流程写死。比如技术文章生成可以固定成：资料检索 -> 大纲生成 -> 正文写作 -> 图片生成 -> 校验润色。这类流程稳定、可预测、好监控，适合生产系统里的高频任务。

动态拆分，是让 LLM 先当一次“项目经理”，根据目标生成计划，再按计划执行。它适合任务形态变化大、路径不确定的场景，比如复杂研究、需求分析、故障排查。

两种方式没有谁绝对更好。工程里常见做法是：主流程用静态 Workflow 控住边界，局部复杂环节再交给 LLM 动态规划。这样既有稳定性，也保留灵活性。

这里还要区分 CoT、ToT 和 Agent 任务拆分。CoT 更像模型在一次回答里展开推理；ToT 会探索多条思路再选择；而 Agent 任务拆分通常会产生独立步骤、工具调用、状态记录、校验和重试。它不是单纯“想得更长”，而是“把执行过程工程化”。

四、动态拆分常用范式：Plan-and-Execute

Plan-and-Execute 的核心思想很朴素：先别急着干活，先把计划想清楚。它通常分成三段。

第一段：规划。Planner 只负责拆任务，不做实际执行，输出步骤列表、依赖关系和验收标准。

第二段：执行。Executor 按步骤逐个执行，每一步只聚焦自己的小目标。

第三段：汇总。Aggregator 把各步骤产出整合成最终交付物，处理衔接和一致性。

Plan-and-Solve Prompting 的研究思路也是先把复杂问题拆成子任务，再按照计划执行；这类方法的意义在于减少遗漏步骤、语义误解和推理断层。放到 Agent 工程里，它对应的就是“先规划，再执行，再汇总”。

一个简单的步骤结构可以这样定义：

from typing import TypedDict, Literal, list

class TaskStep(TypedDict):

id: str

goal: str # 这个步骤只完成什么目标

input_keys: list[str] # 依赖哪些上游结果

output_schema: dict # 输出字段结构

acceptance: list[str] # 验收标准

mode: Literal["llm", "tool", "human"]

注意：这里的重点不是代码本身，而是让每个步骤“像接口一样清楚”。接口清楚了，后面才方便调度、校验、重试和追踪。

五、拆完还不够：要把依赖关系画成 DAG

识别依赖后，可并行步骤可以同时跑，端到端耗时由关键路径决定

任务拆完之后，下一步不是立刻从头跑到尾，而是先看依赖关系。有些步骤必须等上一步结果，比如“写总结”必须等“分析结果”出来；有些步骤互不依赖，比如“查竞品 A”“查竞品 B”“查竞品 C”，完全可以并发执行。

这就是 DAG，有向无环图。节点是步骤，边是依赖。没有依赖的节点可以一起启动；有依赖的节点必须等父节点完成。

并行优化降低的不是单个步骤耗时，而是关键路径长度。比如每步 3 秒，四步串行是 12 秒；如果步骤 1 和步骤 2 可以并行，总耗时可能变成 9 秒。步骤越多、依赖越稀疏，并行空间越大。

import asyncio

async def execute_parallel_steps(independent_steps: list):

# 多个互不依赖的步骤可以同时启动

tasks = [execute_step_async(step) for step in independent_steps]

results = await asyncio.gather(*tasks)

return results

如果要做得更工程化，可以做一个简单的 DAG 调度器：每次找出所有依赖已完成的节点，并发执行；执行完成后再更新依赖状态。

async def run_dag(steps, dependencies):

finished = set()

results = {}

while len(finished) < len(steps):

ready = [

step for step in steps

if step.id not in finished

and all(dep in finished for dep in dependencies[step.id])

]

if not ready:

raise RuntimeError("DAG has cycle or missing dependency")

batch_results = await asyncio.gather(

*[execute_step_async(step) for step in ready]

)

for step, result in zip(ready, batch_results):

results[step.id] = result

finished.add(step.id)

return results

六、拆分粒度：不是越细越好

粒度太粗会混乱，粒度太细会浪费，原子任务才是合适边界

很多人以为任务拆得越细越好，其实不是。拆太粗，模型每步负担太大，还是会出错；拆太细，调用次数增加，token 成本上升，结果还容易割裂。

比较实用的标准是“原子操作”：一个步骤只做一件独立的事，做完能产出明确结果，且可以独立校验。

太粗：整理竞品分析。这个步骤里混着搜索、筛选、分析、写作。

合适：搜索竞品 A 的定价信息。输入是竞品名称，输出是价格字段和来源。

太细：把第一段改短、把标题加粗。这类任务通常不值得单独调用一次模型。

一个简单判断方法：如果你能给它写出清晰函数签名，它大概率是合适的原子任务；如果函数内部还要拆出多阶段，那就应该继续拆。

七、自适应拆分：做不好就继续拆

静态拆分和动态拆分都有一个隐含假设：一开始就能把任务拆好。但真实项目里经常不是这样。某一步看起来简单，执行时才发现很复杂；某一步原本拆得很细，执行时又发现其实一步就够。

更好的方式是自适应拆分：先让执行器尝试做当前任务，如果结果合格，就不继续拆；如果失败、超时、超过最大重试次数、输出质量不达标，再交给规划器把这个失败节点继续拆细。

ADaPT 这类思路强调“as-needed decomposition”：只有当执行器无法直接完成任务时，才让规划器介入拆成更小的子任务。它的好处是不会对所有任务一刀切地过度拆分，成本和复杂度更接近任务真实难度。

async def adaptive_solve(task, depth=0, max_depth=3):

result = await executor.try_run(task)

if verifier.pass_(result):

return result

if depth >= max_depth:

raise RuntimeError("task failed and max depth reached")

sub_tasks = await planner.decompose(task, failure=result.error)

sub_results = []

for sub_task in sub_tasks:

sub_results.append(

await adaptive_solve(sub_task, depth + 1, max_depth)

)

return await aggregator.merge(sub_results)

八、Replan：计划需要跟着现实变化

任务拆分完成后，计划也不是一成不变的。比如计划里写“先查竞品 A 的价格，再和竞品 B 对比”，结果第一步发现竞品 A 已经停止服务。这时候继续执行原计划就没有意义了。

Replan 的做法是：每一步执行后，基于当前结果和剩余计划，判断后续计划是否仍然合理。如果合理就继续；如果不合理，就只重写剩余计划，而不是推翻所有已完成步骤。

不过 Replan 也有成本。每次评估计划都要增加 LLM 调用，所以不要每一步都触发。更推荐设置触发条件：步骤失败、输出与预期差异很大、新约束出现、置信度过低、工具返回异常。

工程上可以给每个计划版本打上 plan_version，方便回溯为什么改计划、改了哪些步骤、旧计划从哪一步开始失效。

九、拆分结果怎么验收？看三个指标

任务拆分最怕凭感觉。一个看起来很细的计划，可能漏掉关键要求；一个看起来很完整的计划，可能步骤之间互相重叠。真正可落地的拆分结果，至少要过三关。

第一，完备性。所有步骤加起来，是否覆盖了用户的全部要求。比如用户要求市场份额、产品功能、定价策略，步骤里就不能只查功能不查价格。

第二，独立性。每个步骤职责是否清楚，是否重复劳动。比如“搜索产品功能”和“分析核心能力”边界很容易重叠，更好的拆法是“搜集原始资料”和“从资料中提炼功能表”。

第三，可验证性。每个步骤执行后，能不能自动判断是否合格。比如“搜索定价信息”的验收标准可以是：必须包含价格数字、计费模式、来源链接和更新时间。缺任一项，就自动重试或转人工。

def verify_price_step(output: dict) -> bool:

required = ["price", "billing_mode", "source_url", "updated_at"]

return all(output.get(key) for key in required)

十、生产级落地：把拆分做成系统能力

产级任务拆分系统需要规划、依赖分析、调度、执行、验收和追踪

如果只是写一个 Prompt，让模型“请把任务拆成几步”，这还不能算生产级任务拆分。真正能上线的 Agent，要把拆分做成系统能力。

Planner：生成步骤、输出结构、依赖关系、验收标准。

DAG Builder：把步骤转成依赖图，识别可并行节点。

Scheduler：控制串行、并行、超时、重试和最大深度。

Executor Pool：调用 LLM、搜索、数据库、业务工具或人工节点。

Verifier：检查格式、字段、证据、置信度，决定是否重试。

Aggregator：把多个步骤结果合并成最终答案，处理冲突和衔接。

Trace Store：记录计划版本、每步输入输出、工具结果、token 成本和失败原因。

Anthropic 在 Agent 工程实践里也强调，优先使用简单、可组合的模式；只有在任务复杂度确实需要时，才逐步增加 Agent 自主性。LangGraph 这类框架则把 Agent 流程建模成图：节点负责执行，边负责决定下一步，状态贯穿整个图，这非常适合表达任务拆分、并行执行和 Replan。

十一、可复用的拆分模板

当你要在项目里设计一个复杂 Agent，可以直接按下面这个模板走。

TaskSplitTemplate = {

"task": "用户原始目标",

"steps": [

{

"id": "step_1",

"goal": "这个步骤只完成什么",

"depends_on": [],

"input": "需要哪些上游信息",

"output": "输出什么结构",

"acceptance": ["验收标准1", "验收标准2"],

"retry_policy": "失败后如何重试",

"replan_trigger": "什么情况下需要重规划"

}

]

}

真正好用的任务拆分，不是把步骤写得很多，而是让每一步都能被执行、被检查、被重试。

十二、总结

第一，为什么拆：降低上下文混乱，让模型每步只专注一个目标。

第二，怎么拆：稳定流程用静态拆分，不确定任务用动态拆分，复杂节点用自适应拆分。

第三，怎么跑：把步骤画成 DAG，识别可并行节点，缩短关键路径。

第四，怎么控：给每个步骤写验收标准，失败可重试，异常可 Replan，全链路可追踪。

任务拆分不是 Agent 的“提示词技巧”，而是复杂 Agent 从 demo 走向生产的调度系统。