生产级多 Agent 评测：不能只测最终回答，要沿依赖图定位退化
2026 年 10 月 16 日，AWS 公开一套用于内部销售智能系统的生产级多 Agent 评测框架。系统包含业绩、客户、数据洞察等专用子 Agent；一次数据、工具和 Prompt 没有协同发布，就曾使预生产通过率从 78% 降到 38%。传统监控仍然全绿，因为服务成功返回了内容，只是内容悄悄错了。
这正是多 Agent 评测与单模型 benchmark 的区别：最终答案是依赖图的汇总产物。任何子 Agent 的数据、工具、提示、权限或模型变更，都可能在上游产生局部正确、下游整体错误的结果。
多 Agent 质量门禁必须知道答案来自哪条路径，而不只是给最终文本一个总分。
为每个节点建立质量契约
每个子 Agent 声明输入 schema、允许工具、关键约束和输出证据。聚合器只接受满足契约的结果：
class AgentResult(BaseModel):
agent: str
version: str
claims: list[Claim]
evidence_refs: list[str]
confidence: float
policy_decisions: list[str]
data_snapshot: str
def accept(result: AgentResult) -> bool:
return (
result.confidence >= 0.85
and all(c.evidence_ref for c in result.claims)
and result.data_snapshot == release_manifest.data_snapshot
)
不能把子 Agent 的自然语言直接拼接给总控。结构化声明与证据引用让聚合器能够去重、发现矛盾，并在一个节点退化时停止传播。
评测集要覆盖依赖图
至少准备四层数据集：单工具契约集、单 Agent 能力集、多 Agent 协作集、端到端业务集。再加入安全红队和最近生产失败。每条样本标记预期调用路径，允许合理替代路径，但禁止跳过必须的权限或证据步骤。
case: customer_revenue_90d
expected_agents: [customer_insights, data_insights]
must_use_data_snapshot: sales_2026w41
hard_assertions:
- currency == USD
- unit == dollars
- every_numeric_claim_has_source
soft_scores:
groundedness: 0.90
completeness: 0.85
AWS 案例中的“410.08 被说成 410.08 Million”无法靠 HTTP 成功率发现，却可以被单位一致性与来源断言直接拦截。
联合发布必须有版本清单
多 Agent 系统不能让数据、工具、Prompt 和代码独立滚动到不兼容组合。发布清单绑定每个组件版本，并在运行开始时固定：
{
"orchestrator": "4.3.1",
"agents": {"customer": "8.2", "sql": "5.7"},
"tools": {"revenue_query": "3.0"},
"prompts": {"customer": "sha256:..."},
"data_contract": "sales-v6"
}
CI 先跑组件与链路回归；预生产执行完整快照；金丝雀比较新旧清单；只有整体通过才扩大流量。紧急回滚恢复整个清单，而不是只回滚一个容器。
在线评测不能保存所有敏感内容
生产侧可对轨迹采样，运行规则评测与模型评测，把分数和最小证据写入持久层。高风险错误采用全量规则监控，普通质量采用分层采样。Prompt 与工具结果先脱敏，敏感原文只在受控存储中通过引用访问。
检测漂移时按任务类型和版本分桶。总体通过率稳定，可能掩盖某个地区、角色或子 Agent 已严重退化。置信区间、样本量和分布变化应与分数一起展示。
评测器也需要版本与校准
LLM judge 会受提示和模型更新影响。记录 evaluator 版本，用人工双盲样本校准；安全、金额、权限等硬规则优先用确定性代码。多个评测器出现分歧时进入复核，而不是简单取平均。
生产级九阶段框架的本质可以归纳为：设计指标、构造数据、组件验证、集成回归、发布门禁、金丝雀评分、线上监控、漂移告警、反馈修复。真正的质量操作系统会把失败定位回数据、Prompt、工具或 Agent 代码，并生成下一次发布必须通过的回归样本。