admin · 2026-05-15 · architecture · multi-agent · MainAgent · EvalAgent · DAG · LLM-as-Judge · workflow
01 一个任务,两种命运
假设你交给 AI 一个任务:为 5 月 12 日南京博物馆之行制作一份导览攻略网页,包含天气穿衣建议、展馆推荐路线和闭馆提醒。
如果交给单体 LLM 处理,会发生什么?
单体 LLM 处理链 ──── 一条路走到黑
1. [推理] 需要查询天气 → 无法联网,只能"编造"数据
2. [推理] 需要展馆信息 → 训练数据可能过时
3. [生成] 撰写攻略文案 → 一次生成,无法自我验证
4. [编码] 生成 HTML → 可能样式错误或移动端不适配
5. [输出] 最终结果 → 错误层层累积,看起来专业但信息有误
而多智能体架构的做法完全不同:
多智能体处理链 ──── 分工、并行、评审
[MainAgent] 分解任务 → 构建 DAG
├── Sub-Agent A: 调用天气 API 获取实时数据 → 准确
├── Sub-Agent B: 搜索南京博物院最新展馆信息 → 实时
├── Sub-Agent C: 基于 A 的数据生成穿衣建议 → 有据可依
├── Sub-Agent D: 基于 B 的数据规划参观路线 → 信息同步
└── Sub-Agent E: 将 C + D 组装为 HTML → 内容准确
[EvalAgent] 独立审查
├── 检查天气数据是否为实时查询结果
├── 检查闭馆提醒是否正确
├── 检查 HTML 是否适配移动端
└── 评分 92/100 → 通过 → 交付用户
区别一目了然:单体 LLM 是"一个人扛到底",多智能体是"团队分工 + 独立质检"。本文将完整拆解从 MainAgent 接收任务到 EvalAgent 评估反馈的全链路设计。
02 架构全貌:三个角色与一条主线
三大核心角色
MainAgent / Orchestrator
项目经理 / 指挥官
任务接收、分解、调度、汇总、重试决策
Sub-Agent / Worker
领域专家 / 执行者
接收子任务、独立执行、返回结果
EvalAgent / Judge
评审专家 / QA
质量评估、报告生成、反馈建议
端到端工作流
1
MainAgent · 需求解析
实体提取 → 任务分类 → 复杂度评估 → 上下文检索
│
▼
2
MainAgent · 任务分解
策略选择(功能/流程/混合)→ 构建 DAG → 拓扑分层
│
▼
3
Sub-Agent · 并行/串行执行
按拓扑层级逐层执行,层内并行,层间串行
│
▼
4
MainAgent · 结果汇总 + 质量初检
收集 → 合并 → 快速格式校验(毫秒级)
│
▼
5
EvalAgent · 独立评估
Rule-based 快筛 → LLM-as-Judge 深评 → 评估报告
│
▼
6
反馈路由 · 闭环迭代
通过 → 交付用户 | 不通过 → 注入反馈 → 重试(最多 3 轮)
03 任务输入:标准化的"弹药输送"
任务输入是整个工作流的起点。MainAgent 定义了一套标准化的输入接口,确保来自不同渠道(CLI、API、Web UI)的任务被统一处理。
输入字段设计
TaskInput 核心字段
TaskInput
├── task_id # 【必填】UUID,全局唯一,全链路追踪
├── task_description # 【必填】自然语言描述,MainAgent 理解意图的核心依据
├── priority # 【选填】low / medium / high / critical
├── constraints
│ ├── max_iterations # 评估反馈循环最大次数(默认 3)
│ ├── timeout_seconds # 单个子任务超时阈值(默认 300s)
│ └── budget_tokens # Token 预算上限
├── expected_output
│ ├── format # text / markdown / json / html / file
│ └── quality_criteria # 用户自定义质量标准列表
└── context
├── session_history # 历史会话摘要
└── domain_knowledge # 领域知识或参考资料
需求解析三阶段
Stage 1 · 实体提取
从
task_description 中抽取结构化实体:target、date、location、format、action
例: "为5月12日南京博物馆之行制作导览攻略网页" → {target: "导览攻略网页", date: "2026-05-12", location: "南京"}
Stage 2 · 任务分类
归入预定义类型:
info_retrieval content_generation code_development composite
类型决定后续的分解策略和评估权重
Stage 3 · 复杂度评估
四维打分:领域跨度 × 0.3 + 步骤深度 × 0.25 + 依赖密度 × 0.25 + 输出精度 × 0.2
≤ 1.5 → single agent | ≤ 3.0 → 2-4 子任务 | > 3.0 → 多层级分解
三层上下文检索
上下文不是一次性全部注入,而是按需分阶段注入:任务分解时注入会话上下文,子任务分发时注入知识切片,评估反馈时注入历史经验。核心原则——最小充分原则:给每个 Agent 恰好够用的信息。
Layer 1 · 会话上下文
当前会话历史消息摘要,理解用户即时意图和偏好
Layer 2 · RAG 知识检索
向量数据库 + 关键词检索,获取领域知识和实时信息
Layer 3 · 长期记忆
历史任务执行记录、用户偏好库、经验沉淀
04 MainAgent 任务分解:从混沌到有序
任务分解是 MainAgent 最核心的能力。一个优秀的分解方案需要满足三个条件:子任务边界清晰、依赖关系明确、每个子任务可独立验证。
三种分解策略
功能分解 · Functional
按
能力域拆分,每个子任务对应一个专业领域
适用:任务涉及多个专业领域,各领域可独立工作
导览攻略网页:
├── A [信息检索]: 查实时天气
├── B [信息检索]: 查展馆信息
├── C [内容生成]: 撰写路线文案
├── D [内容生成]: 撰写穿衣建议
└── E [前端开发]: 组装 HTML
依赖: A→D, B→C, (C,D)→E
流程分解 · Procedural
按
执行步骤拆分,形成流水线
适用:有明确阶段流程,后一步依赖前一步输出
技术博客撰写:
├── Step-1 [调研]: 搜索论文
├── Step-2 [大纲]: 生成大纲
├── Step-3 [草稿]: 按大纲写初稿
├── Step-4 [润色]: 优化表达
└── Step-5 [审校]: 检查准确性
依赖: 严格串行 1→2→3→4→5
混合分解 · Hybrid(实际最常用)
结合功能与流程,构建
多层级子任务树。先按流程分阶段,每个阶段内部按功能模块拆分子任务。例如开发 REST API:Phase-1 设计 → Phase-2 并行编码(注册/登录/权限) → Phase-3 测试 → Phase-4 部署。
DAG 构建:让依赖关系显式化
子任务生成后,MainAgent 构建有向无环图(DAG)来显式管理依赖。三种依赖类型:
| 依赖类型 | 说明 | 示例 |
| 数据依赖 | B 需要 A 的输出作为输入 | 天气查询 → 穿衣建议 |
| 时序依赖 | B 必须在 A 完成后才开始 | API 设计 → API 编码 |
| 条件依赖 | B 是否执行取决于 A 的输出 | 代码审查 → 若有 Bug 则触发修复 |
以导览攻略为例,DAG 拓扑分层如下:
DAG 拓扑分层 ──── 层内并行,层间串行
Level 0 [A: 天气查询] ∥ [B: 展馆查询] ← 可并行
│ │
▼ ▼
Level 1 [C: 穿衣建议] ∥ [D: 路线推荐] ← 可并行(依赖 Level 0)
│ │
└────────┬─────────┘
▼
Level 2 [E: HTML 组装] ← 汇总(依赖 Level 1)
关键路径: A → C → E(假设耗时最长,决定总执行时间)
子任务分发规范
每个子任务以 SubTaskDescriptor 标准化描述分发,包含:subtask_id、详细执行指令、输入规格(依赖哪个子任务的输出)、输出规格(格式/Schema/最大长度)、Agent 能力要求、超时时间。子任务间不直接通信,所有数据交换通过 MainAgent 中转。
05 调度与执行:DAG 如何变成行动
调度器是 MainAgent 的"执行手臂",核心挑战是在效率(并行度)和正确性(依赖满足)之间取得平衡。
四种调度模式
全并行
所有子任务无依赖,全部同时启动
执行时间 = max(单任务耗时),效率最高
全串行
所有子任务严格前后依赖
执行时间 = sum(所有耗时),效率最低
混合调度(最常用)
按拓扑层级逐层执行,层内并行,层间串行
兼顾效率和正确性
条件路由
后续执行路径取决于前序结果
如:测试通过→部署,失败→修复→重测
Sub-Agent 生命周期
Agent 生命周期状态机
CREATED ← 实例化
│
▼
READY ← 等待分配任务 ─────────┐
│ │
▼ │
RUNNING ← 执行任务 │
│ │
┌───┴───┐ │
▼ ▼ │
SUCCESS FAILED │
│ │ │
│ 可重试?── 是 ──→ RETRYING ──┘
│ │
│ 否
▼ ▼
COMPLETED → 复用或销毁
│
▼
DESTROYED ← 资源释放
Agent 池管理遵循优先复用策略:先从空闲池匹配,无匹配才创建新实例,超过并发限制则排队等待。这避免了重复初始化的开销。
三层执行保护
| 保护层 | 机制 | 触发条件 |
| 超时保护 | asyncio.wait_for 强制终止 | > timeout_seconds |
| 异常捕获 | 区分可重试/不可重试错误 | API 限流、服务不可用 |
| 质量快检 | 格式 + 必填字段 + 长度检查 | 输出为空、JSON 语法错误 |
06 结果汇总:从碎片到整体
所有子任务执行完毕后,MainAgent 需要将分散的结果合并为统一产物,供 EvalAgent 评估。
合并策略
内容拼接型(concat)
按拓扑层级顺序拼接
例:攻略文案 + HTML 组装
数据聚合型(aggregate)
合并 JSON 字段为统一对象
例:多源数据汇总
流水线型(pipeline)
后一步增强前一步的输出
例:草稿 → 润色 → 审校
两级质量检查体系
L1
MainAgent 快速初检(毫秒级)
输出非空 → 格式匹配(JSON/HTML 语法检查)→ 必填字段 → 长度约束 → 子任务失败率
目的:快速拦截"明显坏"的结果,节省后续评估成本
│
通过 ↓
L2
EvalAgent 深度评估(秒级)
语义准确性 → 逻辑连贯性 → 用户需求满足度 → 专业深度 → 整体质量评分
目的:深度审查"看起来对但可能有问题"的结果
07 EvalAgent 评估:六维评分 + 双轨架构
EvalAgent 是多智能体系统中质量保障的核心枢纽。它的设计哲学源自软件工程中"开发与测试分离"的基本原则——既当运动员又当裁判,是不靠谱的。
独立性保障
为什么 Sub-Agent 不能自评?
认知盲区:生成者倾向于认为自己的输出正确
标准漂移:多次迭代后逐渐降低自我标准
利益冲突:目标是"完成任务"而非"保证质量"
EvalAgent 的四重独立性
上下文隔离:不共享 Sub-Agent 的执行上下文
模型独立:可用不同 LLM,避免系统性偏差
标准外部化:评分规则由 MainAgent 定义
结果不可篡改:报告直接返回 MainAgent
六维评估模型
准确性 Accuracy
事实是否正确 · 数据是否准确 · 引用是否真实
完整性 Completeness
需求是否覆盖 · 要点是否充分 · 结构是否完整
一致性 Consistency
内部是否矛盾 · 跨 Agent 是否一致 · 风格是否统一
格式合规 Format
格式是否正确 · Schema 是否合规 · 移动端是否适配
可读性 Readability
表达是否清晰 · 结构是否有层次 · 排版是否美观
时效性 Timeliness
信息是否最新 · 执行是否超时
每个任务类型的权重不同,遵循"任务决定重点"原则:
| 任务类型 | 最高权重维度 | 原因 |
info_retrieval | 准确性 30% | 信息检索,正确性最重要 |
content_generation | 可读性 25% + 完整性 25% | 内容既要全又要好看 |
code_development | 格式 30% + 准确性 30% | 代码要能编译且正确 |
composite | 均匀分布 | 跨 Agent 一致性很关键 |
Task-Adaptive Rubrics:评分规则不是一刀切
用同一套标准评估"查询北京天气"和"写一篇科幻小说"是荒谬的。Task-Adaptive Rubrics 的核心思想:评分维度和权重由任务类型动态决定。
①
加载基础模板
根据任务类型加载对应的维度和默认权重
│
②
用户标准注入
解析 quality_criteria 中指定的重点项,匹配到的维度权重 ×1.5
│
③
动态维度扩展
如"页面需适配移动端" → 新增 mobile_compatibility 维度
│
④
权重归一化 + 生成评分细则
确保权重之和 = 1.0;为每个维度生成 90-100 / 70-89 / 50-69 / 0-49 四档评分描述
双轨评估架构
Rule-based(确定性检查)
适用维度:格式合规、完整性、时效性
特点:毫秒级、100% 确定、成本几乎为零
检查项:JSON 语法、HTML 结构、必填字段、时间戳有效性
LLM-as-Judge(语义评审)
适用维度:准确性、一致性、可读性
特点:秒级、存在波动、消耗 Token
关键设计:使用与执行不同的 LLM,避免系统性偏差
输出要求:结构化 JSON(score + reasoning + evidence + issues)
混合评估流程
Step 1: Rule-based 快筛(毫秒级)
→ 格式检查、字段完整性、时效性验证
→ 如果存在 critical 级别问题,直接返回 fail
→ 否则进入 Step 2
│
▼
Step 2: LLM-as-Judge 深评(秒级)
→ 准确性、一致性、可读性等语义维度评估
→ 每个维度独立评分,提供证据和理由
│
▼
Step 3: 结果合并
→ 计算加权总分 = Σ(维度分数 × 维度权重)
→ 通过/不通过判定
评估报告示例(导览攻略任务)
评估报告摘要
| 维度 | 分数 | 权重 | 关键发现 |
| 准确性 | 85 | 0.25 | 地址正确、闭馆日正确;穿衣建议缺乏具体温差数据 |
| 完整性 | 90 | 0.20 | 所有必需模块已覆盖 |
| 一致性 | 78 | 0.15 | 8个展馆仅规划4小时,平均每馆30分钟偏紧 |
| 格式合规 | 95 | 0.15 | HTML 结构完整,移动端适配良好 |
| 可读性 | 88 | 0.15 | 文案流畅,层次分明;部分段落可拆分 |
| 时效性 | 92 | 0.10 | 天气数据包含查询时间戳,为当天结果 |
改进建议(minor):路线规划减少至 5-6 个核心展馆或延长至 5-6 小时;穿衣建议补充具体温差数据
08 反馈闭环:从发现问题到精准修复
EvalAgent 的价值不仅在于"发现问题",更在于将发现转化为可操作的改进指令。一个只说"这里不好"的评估是低价值的;一个说"这里不好,原因是 X,建议改为 Y"的评估才是高价值的。
三级反馈路由
●
EvalAgent 评估报告
包含 issues(问题)+ suggestions(建议)+ 维度评分
│
▼
全局反馈
>50% 子任务有 critical 问题
路由 → MainAgent 重新规划
局部反馈
少量子任务有 major/minor 问题
路由 → 对应 Sub-Agent 定向重执行
建议性反馈
仅 minor 问题,不影响核心功能
路由 → 仅记录,不触发重试
迭代策略:渐进式收敛
为什么默认最多 3 轮迭代?数据说明一切:
| 迭代轮次 | 典型质量 | 边际收益 | Token 消耗 |
| 第 1 轮 | 基线 → 70-80 分 | 最高 | 50% 预算 |
| 第 2 轮 | 70-80 → 85-90 分 | 较高 | 30% 预算 |
| 第 3 轮 | 85-90 → 90-95 分 | 递减 | 20% 预算 |
| 第 4+ 轮 | 90-95 → 95+ | 极低 | 成本线性增长 |
渐进式重试 ──── 范围逐轮缩小
迭代 1: 全面子任务执行 → EvalAgent 评估 → 发现 3 个问题
迭代 2: 仅重新执行有问题的子任务(注入反馈)→ 评估 → 1 个问题
迭代 3: 仅修复最后 1 个问题 → 评估 → 通过 ✅
关键设计:
├── 每轮重试范围逐步缩小(全量 → 部分 → 单点)
├── 反馈信息越来越具体(从"整体质量不足"到"第3段数据有误")
└── Token 消耗逐轮递减
上下文注入:让 Agent 知道上次哪里做错了
重试的关键不在于"重新做一遍",而在于让 Sub-Agent 知道上次哪里做错了、应该怎么改。每次重试注入的上下文包括:
反馈注入模板
## 重试上下文(第 N 次尝试)
### 你上次的输出:
{previous_result.output}
### 评估发现的问题:
{具体问题描述}
### 修改建议:
{可操作的修复方向}
### 重要约束:
1. 请针对上述问题进行修复,不要从头重新生成
2. 保持上次输出中正确的部分,仅修改有问题的内容
3. 特别注意以下"不要重复"的负面提示
降级策略:当多次重试仍无法达标时,系统优雅降级而非无限循环——连续 2 次评分提升 < 5 分则自动降低通过阈值;达到最大迭代次数则返回最佳结果 + 评估摘要。
09 完整架构交互时序图
完整工作流时序 ──────────────────────────────────────────────────►
用户 MainAgent Sub-A Sub-B EvalAgent
│ │ │ │ │
│──任务输入─→│ │ │ │
│ │ │ │ │
│ │─需求解析 │ │ │
│ │─上下文检索 │ │ │
│ │─任务分解(DAG) │ │ │
│ │ │ │ │
│ │─分发子任务1──→│ │ │
│ │─分发子任务2──────────────→│ │
│ │ │ │ │
│ │ │─执行任务1─→│ │
│ │ │ │─执行任务2─→│
│ │ │ │ │
│ │←─结果1───────│ │ │
│ │←─结果2────────────────────│ │
│ │ │ │ │
│ │─结果汇总 │ │ │
│ │─质量初检 │ │ │
│ │ │ │ │
│ │──────────提交评估──────────────────────→│
│ │ │ │ │
│ │ │ │ ┌规则检查──┐
│ │ │ │ │LLM评审 │
│ │ │ │ │报告生成 │
│ │ │ │ └──────────┘
│ │ │ │ │
│ │←──────────评估报告───────────────────────│
│ │ │ │ │
│ │─判断结果 │ │ │
│ │ │ │ │
│ │ IF verdict == "pass":
│ │ → 组装最终输出 → 返回用户
│ │ ELIF iteration < max:
│ │ → 注入反馈 → 重新调度 → 回到执行阶段
│ │ ELSE:
│ │ → 返回最佳结果 + 评估摘要
│ │ │ │ │
│←─最终输出──│ │ │ │
10 核心设计原则回顾
原则 1 · 分而治之
复杂任务分解为可管理的子任务,每个子任务边界清晰、可独立验证
原则 2 · 独立评估
EvalAgent 独立于执行链,上下文隔离、模型独立、标准外部化
原则 3 · 闭环迭代
评估反馈驱动持续优化,渐进式重试逐轮缩小范围,预算前重后轻
原则 4 · 自适应
评分维度和权重根据任务类型动态调整,用户标准自动提升匹配维度权重
原则 5 · 可追溯
每次迭代的输入/输出/评估结果完整记录,问题定位到具体子任务,修改建议可操作
原则 6 · 最小充分
上下文按需分阶段注入,每个 Agent 恰好够用——既不信息饥饿,也不过载
下一篇预告:我们将深入业界主流多智能体框架——LangGraph、AutoGen、CrewAI,对比它们在编排模式、评估反馈、生产就绪度上的差异,并给出选型决策矩阵。