Task Decomposition 任务拆解

三个核心概念的层级关系

Human SOP

给人看的纸本流程

→

Skill

给 Agent 的执行单位

→

Agentic Workflow

多 Agent + 工具串联

本质区别： Human SOP 是文字 + 经验谈，人类能自动补 context → Skill 把方法论打包成结构化文件夹 → Agentic Workflow 把多个 Skill + 工具串联成生产线

Human SOP 的局限

"SOP 文件里写'申请完送主管签核'——人类会自动判断：200块以内的小金额，主管宁愿不要去烦他；但超过5000块，至少要口头知会一声。"

对 Agent 的问题

问题	说明
非结构化	一坨文字，理解成本高
无例外处理	没有 specify，AI 不会知道什么时候省略
维护率低	口头提醒比维护文档更方便

Skill 的三大组件

📄

SKILL.md

核心：人类写给 Agent 的 SOP + 心法

📚

references/

辅助：示例输出、术语表、踩坑记录

⚙️

scripts/

执行：文件解析、格式转换等工程任务

命名规范：看名字就知道做什么、什么时候触发
例如：weekly-report-drafting、pdf-processing

Agentic Workflow 工厂比喻

👤

理解问题

理解用户需求

🔍

查资料

检索数据库/文档

⚡

执动作

调用工具/API

📝

写报告

汇总结果输出

中间调用各种工具、API、数据库，以及你之前写好的 Skills

Mega Agent（整包丢进去）vs 分解工作流

❌ Mega Agent（整包丢进去）

任务太大、太模糊

输出不可预测、不可 review

推理过程不透明

出错找不到下手点

每次执行像买彩券

像个黑箱，无法 production

无法观测、无法修复

✅ 分解工作流（Task Decomposition）

每个 Task 明确 input / output

每个 Task 有明确的成功标准

每步有 log，出错可追踪

哪里坏了改哪里，对症下药

可观测、可修复

Production 级别稳定性

企业级框架标配

生活类比：清洁房间

"只说'把家打扫干净'就出门。回来发现：角落里的灰、柜子后面的东西都没动。因为你对'干净'的定义和帮手完全不一样。"

核心教训

问题从来不是帮手够不够聪明，而是任务定义不清晰。再聪明的 Agent，如果你没有 specify 清楚，它就会用自己默认的理解去执行，结果和你的期望天差地别。

Mega Agent 失败案例

任务	Mega Agent 的典型输出
"帮我优化整个开发流程"	一份洋洋洒洒的优化建议 + 改一堆 config + refactor 不该动的模块
"帮我处理所有客户工单"	回复质量参差不齐，有的误判类型，有的漏掉紧急问题
"帮我做市场分析"	数据来源不明，逻辑跳跃，无法验证哪段推理是对的

你完全不知道哪一段推理是对的，哪一段根本不该让它自动跑

Task Decomposition 3C 原则

📥

Clear Input

明确的输入：参数、上下文、数据来源全部结构化

📤

Clear Output

明确的输出：什么格式、什么结构、什么内容

✅

Clear Success Criteria

明确的成功标准：可量化、可验证的衡量指标

3C 在企业级框架中的体现

每个 Agent 都很笨，但每件事都很明确

Mega Agent 的思路：用最强模型 + 最详细的 Prompt，试图一步到位
↓
Task Decomposition 的思路：把任务拆成一串小 Task，每个都有 3C
↓
出错了？回去看 Log → 发现是分类 Agent 误判 → 改分类 SOP 就好 → 对症下药

案例：客户 Ticket 处理 — 4-Agent 工作流

Human SOP（给人看）："处理客户问题，按类型分类回复，重要问题上报"

Input

Ticket ID

+ 内容

→

Agent 1

查资料

Input: ticket ID

Output: 历史记录

Success: 相关度>80%

→

Agent 2

分类

Input: ticket 内容

Output: 类型标签

Success: 准确率>90%

→

Agent 3

QC 审查

Input: 草拟回复

Output: 审查意见

Success: 漏检率<5%

→

Agent 4

发送回复

Input: 审核通过

Output: 发送确认

Success: 客户确认

✅ 关键：每个 Agent 都很笨，但每个 Agent 只做一件很明确的事。出错了看 Log → 改那个 Skill 就好。

分类错误的影响范围分析

Mega Agent 出错：整条链都要重来，不知道哪里出错。
分解后出错：只改对应 Skill，对其他节点无影响。

Skill 防守范围：太宽 vs 太窄

范围太大

样样通，但都差强人意

Skill 过于泛化

⚖️

正确平衡点

范围适中

单一任务，清晰边界

1 Skill = 1 任务

→

范围太小

每步都读 Skill

过度干预模型

过窄的问题：等于把模型当小孩子，什么都要听人类的。实际上是不信任模型的推理能力，过度干预。

Skill 命名规范

好的命名	触发时机
weekly-report-drafting	每周报告起草
pdf-processing	PDF 文档处理
invoice-categorization	发票分类
customer-ticket-search	查询客户历史工单
reply-qc-check	回复内容质检

看名字就知道它做什么、什么时候该被 trigger。不需要进 Skill 内部就能判断是否适用。

可提取为 Skills 的知识点

Skill 名称	触发场景	核心内容
task-decomposition	把大任务交给 Agent 时	3C 原则
skill-authoring	创建新 Skill 时	SKILL.md + refs + scripts
mega-agent-vs-workflow	选方案时	Mega Agent 局限性
sop-to-agentic-workflow	把人工流程转化时	5 步转化流程

SOP → Agentic Workflow 五步转化

1

识别判断节点
从 Human SOP 中找出每个判断节点：哪些是例外？哪些可以省略？哪些必须做？

2

定义 Input / Output
不是文字描述，是结构化参数。每个节点的输入输出都要明确。

3

判断自动化边界
哪些可以自动化，哪些仍需要人类确认。非结构化的判断需要 human-in-the-loop。

4

串联成 Workflow
每个节点 = 一个 Skill 或一个 Agent。画出完整的数据流图。

5

定义 Success Criteria
每个节点可量化、可验证的衡量指标。如：准确率 > 90%、返回时间 < 5s。

为什么企业级框架都用 Workflow Decomposition

📐

稳定性

任务边界清晰，输出可预测，不是每次执行都像买彩券

👁️

可观测性

每个步骤有 Log，出问题可追踪到具体节点

🔧

可修复性

哪里坏了改哪里，对症下药，不用推翻重来

Task Decomposition 知识图谱

核心思维总结

任务太大、太模糊 → Mega Agent 注定失败

↓

把任务拆成 3C 小任务 → 每个 Agent 做一件明确的事

↓

串联 Skill + 工具 → Agentic Workflow 工厂

↓

稳定性 + 可观测性 + 可修复性 = Production 级别系统

潜在 Skill 清单（可立即创建）

Skill 名称	触发场景	核心原则	优先级
task-decomposition	把大任务交给 Agent 时	3C 原则：Clear Input / Output / Success Criteria	高
skill-authoring	创建新的 Skill 时	SKILL.md + references/ + scripts/ 三组件，1 Skill = 1 任务	高
mega-agent-vs-workflow	选方案时	Mega Agent = 黑箱不稳定；Workflow = 稳定可修复	中
sop-to-agentic-workflow	把人工 SOP 转化时	5 步流程：识别节点 → 定 I/O → 自动化边界 → 串联 → 量化成功标准	中