一个任务扔进来，我的 Agent 团队是这样把它“盘”明白的
前几篇聊了 JSON-LD、CPU 缓存、Oxigraph、Qdrant、Rust——全是“用什么造”。
从这篇开始，正式进入设计细节。今天先讲最核心的概念：Agent 是怎么编排和调度的。
很多同学以为 AI Agent 就是一个机器人吭哧吭哧干活。但真正可靠的 Agent 系统，背后是一套认知流水线——任务扔进来，先分析、再规划、再执行、再检查、再决策，每个环节由不同的 Agent 负责。
这就是我设计的 广义 PDCA 编排模型。
一、五大 Agent 角色：各司其职，互相制衡
flowchart LR
SA["SA 协调者<br/>（大脑）"]
PA["PA 计划者<br/>（策略家）"]
DA["DA 执行者<br/>（干活的）"]
CA["CA 检查者<br/>（质检员）"]
AA["AA 决策者<br/>（复盘官）"]
SA -->|生成提示词| PA
SA -->|生成提示词| DA
SA -->|生成提示词| CA
SA -->|生成提示词| AA
PA -->|执行计划| DA
DA -->|产出结果| CA
CA -->|审计报告| AA
AA -->|反馈决策| SA
这五个角色不是写死的代码，而是 SA 在运行时动态生成的不同提示词模板。它们的职责边界非常清晰：
| 角色 | 职责 | 一句话概括 |
|---|---|---|
| SA (协调者) | 分析任务、动态编排流程、监控执行 | “这事儿该找谁、按什么顺序办？” |
| PA (计划者) | 把目标拆解成可执行的子任务 | “我分三步走：先查数据，再分析，最后画图。” |
| DA (执行者) | 实际调用工具、写代码、查数据 | “我来干！” |
| CA (检查者) | 检查 DA 的产出是否合格 | “你确定这数据是Q2的？这增长率算错了。” |
| AA (决策者) | 根据检查结果决定下一步 | “数据没问题，批准通过。经验存起来下次用。” |
二、为什么需要多 Agent 互相制衡？
单个 Agent 最致命的问题：它会“谎报军情”。
这是 LLM 的固有毛病——当你让它既当球员又当裁判，它会找一百个理由告诉你“任务完成了”，哪怕代码根本没跑通。
典型的翻车现场：
用户：“写个 Python 脚本分析销售数据。”
单 Agent：直接生成一段代码，告诉你“写好了”。你一问才说“环境没装，你手动跑一下”。再追问“结果对吗？”它回“应该没错”。
问题出在哪？没有独立的质量检查环节。
所以我把流程拆成了五个角色，让它们互相盯着：
- DA 执行完，CA 必须独立检查：代码跑了吗？结果符合预期吗？和需求对得上吗？
- CA 检查完，AA 再做最终决策：通过、打回重做、还是换策略？
- 如果 AA 觉得有问题，打回 PA 重新规划，而不是让 DA 自己改
多 Agent 互相制衡的设计，能从架构层面降低 LLM 的“自欺欺人”概率。 不是消除，而是大幅减少。CA 发现一次谎报，AA 就会记录这次失败模式，下次同类任务 SA 会自动加严检查标准。
三、SA 不是固定流程，是动态编排引擎
很多 Agent 框架把 Plan→Do→Check 写死成 DAG。但真实任务千奇百怪：
- “现在几点？”——不需要规划、不需要检查
- “修这个 Bug！”——等不了规划，直接上手
- “重构整个代码库”——得拆成几十个子任务递归执行
所以 SA 不是死板的流程控制器，而是动态编排引擎。 它分析任务的 5W2H 元数据，自动决定用哪种执行拓扑。
系统将任务自动分类为 7 个级别，并相应调整 PDCA 循环：
| 级别 | 类型 | PDCA 适配 | 示例 |
|---|---|---|---|
| L0 | 即时任务 | 单轮，无需 PDCA | “现在几点？” |
| L1 | 简单任务 | 单次 PDCA 循环，最小规划 | “写一个 Python 脚本” |
| L2 | 标准任务 | 完整 PDCA + 结构化审计 | “分析 Q2 销售数据” |
| L3 | 复杂项目 | 多智能体并行 Do 阶段 | “构建 REST API + 测试” |
| L4 | 探索型任务 | 多 DA 并行，不同策略 | “研究最佳技术栈” |
| L5 | 递归任务 | 子任务生成子 PDCA 循环 | “重构整个代码库” |
| L6 | 紧急模式 | 跳过 Plan，立即 Do-Check 循环 | “立即修复生产 Bug” |
flowchart TD
Task[任务输入 + 5W2H元数据]
SA[SA 分析任务复杂度]
Task --> SA
SA -->|L0| Direct[直接回答<br/>无需 Agent]
SA -->|L1| SinglePDCA[单次 PDCA<br/>PA→DA→CA]
SA -->|L2| FullPDCA[完整 PDCA<br/>PA→DA→CA→AA]
SA -->|L3| Parallel[并行 DA<br/>PA→DA1∥DA2→CA→AA]
SA -->|L4| Explore[多策略探索<br/>DA1∥DA2∥DA3→CA]
SA -->|L5| Recurse[递归 PDCA<br/>DA 内部生成子 PA/DA/CA]
SA -->|L6| Emergency[紧急模式<br/>跳过 PA→DA→CA 快速闭环]
四、每个 Agent 内部是 ReAct 架构，支持并行子 Agent
PA、DA、CA、AA 四个执行 Agent 内部都采用 ReAct（Reasoning + Acting）架构：
思考 → 行动 → 观察 → 思考 → 行动 → ... 直到完成
而且它们都能生成并行子 Agent。比如 L3 复杂项目，PA 拆出三个模块，SA 就生成三个 DA 实例同时干活：
flowchart LR
PA[PA 拆解任务]
DA1[DA-1 模块A]
DA2[DA-2 模块B]
DA3[DA-3 模块C]
CA[CA 汇总检查]
PA --> DA1
PA --> DA2
PA --> DA3
DA1 --> CA
DA2 --> CA
DA3 --> CA
每个 DA 是完全隔离的——有自己的提示词、自己的工具白名单、自己的 L1 摘要缓存。DA-1 不能访问 DA-2 的私有数据，但都能读写共享的 L2 黑板。
这种隔离保证了：一个 DA 跑偏不会污染其他 DA 的上下文。 汇总 Agent（CA）通过 L2 黑板拿到所有结果后再做整体判断。
五、PDCA 递归：最复杂的“套娃模式”
L5 递归任务是最复杂但也最强大的模式。
重构整个代码库时，SA 先生成一个 PA，PA 把代码库拆成 10 个模块。每个模块的 DA 在执行时发现“这个模块太复杂，一个 DA 搞不定”——
DA 内部可以再生成一个微观的 SA，走一套完整的 PDCA！
flowchart TD
SA_TOP[顶层 SA] --> PA_TOP[顶层 PA]
PA_TOP --> DA_1[DA 模块1]
PA_TOP --> DA_2[DA 模块2]
DA_2 --> SA_SUB[DA 内部生成<br/>微观 SA]
SA_SUB --> PA_SUB[微观 PA]
PA_SUB --> DA_SUB[微观 DA]
DA_SUB --> CA_SUB[微观 CA]
CA_SUB --> AA_SUB[微观 AA]
AA_SUB -->|递归完成| DA_2
DA_1 --> CA_TOP[顶层 CA]
DA_2 --> CA_TOP
CA_TOP --> AA_TOP[顶层 AA]
这就是 PDCA 递归——一套 PDCA 内部能再套一套 PDCA，理论上可以无限嵌套，直到每个子任务都简化到可执行为止。
这套设计保证了无论任务多复杂，系统都能自动拆解到可管理的粒度。
六、这套设计解决了什么痛点？
| 痛点 | 单 Agent 或固定流程 | 我的设计 |
|---|---|---|
| 谎报完成 | Agent 自行判断“做完了” | CA 独立检查，AA 最终裁决 |
| 复杂任务卡壳 | 固定流程，无法拆解 | SA 动态编排，支持并行和递归 |
| 探索型任务无方向 | 单策略死磕 | 多 DA 并行不同策略，CA 择优 |
| 紧急任务被流程拖慢 | 必须走完整流程 | L6 紧急模式，跳过规划直接执行 |
| Agent 间数据污染 | 共享上下文，一错全错 | 完全隔离，仅通过 L2 黑板通信 |
七、预告
这篇主要讲了 Agent 怎么编排调度。但调度决策的依据是什么？SA 怎么知道一个任务是 L2 还是 L5？
答案就是 5W2H 元数据和 PDCA 本体模型。
下一篇我会专门讲：为什么选择 5W2H 作为任务元数据骨架，以及 PDCA 怎么从质量管理理论变成了 Agent 的原生认知循环。这两个概念是整个 Agent OS 设计的哲学基石。
我这套系统叫 Gliding Horse（流马），所有代码都在 GitHub 上：github.com/doiito/glid…
想跑跑看的可以直接 下载零依赖二进制可执行文件，支持Linux X64、aarch64，MacOS，Win64，README 里有 Quickstart。设计细节系列会持续更新，下一篇见。
