第 30 章：Agent 评测体系 — 从「感觉能用」到「证明能用」¶

Agent 项目最容易死在两句话上：开发期是"我试了几次都行"，上线后是"用户说变笨了"。这两句话的共同解药是评测（Evals）。2026 年，评测能力已经是 Agent 工程师与"调包侠"的分水岭——也是任何 Agent 服务敢收费的底气来源（第 29 章的变现在这里闭环）。

30.1 为什么 Agent 比普通软件更需要评测¶

传统软件测试的输入输出是确定的；Agent 的难点在于：

非确定性：同一个 prompt 两次执行可能走完全不同的工具调用路径。
长链条：一次任务 20 步，每步 95% 成功率，端到端只剩 36%——单点测试全绿不代表能用。
静默劣化：模型供应商静默更新模型、工具 API 改返回格式、系统提示词被同事顺手改了一行——没有任何报错，只有效果慢慢变差。

评测驱动开发（Eval-Driven Development, EDD） 是 2026 年的共识答案：先定义"什么叫对"，再写 Agent。改任何东西之前先跑评测基线，改完对比——把 Agent 开发从玄学变成工程。

典型工作流（每个 PR 都要走一遍）：

  改 prompt / 换模型 / 升级框架
        ↓
  跑评测套件（离线，几分钟）
        ↓
  通过率 ≥ 基线？ → 合并          不通过 → 定位是哪一步退化

30.2 三层评测金字塔¶

不要一上来就做端到端评测——又贵又慢又难定位。按金字塔分层：

          ┌─────────────┐
          │  端到端评测   │  少而精（10–50 条任务），全流程真实运行
          ├─────────────┤
          │  步骤级评测   │  中等数量（100–500 条），检查中间轨迹
          ├─────────────┤
          │  单元级评测   │  海量、便宜、毫秒级（工具调用、格式、路由）
          └─────────────┘

30.2.1 单元级：不花钱的都要测¶

路由正确性：这段请求该不该触发这个工具？（可用小模型批量判）
结构化输出：JSON 合法性、字段完整性、schema 校验——纯代码断言，零 LLM 成本。
格式与安全：系统提示词是否被越狱、输出是否包含敏感信息（正则即可）。

30.2.2 步骤级：看轨迹，不只看答案¶

Agent 的过程（trajectory）比结果更能定位问题：

该调的工具调了吗？（必要工具召回）
不该调的调了吗？（幻觉工具 / 冗余调用）
参数对吗？（工具入参的正确率）
顺序合理吗？（先搜再读，还是上来就瞎猜）

轨迹评测的成本远低于端到端（不需要真实执行到底），又比单元级更能抓住"每步都对、合起来跑偏"的问题。

30.2.3 端到端：任务完成度¶

用任务级判分而不是字符串匹配。判分器（Judge）按任务类型选：

判分方式	适用	成本	风险
精确/包含匹配	有标准答案（提取、分类）	零	表达变化误杀
代码断言	可验证任务（SQL 执行、单元测试通过）	低	只覆盖可执行任务
LLM-as-Judge	开放式生成	中	Judge 偏差（长答案偏好、位置偏差）
人工抽检	上线前最终把关	高	不可规模化

⚠️ LLM-as-Judge 三原则：① Judge 模型 ≠ 被测模型（避免自我偏好）；② 给 Judge 明确的 rubric（评分细则）而不是"你觉得好不好"；③ 定期用人工标注校准 Judge，偏差超过阈值就重新校准。

30.3 评测集怎么建：从 20 条起步¶

不要追求大而全的评测集，按这个顺序攒：

真实失败案例优先：用户报的每个 bug、你自己翻车的每次运行，沉淀成一条评测用例。评测集是事故的化石层，20 条真实失败胜过 200 条编造的"理想情况"。
每类能力至少 5 条变体：同一意图换措辞、换长度、换难度，防过拟合。
对抗样本单独放一层：越狱、诱导、模糊指令，监控"下限"而不是"平均"。
冻结基线：评测集进 git，改动评测集和改动 Agent 代码不许在同一个 PR——否则等于自己给自己改考卷。

30.4 工具选型（2026-10 实测）¶

工具	定位	适合	特点
promptfoo	prompt/Agent 评测 CLI	个人与小团队	配置化、CI 友好、支持多模型对比、免费开源
OpenAI Evals	OpenAI 官方框架	已深度绑定 OpenAI 的团队	生态成熟但绑定较深
DeepEval	pytest 风格的 LLM 评测	Python 重度团队	把评测写进单测，与 CI 天然融合
Langfuse	可观测 + 在线评测	生产环境	与第 16 章可观测性无缝衔接
Braintrust	商业化评测平台	企业级	功能全、收费

建议路径：个人项目用 promptfoo 起步（半天接入 CI）；上线后接 Langfuse 做线上评测回流；团队化后再考虑商业平台。

CI 集成示例（promptfoo + GitHub Actions 核心）：

- name: Run evals
  run: npx promptfoo eval --config eval/promptfooconfig.yaml
  env:
    OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
- name: Enforce threshold
  run: npx promptfoo assert --config eval/promptfooconfig.yaml

📚 串联阅读：第 16 章可观测性（线上评测的数据来源）→ 第 25 章 Harness Engineering（失败恢复支柱与评测的关系）→ 第 20 章 Codex CLI（让编码 Agent 帮你写评测用例）

30.5 把评测变成商业壁垒¶

评测不只是质量工具，它直接服务于第 29 章的变现路线：

敢收费的证据："我们的 Agent 服务通过 500 条评测用例，端到端通过率 98.2%，每周全量回归"——这句话在客户面前比任何 demo 都值钱。
公开评测报告作为获客内容：把"我们如何评测 Agent"写成文章/章节，本身就是稀缺内容，反哺开源影响力。
评测即产品：把你的评测集/评测服务做成 x402 可付费端点（第 29.3 节），让其他 Agent 开发者付费调用——卖铲子永远比挖金子稳。
付费层的分界线：开源核心 + 公开评测基线；付费层提供更大的私有评测集、行业 rubric 和回归报告。评测天然适合做免费/付费的清晰分界。

30.6 本章小结¶

EDD 三步：先定义"什么叫对" → 冻结评测集 → 每次改动跑基线对比。
三层金字塔：单元级（免费海量）→ 步骤级（轨迹定位）→ 端到端（少而精）。
评测集是事故的化石层：从真实失败案例攒起，评测集与 Agent 代码不许同一 PR 修改。
LLM-as-Judge 要有 rubric、要换模型、要人工校准。
评测是变现的底气：敢收费的证据、获客的内容、可售卖的产品、免费/付费的分界线。

📚 串联阅读：第 29 章 Agent 经济与商业化 → 第 16 章可观测性 → 第 18 章选型决策树