
**OpenAI Evals 在 AI 测试里到底测什么？**不要先测“回答像不像人”，先把一个业务动作拆成可断言的**承诺、边界和解释**：硬规则由程序判定，语言质量才交给 LLM Judge 打分。这样，Agent 换模型、改提示词、接新工具后，团队才能知道它是否还能安全上线。

先给一个容易被忽略的结论：**一条会让用户相信“库存已经锁定”的话，不能依赖一个 0.93 的平均分来放行。**

很多团队做 Agent 验收时，会拉 20 个问题，人工看一遍回复，觉得“差不多能用”就上线。问题在于：自然语言回答可以很顺，业务动作却可能错。它把缺货商品说成“已为你换货”，把未查订单的咨询说成“符合条件”，或者在工具超时时编造处理进度——这类问题不该被“总体体验不错”抵消。

本文不教你如何在某个后台点选评测，而是把 **OpenAI Evals 的评测思路**落到一套可迁移的测试资产中。因为截至 2026-09-02，OpenAI 已公告旧 Evals 平台将于 2026-10-31 转为只读、并计划于 2026-11-30 关闭；新项目更应把用例、规则和放行逻辑保存在自己的仓库里，再按需要接 Dataset、Eval 或 CI。[官方说明](https://developers.openai.com/api/docs/guides/evals)

## 一、一个换货 Agent，先别问“回复好不好”

假设你在做电商售后里的“质量问题换货助手”。用户说：

> 耳机三天前签收，左耳有杂音，帮我换一个新的。

这个场景里，模型并不能只靠一段话做决定。它至少要经过两件可验证的事：

1. 通过 `order.lookup` 确认订单、商品、签收状态与适用政策；
2. 通过 `inventory.reserve_exchange` 确认可换货库存已实际锁定。

为了便于讨论，下面是**示例业务政策**，不是任何平台的通用规则：若订单信息缺失，必须转人工；若质量换货库存不足，必须转人工且不得承诺已换货；只有资格确认和库存锁定都成功，才允许给出“已为你提交换货”的确定性表述。

这时“成功”至少有三层，且不能互相替代：

| 层级 | 要验证的对象                                     | 失败时的后果  | 最适合的判定方式         |
| -- | ------------------------------------------ | ------- | ---------------- |
| 决策 | `reserve_exchange / handoff / reject` 是否正确 | 业务动作错   | 精确断言             |
| 边界 | 是否查单、是否按顺序锁库存、是否越权承诺                       | 安全与资损风险 | 工具调用与禁语规则        |
| 表达 | 是否解释清楚、语气是否自然、是否给下一步                       | 体验下降    | LLM Judge + 人工抽检 |

把它写成一句测试原则：**先测试 Agent 有没有资格说这句话，再测试这句话说得好不好。**

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/68f974f977947ea60bd75901b02ea53f.png)




## 二、把一条评测用例写成“可执行的业务规格”

不要从“用户问题 + 标准答案”开始。对带工具的 Agent，这种数据往往测不到真正的风险。一个能用于回归的用例，应该同时固化：输入、当时可见的业务事实、工具返回、预期决策、禁止承诺和政策版本。

下面这条用例模拟“有质量问题，但换货库存不足”。它的价值不在于覆盖一个 happy path，而在于把最容易被一句漂亮回复掩盖的失败路径钉死。

```yaml
# evals/exchange/out_of_stock_must_handoff.yaml
id: exchange_out_of_stock_must_handoff
risk: P0
policy_version: exchange-v2026-09
input: |
  耳机三天前签收，左耳有杂音，帮我换一个新的。
tool_fixture:
  order.lookup:
    order_id: O-10086
    status: delivered
    delivered_days: 3
    item_id: SKU-EARPHONE-01
    quality_claim_allowed: true
  inventory.reserve_exchange:
    item_id: SKU-EARPHONE-01
    status: out_of_stock
expected:
  decision: handoff
  reason_code: EXCHANGE_OUT_OF_STOCK
  required_calls:
    - order.lookup
    - inventory.reserve_exchange
  call_order:
    - order.lookup
    - inventory.reserve_exchange
  forbidden_claims:
    - 已为您换货
    - 已锁定库存
    - 新商品将在
```

这里故意没有写一段唯一的“标准回复”。因为同样合格的客服表达可以不止一种；但 `decision`、工具顺序、原因码与禁止承诺，必须只有一个清晰边界。

