4.1 任务分解：把一句话需求拆成可执行步骤

4.1 任务分解：把一句话需求拆成可执行步骤

本节摘要：任务分解是规划的第一动作：把笼统目标拆成粒度均匀、依赖明确、每步可验证的步骤序列。本节给出分解的三条原则、一份直接可用的分解提示词与 JSON 计划结构，并用一个周报任务演示"拆得好"与"拆得糊"的差别。

为什么不能把大目标直接丢给 ReAct 循环硬啃？因为模型在单步决策上很强，在"边跑十步边记住全局"上很弱。分解的本质是把对全局的记忆负担，前置转换成一张静态清单——清单一旦写定，循环每次只需看"当前步骤是什么、上一步结果如何"，工作记忆的压力骤降。分解质量因此直接决定任务上限：拆得糊，后面每一步都在为前面的含糊买单。

分解三原则

粒度均匀，落在工具调用上。每一步应当对应"一次工具调用加一次判断"，明显大于这个粒度（"整理数据"）模型不知道从哪下手，明显小于（"点击确认按钮"）清单会膨胀到几十步，互相之间全是噪声。判断口径：这一步写完，执行器能立刻说出调哪个工具、参数从哪来。

依赖显式化。哪些步骤必须等哪些步骤完成，要在结构里写明，而不是靠"按顺序排"暗示。显式依赖带来两个红利：无依赖的步骤可以并行执行（省时间）；某步失败时，能精确圈定受影响的下游范围（省重排）。

每步可验证。步骤的完成标志要能被程序或模型判断（"返回 200""文件存在""摘要覆盖全部五个章节"）。不可验证的步骤（"充分理解数据"）等于给执行挖坑——没人说得清它做没做完，失败也就无从谈起。

分解提示词与计划结构

DECOMPOSE_PROMPT = """你是任务规划器。把目标拆解为可执行步骤，遵守：
1. 每步对应一次工具调用，粒度均匀，动词开头。
2. 标明依赖：depends_on 填前置步骤编号；无依赖写空数组。
3. 每步给出 verify：程序或模型可判断的完成标志。
4. 不确定的步骤标 need_clarify: true，先问用户再执行。

可用工具：
{tool_list}

已知背景（来自记忆检索）：
{memory_context}

用户目标：{goal}

只输出 JSON：
{{"steps": [
    {{"id": 1, "action": "...", "tool": "...", "args_hint": "...",
      "depends_on": [], "verify": "...", "need_clarify": false}}
]}}"""
​

分解产出的 JSON 计划，是后续执行的唯一事实源：

{
  "steps": [
    {"id": 1, "action": "读取本周全部会议纪要", "tool": "list_docs",
     "args_hint": {"folder": "/会议纪要", "date_range": "本周"},
     "depends_on": [], "verify": "返回文档数与日历会议数一致",
     "need_clarify": false},
    {"id": 2, "action": "提取每篇纪要的决议与待办", "tool": "extract_items",
     "args_hint": {}, "depends_on": [1],
     "verify": "每篇纪要至少产出一条决议或待办"},
    {"id": 3, "action": "汇总本周进展与下周计划", "tool": "draft_report",
     "args_hint": {"format": "团队周报模板"}, "depends_on": [2],
     "verify": "覆盖全部决议，含进展、风险、下周计划三节"},
    {"id": 4, "action": "发送周报给团队邮箱组", "tool": "send_mail",
     "args_hint": {"to": "team@example.internal"}, "depends_on": [3],
     "verify": "SMTP 返回发送成功"}
  ]
}
​

注意第 4 步——对外发送类动作在计划里就该标记为高风险位，执行时接人工确认（第 7 章的介入点），拆解阶段就把它暴露出来，比上线后再补防线容易得多。

案例：拆得糊与拆得好的一次对照

背景：同一个目标"整理这周会议纪要并发出周报"，两个版本的分解。

糊版：三步——"收集纪要""整理内容""发周报"。执行时第一块就卡住：模型面对"收集"不知道该列目录还是该读日历，索性把搜索框里能找到的旧纪要一并抓来；"整理内容"一步吞掉了提取、汇总、排版三件事，观察窗口瞬间被塞满；最后发送的版本漏了两个会议的内容，而且没人知道漏在哪一环。

好版：如上四步结构，每步有工具、有验证。执行到第 2 步时验证条件立刻揪出问题——第三篇纪要没有产出任何决议，模型回读原文发现它是纯讨论会，正确地将其标记为"无决议"继续推进；发送前 because 第 4 步被标记高风险，草稿先送到用户眼前过目。

解读：两版的差距不在模型能力，在计划的可核对性。糊版的每一步都无法回答"做完了吗"，于是错误静默穿透所有环节；好版的 verify 把每个环节变成关卡，错误在产生地就地暴露。

变式：目标本身含糊（"把数据弄得好看点"）时，先分解出 need_clarify 步骤——第一步不是干活，是把目标问清楚。拒绝拆解一个没说清的目标，是规划器最重要的自律。

⚠️ 常见坑：过度分解。把任务拆到二十步以上通常意味着粒度失控，每一步的判断开销叠加起来又慢又贵，而且清单越长模型越容易在中后段漏项。经验值：大多数业务任务落在五到十步；超过就考虑合并步骤或分层拆（先里程碑后步骤，见章首页的三层结构）。

本节要点回顾

• 分解是记忆卸载：把全局负担前置成静态清单，循环只需关注当前步骤与上一步结果。
• 三原则：粒度落在工具调用、依赖显式标注、每步可验证——不可验证的步骤是隐性地雷。
• 计划即事实源：JSON 结构里 id、depends_on、verify、need_clarify 四个字段缺一不可。
• 高风险步骤在计划期暴露：发送、删除、支付类动作拆出来时就该挂上人工确认标记。

分解出的是一条线性清单，但有些任务的步骤之间需要反复比较与取舍——下一节讲两种推理结构怎么选。