# 智能体评测与评估体系调研：从共享底座到分层建设

版本：v1.1
更新日期：2026-11-15

## 摘要

**结论。** A 选型（同一任务更换智能体或模型）与 B 迭代（agent、skill、prompt 版本对比并用轨迹定位问题）共享“任务集—执行轨迹—评分器—数据集与运行记录”的底层结构，平台层有明显工作流复用，但不构成可直接互换的同一套评测体系：决定成败的是数据总体、通过线、对照设计、统计单位与归因逻辑是否各自成立。四类评测应分层建设；选型成败在控制变量与统计设计，迭代成败在私有回归集与归因；轨迹是桥梁，但应结果优先、过程为辅。平台文档普遍覆盖开发期环节；线上评分与持续抽样的直接表述，本次来源中只见 AWS（持续抽样）与 Langfuse（线上自动评分）；MLflow 有生产监控章节但为 tracing 视角，Google 只提到从生产日志抽样（离线评估）；没有单一来源证明五环节（轨迹采集、评分器、数据集、评测运行、在线评测）端到端打通，统计等价更未获证明。

**建议。** 按“先结果后过程、先回归后能力、先私有后公开”推进：最小可行方案是一个版本化私有回归集、一个结果评分器、一条轨迹留存链路和一道 CI 门禁，先证明“没有退化”，再问“能否更强”。P0 即此四项；P1 为轨迹采集与适配层、judge 基线；人工校准若服务于 P0 的 judge 门禁，须随门禁同期上线，不延后至 P1（见 11.3）；P2 为在线采样、能力集与多 judge。凡承担选型或随机性门禁，统计置信须在该阶段即引入。

**限制。** 证据以厂商与项目自述为主，只能证明“声称具备”，不能证明准确率、成本或跨场景收益。未取得：目标 CLI（opencode、dsh、pi）适配证据、国内非厂商企业公开案例、独立第三方对“两类评测同平台”的量化收益对比、固定 harness 后模型差异归因的方法验证，以及部分工具许可与标准成熟度；均列为缺口，不以推断填补。

## 一、方法与证据口径

本报告以公开一手文档为主。主持人于 2026-11-15 实际打开页面并摘录原文；未运行平台或基准，也未保存页面快照。相对上一版（2026-11-13），有五处事实与证据口径需要更新或更正：DeepEval、Ragas 已取得直接来源；MLflow 的生产监控章节为 tracing 视角；OpenTelemetry 独立成仓属实但“迁出核心仓库”未见公告，降为待核；OpenAI 四环节串列属本文归纳；Google 的生产日志抽样属离线评估，不构成在线评测能力。

证据分四级：**已核实**（来源可读且摘录相符，只证明页面文字如此）、**项目方主张**（自述未独立验证）、**判断**（基于材料的推断）、**未取得**（本次未找到，不等于不存在）；另有**页面表述**（按项目方主张计）与**部分核实**。

## 二、两类场景与四类评测

### 2.1 四类评测的划分

划分标准是评测对象、决策用途、数据总体、接受阈值与统计单位，而非用了哪个工具。

| 类型 | 回答的问题 | 可比性来源 | 数据总体 | 通过线 |
|---|---|---|---|---|
| 外部基准与排行榜 | 相对同行处于什么位置 | 公共任务加统一 harness | 公开题 | 排名与分数 |
| 选型评测 | 在自家任务上应当选谁 | 受控环境加重复试验 | 私有代表任务 | 差异显著且值得切换 |
| 迭代（能力/回归） | 能力是否提升、新版本是否退化 | 版本对照加固定门槛 | 版本化私有集；回归题主要来自真实失败 | 能力宽阈值／回归不许退化 |
| 生产在线 | 线上质量是否漂移 | 抽样与分布监控 | 真实流量 | 告警阈值 |

迭代层含两条子线：能力评测探测上限、阈值宜宽，回归守住已承诺行为、接近全通过；共用版本对照方法，通过线不同（判断）。Anthropic 区分两类目标：能力问 “What can this agent do well?”，回归问 “Does the agent still handle all the tasks it used to?”（已核实，E01）。四类划分是本文按决策用途的综合（判断），不构成对任何厂商效果的独立验证。

### 2.2 A 与 B 的位置