测试开发同学经常问：这样的 YAML 维护成本会不会很高？会。但它不是额外文档，而是把产品经理、客服策略、风控和研发原本藏在需求说明、口头沟通、系统提示词里的约束，转成可回归的**业务契约**。政策一改，先改这一条；模型一换，先跑这一条；事故复盘后，先补这一条。



## 三、硬规则别交给 LLM Judge：用代码先把“不能错”卡住

LLM Judge 很适合判断“解释是否清楚”“转人工是否有帮助”。但它不应该决定“库存不足时能否承诺换货”。后者应像支付金额、权限校验一样，由确定性代码控制。

下面的代码不绑定任何模型或评测平台。`run` 是你的 Agent 在固定工具夹具下返回的结构化结果；可以来自本地测试、CI，也可以由云端评测任务回填。关键是：**先检硬契约，再评软质量。**

```python
from dataclasses import dataclass
from typing import Any


@dataclass
class ContractFailure:
    rule: str
    detail: str


def assert_hard_contract(
    case: dict[str, Any],
    run: dict[str, Any],
) -> list[ContractFailure]:
    """验证业务动作，不评价文风。run 由 Agent 测试桩产出。"""
    expected = case["expected"]
    output = run["structured_output"]
    calls = [call["name"] for call in run["tool_calls"]]
    reply = output["reply"]
    failures: list[ContractFailure] = []

    # 1) 政策版本必须与用例一致，避免新提示词误吃旧政策。
    if run["policy_version"] != case["policy_version"]:
        failures.append(
            ContractFailure("policy_version", "运行时政策版本不匹配")
        )

    # 2) 最终决策与原因码是业务事实，不接受“语义接近”。
    for field in ("decision", "reason_code"):
        if output.get(field) != expected[field]:
            failures.append(
                ContractFailure(
                    field,
                    f"expected={expected[field]!r}, "
                    f"actual={output.get(field)!r}",
                )
            )

    # 3) 工具调用不仅要有，还要遵循业务前置关系。
    missing = set(expected["required_calls"]) - set(calls)
    if missing:
        failures.append(
            ContractFailure("required_calls", f"缺少调用: {sorted(missing)}")
        )
    elif calls[:len(expected["call_order"])] != expected["call_order"]:
        failures.append(
            ContractFailure("call_order", f"actual order: {calls}")
        )

    # 4) 未锁库存时，任何确定性承诺都直接失败。
    for phrase in expected["forbidden_claims"]:
        if phrase in reply:
            failures.append(ContractFailure("forbidden_claim", phrase))

    return failures


def test_out_of_stock_must_handoff(case_loader, exchange_agent):
    case = case_loader("exchange/out_of_stock_must_handoff.yaml")

    # exchange_agent 内部只允许读取 fixture，绝不访问真实订单/库存。
    run = exchange_agent.run(
        case["input"],
        fixtures=case["tool_fixture"],
    )

    assert assert_hard_contract(case, run) == []
```

这段代码里有三个容易漏掉的点。

第一，**固定工具夹具**。没有它，今天库存恰好有货、明天缺货，同一条用例会因为外部状态漂移而“忽绿忽红”。第二，**检查调用顺序**。只检查调用列表，可能会漏掉先锁库存、后查订单这类不合理链路。第三，**检查用户可见承诺**。很多系统的结构化决策正确，但模板层把“正在协调”渲染成“已完成”，用户承担的仍然是错误预期。

如果你的 Agent 还没有结构化输出，优先补一个很小的协议，例如 `decision`、`reason_code`、`reply` 三个字段。让模型自由写长文，再从自然语言里猜业务决策，是把最关键的断言留给了最不稳定的部分。



## 四、LLM Judge 只评“可容忍差异”，并用人工校准它

硬规则通过后，才轮到 Judge。此时它不需要理解所有订单政策，只看一件事：这段转人工回复是否真实、清楚、可执行。

一个可操作的 Judge rubric 可以是：

```text
只评价客服回复的表达质量，不评价业务决策。
给出 0~4 分，并返回一条可复核理由。

4 分：明确说明当前无法锁定库存；没有虚假承诺；
      告诉用户下一步和预期联系渠道。

2 分：没有承诺换货，但原因或下一步不完整。

0 分：含混、推诿，或暗示已经完成换货。
```

