6.3 产品实战：4 Agent 流水线架构
背景与问题
我的自动化产品有 100+ 种工作流节点——20+ 基础节点、80+ CLI 内置节点。用户可以在画布上拖拽编排工作流。
但操作太繁琐了。用户需要：
- 在节点库里搜索合适的节点
- 逐个拖到画布上
- 手动连接节点
- 逐个配置参数
- 检查有没有配错
- 运行测试
一个"下载视频 → 转格式 → 上传 FTP"的简单工作流，要操作 20 多次。
目标：让用户用自然语言描述需求，自动完成工作流的规划、创建、检查、执行。
为什么需要 4 个 Agent
最直觉的做法：一个 Agent 搞定所有事。用户说需求，Agent 直接创建工作流并执行。
但实际做下来，一个问题都解决不好：
问题 1：LLM 边想边做，错误率高
一个 Agent 同时负责"想清楚要做什么"和"动手去做"，结果是想不清楚、做不对。就像让一个人同时当架构师和程序员——他一边设计一边写代码，设计没想好就写了，写完发现设计有问题又要改。
问题 2：自己检查自己，等于没检查
创建完工作流后，同一个 Agent 检查自己的工作——它倾向于认为自己做的没错。这是 LLM 的固有缺陷：会迎合、会自我合理化。
问题 3：不经过检查就执行，风险大
创建完直接执行，万一工作流有错（参数没配、节点连错了），执行就会失败，甚至可能造成损失（删了不该删的文件、上传了错误的数据）。
这三个问题的答案，就是 4 Agent 流水线的架构设计。
4 Agent 分工
用户: "帮我把一个视频转成mp4，加字幕，上传到FTP"
│
▼
┌─────────────────────┐
│ ① 规划 Agent │ ← 脑力活：分析需求、选节点、定拓扑
│ (WorkflowPlanner) │
└────────┬────────────┘
│ 规划结果: {nodes: [...], connections: [...], params: {...}}
▼
┌─────────────────────┐
│ ② 创建 Agent │ ← 体力活：调API把规划变成工作流
│ (WorkflowCreator) │
└────────┬────────────┘
│ 创建完成: workflowId
▼
┌─────────────────────┐
│ ③ 检查 Agent │ ← 质检：验证工作流是否正确
│ (WorkflowChecker) │
└────────┬────────────┘
│ 检查报告: passed | issues[...]
▼
┌─────────────────────┐
│ ④ 执行 Agent │ ← 验收：执行工作流、看结果
│ (WorkflowExecutor) │
└────────┬────────────┘
│ 执行结果: success/fail, output
▼
用户得到最终结果每个 Agent 的定位
| Agent | 类比 | 输入 | 输出 | 是否修改系统状态 |
|---|---|---|---|---|
| 规划 Agent | 架构师 | 用户自然语言需求 | 工作流规划方案 | 否 |
| 创建 Agent | 工程师 | 规划方案 | 工作流 ID | 是（建表） |
| 检查 Agent | QA | 工作流 ID | 校验报告 | 否 |
| 执行 Agent | 运维 | 工作流 ID | 执行结果 | 是（运行） |
四个关键原则
原则 1：规划与创建分离
先思考再行动。规划 Agent 只负责"想清楚要做什么"，不执行任何写操作。创建 Agent 只负责"按方案去做"，不做规划决策。
这个分离解决了一个核心问题：LLM 边想边做导致的错误。 分开之后，规划可以反复修改（用户确认后再创建），创建严格按方案执行（不擅自改动）。
原则 2：检查独立
创建者不应检查自己的工作。检查 Agent 是独立的质检视角——它不知道规划方案是什么，它只看工作流本身是否符合规则。
这就像代码 review——写代码的人不应该自己 review 自己的代码，需要另一个人用独立视角检查。
原则 3：执行是验收
不经过检查的工作流不应执行。执行 Agent 拿到的工作流，一定是已经通过检查 Agent 验证的。如果检查没通过，执行 Agent 不会启动。
原则 4：每步可逆
发现错误可以回退到上一步修正：
- 检查发现问题 → 回退到创建（修复）或规划（重规划）
- 执行失败 → 回退到检查（分析问题）或创建（修改参数）
每一步的输出都是结构化的，可以传递给上一步作为修正依据。
数据流转
4 个 Agent 之间的数据流转是严格定义的：
用户需求（自然语言）
│
▼
┌─────────────────────────────────────────────────────┐
│ 规划 Agent 输出：WorkflowPlan │
│ { │
│ nodes: [ │
│ { id: "node_1", type: "Entry", title: "开始" }, │
│ { id: "node_2", type: "HttpDownload", ... }, │
│ { id: "node_3", type: "VideoFormatConversion", │
│ params: { format: "mp4" } }, │
│ { id: "node_4", type: "FtpUpload", ... }, │
│ { id: "node_5", type: "Exit", title: "结束" } │
│ ], │
│ connections: [ │
│ { from: "node_1", to: "node_2" }, ... │
│ ], │
│ userQuestions: [ │
│ { nodeId: "node_2", question: "请提供视频下载地址" }│
│ ] │
│ } │
└─────────────────────────────────────────────────────┘
│ 用户确认规划
▼
┌─────────────────────────────────────────────────────┐
│ 创建 Agent 通过 API 逐条执行： │
│ 1. workflow_create("视频处理") → id="wf_001" │
│ 2. workflow_add_node(wf_001, "Entry") │
│ 3. workflow_add_node(wf_001, "HttpDownload") │
│ 4. workflow_set_param(wf_001, "node_2", "url", ...) │
│ 5. workflow_connect(wf_001, "node_1", "node_2") │
│ ... │
│ 最终返回 workflowId = "wf_001" │
└─────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────┐
│ 检查 Agent 输出：ValidationReport │
│ { passed: true/false, │
│ issues: [ │
│ { severity: "error", nodeId: "node_2", │
│ message: "URL参数未填写", │
│ suggestion: "请设置 downloadUrl" } │
│ ] } │
└─────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────┐
│ 执行 Agent 输出：ExecutionResult │
│ { success: true/false, │
│ output: { ... }, │
│ duration: "00:03:25" } │
└─────────────────────────────────────────────────────┘Harness 概念在产品中的映射
对照 6.2 的设计清单，看产品是怎么落地的：
| Harness 维度 | 产品实现 |
|---|---|
| 知识 | 每个 Agent 加载不同的 Skill 文档（节点使用模式、校验规则等） |
| 规范 | 规划 Agent 的约束规则（必须有 Entry/Exit、参数区分必填和可推断） |
| 能力 | 每个 Agent 有不同的 Tool 集（Planner 只读、Creator 读写、Executor 执行） |
| 校验 | 检查 Agent 本身就是 EvalCheck 的具象化 |
| 监控 | 执行 Agent 实时监控执行状态、分析失败原因 |
| 边界 | 通过 Tool 权限控制 Agent 边界（Planner 不能创建工作流） |
这个映射关系，就是 Harness 工程从"设计清单"到"产品实现"的落地过程。