我为什么说 5W2H 和 PDCA 是 AI Agent 的“任督二脉”上一篇文章讲了 Agent 怎么编排调度——SA 拿到任务后分析、规划、执行、检查、决策五个角色轮番上阵。但有个问题我没展开SA 凭什么知道这个任务是 L2 还是 L5凭什么决定走完整 PDCA 还是直接 Do答案藏在两个“元模型”里5W2H 和 PDCA。这两个模型一个管“想清楚要做什么”一个管“确保做对了”。它俩合在一起就是 Agent OS 的任督二脉。今天专门聊聊这个。一、先讲个翻车的故事假设你是项目经理对 AI 说了一句“帮我搞一下认证系统。”AI 吭哧吭哧干了两小时回来报告“搞好了”你一看——它把整个用户系统重写了用的 Session不是你要的 JWT没考虑过期时间测试环境能跑生产环境炸了。问题出在哪不是 AI 不够聪明是你没说清楚。再厉害的 AI拿到一句“搞一下”也只能猜。现实中的人类项目经理怎么避免这种事他们会先拉个会把几个问题搞清楚What到底要做什么重构认证不是重写用户系统Why为什么做现在的不安全要换成 JWTWho谁来做、给谁用后端团队负责给所有 API 调用方When什么时候要周五之前灰度发布Where在哪里搞仓库auth-svc分支mainHow怎么搞先升级依赖再重构核心加测试How much花多少资源预算 3 万 Token最多 3 轮检查这七个维度问完AI 拿到的就不再是一句“搞一下”而是一份结构化任务卡片。这就是 5W2H——任务本体的最小完备骨架。二、5W2H任何任务都必须先回答的七个问题在我的 Agent OS 里SA 接到任务的第一件事不是直接干活而是提取 5W2H任务卡片内容用户重构认证系统SA 提取 5W2H任务卡片What: 重构认证升级到 JWT OAuth2Why: 当前实现不安全、性能差Who: 后端工程师角色When: 本周五前灰度发布Where: github.com/xxx/auth-svc, main 分支How: 升级依赖 → 重构核心 → 加测试 → 灰度How much: Token 预算 3 万最多 3 轮 PDCA为什么是这七个维度因为它们覆盖了任何任务都绕不开的基本要素。维度缺失时的典型问题What不知道要做什么执行漫无目的Why无法判断优先级做完了也不知道对不对Who忽略权限边界输出不符合受众需求When没有时间概念死线到了还没开始Where在错误的环境操作或检索无关知识How有目标无路径无法生成可执行计划How muchToken 超支、无限循环、质量不达标5W2H 不是死表单是 SA 用来“审题”的思维框架。用户没说的SA 会自动推断或追问用户说过的SA 会结构化存储供下游 Agent 使用。三、PDCAISO、PMBOK、ITIL 的共同选择题目审清楚了接下来就是干活。但怎么干质量管理领域有个经典模型叫PDCA 循环戴明环Plan计划→ Do执行→ Check检查→ Act改进→ 再 Plan下一轮这个模型看起来很简单但它是几乎所有管理体系的基石ISO 9001质量管理体系 → 核心就是 PDCAPMBOK项目管理知识体系 → 每个过程组都有 Plan-Do-Check-ActITILIT 服务管理 → 服务生命周期就是 PDCA 的变体软件开发中的 CI/CD→ Build → Test → Deploy → Monitor本质也是 PDCA为什么这些标准不约而同选了 PDCA因为它抓住了“持续改进”的本质你不 Check 就不知道对不对你不 Act 就不会变好。在 Agent 系统里这套逻辑完全适用打回重做通过PlanPA 拆解任务制定执行计划DoDA 调用工具产出代码/分析CheckCA 独立审计按维度逐条校验ActAA 最终决策通过/打回/终止归档 沉淀经验单个 Agent 最大的问题是既当球员又当裁判——它会用一百种理由证明自己做对了。PDCA 把这个权力拆开了DA 只管执行CA 独立检查AA 最终裁决。谁也不能替别人做主。四、它俩怎么配合一套完整的认知流水线AACADAPASAUserAACADAPASAUser 5W2H 提取阶段 Plan 阶段⚙️ Do 阶段✅ Check 阶段alt[所有维度 PASS][某个维度 FAIL] Act 阶段“重构认证系统为 JWT”提取 What/Why/Who/When/Where/How/HowMuch判断任务级别 L2标准任务决定走完整 PDCA下发 5W2H 任务卡片拆解依赖升级 → 核心重构 → 测试 → 灰度按计划执行调用 Skill 工具产出代码拿到 DA 产出按 5W2H 维度逐条审计通过打回附带原因拿到审计报告决策通过归档经验交付结果5W2H 管“审题”PDCA 管“做题”。审题不清后面全歪做完不检查等于白做。五、为什么不是 SWOT、不是 SMART、不是其他模型很多人会问搞分析的模型多了去了SWOT、PEST、SMART、5Why……为什么偏选 5W2H 和 PDCA因为它们是“元模型”其他模型都是“插件”。专业模型按需调用通用框架始终必需基础流程可选技能可选技能可选技能可选技能5W2H任务本体明确要做什么PDCA 循环执行模型定义如何执行SWOT 分析战略定位5 Whys根因分析SMART 目标目标细化PEST 分析宏观环境可执行任务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 上https://github.com/doiito/gliding_horse设计细节系列持续更新中。前面聊了编排调度为什么分 SA/PA/DA/CA/AA这篇聊了认知框架为什么选 5W2H 和 PDCA下一篇聊记忆系统。想看什么也可以在 Issue 里说我挑大家最关心的先写。
【Agent Harness实战】我为什么说 5W2H 和 PDCA 是 AI Agent 的“任督二脉”
发布时间：2026/6/10 8:46:15
我为什么说 5W2H 和 PDCA 是 AI Agent 的“任督二脉”上一篇文章讲了 Agent 怎么编排调度——SA 拿到任务后分析、规划、执行、检查、决策五个角色轮番上阵。但有个问题我没展开SA 凭什么知道这个任务是 L2 还是 L5凭什么决定走完整 PDCA 还是直接 Do答案藏在两个“元模型”里5W2H 和 PDCA。这两个模型一个管“想清楚要做什么”一个管“确保做对了”。它俩合在一起就是 Agent OS 的任督二脉。今天专门聊聊这个。一、先讲个翻车的故事假设你是项目经理对 AI 说了一句“帮我搞一下认证系统。”AI 吭哧吭哧干了两小时回来报告“搞好了”你一看——它把整个用户系统重写了用的 Session不是你要的 JWT没考虑过期时间测试环境能跑生产环境炸了。问题出在哪不是 AI 不够聪明是你没说清楚。再厉害的 AI拿到一句“搞一下”也只能猜。现实中的人类项目经理怎么避免这种事他们会先拉个会把几个问题搞清楚What到底要做什么重构认证不是重写用户系统Why为什么做现在的不安全要换成 JWTWho谁来做、给谁用后端团队负责给所有 API 调用方When什么时候要周五之前灰度发布Where在哪里搞仓库auth-svc分支mainHow怎么搞先升级依赖再重构核心加测试How much花多少资源预算 3 万 Token最多 3 轮检查这七个维度问完AI 拿到的就不再是一句“搞一下”而是一份结构化任务卡片。这就是 5W2H——任务本体的最小完备骨架。二、5W2H任何任务都必须先回答的七个问题在我的 Agent OS 里SA 接到任务的第一件事不是直接干活而是提取 5W2H任务卡片内容用户重构认证系统SA 提取 5W2H任务卡片What: 重构认证升级到 JWT OAuth2Why: 当前实现不安全、性能差Who: 后端工程师角色When: 本周五前灰度发布Where: github.com/xxx/auth-svc, main 分支How: 升级依赖 → 重构核心 → 加测试 → 灰度How much: Token 预算 3 万最多 3 轮 PDCA为什么是这七个维度因为它们覆盖了任何任务都绕不开的基本要素。维度缺失时的典型问题What不知道要做什么执行漫无目的Why无法判断优先级做完了也不知道对不对Who忽略权限边界输出不符合受众需求When没有时间概念死线到了还没开始Where在错误的环境操作或检索无关知识How有目标无路径无法生成可执行计划How muchToken 超支、无限循环、质量不达标5W2H 不是死表单是 SA 用来“审题”的思维框架。用户没说的SA 会自动推断或追问用户说过的SA 会结构化存储供下游 Agent 使用。三、PDCAISO、PMBOK、ITIL 的共同选择题目审清楚了接下来就是干活。但怎么干质量管理领域有个经典模型叫PDCA 循环戴明环Plan计划→ Do执行→ Check检查→ Act改进→ 再 Plan下一轮这个模型看起来很简单但它是几乎所有管理体系的基石ISO 9001质量管理体系 → 核心就是 PDCAPMBOK项目管理知识体系 → 每个过程组都有 Plan-Do-Check-ActITILIT 服务管理 → 服务生命周期就是 PDCA 的变体软件开发中的 CI/CD→ Build → Test → Deploy → Monitor本质也是 PDCA为什么这些标准不约而同选了 PDCA因为它抓住了“持续改进”的本质你不 Check 就不知道对不对你不 Act 就不会变好。在 Agent 系统里这套逻辑完全适用打回重做通过PlanPA 拆解任务制定执行计划DoDA 调用工具产出代码/分析CheckCA 独立审计按维度逐条校验ActAA 最终决策通过/打回/终止归档 沉淀经验单个 Agent 最大的问题是既当球员又当裁判——它会用一百种理由证明自己做对了。PDCA 把这个权力拆开了DA 只管执行CA 独立检查AA 最终裁决。谁也不能替别人做主。四、它俩怎么配合一套完整的认知流水线AACADAPASAUserAACADAPASAUser 5W2H 提取阶段 Plan 阶段⚙️ Do 阶段✅ Check 阶段alt[所有维度 PASS][某个维度 FAIL] Act 阶段“重构认证系统为 JWT”提取 What/Why/Who/When/Where/How/HowMuch判断任务级别 L2标准任务决定走完整 PDCA下发 5W2H 任务卡片拆解依赖升级 → 核心重构 → 测试 → 灰度按计划执行调用 Skill 工具产出代码拿到 DA 产出按 5W2H 维度逐条审计通过打回附带原因拿到审计报告决策通过归档经验交付结果5W2H 管“审题”PDCA 管“做题”。审题不清后面全歪做完不检查等于白做。五、为什么不是 SWOT、不是 SMART、不是其他模型很多人会问搞分析的模型多了去了SWOT、PEST、SMART、5Why……为什么偏选 5W2H 和 PDCA因为它们是“元模型”其他模型都是“插件”。专业模型按需调用通用框架始终必需基础流程可选技能可选技能可选技能可选技能5W2H任务本体明确要做什么PDCA 循环执行模型定义如何执行SWOT 分析战略定位5 Whys根因分析SMART 目标目标细化PEST 分析宏观环境可执行任务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 上https://github.com/doiito/gliding_horse设计细节系列持续更新中。前面聊了编排调度为什么分 SA/PA/DA/CA/AA这篇聊了认知框架为什么选 5W2H 和 PDCA下一篇聊记忆系统。想看什么也可以在 Issue 里说我挑大家最关心的先写。