A 主要是选型评测，比较完整智能体时还叠加 harness 维度；B 覆盖迭代层两条子线并接在线回流。共享底座的流向是：任务集→执行与轨迹采集→评分器→数据集与运行记录，由此分出选型、迭代回归与生产在线，在线抽样再把失败样本送回任务集。

底座共用不等于口径共用，四类评测在四处互不通用：**数据总体**（选型用代表业务分布的小规模私有集，回归用真实失败构造的版本化集合，在线用流量抽样）、**通过线**（选型看差异是否显著且值得切换，回归不许退化，能力评测允许大量失败）、**对照设计**（选型跨系统受控，回归同系统跨版本配对）、**统计单位与归因**（选型须处理 harness 与模型两因素及任务聚类，回归须固定评分器版本）（判断）。

### 2.3 “同平台”不等于“同体系”

AWS 写明按需评估面向开发与 CI/CD、在线评估持续抽样线上轨迹，并称 “Because both modes use the same evaluators, what you test in CI/CD is what you monitor in production”（项目方主张，E04）。本报告将其概括为开发期与线上评估共用评估器（转述）。这证明产品能力与工作流复用，不能推出统计等价、阈值可迁移或跨场景可比；把“同一平台能跑两者”读成“同一套体系同时服务两者”，是本文要排除的主要概念滑坡。

## 三、选型评测：把 harness 与模型分开

### 3.1 两因素设计

选型至少做两组对照：同一模型跨 harness、同一 harness 跨模型。比较模型时固定 harness、工具集与权限、提示与上下文预算、沙箱镜像、温度与种子、超时与重试、网络条件，并记录模型与路由快照；比较完整智能体时保留各自配置，把差异记为“系统差异”，不归因到模型。Anthropic 的 “the harness and the model working together” 是直接依据（已核实，E01），但该文只支持两者不可分，固定项清单属方法判断。

### 3.2 重复试验与统计

单次测量不足以估计重复执行下的可靠性。τ-bench 以数据库终态判定成功并提出 pass^k；论文报告 gpt-4o 单次成功率不足 50%、零售 pass^8 不足 25%（已核实为论文特定实验，E14），数值不可外推，方法可借用（判断）：重复次数按最小可检测效应与统计功效确定；3 次仅为最低起点，关键选型通常需 5–8 次或更多。结果按任务配对，报告通过率、pass^k 或均值与 95% 置信区间，并用任务级聚类自助法估计。重复次数、最小业务差异与判定规则应在运行前固定，置信区间跨越门槛时转人工复核，不以追加运行凑显著性。有状态任务须在每次运行前恢复数据库、文件与外部服务基线，并核验遗留副作用；运行前恢复不能撤销已发出的消息，不可逆外部动作还须以工具权限、网络出口与服务替身加以约束。超时与崩溃应计入结果，不得择优重跑。

### 3.3 工具底座与证据缺口

Inspect 以 dataset、solver、scorer 三要素组织评测，可在沙箱运行 Claude Code、Codex CLI、Gemini CLI 等外部智能体，支持 Docker、Kubernetes、Modal（已核实，页面标注 2024-05 发布，E11）。OpenCompass 的 AgentCompass 解耦模型、基准、harness 与环境，支持 30 多个基准与 10 多个 harness，Apache-2.0（页面表述，E12）。二者可作控制变量的工程底座。

两个缺口必须写明：opencode、dsh、pi 无实际适配证据，不能就其可比性下结论；“固定 harness 后差异即模型差异”也无独立验证。前者待工程验证，后者待方法验证，都不应写成既成事实；本报告的选型结论都应读作“在该 harness 下”。

## 四、迭代回归：能力与回归两条线

### 4.1 目标与通过线

能力评测探测上限，阈值宜宽，题源可来自公开基准、合成题与专家设计；回归守住已承诺行为，接近全通过，题源主要来自真实失败、事故与工单。Anthropic 建议从 20–50 条取自真实失败的简单任务起步（“20-50 simple tasks drawn from real failures”，已核实，E01），但这是起点而非充分条件：样本是否覆盖高风险路径、评分器是否稳定，决定它能否当门禁。

### 4.2 CI 分级与版本对照

建议四层执行（判断）：PR 级 smoke 只跑高确定性、低耗时核心回归；夜间跑全量；发布前跑完整回归并出对比报告；上线后小流量 canary。CI 内部只分 smoke 与全量两级，发布前完整回归与上线 canary 另列。版本对比须同任务、同环境、同评分器版本；评分器变更时也要复核，否则分数变化无法归因。

