AWS 开源 UAEF：统一多框架智能体评测与回归检测

摘要：AWS 发布并开源通用智能体评测框架 UAEF，通过适配器将 LangGraph、LangChain、Strands Agents、Bedrock AgentCore 与 Langfuse 的执行轨迹统一为 AgentTrace，再以 36 项指标覆盖工具调用、响应质量、安全、延迟、多轮对话、多智能体协作和推理七个维度。系统结合 DynamoDB、S3、Python API 与低代码界面，支持版本对比、回归分级、离线评测和在线监控。其价值在于降低框架迁移成本，但 LLM-as-a-judge 指标仍存在模型偏差、调用成本与评测稳定性限制。

---

核心设计：先统一轨迹，再统一评分

AWS 开源的 Universal Agent Evaluation Framework（UAEF）把智能体评测从特定框架中抽离出来。LangGraph、LangChain、Strands Agents、Amazon Bedrock AgentCore、Langfuse 以及自定义框架分别使用不同的消息结构、工具调用格式与智能体交接协议，UAEF 通过适配器把这些原生执行记录转换为统一的 AgentTrace 或 MultiAgentTrace。后续指标引擎只处理规范化轨迹，不再直接理解框架私有格式。

这一分层带来两个直接结果：同一个数据集可以评测不同框架构建的智能体，同一套评分逻辑也能在本地、HTTP 端点和托管运行时之间保持一致。团队既可以导入已有轨迹，也可以让 UAEF 根据 ARN 或 HTTP 地址主动调用智能体，采集输出后同步完成适配。

不过，“框架无关”并不等于“语义完全等价”。适配器能否完整保留并行工具调用、隐式状态、重试、内部路由和交接失败，决定了不同框架之间的比较是否有效。生产使用前应针对每个适配器建立轨迹保真测试，尤其要检查丢失事件是否会被误判为智能体本身的能力退化。

七个维度与 36 项指标

UAEF 内置 36 项指标，并将结果统一归一化到 [0,1]：

• 工具调用：检查工具选择、调用顺序、参数质量与 MCP 合规性。
• 响应质量：评估相关性、完整性、准确性、忠实度与幻觉。
• 负责任 AI：覆盖安全性、毒性、偏见和提示注入检测。
• 性能：衡量延迟、Token 效率、成本效率与吞吐量。
• 多轮对话：跟踪上下文保持、连贯性、目标完成和轮次效率。
• 多智能体协作：评估任务委派、工作流完成度、智能体利用率和协调开销。
• 推理：检查逻辑一致性、步骤正确性和推理谬误。

指标分为两类。确定性指标直接从轨迹与参考答案计算，重复执行可复现，适合工具序列、参数校验、延迟和 Token 统计；LLM-as-a-judge 指标则通过 Amazon Bedrock 上的评审模型评价相关性、安全性等难以写成闭式规则的质量维度，并可接入 RAGAS、DeepEval 或自定义指标。

参考答案并非强制项。只有依赖参考答案的指标需要 Answer 或 expected_tool_calls；工具调用评测要定义工具、顺序和参数，因此数据集必须包含结构化期望轨迹。UAEF 会跳过缺少真值的数据，这方便接入无标签生产流量，但也意味着不同数据集计算出的总分不能直接横向比较。

LLM 评审的安全与统计边界

UAEF 将智能体输出视为不可信输入，而不是评审提示中的指令。评审规则与待评内容分开传递，内容会被转义，评审结果必须引用待评文本中的原文片段；找不到对应证据的评分会被拒绝。这种设计能够降低智能体通过提示注入操纵评审模型的风险，但不能消除评审模型自身的误判、位置偏差或模型偏好。

UAEF 也明确指出，LLM 评审分数只是评测信号，不应承担运行时安全门禁职责。生产链路的实际拦截仍应由 Amazon Bedrock Guardrails 等独立控制面完成。若团队将 UAEF 分数用于发布门禁，还应补充评审模型版本、采样参数和提示模板，否则同一轨迹在模型升级后可能产生不可比的结果。

