AI Harness 不是测试脚本，而是 AI 系统的质量控制台

大多数 AI 应用在原型阶段都非常惊艳，但在推向生产环境后，往往会陷入“修好一个 Bug，带出三个新幻觉”的恶性循环。为了避免系统失控，我们需要建立一种系统化的工程手段，这就是 AI Harness Engineering。它不仅仅是一组测试脚本，而是连接任务协议、数据集、评测、工具执行、运行期观测、安全边界和发布决策的控制台。

从“Demo 惊艳”到“上线失控”：AI 系统的非确定性陷阱

在开发传统软件时，我们的输入与输出之间存在明确的逻辑规则。如果输入 A，系统必然输出 B。如果输出不是 B，那一定代码写错了。

大模型驱动的系统打破了这一常识。它的底层是一个非确定性的统计概率引擎。这意味着：

1. 不可重现的失败：同一个提示词（Prompt）在相同的模型版本下，运行十次可能会产生一次灾难性的输出（例如输出格式崩溃或泄露敏感信息）。
2. 暗淡的回归风险：当你为了解决用户的某个特定抱怨而精心微调了 Prompt，你很可能会在无意中降低了模型在其他核心场景上的泛化表现。
3. 沉默的系统退化：外部 API 的微小更新、底座模型的静默升级、或者下游检索数据质量的变动，都会让你的 Agent 在没有任何报错日志的情况下，逐渐给出低质量的回答。

面对这种非确定性，仅仅依靠工程师在本地终端敲几次“手工测试”，或者写几个简单的 Assert 语句来检查是否包含特定关键词，是无法支撑企业级应用上线的。如果系统需要满足严肃的商业合规与安全要求，我们就必须建立一个全生命周期的质量控制台。

厘清边界：普通 Test Harness、LLMOps 与 AI Harness 的本质区别

为了不混淆概念，我们需要划清三者的职责边界。

• 普通 Test Harness（测试套件/脚手架）：针对确定性代码。它通过 Mock 外部依赖，给系统固定的输入，并验证输出是否与预期严格一致。它无法处理大模型的概率性输出，更无法评估“语义相似度”或“毒性”。
• LLMOps（大模型运维平台）：是一个宏观的生命周期管理范畴，涵盖模型托管、微调管道、向量数据库运维、分布式部署等。它关注的是资源、算力和整体流水线（Pipeline）。
• AI Harness（AI 质量控制台）：专注于保障应用层的预期行为与安全性。它不关心底层 GPU 的调度，而是深入到模型和 Agent 内部。它通过统一的任务协议，将线下数据集的自动化评测与线上的真实观测对齐，从而支撑起模型升级、Prompt 迭代、工具调用（Tool Use）以及检索增强生成（RAG）的灰度发布决策。

+-------------------------------------------------------------+
|                        LLMOps 平台                           |
|  +-------------------------------------------------------+  |
|  |                     AI Harness                        |  |
|  |   +-------------+   +---------------+   +-----------+ |  |
|  |   | 任务协议层  |   | 自动评测门禁  |   | 观测对齐  | |  |
|  |   +-------------+   +---------------+   +-----------+ |  |
|  +-------------------------------------------------------+  |
|  +-------------------------------------------------------+  |
|  | 算力调度、模型微调、向量数据库运维、网关路由          |  |
|  +-------------------------------------------------------+  |
+-------------------------------------------------------------+

AI Harness 的核心骨架：从输入协议到风险决策的闭环

一个完整的 AI Harness 必须提供从研发测试到生产运营的闭环反馈。它包含以下核心模块：

1. 任务与输入协议层 (Task Protocol)：规范化 Agent 或大模型的输入输出接口，使评估工具不依赖特定模型的 API 格式。
2. 黄金数据集 (Golden Datasets)：不仅包含正向用例，更要包含边界用例、反向攻击用例和历史遗留的 Bad Case（脏数据）。
3. 多维评测引擎 (Evaluation Engine)：包含硬性断言、基于规则的检测（如 JSON 模式校验）、以及基于裁判员模型（LLM-as-a-judge）的语义评估。
4. 运行期观测收集器 (Runtime Telemetry)：在线上和线下执行过程中，捕获统一格式的 Trace 和 Metric。
5. 安全与合规网关 (Guardrails)：在线上作为过滤器拦截高风险输入与输出，在线下作为漏洞扫描工具。
6. 发布决策看板 (Release Gatekeeper)：量化新旧版本的退化差值，自动决定是否通过 CI/CD 门禁。