### 4.3 私有集、回流与门禁定位

私有回归集应版本化，开发集与隐藏验收集分离，题目定期轮换并做污染探测，防止在评测集上调 prompt 或过拟合。skill、知识库与提示的变更也应作为版本变量纳入同一回归集，避免与执行框架变化混在一起。回流路径是：线上轨迹→筛选失败→脱敏复核→标注→进入回归集，并保留来源、版本与删除机制。门禁定位须分清：回归集适合作常规质量门禁，能力集适合发布说明与选型、不宜设为阻断线，新能力上线前的安全与能力验收另设专门门禁（判断）。

## 五、轨迹评测：结果优先，过程为辅

Anthropic 主张 “it's often better to grade what the agent produced, not the path it took”（已核实，E01），这与微软 Foundry 的步骤比对形成张力：后者分系统与过程两层，其中 Task Navigation Efficiency 以期望工具序列比对工具调用是否高效，匹配含精确、按序与任意序（已核实，E05）。二者不矛盾，差别在优先级（判断）。

- **确定性轨迹匹配**：按消息与工具调用序列比对，LangChain 的 agentevals 包提供严格、无序、子集、超集模式，确定、可复现（已核实，E07；该页介绍的是开源包，速度快、成本低属判断）。适合合规、协议步骤与必须调用的工具，不适合多正解的开放任务，容易把有效路径判错。
- **LLM judge**：更灵活但更不确定，适合语义质量与开放式结果；须配 rubric、盲化候选身份、交换顺序，并以人工标注校准。
- **人工标注**：建立金标准、处理歧义与争议样本，成本最高，应抽样使用。

步数、冗余调用、工具错误率、时延与 token 成本宜作诊断指标与预算约束；只有安全、合规以及契约或协议要求的工具调用才作硬性通过条件（判断）。安全硬条件须具体化：越权访问、数据泄露与被禁止的外部副作用一经确认即判失败，不由成功率或均分抵消，确认由确定性规则或人工复核作出。轨迹差异只产生根因假设，还须回放或消融验证。被测智能体与评分器应隔离权限，以降低轨迹对 judge 的提示注入风险；评分在脱敏派生副本上进行，受控原始证据留存备查，但隔离与过滤不能证明评分器不会被操纵。judge 校准样本应覆盖恶意工具输出、伪造评分指令与敏感信息诱导。

## 六、平台与工具生态

### 6.1 平台能力与 A/B 需求（治理为一级约束）

| 能力 | 解决什么 | A 的需求 | B 的需求 |
|---|---|---|---|
| 执行 harness 与沙箱 | 可复现地运行任务 | 高 | 中 |
| 实验与数据集平台 | 版本对照与可比 | 高 | 高 |
| 可观测与在线评测 | 真实分布与漂移 | 低到中 | 高 |
| 人工标注 | 金标准与校准 | 中 | 高 |
| 治理：权限、版本、成本、回流 | 可持续 | 高 | 高 |

评级为判断。治理不是与其他四项并列的第五类能力，而是横贯四类评测的一级约束（判断）。表中单列一行只为对照阅读。缺少版本、权限与成本约束，评测集会随版本漂移失去可比性。

### 6.2 商业平台：五个环节与逐家证据

本文把“轨迹采集、评分器、数据集、评测运行、在线评测”称为五个环节，这一归纳来自多家产品文档的共性（判断），不是任何厂商的原始分类。逐家看，可证实的环节不同。OpenAI 以轨迹、评分器、数据集与评测运行组织工作流：轨迹记录单次运行的模型与工具调用、护栏与交接，页面写明从单条轨迹走向可重复的数据集与评测；轨迹评分用于比较变更、发现回归（项目方主张，E02、E03；串列为本文归纳）。微软 Foundry 分系统与过程两层，部分评估器仍标 preview（已核实，E05）。Google Vertex AI 支持智能体专用指标、跨厂商头对头、重跑闭环与按提示动态生成的 pass/fail 量表（已核实，E06）。百炼支持智能体与工作流评测、自动评估器与人工标签，每任务最多 10 个评估器，轨迹示例标 ATIF-v1.8、单条不超过 1 MB（页面表述，E18）。

