个人知识库

2026-06-06-woshipm-agent-task-decomposition

11分钟阅读

真正能落地的AI项目是怎么做的？

AI Agent 落地的关键不在模型多强，而在你能不能把人类 SOP 拆成 Agent 可执行的任务节点——本文给出 Human SOP → Skill → Agentic Workflow 的三层概念框架和四步转化方法论。

基本信息

核心观点

  1. Human SOP ≠ Agentic Workflow，两者存在根本断层：人类 SOP 高度依赖隐性经验——财务报销 SOP 里写”必要时退回补充”，人能理解但 Agent 只能猜。Agent 不知道”五百块”和”五千块”在你们公司意味着什么，不知道哪步可以省、哪步不能省。任务太大、太散、太依赖人类脑补，是 Agent 不稳定的根因，不是模型不够聪明。

  2. 三个概念必须分清层级：Human SOP → Skill → Agentic Workflow：Human SOP 是写给人看的流程（依赖人的理解和补全能力）；Skill 是把单一任务打包给 Agent 的执行单位（包含核心说明、参考资料、可执行脚本）；Agentic Workflow 是由多个 Skill、工具、数据源和人工确认节点组成的生产线。一个 Skill 最好只对应一个相对明确的任务，边界太大变万能工具，边界太小把模型当小孩。

  3. 任务拆解（Task Decomposition）的四步方法论——从”人话 SOP”到可执行 Workflow：(1) 格式标准化：参数化 + MUST/SHOULD/MAY 规则强度分级 + 结构化 Markdown 区块；(2) 任务拆解：把一句话流程拆成 7-9 个独立节点（如报销审核拆为”提取信息→校验发票→判断费用类型→匹配制度→检查缺失→识别风险→生成结论→人工确认”）；(3) 双向开发：用真实执行结果反向修 SOP——每次出错都是在挖出隐性知识；(4) 接入真实工具 + 设计人工确认点。

  4. 真正能上线的 Agentic Workflow 要的不是”看起来很聪明”，而是稳定性、可观测性、可修复性：把企业微信客户咨询拆成 6 个 Agent（意图识别→用户资料查询→知识库匹配→回复生成→风险检查→跟进分配），每个 Agent 只做一件明确的事——意图识别错了改分类规则，回复不好改话术规范，风险检查漏了补质检规则。逐节点可调试 > 整体端到端黑箱。

  5. 规则强度分级 MUST/SHOULD/MAY 是 SOP 可执行化的关键工具：MUST（必须检查发票抬头/金额一致性、金额超限必须人工确认），SHOULD（应该根据费用类型提示缺失材料），MAY（可以在低风险小金额时直接生成通过建议）。规则一旦分出强度，Agent 就知道哪些地方不能商量、哪些可以结合上下文判断——比”根据公司制度审核”清楚太多。

实操内容保留

代码/配置

报销审核节点间的 JSON 中间格式（上一节点输出 = 下一节点输入）：

{
  "submitter": "张三",
  "department": "销售部",
  "expense_type": "客户招待",
  "amount": 5280,
  "invoice_title_matched": true,
  "tax_id_matched": true,
  "project_code": "BD-2026-03",
  "attachments": ["发票", "付款截图", "事前审批单"],
  "possible_risks": ["金额超过普通审批阈值"]
}

AI 客服意图识别 Skill 输出 JSON 格式：

{
  "intent": "价格咨询",
  "lead_level": "中意向",
  "needs_human": false,
  "recommended_action": "发送价格说明并补充价值差异",
  "draft_reply": "这个要看您选择的版本和使用周期，我先简单帮您说明一下……",
  "tags": ["价格敏感", "待转化"],
  "risk_flags": []
}

Prompt 模板

SOP 标准化模板结构：

  • Purpose：这个 SOP 解决什么问题
  • Trigger：什么时候触发
  • Inputs：输入是什么
  • Parameters：可配置参数有哪些
  • Steps：执行步骤
  • Output：输出格式
  • Error Handling：异常怎么处理
  • Human Checkpoint：什么时候必须问人

报销规则参数化字段：

  • expense_type：费用类型（差旅、交通、招待、采购、市场活动）
  • amount：报销金额
  • department：提交部门
  • project_code：项目归属
  • invoice_type：发票类型
  • approval_level：所需审批层级
  • policy_version：当前适用的制度版本

