外观
第 39 章 Research Brief：Harness 测试策略与 Benchmark
要解决的读者问题
一次成功演示只能证明某个输入在某次运行中得到了可接受结果，不能证明 Harness 的组件边界、工具失败路径、权限拒绝、上下文缺失和后续变更都仍然可靠。读者需要一套分层策略：底层用确定性检查定位契约错误，中层验证工具和环境边界，顶层用完整任务评估结果与轨迹，再用版本化的固定任务集识别回归，并让线上观察补充离线集合没有覆盖的新问题。
本章不重新定义第 17 章的评估规格（Evaluation Spec）与质量门，不重复第 31 章的 API/UI 测试方法，也不提前设计第 40 章的成本预算、第 41 章的安全控制或第 42 章的发布实验。第 39 章只回答：这些证据如何组成 Harness 的测试层级、Benchmark 与回归判定，而不被单一平均分或一次绿色结果误导。
研究范围与非范围
| 读者问题 | 本章研究的回答 | 本章不回答 |
|---|---|---|
| Harness 应从哪里开始测试？ | 先隔离确定性组件与契约，再逐层加入适配器、受控环境和完整任务；每层声明它能证明什么。 | 一个适用于所有 Agent、工具和环境的固定测试金字塔比例。 |
| 固定任务集怎样用于发布判断？ | 将任务、输入版本、环境、评分器、必过项和不覆盖范围写入评估套件与基准卡。 | 某个公开 Benchmark 分数足以证明具体产品可用、安全或适合部署。 |
| 怎样处理模型输出波动？ | 保存试次级结果，区分确定性失败与统计波动；聚合结果仍保留硬性失败和不确定项。 | 捏造试次数、置信区间、通过率或跨任务统一阈值。 |
| 线上信号如何回流？ | 线上观察用于发现新分布、失败模式和候选任务，经隐私与责任审查后再进入离线集合。 | 接入真实用户流量、日志、账户、凭证、实验平台或生产监控。 |
| 如何避免“分数提高但系统变差”？ | 分开记录任务结果、过程约束、安全/权限边界、鲁棒性与资源信号；必过项不能被平均分抵消。 | 用本章替代安全审计、人工批准、业务验收或成本决策。 |
已核验的一手资料与受限用途
2026-07-17 已实际读取以下官方页面与原始论文。完整 URL、访问日期、允许陈述和外推禁区见本章候选参考资料。
| 本地键 | 来源明确表达的内容 | 允许用于本章的范围 | 不可外推 |
|---|---|---|---|
| CH39-REF-01 | Anthropic 的工程文章把 Agent 评估拆成 task、trial、grader、transcript、outcome、evaluation harness 与 agent harness，并区分 capability eval 和 regression eval；文章还指出一次任务可运行多个 trial，并讨论代码、模型和人工评分器的取舍。 | 说明 Agent 评估需要同时观察任务、轨迹、最终环境状态和 Harness/模型组合，并把能力探索与回归保护分开。 | 跨产品标准、固定试次数、通过阈值、评分器可靠性、当前模型表现、公开 Benchmark 排名或产品效果。 |
| CH39-REF-02 | OpenAI 的动态指南建议使用任务特定、接近真实分布的评估，记录开发数据，尽可能自动化，持续评估，并用人工反馈校准自动评分；同页明确反对只靠通用指标和主观感觉。 | 说明离线集合应围绕本系统任务与实际分布建立，自动评分仍需校准，评估应随变更持续运行。 | OpenAI 产品 API、模型选择、示例阈值、平台可用性或任何其他厂商的行为。该页已公告旧 Evals 平台的停用时间线，因此产品操作内容不能作为稳定接口。 |
| CH39-REF-03 | NIST AI RMF Core 的 Measure 功能涵盖量化、质化或混合方法来分析、评估、Benchmark 和监测风险；它要求部署前测试、运行期间定期评估，并记录测试集、指标、工具、条件、局限与不确定性。 | 说明测试、Benchmark、运行期监测和文档需要关联使用语境、风险与可追溯记录。 | 固定 Agent 测试流程、认证、法规义务、组织阈值、产品安全结论或本章字段设计。 |
| CH39-REF-04 | Raji 等的立场论文讨论少数高影响 Benchmark 被当作广泛进步替代指标时的构念效度问题。 | 说明 Benchmark 只能支持与任务、数据、指标和适用语境一致的受限结论。 | 证明所有 Benchmark 无效、给出 Harness 测试算法，或据此否定任何具体模型与系统。 |
| CH39-REF-05 | HELM 原始论文以场景与指标的分类、多指标评估、缺失/代表不足项和公开原始输入输出提高语言模型评估透明度。 | 作为“场景 × 指标”和显式记录未覆盖项的研究背景，说明单一准确率会隐藏其他权衡。 | 将 HELM 的场景、指标、数据、数值和模型结论直接移植到 Agent 或本书 Benchmark。 |
CH39-REF-01 与 CH39-REF-03 分别复用正式引用 REF-061、REF-062；CH39-REF-02、CH39-REF-04、CH39-REF-05 已由主线程分别登记为 REF-117、REF-118、REF-119。Anthropic、OpenAI 与 NIST 在线页面可能更新，First Draft、Technical Review 和 Fact Check 必须在写作当天重读。
本书的工程模型
下列结构是本书为第 39 章设计的测试与发布判定模型，不是任何来源的现成框架、产品配置或统计标准。
分层测试模型
- 组件与契约层： 检查指令装配、状态迁移、输入校验、路由和评分规则等确定性逻辑。该层定位快，但不能证明真实工具、模型或环境能工作。
- 边界与集成层： 使用受控替身或隔离环境验证工具适配器、权限拒绝、超时、错误信封和状态关联。替身通过不能证明生产依赖可用。
- 完整任务层： 在声明的环境中运行端到端任务，关联输入、轨迹、结果状态与多个评分器。一次通过仍不能代表稳定性或泛化能力。
- 离线 Benchmark 层： 对版本化任务集运行多个试次，分开统计能力、回归、鲁棒性、安全边界和资源信号，并保留每项硬性失败。
- 线上观察层： 收集经过授权且去标识化的失败模式、分布变化与用户反馈，形成候选任务；只有经过审查后才进入离线套件。
这五层不是按数量比例定义的“行业测试金字塔”。图示中的宽窄只表达反馈频率、隔离程度和诊断成本的相对关系，不代表固定用例数、时间或预算。
三类计划工件
| 工件 | 最小字段 | 解决的问题 | 不证明的内容 |
|---|---|---|---|
| 评估套件（Eval Suite） | 套件版本、任务范围、场景类别、输入版本、环境契约、试次策略、评分器、必过项、停止条件 | 明确“测什么、在哪测、怎样判定” | 任务集具有代表性、评分器无偏或环境与生产一致 |
| 基准卡（Benchmark Card） | 目标用途、目标人群、数据来源、场景分布、指标、已知缺口、污染风险、适用期限、复核责任 | 限定 Benchmark 结论能外推到哪里 | 公开排名、产品质量、安全认证或跨版本可比性 |
| 回归测试矩阵（Regression Test Matrix） | Harness/模型/工具/数据版本、基线、候选结果、必过失败、波动范围、未覆盖项、发布路由 | 把变化与可比较证据关联 | 自动发布、回滚、批准或因果归因 |
结果聚合规则
- 硬性门与诊断指标分离： 权限越界、未满足的结果契约和不可解释副作用属于不可被平均分抵消的失败；步骤数、token、时延等只作为诊断或第 40 章的资源输入。
- 任务结果与过程证据分离： 最终状态正确不能自动证明过程合规，轨迹看起来合理也不能替代结果观察。
- 基线与候选同条件比较： 版本、输入、环境、工具替身和评分器不一致时，不给出“提高”或“回归”结论，只输出不可比较或需要补证。
- 离线与线上信号分离： 离线通过不代表线上有效；线上投诉、点赞或单次事故也不自动成为评分真值。
- 总体分数与分组结果并存： 即使提供汇总值，也必须保留场景、风险层、失败类型和未覆盖项，避免弱项被平均数隐藏。
计划案例、图示与示例
教学案例： 为一个虚构的最小 Harness 规划四类任务：受控成功、工具返回可分类失败、权限策略拒绝动作、必需上下文缺失。每类任务分别声明预期结果、允许轨迹、禁止效果和证据缺口。案例只形成评估输入，不声称模型、工具、权限系统、文件、网络、账户、凭证、真实 Benchmark 或线上流量已经运行。
计划图示： Mermaid 图在后续阶段展示“组件/契约 → 边界/集成 → 完整任务 → 离线 Benchmark → 线上观察”的双向反馈。主链从低成本定位走向高语境验证；反馈链把线上新失败送回候选任务审查。图中必须标明：单层通过 ≠ 系统通过、离线通过 ≠ 线上有效、总体分数 ≠ 所有硬性门通过。
计划示例： Example Implementation 阶段可设计纯内存函数 assessHarnessEvaluationPlan(input)，只检查注入的套件版本、四类场景、环境摘要、评分器、必过项、基线与候选记录，返回 ready_for_benchmark、needs_scenarios、not_comparable、regression_detected 或 needs_review。本研究阶段不创建该函数、测试、演示、示例计划或 npm 入口。
风险与后续核验
- 构念漂移： Benchmark 名称未变，不代表它仍测量同一能力；任务、数据、评分器和环境版本必须共同记录。
- 集合污染与过拟合： 固定任务一旦反复用于优化，可能逐渐只反映对该集合的适配。后续正文若讨论保留集、轮换集或污染检测，需要补充一手来源并限定方法。
- 分布错配： 离线任务与线上请求、语言、工具状态或权限策略不同，离线分数不得直接外推为线上成功率。
- 评分器漂移： 模型评分器、Rubric 或人工标签规范变化会破坏跨版本可比性；需要版本化并重新校准。
- 伪精确统计： 本章不捏造试次数、置信水平、显著性门槛或发布阈值。真实项目必须由样本、风险和决策成本决定统计方法。
- 隐私与责任： 线上失败进入测试集之前，需要处理授权、隐私、保留期和责任归属；本章不收集真实用户数据。
TODO(verify)：First Draft 当天重读 Anthropic、OpenAI 与 NIST 在线页面，确认术语、产品停用提示和动态建议仍然成立。TODO(verify)：若正文加入抽样、置信区间、显著性或 A/B 判断，先取得统计方法的一手来源，并把发布决策留给第 42 章。TODO(verify)：若后续示例进入真实模型、工具或网络环境，必须另建环境契约、费用/权限上限和可清理测试数据；当前只允许纯内存教学对象。
下一阶段建议
Chapter Outline 应把五层测试模型、三类工件、四个教学场景、结果聚合规则、图示断点和第 17/31/38/40/41/42 章责任边界拆成逐节蓝图。每节均须分开来源事实、本书工程扩展、虚构输入和未运行范围；不得把公开 Benchmark、一次测试、模型评分器或总体平均分写成 Harness 已经可靠。
阶段门
- [x] 已读取一手官方资料、风险管理框架与原始论文。
- [x] 已记录每条来源的允许陈述、外推禁区和访问日期。
- [x] 已将测试层级、Eval Suite、Benchmark Card 与回归矩阵标为本书工程模型。
- [x] 已规划图示与示例，但未实现正文、图源、代码、测试或运行入口。