在线环节须逐家区分。AWS 明确持续抽样线上轨迹并面向 CI/CD（已核实，E04），页面虽提及构建与整理测试数据集，却未描述数据集管理能力或运行记录；Langfuse 明确自动评分线上轨迹并支持数据集、实验与并排比较，但无抽样字样（页面表述，E08）；MLflow 有生产监控章节但为 tracing 视角，未取得线上自动评分或抽样表述（页面表述，E10）；OpenAI、微软与百炼的本次来源未涉及在线环节；Google 页面提到可从生产日志抽样评估，属对已有日志的离线评估，未描述线上实时评分或持续监控，不能据此认定其具备在线评估能力。

共性在于复用轨迹、评分器、数据集与运行记录（判断）。差异属产品定位，不等于能力高低，也无独立效果数据可比。厂商自述不能证明跨平台可比性、评分器与人工的一致性、离线与在线的统计等价与投入产出比；绑定专有格式还会带来迁移锁定。没有单一来源同时证明五环节端到端打通。

### 6.3 工具生态的分类

本节含开源项目、商业产品与托管服务，许可与部署须逐项核对，表中只填已核对者，未核对者如实标注。

| 类别 | 代表项目 | 定位 | 许可与部署 | 主要局限 |
|---|---|---|---|---|
| 任务基准 | SWE-bench、τ-bench、AgentBench、Terminal-Bench | 任务、环境与判定 | 未逐一核对 | 结果受时间、模型与 harness 影响，不能直接当选型结论 |
| 执行框架与基准库 | Inspect、OpenCompass/AgentCompass | 统一 harness、组织基准、运行外部智能体 | AgentCompass 为 Apache-2.0；Inspect 未核对 | 需自建评分器与私有集 |
| 通用评测框架与注册表 | OpenAI Evals、DeepEval、Ragas | 依次为：开源基准注册表与模型评分（model-graded）评测；judge 指标、工具正确性与轨迹评测；RAG 指标与测试集生成 | 分别为 MIT、Apache-2.0、Apache-2.0 | Evals 注册表不收含自定义代码的提交（投稿政策）；另两者版本与边界未核对 |
| 实验与可观测平台 | LangSmith、Langfuse、Arize Phoenix、MLflow | 轨迹评测（agentevals 包）、数据集与实验、线上自动评分、OTel 轨迹与重跑（能力合并列示，非逐项对应） | LangSmith 为商业平台；其余未逐一核对 | 本表四家中，生产监控的直接表述以 Langfuse 的线上自动评分与 MLflow 的 tracing 章节为限 |

依据（页面表述或已核实的页面自述，均不证明效果）：SWE-bench 用真实 issue 与 Docker 复现，Verified 为 500 个工程师确认可解的问题（已核实，E13）；AgentBench 覆盖 8 类环境（已核实，E15）；Terminal-Bench 在沙箱终端评测，beta 约 100 任务（已核实，E16）；OpenAI Evals 为 MIT 框架与开源注册表，提供 Completion Function Protocol（已核实，E17）；DeepEval 提供工具正确性、完整轨迹评测、合成数据与 CI 集成（页面表述，E21）；Ragas 提供 RAG 指标与测试集生成（页面表述，E22）；LangSmith 定价页列免费层、按成员收费与企业方案，未称开源（已核实，E23）。Langfuse、Phoenix、MLflow 的定位与限制见表行，其许可与版本未逐一确认（E08、E09、E10）；DeepEval、Ragas 未运行验证。

### 6.4 国内实践

可核实三类：百炼提供评测集与轨迹评测（页面表述，E18）；OpenCompass/AgentCompass 提供开源评测平台（Apache-2.0，页面表述）；中国信通院 2026 年启动智能体安全系列评测，覆盖场景任务类安全、行业任务类安全、应用安全保障能力与应用安全成熟度四维度（已核实，E19），但未取得方法细则与结果。国内非厂商企业的公开建设案例未取得，报告不写“不存在”，只记为缺口。

## 七、标准与互操作