落地第一步：用 OpenAI 评测方法论构建你的第一份任务数据集

根据 OpenAI 发布的 Evaluation best practices 官方指南，构建评估集时应首先明确具体的业务目标，并建议从真实的用户交互或边缘案例中提取样本。因此，我们在构建 Harness 的数据集模块时，不应该闭门造车地编写虚构测试用例，而必须设计一套能够持续收集、筛选并清洗线上真实 Bad Case 的自动化管道，以此作为 Harness 的基础燃料。

为了开始，我们先定义一个标准的数据集格式。在 AI Harness 中，一个基础的 Eval 用例（基于 OpenAI Evals 兼容的设计思想）通常应该包含输入、理想的黄金参考输出（如有），以及可选的上下文信息：

{
  "examples": [
    {
      "id": "case_001",
      "input": "我想退订下周一从北京飞往上海的 CA1831 航班，请帮我操作。",
      "context": {
        "user_status": "VIP_GOLD",
        "current_date": "2026-06-01"
      },
      "ideal": "好的，我已为您查询到 CA1831 航班。根据您的金卡会员权益，此航班在起飞前48小时内退票将收取 5% 手续费。请问您是否确认扣除手续费并继续退票？"
    }
  ]
}

如果系统涉及高风险、直接面向用户的决策，应该在 Harness 中加入人机协同（Human-in-the-loop）的评估环节，不要完全依赖大模型作为裁判（LLM-as-a-judge），因为大模型自身存在偏见和幻觉，只有结合人工审查才能确保评估的置信度。这一点在处理可能产生纠纷的退改签业务或医疗、财务建议时尤为关键。

线上与线下的桥梁：基于 OpenTelemetry 语义约定的运行期观测

评估不仅发生在本地的 CI 环境中。只有将线上运行时的真实数据流转化成与测试环境相同格式的指标，AI Harness 才能实现真正的反馈闭环。

在定义运行期观测指标时，OpenTelemetry GenAI semantic conventions 规范化了大模型调用中的属性命名，例如 gen_ai.request.model 和 gen_ai.usage.tokens。因此，在开发 AI Harness 的观测层（Observability）时，必须直接对接这些标准属性，这样不仅能统一线上监控和线下评测的数据格式，还能避免因更换监控工具而重写所有指标解析逻辑。

以下是一个典型的 OpenTelemetry 语义属性映射示例，它展示了当 Agent 执行一次大模型请求时，Harness 的埋点应该记录哪些元数据：

# 这是一个符合 OpenTelemetry 规范的 span 属性注入示例
# 实际开发中，这些属性将被导出到你的 Prometheus 或 OpenTelemetry 收集器中
telemetry_payload = {
    # 基础信息
    "gen_ai.system": "openai",
    "gen_ai.request.model": "gpt-4o",
    "gen_ai.request.temperature": 0.2,
    
    # 使用情况与性能
    "gen_ai.usage.input_tokens": 1024,
    "gen_ai.usage.output_tokens": 256,
    "gen_ai.response.finish_reasons": ["stop"],
    
    # 业务与安全元数据
    "app.harness.test_case_id": "case_001",
    "app.harness.execution_stage": "offline_eval" # 或是 "production_runtime"
}

如果系统的响应延迟（Latency）抖动较大，可以优先引入 OpenTelemetry 的 GenAI 语义约定进行细粒度追踪，除非你能确定延迟瓶颈仅仅存在于网络连接层，否则盲目优化模型参数并不能解决由于工具链调用（Tool Use）或向量检索延迟引发的性能退化。

治理与对齐：将 NIST AI RMF 框架融入自动化评测门禁

质量不仅是“回答得对不对”，还包括“安不安全、合不合规”。NIST AI Risk Management Framework (NIST AI RMF) 强调了在 AI 系统全生命周期中管理风险的重要性，并将其分为 Govern（治理）、Map（映射）、Measure（测量）和 Manage（管理）四个关键功能。在 AI Harness 的设计中，我们应当将“Measure”这一功能固化为自动化的门禁（Gatekeeping）机制，通过设定明确的风险和性能指标阈值，在模型上线前进行量化评估，不通过则自动阻断发布。

根据 NIST AI RMF 的指导思想，AI Harness 的安全评估必须能够检测以下风险维度：