操作步骤

Human SOP → Agentic Workflow 四步转化法：

  1. 格式标准化：参数化（不把规则写死）+ MUST/SHOULD/MAY 区分规则强度 + 结构化 Markdown 区块（Purpose/Trigger/Inputs/Parameters/Steps/Output/Error Handling/Human Checkpoint）
  2. 任务拆解：把一个完整流程拆成多个独立节点，每个节点有独立输入、输出和成功标准——报销审核可拆成 9 个节点，客服可拆成 6 个 Skill
  3. 双向开发：先用自然语言告诉 Agent 你的审核逻辑 → Agent 写出第一版 SOP → 跑真实案例 → 每次出错补一条规则（如”如果费用说明出现客户/拜访/商务沟通关键词且发票为餐饮，SHOULD 标记为客户招待候选项”）→ 跑三五轮逐渐稳定
  4. 接入真实工具 + 设计人工确认点：接入企业微信/OA/发票识别/知识库等系统；高风险动作（大额付款、退款、管理员权限、对外承诺）必须人工确认

关键概念

  • 任务拆解（Task Decomposition）— 本文核心概念，把大流程拆成独立可执行节点的方法论
  • Skill — 本文定义为”把单一任务打包给 Agent 的执行单位”，含核心说明/参考资料/可执行脚本三类内容
  • MCP 模型上下文协议 — 本文用”AI 世界里的 USB-C”比喻标准化接口协议
  • AI Agent 智能体 — 多 Agent 协作场景（6 个客服 Agent 各司其职）
  • Agentic Workflow — 由多个 Skill、工具、数据源和人工确认节点组成的生产线
  • 任务拆解四步法 — 格式标准化→任务拆解→双向开发→接入工具
  • MUST/SHOULD/MAY 规则强度分级 — 让 SOP 具备可执行性的结构化方法
  • Tacit Knowledge（意会知识）— 你会做但很难完整说出来的经验，只有 Agent 做错时你才会发现原来这条规则没写进去

与其他素材的关联

  • 与 2026-06-02-woshipm-skill-creation-guide 的关系：流窜AI 的 Skill 创建指南讲”怎么写 Skill”，本文讲”怎么把一整条 Human SOP 拆成多个 Skill 组成的 Workflow”——前者是单 Skill 构建，后者是多 Skill 编排，两篇形成”微观→宏观”互补
  • 与 2026-05-23-woshipm-sop-as-cot-agent-clone-expert 的关系：忘机的”SOP 即思维链”讲怎么把老专家隐性经验注入 Agent（12 步 ReAct 思维链），本文的”双向开发”第三步讲的就是同一过程——每次出错把你脑子里的默会知识挖出来。两篇在”隐性知识显性化”上高度一致
  • 与 2026-06-03-youtube-multi-agent-accounting-pipeline 的关系：YouTube 的会计 5 Agent 管道正是本文”把复杂任务拆成多个 Agent”的具体案例——数据准备→分类→核对→报告→洞察，每个 Agent 恰好一个职责，逐个构建逐个测试

原文精彩摘录

很多人一上来就想研究最复杂的框架、最强的模型、最炫的工具调用，却忽略了一个更基础的问题：你到底会不会把一个大任务，拆成 AI 能真正执行的小任务？ 这件事听起来不性感。甚至有点像项目管理里的老话题。但它恰恰是 Agent 能不能稳定落地的关键。

你不要让一个 Agent 从头到尾全干。可以拆成六个环节：第一个 Agent，只负责识别用户意图。第二个 Agent，只负责查询用户资料和历史对话。第三个 Agent，只负责匹配产品知识库或营销方案。第四个 Agent，只负责生成回复内容。第五个 Agent，只负责检查话术风险。第六个 Agent，只负责根据结果打标签、分配销售或转人工。每个 Agent 看起来都很笨。但它只做一件明确的事。

Agent Workflow 不是一次性交付出来的。它是跑出来、修出来、磨出来的。先写一个粗糙版本。尽快跑起来。用真实案例测试。发现问题就补规则。用迭代速度换稳定性。

未来会用 AI 的人，未必是最会写 prompt 的人。而是最会拆任务、写流程、定边界、做迭代的人。前者半年就可能过时。后者会越来越值钱。

相关页面

关系图谱

快速导航

反向链接