OpenTelemetry GenAI 语义约定仓库定义生成式 AI 的 spans、metrics 与 events，并覆盖 MCP 与厂商特定约定（部分核实，E20）。独立成仓属实，但“原页面已迁出核心仓库”未见公告，智能体与工具的命名及成熟状态也未见声明，均列为待核。它是最有潜力的跨平台采集底座（判断），前提是字段成熟度确认。ATIF-v1.8 只见于百炼的轨迹示例，不能认定公开标准，其 1 MB 限制是产品约束。对企业的含义：以 OTel 作采集与导出底座（判断），自建轨迹适配层，在受限存储保留原始 JSON 并设保留期限，删除要求覆盖派生的回归副本与导出副本，字段与 schema 版本化；不把私有格式硬编码为标准，不在成熟度未明时写死字段名。

## 八、质量陷阱与校准

| 陷阱 | 表现 | 校准措施 |
|---|---|---|
| 污染与过拟合 | 公开题进入训练或提示调优 | 隐藏集、时间切分、题目轮换、污染探测 |
| judge 偏差 | 偏爱长答案、自身风格或特定位置 | 盲化候选、交换顺序、多 judge、人工一致性校准 |
| 静态基准饱和 | 分数触顶失去区分度 | 定期换题，补充高难度与真实失败任务 |
| 单次通过率高估 | 一次成功被当作稳定能力 | 重复试验、pass^k、置信区间 |
| 奖励黑客 | 只优化评分信号，产生真实副作用 | 检查外部状态与副作用，隔离评分器权限 |
| 评测成本 | 全量 judge 不可持续 | 分层采样、便宜检查前置、昂贵复核抽样 |

重复试验的必要性有 τ-bench 方法支持，具体通过率不可外推（E14）。不校准 judge 就当发布门禁是企业常见的技术债（判断）；校准须按场景分别做。若 P0 的结果评分器是 judge，人工校准必须与门禁同时上线。

## 九、组织与工程

所有权三分：中央平台团队负责 harness、轨迹 schema、评分器框架与运行环境；领域团队负责业务任务、阈值与标注；安全与数据治理负责权限、敏感数据与回流审核；门禁由 release owner 签字。评测即代码：数据集与评分器纳入版本管理，配置与镜像记录版本与摘要；受控数据以受控存储中的版本引用纳入。

从 0 到 1 的最小配置约 2 名专职人员（评测负责人与平台工程师）加领域专家兼任（判断），视领域数量与标注量。先用最小配置（一个 harness、一个轨迹存储、人工复核）跑通闭环。生产抽样比例可按流量与成本取 1%–5%（判断），并按风险分级：写操作、权限变更与工具报错提高覆盖率；需按业务校准，不是行业标准。

## 十、趋势判断

判断是：已有平台在能力、回归与在线评测之间复用评估器与工作流，统计口径仍须分别验证。支持面是 AWS 写明两种模式共用评估器并持续抽样（E04），Langfuse 支持线上自动评分（E08），MLflow 有生产监控章节（E10，tracing 视角）；但没有单一来源证明五环节打通。该判断的边界与潜在反证有五项：只有第 1 项直接检验统计等价；第 3 项只影响回放条件与对照可行性，不改变判准：

1. 同一评分器与阈值在离线、在线及跨 harness 长期保持同等精确率与召回率，无需重校准；
2. 公开基准排名与私有选型排名高度相关；
3. 生产样本因权限或脱敏无法可靠回放，离线与在线被迫割裂；
4. 企业采购持续把可观测与评测分开招标；
5. judge 成本使在线全量评分不可行，只能抽样告警。

第 2–5 项分别涉及排名相关性、回放条件、采购行为与成本约束，均不能单独推翻工作流复用；这些观察缺独立量化证据，故“同一体系”仍属产品叙事而非已验证事实。

## 十一、企业建设路线

### 11.1 三阶段路线与季度校准

**规划期**：按四类评测明确用途、owner 与通过线；盘点任务、轨迹与数据；决定买或建；用 2–4 周小规模试点；先建回归集，不追排行榜。**实施期**：结果评测优先，从 20–50 条真实失败任务起步；选型做两因素对照与重复试验；接入 OTel 轨迹与适配层；judge 与人工做一致性校准；CI 内再分 smoke 与全量两级（见 4.2 节）。**应用期**：发布门禁、季度基准刷新、生产采样、事故转任务、成本与权限治理、失败回滚。季度校准与题目轮换是循环项，把失败样本送回实施期，避免评测集随版本漂移失效。

### 11.2 常见失败与禁止项

