我为什么说 5W2H 和 PDCA 是 AI Agent 的“任督二脉”
上一篇文章讲了 Agent 怎么编排调度——SA 拿到任务后，分析、规划、执行、检查、决策，五个角色轮番上阵。
但有个问题我没展开：SA 凭什么知道这个任务是 L2 还是 L5？凭什么决定走完整 PDCA 还是直接 Do？
答案藏在两个“元模型”里：5W2H 和 PDCA。
这两个模型，一个管“想清楚要做什么”，一个管“确保做对了”。它俩合在一起，就是 Agent OS 的任督二脉。今天专门聊聊这个。
一、先讲个翻车的故事
假设你是项目经理，对 AI 说了一句：
“帮我搞一下认证系统。”
AI 吭哧吭哧干了两小时，回来报告：“搞好了！”
你一看——它把整个用户系统重写了，用的 Session，不是你要的 JWT；没考虑过期时间；测试环境能跑，生产环境炸了。
问题出在哪？
不是 AI 不够聪明，是你没说清楚。再厉害的 AI，拿到一句“搞一下”，也只能猜。
现实中的人类项目经理怎么避免这种事？他们会先拉个会，把几个问题搞清楚：
- What：到底要做什么？（重构认证，不是重写用户系统）
- Why：为什么做？（现在的不安全，要换成 JWT）
- Who：谁来做、给谁用？（后端团队负责，给所有 API 调用方）
- When：什么时候要？（周五之前，灰度发布）
- Where：在哪里搞？（仓库
auth-svc，分支main） - How：怎么搞？（先升级依赖，再重构核心，加测试）
- How much：花多少资源？（预算 3 万 Token，最多 3 轮检查）
这七个维度问完，AI 拿到的就不再是一句“搞一下”，而是一份结构化任务卡片。
这就是 5W2H——任务本体的最小完备骨架。
二、5W2H：任何任务都必须先回答的七个问题
在我的 Agent OS 里，SA 接到任务的第一件事，不是直接干活，而是提取 5W2H：
graph LR
Input["用户：'重构认证系统'"]
SA["SA 提取 5W2H"]
Card["任务卡片"]
Input --> SA
SA --> Card
subgraph CardDetail["任务卡片内容"]
What["What: 重构认证，升级到 JWT + OAuth2"]
Why["Why: 当前实现不安全、性能差"]
Who["Who: 后端工程师角色"]
When["When: 本周五前，灰度发布"]
Where["Where: github.com/xxx/auth-svc, main 分支"]
How["How: 升级依赖 → 重构核心 → 加测试 → 灰度"]
HowMuch["How much: Token 预算 3 万，最多 3 轮 PDCA"]
end
Card --> What & Why & Who & When & Where & How & HowMuch
为什么是这七个维度？因为它们覆盖了任何任务都绕不开的基本要素。
| 维度 | 缺失时的典型问题 |
|---|---|
| What | 不知道要做什么，执行漫无目的 |
| Why | 无法判断优先级，做完了也不知道对不对 |
| Who | 忽略权限边界，输出不符合受众需求 |
| When | 没有时间概念，死线到了还没开始 |
| Where | 在错误的环境操作，或检索无关知识 |
| How | 有目标无路径，无法生成可执行计划 |
| How much | Token 超支、无限循环、质量不达标 |
5W2H 不是死表单，是 SA 用来“审题”的思维框架。 用户没说的，SA 会自动推断或追问；用户说过的，SA 会结构化存储，供下游 Agent 使用。
三、PDCA：ISO、PMBOK、ITIL 的共同选择
题目审清楚了，接下来就是干活。但怎么干？
质量管理领域有个经典模型叫 PDCA 循环（戴明环）：
Plan（计划）→ Do（执行）→ Check（检查）→ Act（改进）→ 再 Plan（下一轮）
这个模型看起来很简单，但它是几乎所有管理体系的基石：
- ISO 9001 质量管理体系 → 核心就是 PDCA
- PMBOK 项目管理知识体系 → 每个过程组都有 Plan-Do-Check-Act
- ITIL IT 服务管理 → 服务生命周期就是 PDCA 的变体
- 软件开发中的 CI/CD → Build → Test → Deploy → Monitor，本质也是 PDCA
为什么这些标准不约而同选了 PDCA？因为它抓住了“持续改进”的本质：你不 Check 就不知道对不对，你不 Act 就不会变好。
在 Agent 系统里，这套逻辑完全适用：
flowchart LR
P[Plan<br/>PA 拆解任务<br/>制定执行计划]
D[Do<br/>DA 调用工具<br/>产出代码/分析]
C[Check<br/>CA 独立审计<br/>按维度逐条校验]
A[Act<br/>AA 最终决策<br/>通过/打回/终止]
P --> D --> C --> A
A -->|打回重做| P
A -->|通过| Done[归档 + 沉淀经验]
单个 Agent 最大的问题是既当球员又当裁判——它会用一百种理由证明自己做对了。PDCA 把这个权力拆开了：DA 只管执行，CA 独立检查，AA 最终裁决。 谁也不能替别人做主。
四、它俩怎么配合？一套完整的认知流水线
sequenceDiagram
participant User
participant SA
participant PA
participant DA
participant CA
participant AA
User->>SA: “重构认证系统为 JWT”
rect rgb(230,240,255)
Note over SA: 🔍 5W2H 提取阶段
SA->>SA: 提取 What/Why/Who/When/Where/How/HowMuch
SA->>SA: 判断任务级别 = L2（标准任务）
SA->>SA: 决定走完整 PDCA
end
rect rgb(255,240,230)
Note over SA,PA: 📋 Plan 阶段
SA->>PA: 下发 5W2H 任务卡片
PA->>PA: 拆解：依赖升级 → 核心重构 → 测试 → 灰度
end
rect rgb(230,255,230)
Note over SA,DA: ⚙️ Do 阶段
SA->>DA: 按计划执行
DA->>DA: 调用 Skill 工具，产出代码
end
rect rgb(255,255,230)
Note over SA,CA: ✅ Check 阶段
SA->>CA: 拿到 DA 产出
CA->>CA: 按 5W2H 维度逐条审计
alt 所有维度 PASS
CA-->>SA: 通过
else 某个维度 FAIL
CA-->>SA: 打回（附带原因）
end
end
rect rgb(240,230,255)
Note over SA,AA: 🎯 Act 阶段
SA->>AA: 拿到审计报告
AA->>AA: 决策：通过，归档经验
AA-->>User: 交付结果
end
5W2H 管“审题”，PDCA 管“做题”。审题不清，后面全歪；做完不检查，等于白做。
五、为什么不是 SWOT、不是 SMART、不是其他模型？
很多人会问：搞分析的模型多了去了，SWOT、PEST、SMART、5Why……为什么偏选 5W2H 和 PDCA？
因为它们是“元模型”，其他模型都是“插件”。
graph TB
subgraph "通用框架（始终必需）"
U1["5W2H<br/>任务本体<br/>明确要做什么"]
U2["PDCA 循环<br/>执行模型<br/>定义如何执行"]
end
subgraph "专业模型（按需调用）"
S1["SWOT 分析<br/>战略定位"]
S2["5 Whys<br/>根因分析"]
S3["SMART 目标<br/>目标细化"]
S4["PEST 分析<br/>宏观环境"]
end
U1 -->|基础| TASK["可执行任务"]
U2 -->|流程| TASK
S1 -.->|可选技能| TASK
S2 -.->|可选技能| TASK
S3 -.->|可选技能| TASK
S4 -.->|可选技能| TASK
5W2H 适合所有任务，因为它描述的是“行动本身”的要素。 任何任务都有 What、Why、Who……哪怕最简单的“现在几点？”也有隐式的 What（查询时间）和 When（现在）。
PDCA 适合所有需要持续改进的任务，因为它描述的是“执行过程”的闭环。 ISO、PMBOK、ITIL 都选它，不是巧合，是共识。
而 SWOT、PEST、5Why 这些，是特定场景下的分析工具——战略分析用 SWOT，故障诊断用 5Why，目标设定用 SMART。它们不是“骨架”，是“技能”——可以按需调用，但不能替代 5W2H 和 PDCA 的位置。
一句话总结：5W2H 和 PDCA 是 Agent OS 的“系统内置功能”，其他模型是“可安装的 Skill 扩展”。
六、设计哲学：让机器像工程师一样思考
回到最开始的问题：为什么 SA 能自动判断任务级别？
因为 5W2H 给了它判断的依据：
- 如果 What 很模糊、Why 不明确 → L4 探索型任务，需要多策略并行
- 如果 What 明确、How 有现成 Skill → L2 标准任务，走完整 PDCA
- 如果 When 写的是“立即”、What 是“修复 Bug” → L6 紧急模式，跳过 Plan
- 如果 How 的步骤超过 10 个 → L5 递归任务，子任务需要独立 PDCA
这不是魔法，是结构化的力量。 把一个模糊的自然语言任务，拆成七个维度的结构化卡片，SA 就能自动判断复杂度和执行策略。
这就是 Gliding Horse 的设计哲学：用工程化的方法做 Agent，而不是靠 Prompt 的魔法。 5W2H 和 PDCA 来自几十年的工程管理实践，经过了无数项目的验证。我把它们移植到 Agent 系统里，不是创新，是工程上的正确选择。
七、预告
下一篇会继续聊设计细节：Agent 之间的记忆系统是怎么工作的——L0 到 L3 的四层架构怎么配合，MESI 协议怎么落地，以及为什么一个 Agent 永远不会“失忆”。
我这套系统叫 Gliding Horse（流马），所有代码都在 GitHub 上：github.com/doiito/glid…
设计细节系列持续更新中。前面聊了编排调度（为什么分 SA/PA/DA/CA/AA），这篇聊了认知框架（为什么选 5W2H 和 PDCA），下一篇聊记忆系统。想看什么也可以在 Issue 里说，我挑大家最关心的先写。
