H3 · 如何评估 Agent System 的能力与执行质量？ - Evaluation
所属知识库：Agent 全栈技术地图
所属领域：03 · Agent System
所属章节：03 · 如何让 Agent System 稳定、安全、可控地运行？ - Engineering & Governance
文档类型：评估方法论、实验设计与工程实施专题研究
版本：v1.1
更新日期：2026 年 10 月 28 日
核心问题：面对具有不确定性、工具调用、长期执行和多 Agent 协作能力的 Agent System，如何定义可测量的成功，构建可信评估数据、指标和评审机制，识别质量、成本、安全与可靠性的权衡，并通过可复现的实验决定系统是否可以发布或迭代？
专题导读
本篇属 Engineering & Governance。Agent System 的质量无法仅用模型回答是否流畅来判断。用户要求“完成一份有来源、能复核的产业研究报告”，系统可能生成措辞漂亮的报告，却引用不存在的材料；也可能检索准确但漏掉关键分析；还可能完成任务，却重复调用付费接口、泄露不该访问的文件，或在多 Agent 交接中丢失用户约束。最终产物、过程行为、系统约束与用户价值必须同时进入评价。
本专题以“技术研究报告 Studio”为贯穿案例：用户提出研究任务，选题、检索、分析、审核与发布 Agent 通过 L4 Agent Engine 和 L5 Orchestration & Collaboration 完成任务，L6 Application 向用户交付结果。本文给出从评价对象、指标、数据集、自动裁判、人工标注、实验设计，到持续评估与发布门禁的完整方法。重点讨论如何将“看起来不错”转化为有证据、可比较、可追责的工程判断。
边界说明： H3 Evaluation 判断系统是否达到目标、为什么出现质量差异；H10 Testing & Validation 更侧重功能契约、确定性行为、集成与故障测试；H1 Observability 提供运行证据；H2 Security 规定安全边界；H7 Reliability 衡量服务持续性；H8 Resource Management 管理预算。它们共享数据，但不互相替代。模型本体的通用基准测试也不等同于端到端 Agent System 评估。
一、什么是 Agent System Evaluation？
1.1 定义与评估对象
Agent System Evaluation 是针对特定任务分布、使用场景与运行约束，以可审计的证据判断系统能力、执行过程和交付结果是否满足预先定义目标的方法体系。它不仅是一个“打分器”，还包含目标定义、样本构建、执行环境、结果采集、裁判协议、统计分析、回归门禁和失败归因。
评估对象至少包括五个层次：
- 最终结果（Outcome）：是否完成用户真实目标，产物是否正确、完整、可用。
- 执行轨迹（Trajectory）：步骤选择、工具参数、信息检索、推理产物和协作交接是否合理。
- 约束遵守（Constraints）：权限、时间、成本、隐私、格式、人工审批是否满足要求。
- 运行特性（Operational behavior）：延迟、失败恢复、重试放大、Token 消耗、资源效率。
- 用户价值（User value）：用户能否据此行动，修订工作量是否减少，是否愿意再次使用。
评估的基本单元应明确为 (任务样本, 环境版本, 系统版本, 随机种子或采样配置, 执行记录, 评分结果)。仅记录一条“85 分”的分数，不足以支持复现或归因。
1.2 能力、质量、可靠性和安全不是一个指标
| 维度 | 关键问题 | 示例证据 |
|---|---|---|
| 能力 | 能否解决目标任务？ | 任务成功率 |
| 质量 | 结果是否正确且有用？ | 事实核验、专家评分 |
| 过程 | 是否采用合理步骤？ | 工具轨迹、证据链 |
| 效率 | 用多少资源完成？ | 成本、耗时、调用次数 |
| 稳定性 | 多次执行是否一致？ | 重复实验的分布 |
| 安全 | 是否越过禁止边界？ | 违规率、攻击测试 |
| 体验 | 用户是否容易使用？ | 修订率、任务满意度 |
“平均得分提高”不能自动抵消严重安全事故；高成功率也可能掩盖少量极端高成本任务。建议采用硬性门禁 + 多维指标面板 + 权衡分析，而非把所有指标简单加权成一个总分。
1.3 评估与测试的关系
确定性测试通常回答“接口在给定条件下是否遵守契约”；评估更经常回答“在真实任务分布下，系统做得有多好”。例如，测试可以断言“引用字段必须包含可解析 URL”；评估则进一步判断“该来源是否真实支持这条结论”。两者有交叉：规则型评估可直接成为自动测试，评估数据集也可作为回归测试输入。不要把概率性裁判的单次判断包装成确定性证明。
二、先定义成功：从用户目标到可操作的评价契约
2.1 从任务说明拆出验收维度
以“比较三种 Agent 编排框架并提出技术选型建议”为例，用户真实目标并非“生成 3,000 字”，而是获得能够支持工程决策的比较。可将需求分解为：比较对象正确、版本和资料时效明确、关键能力覆盖、引用可追溯、结论与证据一致、适用条件说明充分、风险和迁移成本可见。
建议为每个评估任务编写 Evaluation Spec：
case_id: research-framework-017
user_goal: "比较三种 Agent 编排框架并给出选型建议"
task_family: comparative_research
input_fixture: "fixtures/framework-017/"
allowed_tools: [web_search, document_reader]
forbidden_actions: [publish_external, modify_source]
required_outputs: [comparison_report, source_manifest]
acceptance:
hard_constraints:
- "不得伪造引用或声称未执行的测试已执行"
- "不得访问其他租户的文档"
graded_dimensions:
- factual_support
- decision_usefulness
- coverage
- uncertainty_calibration
resource_limits:
max_wall_seconds: 900
max_usd: 2.00
review_protocol: "rubric-v3"这是建议的评估契约示例，不是现成框架的标准配置文件。任务要求、禁止行为和预算要在执行前确定，不能看到结果后临时改规则。
2.2 硬约束与软质量分开
硬约束包括越权访问、未授权发布、敏感信息泄露、伪造执行证据、关键结构缺失等。只要违反特定硬约束，即使内容质量很高也应判为不可发布。软质量包括表达清晰、结构完整、建议可操作、引用充分等，适合分级评分。
一个可解释的决策函数是：
release_eligible = all(critical_gates_pass)
AND lower_confidence_bound(success_rate) >= target
AND quality_score >= threshold
AND p95_cost <= budget这里的阈值由业务风险、样本规模和发布策略决定；表达式展示的是决策结构，并非推荐所有系统共用某组阈值。当样本很少时，成功率的置信区间会很宽，应避免将表面改善视为可靠提升。
2.3 任务分布比单一 Benchmark 更重要
公开 Benchmark 有助于横向比较，但通常不能代表私有工具、内部文档、组织权限和真实用户需求。实际评估应覆盖：高频简单任务、长链路复杂任务、边界模糊任务、资源受限任务、工具异常任务、恶意输入和稀有高风险任务。每类应明确抽样比例；线上自然分布与风险加权分布可分别报告，避免把人工强化的危险案例当成日常流量比例。
三、指标体系：从最终产物到每一步行为
3.1 任务成功率及其分母
定义 Task Success Rate = 满足验收条件的任务数 / 纳入评估的任务总数。必须同时规定：超时、用户取消、工具不可用、部分完成、人工接管、重试成功分别如何计入。不能只统计“有输出的任务”，否则会产生幸存者偏差。
研究报告任务可采用两层判定：第一层检查任务是否生成了完整可交付报告；第二层检查关键结论是否得到证据支持。两层同时通过才算完整成功。对于部分完成，应单独报告 partial success，不能混入完全成功率。
3.2 结果质量与事实性
结果质量可拆为：正确性、覆盖度、相关性、逻辑一致性、可操作性、引用质量和不确定性表达。对于开放式研究，**事实支持度（groundedness）**尤其重要：将报告拆成可验证主张，逐条判断“支持 / 反驳 / 证据不足 / 无法判定”，并记录支持材料片段与来源位置。
Supported Claim Rate = 有充分证据支持的可核验主张数
/ 已审查的可核验主张数
Citation Validity Rate = 可定位且与主张相关的引用数
/ 被审查的引用总数两者不可混用：链接存在不代表链接支持论断；引用覆盖高也不代表事实正确。对时间敏感事实还需核对发布日期、资料版本和引用时点。
3.3 过程行为指标
过程指标用于发现“结果偶然正确、过程不可控”的问题，例如：
- 工具选择正确率：所选工具是否适合当前子任务。
- 工具参数有效率：参数是否满足 Schema 和业务约束。
- 关键步骤完成率：是否经过必须的检索、核验、审批环节。
- 无效循环率：重复检索或重复推理但无新增证据的比例。
- 不必要动作率：未带来可识别收益的高成本操作。
- 交接保真率：上游关键约束是否完整传递到下游 Agent。
- 恢复正确率：中断后是否保留必要上下文并避免重复副作用。
注意“最短轨迹”不一定是“最佳轨迹”：医疗、法律、财务和发布等高风险任务需要额外核验，不能简单奖励更少步骤。过程评分应围绕必要性、授权性和有效性，而不是追求唯一标准路径。
3.4 效率、成本和尾部风险
同时报告任务级 wall-clock latency、模型调用时间、工具等待时间、人工等待时间、总 Token、实际账单成本、调用次数和重试次数。延迟至少看 p50、p95，成本至少看均值、p95 和超预算比例。需要区分估算 Token 与供应商实际计费 Token，以及缓存、批处理和不同模型价格版本造成的差异。
当人工审批是产品设计的一部分，应分开报告“机器处理时间”和“包含人工等待的端到端时间”，否则跨版本比较失真。
3.5 多 Agent 协作指标
多 Agent 的价值不是参与 Agent 数量，而是协作是否带来更好的质量或效率。建议测量任务分解合理性、依赖完成率、交接丢失率、冲突解决质量、审核返工有效率、汇总一致性和额外协作成本。要设置单 Agent 或简化工作流作为对照组，避免把复杂性本身当作进步。
四、评估数据集：样本、金标准与环境控制
4.1 五类互补数据来源
| 来源 | 优点 | 主要风险 |
|---|---|---|
| 真实任务脱敏 | 贴近使用场景 | 隐私、选择偏差 |
| 专家设计案例 | 可覆盖关键能力 | 与真实分布偏离 |
| 失败回放案例 | 适合防回归 | 过拟合旧故障 |
| 合成任务 | 扩展覆盖面快 | 模板化、泄漏 |
| 对抗案例 | 发现边界风险 | 不能代表自然流量 |
生产日志不能直接无筛选地作为“真值”。用户点赞可能仅代表语言风格满意，未必代表事实正确；人工修订记录可能包含后续信息，不应倒灌给评估时的 Agent。每条样本要保留来源、授权状态、采集时间、脱敏方式、标签版本和数据保留策略。
4.2 数据切分与污染控制
至少区分开发集（用于设计和调参）、验证集（用于版本选择）和保留测试集（最终报告）。对长周期系统还应设置时间外推集（较新资料）、领域外集（未见任务类型）与高风险集。相似文档、同一用户任务的不同改写和同一案例衍生样本应按案例族分组切分，避免近重复泄漏。
对联网研究任务，模型可接触到不断变化的网页。应提供两种模式：
- 冻结环境评估：固定网页快照、文档版本、工具返回和时间，主要用于可复现回归。
- 开放环境评估：允许实时检索，主要衡量真实可用性；必须记录检索时间、页面版本和外部异常。
冻结环境牺牲部分真实性，开放环境牺牲部分可复现性；两种结果应分开解释。
4.3 金标准不是唯一参考答案
开放式任务往往存在多种有效答案。建议采用“必要事实 + 禁止错误 + 评价量规 + 参考证据”组合，而不是只用字符串相似度。对编程或结构化任务，单元测试、SQL 查询结果、Schema 校验可提供更强的客观证据；对研究报告，专家共识与证据核验更重要。
一个完整样本记录可以包含：case_id、任务描述、上下文快照、授权工具、预期交付、必须满足的事实、可接受替代方案、不可接受行为、评分量规、标签来源、版本和审查者。
4.4 数据集治理
建立数据集版本号与不可变快照。修改标签必须保留修订原因和审批记录；高风险样本限制访问；训练、提示词优化和评估之间明确隔离。出现模型或系统对测试集“刷分”时，应更换保留集并补充真实任务抽样。数据量扩大不自动提高代表性，样本覆盖和标签质量更关键。
五、裁判机制：规则、执行验证、模型裁判与人工审查
5.1 裁判层级与证据强度
优先使用可验证的客观机制，再引入主观判断。典型顺序是：Schema 与规则检查 → 可执行验证 → 来源与事实核验 → LLM-as-a-Judge → 人工专家复核。顺序不表示后者必然较弱，而是不同维度应选择最适合的证据。
| 裁判 | 适合判断 | 不适合单独判断 |
|---|---|---|
| 规则校验 | 格式、字段、禁止动作 | 深层事实正确性 |
| 执行验证 | 代码、查询、工具副作用 | 开放式论证质量 |
| 来源核验 | 引用是否支持主张 | 整体用户价值 |
| 模型裁判 | 相关性、覆盖度、表达 | 事实真值的唯一依据 |
| 人工专家 | 专业判断、复杂权衡 | 无限制大规模实时评分 |
5.2 LLM-as-a-Judge 的正确使用
模型裁判可降低大规模人工评审成本，但存在位置偏差、长度偏好、措辞偏好、模型家族相关性和事实幻觉。建议采用逐维评分 + 明确锚点 + 引用证据 + 不确定项，而不是“请打 1 - 10 分”。
角色：评估员，而不是内容生成助手。
输入：任务要求、候选报告、可核验来源摘录、评分量规。
请分别判断：事实支持、任务覆盖、决策可用性。
每个维度输出：等级、理由、支持证据位置、无法判定项。
不得根据文章长度直接提高分数。
若来源不足，标记“证据不足”，不得补充外部事实。
输出符合指定 JSON Schema。该提示词只是裁判设计示例，不能保证消除偏差。评分时应固定裁判模型版本、提示词版本、温度等参数；对成对比较交换候选顺序；在人工标注子集上检查裁判一致性、误判类型和不同任务族的偏差。若裁判与被评估系统使用相同模型家族，更需要独立核验。
5.3 评分量规（Rubric）设计
推荐使用有行为锚点的 0 - 4 级量规。以“证据支持度”为例：
| 分值 | 判定锚点 |
|---|---|
| 0 | 大量关键主张无依据或错误 |
| 1 | 关键主张存在明显证据缺口 |
| 2 | 部分关键主张有证据，仍有重要缺口 |
| 3 | 主要主张可追溯，少量非关键缺口 |
| 4 | 关键主张充分支持且不确定性清楚 |
评分前应明确“关键主张”的判定规则，并对高风险事实给予独立核验。量规应尽量避免“专业”“深刻”“优秀”等无法操作化的词。对于无法判断的情况使用 N/A 或 insufficient_evidence，不要强行给中间分。
5.4 人工标注一致性
对有争议的任务至少进行双人盲评，并记录分歧与仲裁。分类任务可使用 Cohen's kappa 等一致性指标；有序等级可使用加权 kappa；多评审者可考虑 Krippendorff's alpha。指标选型依赖数据类型与缺失情况，不能机械套用。报告一致性时同时公布标签分布、样本量与典型分歧，因为类别极不平衡时单个系数可能误导。
5.5 何时必须升级人工复核
高风险操作、低置信度、裁判冲突、疑似引用伪造、政策违规、异常高成本以及接近发布门槛的边缘样本，应进入人工复核队列。人工复核不是“兜底万能答案”，同样需要标准、培训、抽样质检和审计记录。
六、轨迹评估：不仅检查答案，还检查 Agent 如何到达答案
6.1 轨迹的数据结构
一个可审查的轨迹至少需要：task_id、run_id、step_id、agent_id、时间戳、动作类型、工具标识、输入摘要、输出摘要、权限判定、状态转换、错误分类、证据引用和关联的产物版本。敏感原文不必全部进入评估仓库，可保存受控引用、哈希和脱敏摘要。H1 负责采集和关联，H3 负责判定行为质量。
6.2 结果正确但过程错误
例如检索 Agent 访问了无权读取的文档，却恰好生成正确结论。仅检查最终报告会将其计为成功，但过程违反硬性安全约束，应判定不可接受。相反，Agent 先检索失败再合法回退至备用来源，虽然轨迹更长，仍可能是正确策略。轨迹评价必须同时理解目标、权限和环境条件。
6.3 关键动作与非关键动作
不是每个步骤都值得人工逐条评估。可建立关键动作清单：外部发布、删除/修改、支付、权限变更、敏感数据读取、跨 Agent 权限委托、最终结论引用等。对关键动作进行全量规则审计；对一般搜索与思考步骤进行抽样、异常检测或模型裁判。
6.4 反事实与归因的限制
看到失败轨迹后可以提出“如果更早检索会更好”的假设，但这不等于因果证明。要确认某组件导致性能变化，最好使用受控消融实验：固定其余条件，替换单个路由策略、提示词、工具或协作结构，再比较结果。Agent 执行具有路径依赖，某一步的修改可能改变后续全部环境，因此“只重放最后一步”常常不足以说明系统级影响。
七、实验设计：让版本比较有统计意义
7.1 明确比较单位
常见比较对象包括：模型版本、系统提示词、检索策略、工具集合、Agent 分工、编排图、审核流程、预算配置。每次实验记录版本指纹：代码提交、配置、模型供应商与模型 ID、提示词模板、工具版本、检索索引版本、数据集快照、裁判版本和运行时间。
7.2 配对实验与重复运行
优先让候选 A、B 在相同任务样本与尽可能相同的环境快照上运行，计算每个案例的差值，而不只比较两组平均数。对于随机性明显的系统，对部分样本重复运行，报告均值、分布与波动。即使温度为 0，也不能假定跨供应商、并发环境或模型更新时结果完全确定。
7.3 置信区间与显著性
成功率是二项比例，可使用 Wilson 区间等方法描述不确定性；配对成功/失败结果可考虑 McNemar 检验；连续评分的配对差值可使用适当的 Bootstrap 置信区间。统计方法须符合抽样方式和独立性假设。对于同一客户或同一任务族的多个高度相关案例，应采用分组重采样或层级分析，不能把它们全部视为独立观测。
示例：在 40 个案例上成功率从 70% 升至 75%，并不能仅凭 5 个百分点差距断言改进稳定成立。应查看哪些案例改善、哪些退化、样本量与置信区间，以及是否出现严重安全回归。
7.4 多目标权衡与 Pareto 前沿
常见权衡是质量、延迟、成本与安全。某版本提高质量 2%，但成本翻倍、p95 延迟增加三倍，未必适合生产。可以展示 Pareto 前沿：若某候选在所有关键指标上不劣且至少一项更好，它支配另一候选；若存在权衡，则依据产品约束选择。硬性安全门禁不可作为一般成本收益权衡项。
7.5 在线实验的特殊问题
A/B 测试需考虑用户随机分组、任务难度差异、用户学习效应、网络效应和跨任务记忆污染。多 Agent Studio 可能产生长期状态，不能让同一工作空间在两个版本间随意切换后仍当作独立样本。线上实验应预设停止条件、风险监控、回滚策略和用户影响评估。
八、完整工程架构：评估系统如何接入 L1 - L6
8.1 建议的组件划分
Evaluation Control Plane
┌───────────────────────────────────────────────────┐
│ Case Registry / Dataset Version / Experiment Spec │
│ Run Scheduler / Environment Snapshot / Budget │
│ Grader Registry / Human Review / Report / Gate │
└──────────────────────┬────────────────────────────┘
│ 执行任务与版本配置
▼
┌───────────────────────────────────────────────────┐
│ Agent System Under Test │
│ L6 Application → L5 Orchestration → L4 Engine │
│ → L3 Model Services │
│ → L2 Services → L1 Infra │
└──────────────────────┬────────────────────────────┘
│ 结果、轨迹、费用、证据
▼
┌───────────────────────────────────────────────────┐
│ Evidence Store → Deterministic Graders │
│ → Source Checks / Model Judges │
│ → Human Adjudication │
│ → Aggregate Metrics / Release Gate │
└───────────────────────────────────────────────────┘Evaluation Control Plane 是逻辑设计概念，并非要求部署独立平台。小规模项目可以从 Python 脚本、版本化 JSONL 和人工复核表开始；只有在多团队、多环境、多版本比较时才逐步引入调度服务与评审平台。
8.2 关键数据实体
| 实体 | 核心字段 | 用途 |
|---|---|---|
| DatasetVersion | id、hash、source | 固定样本集合 |
| EvalCase | case_id、spec、fixture | 定义单个任务 |
| Experiment | candidate、baseline、config | 定义对照 |
| EvalRun | run_id、case_id、version | 记录一次执行 |
| EvidenceBundle | trace_ref、artifact_ref | 汇总证据 |
| Grade | rubric、score、judge_version | 保存评分 |
| Adjudication | reviewers、decision | 处理争议 |
| GateDecision | thresholds、result | 发布判定 |
评分必须引用不可变的 EvalRun 与 EvidenceBundle；如果后续补充新证据或更换裁判，应产生新的 Grade 版本，而不是静默覆盖旧分数。
8.3 最小可行实现路线
阶段一：手工基线。 收集 30 - 50 个具有代表性的任务，制定任务级成功标准，保存原始输出与关键来源，安排人工盲评，建立基线。样本数量只是启动建议，不能视为统计充分性的保证。
阶段二：自动化执行。 固定数据集和环境，批量运行 Agent，自动采集 Run、Step、工具调用、产物与成本，加入 Schema、权限和引用有效性规则。
阶段三：混合裁判。 引入模型裁判和来源核验，保留人工校准集，分析不同任务族的裁判误差与一致性。
阶段四：持续评估。 接入 CI/CD 和发布流程：每次关键模型、提示词、工具或编排改动触发回归；每天或每周抽样线上案例；按风险级别执行发布门禁。
阶段五：闭环优化。 将失败案例按根因归档，转化为回归集，并通过消融实验确认修复有效，避免只针对个别样本改提示词。
九、研究报告 Studio：端到端评估案例
9.1 业务场景与候选系统
任务：“分析某细分行业过去三年的市场变化，比较主要参与者，并给出未来一年可执行的进入建议。”候选 A 使用单 Agent 加检索工具；候选 B 使用选题、检索、分析、审核四类 Agent；候选 C 在 B 基础上增加独立事实核验环节。实验目标是判断额外协作是否提升证据质量，以及提升是否足以覆盖成本和延迟。
9.2 案例集设计
将案例分为事实检索、比较研究、综合判断、资料冲突、信息不足、过期资料、访问受限与异常工具返回八类。每类设计明确验收标准，并标记高风险事实。对于来源经常变化的案例，保存检索快照并记录采集日期。
9.3 评价矩阵
| 维度 | 测量方法 | 失败示例 |
|---|---|---|
| 任务完成 | 必要章节与目标检查 | 缺少进入建议 |
| 事实支持 | 主张逐条核验 | 数据无来源 |
| 来源质量 | 引用定位与时效检查 | 引用不支持结论 |
| 分析有效性 | 专家量规 | 建议无法执行 |
| 过程合规 | 工具轨迹与权限审计 | 越权读取文件 |
| 协作质量 | 交接与返工记录 | 审核意见未落实 |
| 效率 | 任务成本与 p95 延迟 | 反复无效检索 |
| 稳定性 | 同任务重复运行 | 结论大幅漂移 |
9.4 示例评分与门禁
假设某研究案例：内容完整性 4/4，事实支持 2/4，建议可执行性 3/4，成本合格，且未发生越权。此时不应因平均分 3/4 就直接发布：事实支持度低于研究报告的必要标准，应进入核验返工。再如，事实支持 4/4 但发布 Agent 未经授权直接公开报告，则触发安全硬门禁，任务判为不可发布。
这些分值用于解释规则，不代表真实系统的测量结果。
9.5 如何判断多 Agent 是否值得
比较 A/B/C 的配对任务成功差异、证据支持率、专家评分、成本与尾部延迟，并单独观察哪些任务族受益。例如复杂资料冲突案例可能因独立审核明显改善，而简单事实检索可能因额外交接变慢。可以采用按任务复杂度路由的混合策略，但必须用独立验证集确认该策略有效，避免事后挑选有利案例。
十、失败分析与持续改进
10.1 失败分类法
建议以“可行动的根因”为中心建立标签体系：任务理解错误、检索覆盖不足、证据误读、模型推理错误、工具参数错误、工具不可用、上下文丢失、协作交接失败、审核失效、状态恢复错误、权限拒绝处理不当、预算耗尽、用户需求不明确等。一个失败可以有多个原因，但应标注主要触发点与证据。
10.2 从指标退化到根因定位
例如版本升级后事实支持率下降：先确认数据集与裁判版本未变化，再查看是否集中于特定任务族；随后比较检索命中、引用来源、摘要压缩、Agent 交接与最终写作阶段。H1 的 Trace 证明“发生了什么”，H3 的量规判断“质量为何下降”，消融实验进一步检验“哪个变更造成下降”。
10.3 防止 Goodhart 式指标优化
一旦某个指标成为唯一目标，系统可能学会迎合指标而非用户价值。例如追求引用数量会制造无关引用；追求步骤数减少会跳过必要核验；追求裁判分数可能增加华丽但空洞的表达。应持续审查指标与真实业务目标的相关性，并保留独立人工抽样与用户任务完成证据。
10.4 漂移与重新评估
模型版本、工具接口、知识库内容、用户群体和任务难度变化，都会导致历史分数失效。需要定义触发重新评估的事件：模型或提示词变更、检索索引重建、工具权限调整、重大事故、线上质量持续退化、新任务族进入生产等。历史评估结果应标注适用版本和有效时间范围。
十一、评估的常见误区与工程纠偏
误区一：只评估最终文本。 纠偏：同时审查关键轨迹、权限、引用、成本和用户价值。
误区二：让一个模型直接给所有结果打总分。 纠偏：客观检查优先，分维度量规，模型裁判与人工校准结合。
误区三：把 Benchmark 排名当成系统上线依据。 纠偏：使用私有任务分布、真实工具与权限环境进行端到端评估。
误区四：用测试集反复调提示词。 纠偏：区分开发、验证、保留测试集，并按案例族防止近重复泄漏。
误区五：只看均值。 纠偏：报告分位数、失败类型、置信区间、极端成本和关键任务族。
误区六：认为 LLM-as-a-Judge 可以替代事实核验。 纠偏：对关键事实使用可定位证据与独立复核。
误区七：把一次成功当作稳定成功。 纠偏：重复运行，测量方差、失败概率和环境依赖。
误区八：认为 Agent 越多越好。 纠偏：用单 Agent 基线和配对消融证明协作增益。
误区九：把安全事故平均进质量分。 纠偏：关键安全约束独立设置硬门禁。
误区十：将线上用户反馈直接作为正确答案。 纠偏：反馈可作为线索，但需与事实核验、任务成功和代表性抽样结合。
十二、可执行的最小评估实验
12.1 实验目标
验证一个最基础的评估聚合器是否能：①计算任务成功率；②独立识别硬性安全失败；③汇总成本；④阻止“高平均分掩盖安全违规”。以下代码仅使用 Python 标准库，输入为模拟评分记录，不涉及真实 Agent 或 LLM 裁判。配套文件 H3-Agent-System-Evaluation-v1.1-demo.py，Python 3 标准库（含 3.9）。运行：python3 H3-Agent-System-Evaluation-v1.1-demo.py。
from __future__ import annotations
from dataclasses import dataclass
from statistics import mean
@dataclass(frozen=True)
class EvalRecord:
case_id: str
success: bool
quality: float
critical_violation: bool
cost_usd: float
def summarize(records: list[EvalRecord]) -> dict:
if not records:
raise ValueError("Evaluation set must not be empty")
if any(not (0 <= r.quality <= 4) or r.cost_usd < 0 for r in records):
raise ValueError("Invalid score or cost")
return {
"cases": len(records),
"success_rate": sum(r.success for r in records) / len(records),
"mean_quality": mean(r.quality for r in records),
"total_cost_usd": sum(r.cost_usd for r in records),
"critical_violations": sum(r.critical_violation for r in records),
"release_eligible": all(not r.critical_violation for r in records),
}
sample = [
EvalRecord("case-1", True, 4, False, 0.20),
EvalRecord("case-2", True, 4, True, 0.30),
EvalRecord("case-3", False, 1, False, 0.10),
]
result = summarize(sample)
assert result["cases"] == 3
assert abs(result["success_rate"] - 2 / 3) < 1e-12
assert result["critical_violations"] == 1
assert result["release_eligible"] is False
print(result)本地执行通过：输出 {'cases': 3, 'success_rate': 0.6666666666666666, 'mean_quality': 3, 'total_cost_usd': 0.6, 'critical_violations': 1, 'release_eligible': False}。
这里 release_eligible 只展示硬性违规门禁，真实发布还必须增加质量阈值、样本充分性、统计不确定性、延迟和成本条件。代码不支持概率置信区间，也不能判断模拟分数是否正确。
12.2 建议的集成验收清单
- 同一数据集、配置和环境快照可重复运行，生成可关联的实验 ID。
- 每次执行保存输入、输出、关键轨迹、产物哈希与计费证据。
- 规则裁判可独立复现，模型裁判记录模型与提示词版本。
- 关键安全违规在高质量评分下仍触发发布阻断。
- 不同候选使用同一案例集并报告配对差异。
- 人工评审具有盲评、争议仲裁和一致性检查。
- 线上数据经授权、脱敏和保留策略处理。
- 失败样本进入回归集时，记录原因并防止污染保留测试集。
十三、研究结论
结论一：评估的对象是 Agent System 完成真实任务的能力，不只是模型输出。 最终产物、执行轨迹、权限约束、成本和用户价值共同决定系统是否可用。
结论二：成功标准必须在实验前明确。 对开放式任务，应以任务验收契约、关键事实、评分量规和禁止行为组合定义成功，而非依赖单个参考答案。
结论三：自动评估应采用混合裁判体系。 Schema、可执行验证和证据核验提供客观基础；模型裁判扩大覆盖；人工专家负责校准、争议和高风险判断。
结论四：评估结果必须可复现、可比较、可归因。 数据集、环境、模型、提示词、工具、裁判及产物均需版本化；比较应采用配对实验、适当重复和不确定性分析。
结论五：发布决策不能被平均分绑架。 安全硬门禁、关键任务成功率、质量分布、尾部成本和延迟需要分别呈现。
结论六：多 Agent 的价值需要通过实验而非架构复杂度证明。 应与单 Agent 基线比较，按任务族识别协作的真实收益和代价。
结论七：评估是持续工程机制。 系统、数据和环境变化会使旧结果失效；线上抽样、失败归因、回归评估和重新校准应构成长期闭环。
附录 A：参考文献与原始资料
以下列出与本专题方法和工具有关的主要公开资料。链接用于进一步核验；具体接口、模型和框架能力可能随版本变化。本文中的 Studio 案例、指标组合、Evaluation Spec 和工程架构属于综合设计建议，不应误认为以下资料原文提供的统一标准。
- [R1] OpenAI, Evaluation best practices：platform.openai.com/docs/guides/evaluation-best-practices
- [R2] OpenAI, Evals API：platform.openai.com/docs/api-reference/evals
- [R3] LangSmith, Evaluation concepts：docs.smith.langchain.com/evaluation/concepts
- [R4] LangSmith, Evaluate a dataset：docs.smith.langchain.com/evaluation/...te_llm_application
- [R5] Arize Phoenix, Evaluations：arize.com/docs/phoenix/evaluation/overview
- [R6] DeepEval, Documentation：deepeval.com/docs/getting-started
- [R7] NIST, AI Risk Management Framework (AI RMF 1.0)：www.nist.gov/itl/ai-risk-management-framework
- [R8] NIST, AI RMF Generative AI Profile：www.nist.gov/itl/ai-risk-management-...telligence-profile
- [R9] OpenTelemetry, Semantic Conventions for Generative AI：opentelemetry.io/docs/specs/semconv/gen-ai
- [R10] SWE-bench, Benchmark and repository：www.swebench.com
- [R11] Stanford HELM, Holistic Evaluation of Language Models：crfm.stanford.edu/helm
- [R12] Anthropic, Building effective agents：www.anthropic.com/engineering/building-effective-agents
- [R13] Microsoft, AutoGen documentation：microsoft.github.io/autogen/stable
- [R14] OpenAI, Agents SDK documentation：openai.github.io/openai-agents-python
- [R15] LangGraph, Documentation：docs.langchain.com/oss/python/langgraph/overview
A.1 如何使用这些资料
R1 - R6 主要用于了解评估流程、数据集、自动裁判与工具实践；R7 - R8 提供风险治理背景；R9 支持运行证据采集的标准化思路；R10 - R11 用于理解公开基准的适用边界；R12 - R15 帮助理解不同 Agent 架构的运行方式。公开基准并不天然覆盖私有工具、组织权限和真实业务成功标准。
附录 B：研究证据、验证声明与适用边界
B.1 内容来源与证据等级
- 标准或官方资料支持的概念：风险管理框架、评估 API/工具的基本用途、生成式 AI 追踪规范及相关框架的公开架构概念。
- 研究综合与工程建议：本文的五层评估对象、硬门禁设计、评价矩阵、Studio 数据实体、实验阶段路线和示例量规，是针对 Agent System 的设计性归纳，非某一官方标准的逐条规定。
- 示例性假设：样本规模、预算、分值、发布条件和 A/B/C 对照架构均为说明方法而设，不代表真实生产数据。
B.2 验证声明
本文没有执行真实模型、联网检索、第三方评估平台、人工专家盲评或生产环境 A/B 实验；不宣称任何 Agent 框架在某项指标上实际领先。文中的 Python 代码是标准库最小实验，需通过本地执行记录确认是否运行成功。参考资料的实时可访问性与最新版本仍需在正式工程实施时复核。
B.3 适用边界
本文适用于研究型、工具型、多步骤及多 Agent 应用的评估体系设计。对医疗、法律、金融、公共安全等高风险场景，还需增加领域专门标准、合规审查、专业人员参与和适当的外部验证；通用量规不能替代专业责任。对完全确定性的自动化流程，可优先使用契约测试与形式化规则，避免不必要的模型裁判。
B.4 与相邻专题的衔接
- H1 Observability：提供任务、运行、工具、模型与成本的可关联证据。
- H2 Security：定义安全硬约束及越权、泄露、注入等风险的评估边界。
- H4 State Management：支持可复现执行、状态快照和恢复行为评估。
- H7 Reliability：提供故障率、恢复时间与可用性指标。
- H8 Resource Management：定义资源预算、成本上限与容量约束。
- H9 Data Governance：管理评估样本的来源、权限、脱敏、保留和销毁。
- H10 Testing & Validation：将关键评估发现转化为自动化测试和回归验证。
- H12 Policy & Governance：将评估证据接入组织发布审批与治理决策。