常见失败：把排行榜当选型结论、跨 harness 直接比模型、用未校准 judge 卡发布、用单次结果定选型、在评测集上调 prompt、把厂商自述当验收。禁止项：不做无版本管理的评测集、不做无对照的单版本对比、不把探索性能力分设为发布线（见 4.3 节）。

### 11.3 优先级与门禁顺序

P0 为私有回归集、结果评分器、轨迹留存（先按现有 harness 的原始记录留档）和一道 CI 门禁。P1 为 OTel 采集与适配层、judge 基线（若 P0 评分器为 judge，人工校准随门禁同期，不列入 P1）。P2 为在线采样、能力评测集与多 judge。凡承担选型或随机性门禁，统计置信须在该阶段即引入，不能推迟到 P2。先做能证明“没有退化”的部分，再做“能否更强”的部分。门禁硬约束：安全硬失败必须直接阻断发布，不由成功率或均分抵消；安全检查未完成或无法判定（超时、崩溃、轨迹缺失）即暂停放行，不静默通过，由 release owner 裁决并留痕；若 P0 的评分器是 judge，人工校准须同期完成。20–50 条起步集通常覆盖不到低频高损安全事件，安全验收仍靠专门门禁与执行时权限检查，生产抽样不能替代。违规与泄露检查宜用确定性规则前置，judge 用于语义质量与抽样复核（判断）。

## 十二、未决分歧与证据缺口

以下分歧未整体采纳为主干表述（个别仅部分采纳），缺证据的事项一并列明，供读者判断；它们不影响前文的建设顺序。

**术语：一套基础设施，还是“同一体系”。** 有意见认为 A 与 B 可称“同一体系”，前提是只共享底座、不共用口径。本报告未采用：“体系”兼指设施与口径两层，易被读成“口径可互换”。本报告的定义是“一套基础设施、四类口径”，分歧属命名而非实质；全文“同一套评测体系”均指口径层。

**过程约束的边界。** 有意见主张过程指标应一律作软约束，不得设为硬性阻断。本报告部分采纳：常规过程指标只作诊断与预算约束，仅安全、合规以及契约或协议要求的工具调用三类作硬条件（判断）；并保留该意见的警告：过度精确的轨迹匹配会惩罚有效的替代解法。

**选型归因的有效性。** “固定 harness 后差异即模型差异”没有独立验证。本报告据此把选型结论限定在具体 harness 下，但该限定本身仍是未闭环的方法问题。

**统计等价的边界。** 同一评分器跨离线、在线与跨 harness 是否同等判准，没有证据。引用厂商“共用评估器”应停在“工作流复用”，不能延伸为阈值可迁移。

**算力与复现成本。** 有建议主张加入沙箱瞬时重建与上下文缓存基线，并以“确定性规则初筛→judge 抽检→人工复核”三级漏斗控制算力。粗粒度漏斗已体现在第八节的成本一行，细粒度策略与沙箱、缓存基线未验证，留待后续版本。

**回流合规替代。** 有意见主张只提取失败模式、以合成任务入集。本报告将其列为补充选项：合成可降低真实数据暴露，但不消除删除义务与敏感残留风险，也不能替代对原失败机制的验证。

**证据缺口。** opencode、dsh、pi 的适配证据；跨 harness 的排序稳定性；国内非厂商企业公开案例；第三方对“两类评测同平台”的量化收益对比；Langfuse、Phoenix、MLflow 的许可与版本；OTel 智能体 span 的命名与成熟度；信通院安全评测的方法细则，以及行业媒体提及的“评估体系 2.0”官方原文。这些是下一阶段应补齐的实证，不是可略过的注脚。

## 十三、结论

两类场景应建在同一套评测基础设施上，但必须保留四套口径：平台层收敛值得利用，统计层等价不能假设。先建可复现的私有回归集与结果评分器，再补轨迹诊断与在线采样，是风险最低、也最易验证的路径；排行榜、单次结果与未校准的 judge 不足以支撑选型或发布决策。目标 CLI 适配证据、国内案例、归因方法验证与标准细节仍未取得，应作为下一阶段的实证任务，而非结论的前提。

## 附录 A：参考来源

正文中的 E 编号与下列条目一一对应。

