6.5 产品实战：Agent 间的协作与纠错
LeadAgent 编排逻辑
4 个 SubAgent 不是自己串联的，由 LeadAgent 统一编排：
用户消息
│
▼
LeadAgent 意图识别
│
├─ 工作流相关 → 按流水线处理：
│
│ ① TaskTool → WorkflowPlanner
│ ↓ 返回: 规划方案
│
│ ② 是否确认规划？
│ ├─ 用户确认 → 继续
│ └─ 用户修改 → 回到①重新规划
│
│ ③ TaskTool → WorkflowCreator（输入规划方案）
│ ↓ 返回: workflowId
│
│ ④ TaskTool → WorkflowChecker（输入workflowId）
│ ↓ 返回: 校验报告
│
│ ⑤ 是否有问题？
│ ├─ 有严重问题 → 回到③（修复）或①（重规划）
│ ├─ 有警告 → 询问用户是否继续
│ └─ 通过 → 继续
│
│ ⑥ TaskTool → WorkflowExecutor（输入workflowId）
│ ↓ 返回: 执行结果
│
│ ⑦ 汇总报告给用户
│
└─ 非工作流 → 通用对话流水线是 LeadAgent 的职责，不是 SubAgent 自己管的。LeadAgent 控制流程，决定何时调用哪个 SubAgent，以及遇到错误时如何处理。
Checker → Creator 修正循环
检查 Agent 发现问题后，不是直接告诉用户"有错"，而是自动触发修正：
Checker 发现 ERROR
│
▼
LeadAgent 判定问题严重性
│
├─ Error → 自动重新派发 Creator
│ └─ Creator 收到原 WorkflowPlan + Checker 的问题列表
│ └─ 按问题列表修正（不是重新创建，是针对性修改）
│ └─ 修正后再次派发 Checker
│ └─ 循环直到无 Error 或达到最大重试次数
│
├─ Warning → 询问用户是否处理
│ ├─ 用户确认 → 派发 Creator 修正
│ └─ 用户忽略 → 继续下一步
│
└─ Info → 记录但不阻塞最大修正循环次数
默认最多 3 轮修正循环。超过后无论结果如何都返回给用户手动处理。
为什么要限制？防止死循环。LLM 可能反复犯同一个错误，Checker 反复检查出来，Creator 反复修正不了。3 轮是一个合理的平衡点——大部分问题 3 轮内能解决，解决不了的说明需要人介入。
修正的数据流
第一轮：
Planner → WorkflowPlan → Creator → 工作流 v1 → Checker → [Error: URL未填]
第二轮：
Creator 收到 WorkflowPlan + [Error: URL未填] → 修改参数 → 工作流 v2 → Checker → [通过]
结果：工作流 v2 交付Creator 在修正时收到的不是全新的任务，而是"原方案 + 问题列表"。它只需要针对性修改，不需要重新创建整个工作流。
执行失败 → 回退链路
执行 Agent 发现运行时问题后，根据问题类型决定回退到哪一步：
Checker 通过 → Executor 执行 → 失败
│
▼
分析失败原因
│
┌─────┴─────┐
│ │
参数问题 环境/超时问题
│ │
▼ ▼
LeadAgent 判断 LeadAgent 告知用户
├─ 自动重规划？ └─ 需要用户介入
└─ 用户确认？静态检查 vs 动态分析
关键区别：
- Checker 检查的是"设计是否正确"（静态分析）
- Executor 发现的是"运行时问题"（动态分析）
静态检查通过不代表运行时一定能成功——网络不通、文件不存在、FTP 密码错误，这些问题只有执行时才会暴露。
失败后的用户引导
| 失败类型 | Agent 建议 |
|---|---|
| 参数错误 | "请问是否需要调整参数？我可以帮你重新创建" |
| 环境错误 | "系统中缺少 XXX 工具，请安装后再试" |
| 权限错误 | "请检查 FTP/文件路径的访问权限" |
| 超时 | "工作流执行时间超过限制，建议拆分成多个子工作流" |
EvalCheck 的具象化
在 6.2 中，EvalCheck 是一个抽象概念——"输出后校验"。在这个产品里，EvalCheck 具象化为一个独立的 Agent。
对比：
| 维度 | 抽象的 EvalCheck | 产品中的 Checker Agent |
|---|---|---|
| 触发时机 | LLM 输出后 | 工作流创建后 |
| 检查方式 | 函数式委托 | LLM 智能检查 + 规则引擎 |
| 失败处理 | 自动重试/降级/人工 | 自动修正循环（最多 3 轮） |
| 检查内容 | JSON 格式、必填字段 | 结构完整性、参数正确性、控制流逻辑 |
Checker Agent 本质上是 EvalCheck 的"放大版"——把一个函数级的检查，放大为一个 Agent 级的检查。它拥有自己的工具集、自己的 Skill 文档、自己的 Prompt 设计。
这个设计选择的原因：当检查逻辑足够复杂时，一个函数不够用，需要一个完整的 Agent。
监控在产品中的体现
Monitor 在产品中体现为执行 Agent 的实时监控能力：
- 状态轮询：每 2 秒查询执行状态
- 进度报告：实时向用户报告当前执行到哪个节点
- 超时控制：单个工作流最大 60 分钟，单个节点最大 15 分钟
- 失败分析：执行失败时自动分析原因并分类
这不是 6.2 中的 MonitoringContextProvider（那个是框架级的监控），而是业务级的监控——面向用户的执行状态报告。
协作模式总结
| 协作场景 | 触发条件 | 回退到哪一步 | 最大次数 |
|---|---|---|---|
| 规划确认 | 用户不确认 | 重新规划 | 无限（用户驱动） |
| 检查修正 | Checker 发现 Error | Creator 修正 → Checker 再查 | 3 轮 |
| 执行回退 | Executor 失败 | 视情况：Creator 修正或 Planner 重规划 | 3 轮 |
| 环境错误 | 外部条件不满足 | 告知用户，不自动回退 | — |
整个流水线的核心设计思想：每一步的输出都是结构化的，可以传递给下一步作为输入，也可以传递给上一步作为修正依据。
这就是为什么 4 Agent 流水线能工作——不是因为每个 Agent 很聪明，而是因为 Agent 之间的数据流转设计得好。