Agent 如何进行任务拆解？

简化版

Agent 任务拆解，是把模糊目标转成一组有输入、输出、依赖和验收条件的可执行子任务。好的拆解不追求步骤越多越好，而要让每一步都能调用现有工具、独立验证，并把有依赖的任务串行、无依赖的任务并行；执行中若观察结果改变前提，还要局部重规划，而不是从头生成一份新计划。

详细版

可以按“目标澄清—约束提取—产物倒推—依赖排序—验收定义”拆解。先确定最终交付物和禁止事项，再从交付物反推所需中间产物，把每个子任务写成 输入 + 动作 + 输出 + 完成条件。随后构造依赖图，拓扑排序出执行顺序，并标记可并行节点、风险节点与人工确认点。

目标：发布一篇竞品分析
  ├─ A 收集官方资料 ─┐
  ├─ B 收集价格数据 ─┼─> D 对比分析 -> E 事实核验 -> F 发布
  └─ C 定义评价维度 ─┘

执行器每完成一步都把结构化结果写回状态，验证器检查产物，而不是相信模型声称完成。若 B 缺少某产品价格，只重规划 B 及其下游 D、E；已通过验证的 A、C 不重复执行。还要限制最大深度、子任务数、预算和副作用，防止过度拆解与计划无限膨胀。

完整版教学

一、拆解解决的是可执行性，不是排版

用户目标常是“帮我做一个市场调研”或“修好这个项目”，其中没有说明范围、数据源、产物格式和成功标准。模型直接行动容易边搜边猜，最后堆出很多材料却无法判断任务是否完成。

拆解的价值是把目标变成系统能调度和验证的工作单元。编号列表只是表现形式；真正的子任务必须知道需要什么输入、调用什么能力、产生什么产物，以及怎样证明产物合格。

记忆钩子：任务拆解不是把一句话切成十句话，而是把“不可验收的愿望”变成“可执行、可依赖、可验收的节点”。

二、先澄清目标和硬约束

同一句“整理会议内容”，可能要逐字稿、决策摘要或待办清单。拆解前要识别最终产物、受众、截止时间、可用数据、费用上限和禁止操作；缺少会显著改变计划的信息，应先向用户澄清。

可以用一个目标契约保存：

{
  "deliverable": "三页中文竞品分析",
  "must_cover": ["价格", "核心功能", "证据链接"],
  "deadline": "17:00",
  "constraints": ["只用官方来源", "不得发布"]
}

“不得发布”必须进入执行层权限，而不能只留在自然语言计划里。否则后续模型即使忘记约束，工具网关仍能拦住发布动作。

三、从交付物向前倒推

从第一步顺推，模型容易列出熟悉但无用的动作；从最终产物倒推，会迫使计划说明每个字段由哪里来。竞品表需要价格、功能和证据，因此必须先有数据收集与来源校验；结论依赖对比表，因此分析不能跑在采集之前。

每个节点可采用以下契约：

Task = {
  id, objective, inputs, tool,
  expected_output, acceptance_criteria, dependencies
}

若一个节点无法写出 expected_output，它通常仍然太模糊；若验收条件要靠“看起来不错”，则验证性不足，需要继续细化。

四、用依赖图代替死板步骤表

线性计划会把本可并行的任务排成长队。依赖图中，只有读取前序产物的节点才连边；没有路径依赖的资料采集可并行执行，汇总节点等待所需输入齐全后再启动。

假设 A、B、C 各耗时 8、10、6 分钟，D 耗时 5 分钟。全部串行要 8+10+6+5=29 分钟；前三项并行后，关键路径约为 max(8,10,6)+5=15 分钟。但并行会增加并发调用和限流压力，所以调度器还要受最大并发数约束。

关系	调度方式	例子
数据依赖	串行	先取数据，再计算指标
无依赖	可并行	同时查询三个独立来源
共享写入	串行或加锁	多任务更新同一文档
高风险动作	等待确认	发布、付款、删除

五、粒度要与工具能力匹配