1. **E01** Anthropic Engineering, “Demystifying evals for AI agents”, 2026-01-09. https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
2. **E02** OpenAI API Docs, “Agent evals”, 页面未标注日期，2026-11-15 访问. https://developers.openai.com/api/docs/guides/agent-evals
3. **E03** OpenAI API Docs, “Trace grading”, 页面未标注日期，2026-11-15 访问. https://developers.openai.com/api/docs/guides/trace-grading
4. **E04** AWS Machine Learning Blog, “Build reliable AI agents with Amazon Bedrock AgentCore Evaluations”, 2026-03-31. https://aws.amazon.com/blogs/machine-learning/build-reliable-ai-agents-with-amazon-bedrock-agentcore-evaluations/
5. **E05** Microsoft Learn, “Agent Evaluators for Generative AI - Microsoft Foundry”, ms.date 2026-09-30, updated 2026-10-08. https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators/agent-evaluators
6. **E06** Google Cloud Vertex AI Docs, “Evaluation overview”, 页面未标注日期，2026-11-15 访问. https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/evaluation-overview
7. **E07** LangChain Docs, “Evaluate agent trajectory”, 页面未标注日期，2026-11-15 访问. https://docs.langchain.com/langsmith/trajectory-evals
8. **E08** Langfuse Docs, “Evaluation overview”, 页面未标注日期，2026-11-15 访问. https://langfuse.com/docs/evaluation/overview
9. **E09** Arize Phoenix Docs, 页面未标注日期，2026-11-15 访问. https://arize.com/docs/phoenix
10. **E10** MLflow Docs, “LLM and Agent Evaluation”, © 2025. https://mlflow.org/docs/latest/genai/eval-monitor/
11. **E11** Inspect Docs, 页面标注 “Released May”（2024-05）. https://inspect.aisi.org.uk/ ；仓库 https://github.com/UKGovernmentBEIS/inspect_ai
12. **E12** OpenCompass GitHub 仓库, “What's New” 2026-09-30. https://github.com/open-compass/opencompass
13. **E13** SWE-bench GitHub 仓库, README 最新条目 2026-09-01. https://github.com/SWE-bench/SWE-bench
14. **E14** τ-bench, arXiv:2406.12045, 2024-06-17. https://arxiv.org/abs/2406.12045
15. **E15** AgentBench GitHub 仓库, ICLR 2024. https://github.com/THUDM/AgentBench
16. **E16** Terminal-Bench GitHub 仓库, beta 期约 100 任务. https://github.com/laude-institute/terminal-bench
17. **E17** OpenAI Evals GitHub 仓库, © 2026. https://github.com/openai/evals
18. **E18** 阿里云帮助中心（百炼），“评测任务”“添加轨迹评测数据”, 页面未给出具体更新日期，2026-11-15 访问. https://help.aliyun.com/zh/model-studio/agenteval-evaluation-task ；https://help.aliyun.com/zh/model-studio/agenteval-evaluation-set-trajectory-data
19. **E19** 中国信通院 AI Hub, 2026 年智能体安全系列评测. https://aihub.caict.ac.cn/docs/6YLKEY9XztYo
20. **E20** OpenTelemetry GenAI Semantic Conventions GitHub 仓库, 2026-11-15 访问. https://github.com/open-telemetry/semantic-conventions-genai
21. **E21** DeepEval GitHub 仓库（confident-ai/deepeval），2026-11-15 访问. https://github.com/confident-ai/deepeval
22. **E22** Ragas GitHub 仓库（explodinggradients/ragas），2026-11-15 访问. https://github.com/explodinggradients/ragas
23. **E23** LangChain Pricing, 2026-11-15 访问. https://www.langchain.com/pricing

## 附录 B：缩写

- agent：智能体，本文指模型与执行框架（harness）的组合。
- harness：执行框架，负责工具调用、上下文管理、沙箱与环境交互。
- CI/CD：持续集成与持续交付。
- LLM judge：以大语言模型作为评分器的评估方法。
- pass^k：同一任务重复 k 次全部成功的概率，用于衡量可靠性。
- P0/P1/P2：本报告的建设优先级；P0 为最小可行项，P1 为增强项，P2 为扩展项。
- release owner：发布责任人，负责门禁裁决与放行签字。
- OTel：OpenTelemetry，跨平台可观测数据规范。
- ATIF：阿里云百炼轨迹数据示例中出现的 schema 版本标识，本文不认定其为公开标准。