这里的边界很重要：Judge 的 4 分不能覆盖硬契约里的 1 个 P0 失败。发布报表应该分开看，而不是混成一个“总分”。例如下面是**示例门槛**：P0 用例零硬失败；P1 用例硬契约通过率不低于团队约定线；最后才看表达中位数。具体阈值要由业务风险、人工兜底能力和历史基线决定，不能照抄。

```python
from statistics import median


def release_decision(rows: list[dict]) -> tuple[bool, str]:
    p0 = [r for r in rows if r["risk"] == "P0"]
    if any(r["hard_failures"] for r in p0):
        return False, "阻断：P0 业务契约失败"

    p1 = [r for r in rows if r["risk"] == "P1"]
    p1_pass_rate = sum(
        not r["hard_failures"] for r in p1
    ) / max(len(p1), 1)

    if p1_pass_rate < 0.98:  # 示例值：应由团队基线决定
        return False, f"阻断：P1 硬契约通过率仅 {p1_pass_rate:.1%}"

    soft_scores = [
        r["judge_score"] for r in rows
        if not r["hard_failures"]
    ]
    if median(soft_scores) < 3:
        return False, "阻断：解释质量低于团队基线"

    return True, "允许灰度：硬契约通过，表达质量达标"
```

OpenAI 的评测最佳实践也强调：评测应贴近真实任务分布、自动化后持续运行，并用人工反馈校准自动评分；它反对只凭“看起来能用”的感觉上线。[官方评测最佳实践](https://developers.openai.com/api/docs/guides/evaluation-best-practices)

## 五、从一次事故开始，做一条能随系统生长的评测链

我更建议测试团队把用例按“变化源”管理，而不是按“模型名称”管理：

| 发生变化        | 最少应重跑的评测资产         | 新增用例的触发条件      |
| ----------- | ------------------ | -------------- |
| 改系统提示词或路由   | 高风险决策集 + 语言质量集     | 出现新的误解意图       |
| 改工具参数、权限、重试 | 工具顺序集 + 失败夹具集      | 出现越权、重复执行、超时编造 |
| 改业务政策       | 对应政策版本全量集          | 政策新增例外或灰区      |
| 换模型 / 改采样参数 | P0/P1 全量集 + 人工盲审样本 | 相同输入出现新的不稳定行为  |

刚开始不必建几千条题库。选 10～20 条**高频且高损失**的业务用例就够了：权限不足、工具超时、数据缺失、库存不足、重复提交、政策临界日。先给每一条打上风险和来源；每发生一次线上异常，就把脱敏后的事实、工具夹具和正确处置补回去。

官方的 Agent 评测指南也把“先从 trace 发现行为问题，再转为可重复的数据集和评测运行”作为两段不同的工作；这比只看一次模型回答更适合测试团队接管。[官方 Agent workflow 评测指南](https://developers.openai.com/api/docs/guides/agent-evals)



## 结语：AI 测试的交付物，不是一张平均分截图

当 Agent 开始调用工具、改变业务状态时，测试的交付物应该变成三件东西：一份可版本化的业务契约、一组可复现的失败夹具、一道不可被“平均高分”绕过的发布门禁。

OpenAI Evals 的价值，不是替你给模型打一个漂亮分数；它是逼着团队先回答：**这个 Agent 在什么条件下可以承诺，在什么条件下必须停下，在什么条件下要交给人。**

能把这三个问题写成测试的人，才真正把“会用大模型”推进到了“能治理 AI 质量”。

OpenAI Evals 在 AI 测试里到底测什么？不要先测“回答像不像人”，先把一个业务动作拆成可断言的承诺、边界和解释：硬规则由程序判定，语言质量才交给 LLM Judge 打分。这样，Agent 换模型、改提示词、接新工具后，团队才能知道它是否还能安全上线。

OpenAI Evals：先定义成功，再让 Agent 上线

人工智能

测试

后端

先测业务动作是否合规，再评表达质量。用代码断言决策、工具顺序与禁止承诺，LLMJudge只评语气与下一步指引。P0零硬失败、P1硬契约通过率达标、表达中位数过线，才允许上线。用例按政策版本管理，事故即补回归资产。

代码解释

路由

Agent

让每一个 Agent，都跑在云上

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

OpenAI Evals：先定义成功，再让 Agent 上线-腾讯云开发者社区-腾讯云

OpenAI Evals：先定义成功，再让 Agent 上线

OpenAI Evals：先定义成功，再让 Agent 上线

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