任务拆解
Task Decomposition——把一个大流程拆成多个有明确输入、输出和成功标准的独立节点，让 Agent 能逐个执行、逐个调试、逐个修复
简介
任务拆解（Task Decomposition）是 Agentic Workflow 落地过程中最核心、也最常被低估的能力。它的本质是把写给人看的 Human SOP，转化成 Agent 能稳定执行的独立节点序列——每个节点有清晰的输入、输出和成功标准，可以独立调试，出错时只修对应节点而不必重写整条流程。
很多人把模糊的大任务整包丢给 Agent（“帮我处理客户咨询”、“帮我优化整个销售流程”），然后期待它自己理解背景、判断边界、规划步骤。但 Agent 不知道”五百块”和”五千块”在你们公司意味着什么，不知道哪些步骤可以省、哪些不能省，遇到例外也不知道该继续还是该停下来问人。任务太大、太散、太依赖人类脑补，才是 Agent 不稳定的根因，不是模型不够聪明。
任务拆解不同于项目管理中的 WBS（工作分解结构）——WBS 分解的是”谁做什么”，任务拆解分解的是”Agent 执行什么、输入什么、输出什么、什么时候停下来问人”。它也不同于简单的 prompt chain——prompt chain 是把多个 prompt 串起来，任务拆解要求每个节点有明确的中间格式（通常是 JSON）、可独立验证的输出、以及清晰的异常处理路径。
关键信息
- 类型：概念
- 领域：Agentic Workflow / 企业 AI 落地 / 流程自动化
- 相关概念：Agentic Workflow、Skill、AI Agent 智能体、MCP 模型上下文协议、人机协同
核心特性
定义
任务拆解是把一个完整的人类业务流程，拆成多个独立的 Agent 可执行节点的过程。每个节点必须满足三个条件：
- 明确的输入：上一节点的输出或外部数据源
- 明确的输出：通常是结构化的 JSON，包含所有下游节点需要的字段
- 明确的成功标准：什么算”做对了”，什么算”需要人工介入”
四步转化方法论
从 Human SOP 到 Agentic Workflow 的标准转化路径：
第一步：格式标准化——把散文式流程改成 Agent 能理解的结构：
- 参数化：不把规则写死（如
expense_type+amount+department+approval_level的组合判断，而非”超过五千要审批”的死规则） - 规则强度分级：MUST（不能跳过）/ SHOULD（建议做）/ MAY（可做可不做）
- 结构化区块：Purpose / Trigger / Inputs / Parameters / Steps / Output / Error Handling / Human Checkpoint
第二步：任务拆解——把大流程拆成独立节点：
- 每个节点可以是小 Skill、小 Agent 或一段脚本
- 上一个节点的输出 = 下一个节点的输入（靠清楚定义的中间格式连接，不是靠模型”心有灵犀”）
- 典型拆解案例：报销审核拆成 9 个节点（提取信息→校验发票→判断费用类型→匹配制度→检查缺失→识别风险→生成结论→生成补充说明→人工确认）
第三步：双向开发——用真实执行结果反向修 SOP：
- 第一轮用自然语言告诉 Agent 审核逻辑 → Agent 写出第一版 SOP → 跑真实案例 → 出错时补规则
- 每次出错都是在挖出隐性知识（Tacit Knowledge）——“原来这条规则我没写进去”
- 迭代三五轮后 SOP 越来越稳定，不是因为第一版写得完美，而是用真实执行结果持续反向修复
第四步：接入真实工具 + 设计人工确认点：
- 接入企业微信/OA/ERP/发票识别/知识库等系统（MCP 是标准化接口协议）
- 高风险动作（大额付款、退款、管理员权限、对外承诺）必须人工确认
- 重复机械的事交给 Agent，高风险模糊的事留给人
稳定性、可观测性、可修复性
任务拆解的最终目标不是”看起来很聪明”的端到端黑箱，而是三个工程属性：
| 属性 | 含义 | 拆解前 | 拆解后 |
|---|---|---|---|
| 稳定性 | 输出结果可预期 | 整包丢给 Agent，结果随机 | 每个节点边界清晰，输出可控 |
| 可观测性 | 能看到中间过程 | 只有最终结果，过程黑箱 | 每个节点的输入输出可追踪 |
| 可修复性 | 出错时能定位修复 | 不知道哪里错了 | 意图识别错了改分类规则，回复不好改话术规范 |
常见误区
- 把 Human SOP 原封不动丢给 Agent：Human SOP 高度依赖人的隐性经验，“必要时退回补充”对人够用，对 Agent 远远不够
- 追求”一个 Agent 做所有事”：看起来合理但输出不可控——你不知道哪些判断是正确的、哪些是模型推测的、哪些本来应该由人确认
- 先花两个月写”完美 SOP”再跑：第一次写出来的 SOP 一定会漏东西。正确做法是先粗糙版本→尽快跑→用真实案例测试→发现问题就补规则
- 把所有规则写死：不参数化的 SOP 很快变成只服务某个特殊场景的长文档，看起来写了很多实际容错很低
不同素材中的观点
来自 2026-06-06-woshipm-agent-task-decomposition：
- 本文首次系统阐述了 Task Decomposition 的完整方法论——四步转化法（格式标准化→任务拆解→双向开发→接入工具+人工确认）
- 用报销审批和 AI 客服两个完整案例演示了从”一句话 SOP”到”多节点 Agentic Workflow”的转化过程
- 提出 MUST/SHOULD/MAY 规则强度分级作为 SOP 可执行化的关键工具
- 核心洞察：“Agent Workflow 不是一次性交付出来的，它是跑出来、修出来、磨出来的”
来自 2026-06-03-youtube-multi-agent-accounting-pipeline：
- Sequential Pipeline（顺序管道）是规则驱动业务的最优任务拆解架构——会计/记账的 5 个 Agent（数据准备→分类→核对→报告→洞察）恰好对应任务拆解原则：每步边界清晰、输出严格单向流入下一层
- “逐个构建、逐个测试”的 Agent 工程纪律是任务拆解的正确执行方式——不是做完所有节点再跑端到端，而是构建一个→测试→构建下一个→测试
- 数据文件夹是唯一的共享状态——节点之间不直接通信，只通过文件（中间格式）传递数据，这保证了可观测性和可修复性
实用信息
快速上手步骤
- 找一份你手上最无聊、最重复的 SOP（报销/周报/checklist/需求整理）
- 用 MUST/SHOULD/MAY 把里面的规则强度标出来
- 画出节点图：每个节点的输入是什么、输出是什么、什么时候必须问人
- 先做第一版，拿真实案例跑，出错就补规则
关键模板
SOP 标准化结构：Purpose / Trigger / Inputs / Parameters / Steps / Output / Error Handling / Human Checkpoint
节点间中间格式：上一节点输出 JSON，下一节点读取对应字段——靠格式连接，不靠模型默契
规则强度标注：MUST（必须，不能跳过）/ SHOULD（建议，除非有明确理由不做）/ MAY（可做可不做）
注意事项
- 不要一开始就追求完美——先粗糙版本跑起来，用真实案例迭代
- 不要把所有规则写死——参数化让 SOP 可复用
- 不要省略人工确认点——涉及资金/权限/承诺/合规的节点必须有确认机制
- 不要让一个 Skill 承担整个工作流——一个 Skill 对应一个明确任务，多个 Skill 串联才是 Workflow