## 附录 C：更新历史

### C.1 v1.0-r1（2026-11-13，初稿）

- 确立主结论：两类场景共享底座、不共享口径，四类评测分层建设。按首轮意见成稿，方法与证据口径、四类划分、选型与迭代方法、轨迹评测边界、平台与生态盘点、建设路线进入正文。

### C.2 v1.0-r2（2026-11-13，修订）

- 收窄平台在线能力表述：按家写明已证实的环节，删除“两家合计覆盖完整闭环”的概括；补充方法判断标注；统一开源生态的四类分法与起步样本量表述。

### C.3 v1.0-r3（2026-11-13，修订）

- 逐家改写在线环节与抽样表述；限定评测注册表投稿政策的范围，删除由投稿政策外推的能力结论；修正“四类口径”与枚举项数不一致，补转述标注。

### C.4 v1.0-r4（2026-11-13，修订）

- 更正评估器复用的直引与转述关系；把商业可观测产品与开源项目分开表述；补平台工具生态的许可提示；精简重复论证与若干归属表述。

### C.5 v1.0（2026-11-13，定稿）

- 版本号转为正式版本 v1.0；本版正文与上一工作稿内容一致。

### C.6 v1.0-r1（2026-11-15，再次审议工作稿）

- 按再次审议要求重组章节：摘要改为先给结论、建议与限制；概念边界、选型、迭代、轨迹、平台、标准、校准、组织、趋势、路线依次展开；未决分歧单列一章并剥离已采纳事项。
- 证据更新：DeepEval、Ragas 取得直接来源并纳入工具生态，相应缺口删除；MLflow 补记生产监控章节并区分其 tracing 视角；OpenTelemetry 迁移降为待核；明确“轨迹—评分器—数据集—评测运行”为归纳而非原文列举；LangSmith 补记商业属性与定价依据。
- 表述修订：定义“五个环节”；把“复用部分数据和工作流”改为“复用评估器与工作流”；安全硬失败的确认主体明确为规则或人工复核；治理表述改为与实验平台同列一级约束；流程项“三阶段”补足季度校准循环；删去无来源的标准维度转述。
- 结论未变。

### C.7 v1.0-r2（2026-11-15，再次审议第 2 轮复审后修订）

- 消除摘要与正文在人工校准上的时序冲突：摘要与 11.3 一并改为“P0 评分器为 judge 时校准随门禁同期，不列入 P1”。
- 修正未决分歧章引导句与“部分采纳”条目的字面冲突；在线环节表述补“本次来源中”限定；治理改为“横贯四类评测的一级约束”；第十节补明第 3 项只影响回放与可行性。
- 收窄三处引文：Inspect 日期改标“页面标注 2024-05 发布”；Google 改为“按提示动态生成的 pass/fail 量表”；OpenAI Evals 不再列“judge 指标”，改按页面自述的模型评分定位。
- 吸收实施细化：重复试验须运行前固定次数与判定规则、跨门槛转人工复核；有状态任务逐次恢复基线；安全检查故障闭锁；原始轨迹受限存储、保留期限与派生副本删除；生产抽样按风险分级。
- 结论与建议优先级未变。

### C.8 v1.0-r3（2026-11-15，再次审议第 3 轮复审后修订）

- 补全引用链：E01 补足整句、E03 恢复单列、E05 补记三个匹配取值、E11 注明页面日期 2024-05；6.3 表补“本表四家中”限定。
- 补入实施限定：重复次数以统计功效为准、不可逆外部副作用、门禁暂停放行由 release owner 裁决、低频高损事件不由 20–50 条起步集覆盖、judge 校准纳入对抗样本。
- 第十二节补回流合规替代选项与跨 harness 排序稳定性缺口；摘要与 6.2 明确 Google 生产日志抽样属离线评估。
- 结论、优先级与门禁规则未变。

### C.9 v1.1（2026-11-15，定稿）

- 版本由 v1.0 升为 v1.1（升第二位）：核心结论、总体建议与 P0–P2 优先级未变，本次为章节重组、证据与来源更新、表述修订及实施限定补充。

> 版本标记中的轮次指当次审议的轮次。2026-11-13 的 v1.0-r1 至 v1.0-r4 为首次审议的工作稿记录；2026-11-15 起为对已发布 v1.0 的再次审议，轮次重新计数。