统计上，[0,1] 的归一化便于组合展示，但不意味着不同指标可以直接平均。安全、延迟、成本与准确率往往具有不同的业务权重，官方未说明总体平均是否采用可配置权重。团队更稳妥的做法是按维度建立硬门禁，并结合样本置信区间，而不是只盯住一个综合分。

实验管理、回归检测与报告

持久化运行时，UAEF 使用 DynamoDB 保存每个实验的元数据和指标平均值，使用 S3 保存包含逐样本分数、评审理由等内容的完整 JSON 结果。一次运行还可以记录框架、模型、工具、系统提示、参数、配置快照与 Git commit，从而把分数与具体代码变更关联起来。

比较引擎针对两次运行共有的指标计算绝对变化和百分比变化。默认以 5% 为变化阈值，并将退化分为轻微（5%–10%）、中等（10%–20%）和严重（超过 20%）。开发者可以指定一个基线，同时比较多个候选版本，并在 Web UI 中按框架或数据集筛选实验。

报告分为三层：结果页展示总体分数、维度雷达图、逐样本结果和失败案例；统计报告从已存分数计算置信区间、离群点、分布、指标相关性及责任 AI 摘要，因此相同输入可重复生成；LLM 生成洞察则进一步归纳优势、潜在根因和下一步修改建议。后者具有较强解释力，但也可能把相关性误写成因果关系，生产团队应回到原始轨迹验证建议。

工程权衡与落地建议

UAEF 的主要收益是减少评测基础设施的重复建设。团队不必为每种智能体框架重写指标、存储与报告逻辑，也可以将 Python API 接入 CI/CD，并用 Web UI 让非开发人员查看实验差异。对于 LangGraph、Strands 和 AgentCore 已有观测栈的团队，导入既有轨迹比重新执行智能体更节省成本。

代价同样明确。第一，LLM 评审会增加 Bedrock 调用量、数据出域要求和运行成本；全量启用 36 项指标往往没有必要，应从业务风险较高的维度开始。第二，S3 中保存完整结果和评审理由可能扩大敏感数据暴露面，必须启用 PII 检测与脱敏，并配置生命周期策略。第三，DynamoDB 与 S3 中间件带来持续成本，AWS CDK 默认采用保留策略，删除服务栈不会自动清除实验数据。

多轮评测还有一个容易忽略的前提：UAEF 按 session_id 和 turn_id 顺序发送输入，但不会替代理重放完整历史，智能体端点必须自行维护会话状态。对于在线评测，追踪数据流还需要考虑采样偏差和隐私治理，不能把全部生产流量直接送入评审模型。

推荐的生产路径是：先选取一个代表性场景和少量高价值指标，建立确定性基线；随后固定评审模型、提示模板与采样参数；将版本对比接入 CI/CD，并以维度级门禁替代单一总分；最后再扩展到多轮、多智能体与在线监控。这样既能获得统一评测层，也能避免为了“全维度”而过早消耗预算。

部署形态与清理注意事项

UAEF 的 Python 库支持 Notebook、脚本及 CI/CD 流水线；可部署服务则提供低代码界面，两条路径复用同一评测引擎和存储。数据集可用 CSV 或 XLSX 提供，Question 是唯一必填列，Answer、检索上下文、期望工具调用以及多轮会话标识均为可选项。

删除实验时，需要分别清空 S3 桶并删除 DynamoDB 表。部署栈的保留策略不会自动销毁结果，这是保护实验数据的刻意设计，但也会产生持续存储费用，生产环境应配套资源清理和成本告警。

---

消息来源：AWS Machine Learning Blog (2026-11-11)

—— 完 ——

主题标签： #AWS 关注 #UAEF 关注 #智能体评测 关注 #LLM-as-a-judge 关注 #开源框架 关注