“完成整个调研”太粗，失败后不知道卡在哪里；“打开页面、读第一行、读第二行”又太细，会让模型调用次数和上下文快速膨胀。合理粒度是一次工具调用或一个短工作流能稳定完成，并能产生独立可验收的产物。

如果搜索工具一次能返回带来源的结构化结果，“收集某产品官方价格与版本”就是合适节点。若浏览器工具不支持动态登录，该节点必须进一步拆成获取凭证、人工授权和页面读取，而不是假定工具能完成。

粒度还影响重试范围。节点越大，部分失败时重复成本越高；节点越小，编排成本越高。应通过历史成功率、平均耗时和失败恢复成本寻找平衡。

六、验收条件要先于执行定义

计划阶段就写验收条件，可以防止模型事后降低标准。采集节点的条件可能是“每个价格都带官方 URL 和抓取时间”；代码节点可能是“指定测试通过且无范围外文件变化”。

验收最好由确定性代码或独立证据完成。URL 可检查域名和状态码，JSON 可用 Schema，数值可检查范围，代码可跑测试。开放式文章仍可用检查表和人工审核，而不是让原生成模型自评满分。

若 20 个节点各自成功率都是 95%，全部一次成功的粗略概率只有：

0.95 ^ 20 ≈ 35.8%

这说明过度拆解也会积累失败面；关键节点要有重试、替代路径或人工接管。

七、重规划应该局部且保留证据

静态计划无法预见工具超时、数据缺失和用户变更。观察与预期不符时，先判断受影响的节点集合，只使其及下游结果失效；已验证且前提未变的节点继续复用。

例如价格采集 B 失败，依赖 B 的对比 D 和核验 E 需要暂停，但独立的功能采集 A 不应重跑。调度器可记录产物版本和依赖哈希：只有输入版本变化，节点才重新执行。

重规划还要设次数与预算上限。连续两次替代数据源仍失败时，应询问用户是否接受缺失项，而不是让模型无休止搜索。

八、用计划质量指标发现假拆解

评估不应只看最终任务成功率。还要看计划有效率、无用节点比例、依赖错误数、并行收益、重规划次数、重复工具调用率以及验收失败集中在哪类节点。

可以准备 100 个任务，人工标注必需产物和关键依赖。若 Agent 平均生成 12 个节点，其中 3 个对最终结果没有贡献，无用节点率就是 25%。减少这些节点通常比提升单次模型能力更直接地降低成本和延迟。

线上 Trace 应能从最终结论追溯到产物、任务节点和工具证据。没有这条链路，拆解只是模型内部叙述，故障时无法定位。

九、常见误区与追问

误区：步骤列得越细，计划越专业。 过细会增加调用、状态和失败面，粒度应匹配工具的原子能力。
误区：计划生成后就应严格照做。 外部信息会变化，需要基于观察局部重规划。
误区：无依赖节点全部并行最快。 还要考虑限流、费用和共享资源冲突。
误区：子任务完成由模型自己判断即可。 完成条件应绑定产物、测试或外部证据。
误区：失败后重新生成整份计划最干净。 这会丢失已验证成果并重复副作用。
追问：什么时候需要用户澄清？ 缺失信息会改变交付物、权限、风险或主要路径时，应在执行前询问。
追问：如何防止任务树无限展开？ 限制深度、节点数和预算，并要求每个子节点直接贡献于父节点验收条件。
追问：怎样支持并行执行？ 建 DAG、做拓扑调度，并为共享写操作增加锁或汇总节点。

十、加强记忆

任务拆解记住“契约、倒推、依赖、验收、重规划”：先用目标契约固定交付物和边界，从产物倒推必要节点；每个节点写清输入、动作、输出和验收，再用 DAG 区分串行与并行。执行结果改变前提时，只重规划受影响的下游，并保留已验证产物。好的拆解让系统知道下一步做什么、何时算完成、失败后从哪里继续，而不是单纯生成一张很长的待办清单。

简化版

详细版