• 有害内容与偏见：评估输出中是否包含侮辱性、歧视性言论。
• 信息泄露风险：评估大模型是否会在 Prompt Injection（提示词注入）攻击下泄露系统内部指令（System Prompt）或上游 API 密钥。
• 幻觉与事实不符：评估模型是否在凭空捏造事实，或给出了与输入上下文（Context）相矛盾的解释。

如果评测的数据集包含敏感的用户数据，必须在将数据送入评估流之前进行脱敏处理，不要直接传输明文，否则会违反隐私保护法规并增加数据泄露风险。这需要在 Harness 内部构建一个本地运行的脱敏组件（De-identifier）。

实战交付：设计你的 AI Harness 能力地图与项目目标表

现在，我们把上述核心概念、评估规范和风险管理框架，落地为一张可供团队直接使用的能力地图与项目目标表。

AI Harness 能力地图

这张地图定义了你当前所处的阶段以及后续建设的目标：

贯穿项目首期目标表

请在你的项目中，使用以下表格来规划和追踪 AI Harness 的建设：

持续演进：AI Harness 的版本维护与时效机制

本课内容基于以下关键来源，并参考了 2026-05-28 访问的相关技术规范。由于生成式 AI 领域技术迭代极快，当以下情况发生时，应该及时对你的 AI Harness 设计方案进行升级与复核：

1. OpenTelemetry 变更：当 OpenTelemetry GenAI 语义约定从草案（Draft/Experimental）正式升级为 Stable 时，应根据最新属性字段同步更新你的 Trace 埋点。
2. OpenAI Evals 工具演进：如果 OpenAI 官方的 Evals 评测仓库和规范提供了更高级的高并发裁判机制或更低价格的评估接口，应及时调整线上 Harness 的成本分配比例。
3. 合规性更新：如果国家或行业针对生成式 AI 落地了新的强制性法规（如最新的深度合成服务管理规定或 NIST AI RMF 细化指南），必须将合规性条款及时补充至你的 AI Harness 风险控制台指标中。

练习与自测

• 动手练习：基于本课的 JSON 格式示例，尝试为你的 AI 应用编写一个包含 5 个正向和 5 个反向攻击用例的本地微型数据集 harness_sample.json，并写一段 20 行以内的 Python 脚本读取它，调用你最常用的模型，验证模型是否能在每次调用中都满足输出格式的要求。

AIHarness不是测试脚本，而是AI系统的质量控制台：把判断写进 Harness 证据链

AI Harness 不是把测试脚本堆在一起，而是把语义质量、工具执行和风险控制变成可复查证据。本课交付物是 一张 AI Harness 能力地图和贯穿项目目标表，它必须能被复跑、复核、追踪和复盘。

如果 AIHarness不是测试脚本， 还没有对应的输入样例，先不要讨论自动化覆盖率，因为没有样例就无法判断 harness 是否真的抓住问题。 如果一次评测失败会影响发布，应该保留失败输入、模型输出、工具轨迹和判分理由，否则团队只能凭记忆争论。 如果你准备把某个结果自动放行，必须先写清人工复核的例外条件，只有例外条件明确时，门禁才不会变成新的风险源。

诊断时先看任务协议是否明确，再看样例是否覆盖边界，最后看评测报告是否能解释失败。围绕 AIHarness不是测试脚本，而是 做排查时，记录步骤、样例、指标、风险、修复动作和复测结果。

OpenAI 的《Working with evals》说明：支撑 AI 输出评测集、评测运行、模型质量回归和上线门禁。；这意味着 AIHarness不是测试脚本， 要把来源转成可执行断言。OpenAI 的《Evaluation best practices》提醒：支撑目标定义、数据集、指标、连续评测、人审、judge 偏差和 eval harness 设计。；因此本课必须写清自动判断和人工判断的边界。OpenTelemetry 的《OpenTelemetry GenAI semantic conventions》提供的证据是：支撑 GenAI span、metric、event、token/latency 属性和标准化观测。；所以当前结论按 2026-05-28 的来源状态使用。

复核触发条件要具体：如果模型 API/SDK、评测工具版本、Agent 框架、RAG 指标、安全规范、合规政策、平台 release/changelog 或关键来源页面变化，需要重新运行本课样例并更新 harness。

练习验收：把 AIHarness不是测试脚本，而是 接入一个最小 AI 应用，提交包含输入样例、评测结果、失败诊断、来源证据、人工复核结论和下一步修复动作的记录。缺少任何一项，都标记为 needs_review。