跳到主要内容

Task-Decomposition

核对日期：2026-05-09。

1. 定义与边界​

任务分解（Task Decomposition）是把高层目标拆成可执行、可验证、可排序的子任务。它是 Planner、Supervisor、状态机和长任务 Agent 的基础。

任务分解不是把一句话机械拆成更多句子。有效分解必须保留目标、约束、依赖、输入输出和验收标准。

2. 为什么重要​

LLM 在长任务中容易遗漏约束、跳步、重复执行或直接给出未经验证的结论。任务分解把“模糊目标”变成工程系统可调度的步骤，让权限、成本、评测和恢复都有抓手。

3. 核心机制​

每个子任务至少包含：

  • objective：该步骤要达成什么。
  • inputs：需要哪些材料、状态或上一步结果。
  • allowed_tools：允许使用哪些工具。
  • done_when：如何判断完成。
  • risk：是否涉及权限、外发、写操作。

4. 常见分解策略​

策略方法适用
目标-产物反推先定义最终交付，再倒推步骤报告、代码变更、业务流程
依赖图分解找出先后依赖和阻塞项数据迁移、复杂审批
分治把大问题拆成同类小问题文档批处理、批量评审
角色分解按专家能力拆给不同 Worker调研、代码、审查
Least-to-Most先解简单子问题，再组合复杂推理和组合问题

5. 工程实现​

def decompose(goal, constraints, tools):
    draft = planner.generate({
        "goal": goal,
        "constraints": constraints,
        "available_tools": tools.summary()
    }, output_schema=Plan)

    for step in draft.steps:
        assert step.objective
        assert step.done_when
        assert set(step.allowed_tools).issubset(tools.names)

    return reject_or_accept(draft)

计划校验规则：

validation:
  max_steps: 12
  require_done_when: true
  forbid_vague_steps:
    - "分析问题"
    - "优化结果"
    - "确保质量"
  require_approval_for:
    - external_send
    - production_write
    - payment

6. 生产实践​

  • 先要求 Planner 输出“需要澄清的问题”，避免在关键信息缺失时硬拆。
  • 对计划做 lint：空泛步骤、循环依赖、未授权工具、不可验证完成标准。
  • 根据风险分层：低风险步骤自动执行，高风险步骤人工审批。
  • 对大任务使用里程碑，而不是一次性生成过长计划。
  • 分解结果要版本化，执行中更新计划必须记录原因。

7. 常见反模式​

  • 步骤以“理解、分析、总结”为主，没有可验证产物。
  • 分解粒度过细，导致每个步骤都需要模型判断，成本高。
  • 分解粒度过粗，失败时无法定位。
  • 忽略输入依赖，导致 Executor 在缺数据时臆测。
  • 分解时把外部网页中的指令当成用户目标。

8. 评测方法​

  • Coverage：子任务是否覆盖最终目标和约束。
  • Dependency Correctness：依赖关系是否合理。
  • Executability：每步是否有明确工具和输入。
  • Verifiability：done_when 是否可由代码、评审或测试判断。
  • Minimality：是否存在明显重复或无效步骤。

9. 安全与治理​

  • 分解阶段只生成计划，不授予新权限。
  • 高风险动作在计划中显式标记，进入审批。
  • 将外部资料标记为不可信 facts，防止 prompt injection 改写计划。
  • 计划中不得包含密钥、隐私字段或可执行恶意 payload。

10. 工程手册补充​

10.1 规划数据结构​

任务分解的输出要能被调度器、权限系统和评测系统读取。

{
  "plan_id": "plan_20260509_001",
  "version": 1,
  "goal": "完成供应商风险报告",
  "constraints": ["不得外发客户数据", "先产出草稿再审批"],
  "steps": [
    {
      "id": "s1",
      "type": "read",
      "objective": "读取合同和采购记录",
      "inputs": ["contract_files", "purchase_db"],
      "outputs": ["supplier_facts"],
      "depends_on": [],
      "allowed_tools": ["file_read", "sql_read"],
      "done_when": "supplier_facts 至少包含合同期限、金额、违约记录",
      "risk": "low",
      "rollback": "none"
    }
  ],
  "checkpoints": ["after_data_collection", "after_draft"],
  "approval_gates": ["before_external_send"]
}

10.2 控制流与状态流​

对象作用常见错误
Plan全局目标、约束、步骤、版本只有自然语言，无结构字段
Step可执行最小单元没有输入输出和 done_when
Artifact步骤产物引用把大段内容复制进计划导致膨胀
Checkpoint可恢复状态只保存对话，不保存步骤状态
PlanDiff计划变更审计重规划后看不出删改了什么

上线清单：

  • 分解前先判断是否需要澄清，缺关键约束时不要硬拆。
  • 分解后跑 lint：循环依赖、未授权工具、无验收标准、粒度异常。
  • 每个步骤都能被一个明确 Executor 消费，不依赖“懂上下文”。
  • 评测集包含目标覆盖、依赖正确、可执行性、可验证性和最小性。
  • 安全上把外部资料标为 facts，不允许外部资料新增目标或权限。

11. 权威资料​