给 AI Agent 装上"裁判眼"2:从任务分解到评估反馈的多智能体协作全链路

admin · 2026-05-15 · architecture · multi-agent · MainAgent · EvalAgent · DAG · LLM-as-Judge · workflow

给 AI Agent 装上"裁判眼"2:从任务分解到评估反馈的多智能体协作全链路

给 AI Agent 装上"裁判眼"2:
从任务分解到评估反馈的多智能体协作全链路

当 MainAgent 拆解任务、Sub-Agent 并行执行、EvalAgent 独立评审——一条从需求到交付的完整闭环

作者: admin 2026-05-15 buddyMe v0.1.35

上一篇:Eval 系统从零到落地的完整实录

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: 结果合并 → 计算加权总分 = Σ(维度分数 × 维度权重) → 通过/不通过判定

评估报告示例(导览攻略任务)

评估报告摘要
维度分数权重关键发现
准确性850.25地址正确、闭馆日正确;穿衣建议缺乏具体温差数据
完整性900.20所有必需模块已覆盖
一致性780.158个展馆仅规划4小时,平均每馆30分钟偏紧
格式合规950.15HTML 结构完整,移动端适配良好
可读性880.15文案流畅,层次分明;部分段落可拆分
时效性920.10天气数据包含查询时间戳,为当天结果
加权总分: 87.5
VERDICT: PASS
改进建议(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,对比它们在编排模式、评估反馈、生产就绪度上的差异,并给出选型决策矩阵。
一句话引用:当 MainAgent 拆解任务、Sub-Agent 并行执行、EvalAgent 独立评审——一条从需求到交付的完整闭环。涵盖任务输入设计、DAG 构建、调度执行、六维评估模型、双轨评估架构与反馈闭环迭代。