软件测试有一套成熟的方法论：写测试用例，定义输入和预期输出，跑测试，对比结果，通过或失败。这套方法在传统软件里运转得很好，因为"预期输出"是确定的——给定输入 A，正确的输出就是 B，不是 B 就是错。

AI Agent 的输出不是这样的。给定"帮我查上个月 A 仓库的出库记录"，Agent 可能用不同的表述方式返回结果，可能在结果之前加一句说明，可能把数据整理成表格也可能列成文字。这些都是正确的输出，但它们不是同一个字符串，传统的字符串比对会把大多数正确答案判成失败。

测试 Agent，需要一个能理解语义的评判者。"LLM as a Judge"就是这个思路的工程实现。

核心思路：用一个 LLM 评判另一个 Agent

LLM as a Judge 的基本框架是：用一个独立的语言模型，作为测试用例执行结果的评判者。

被测的对象是工作台里运行的数字员工，叫做被测 Agent。评判的对象是另一个独立的 LLM，叫做评判模型。评判模型通常会选用和被测 Agent 不同的模型，这样可以降低一部分同源偏差，但不能让评判天然变得客观。它仍然需要和人工评审结果校准，才能成为可信的测试组件。

评判模型拿到四类信息：测试问题、预期结果、被测 Agent 的 CUI （交互式用户界面）交互记录、被测 Agent 的业务系统调用日志。基于这四类信息，评判模型给出一个评分、通过/失败判断和评判理由。这里要注意数据边界：如果评判模型调用外部 LLM API，交互记录和调用日志需要脱敏，只保留评判所需的字段；如果日志里包含敏感业务数据，评判模型应该使用私有部署或企业可控的模型服务。

测试用例怎么设计

测试用例的核心内容可以用自然语言描述，但用于自动化测试时，外层仍然需要稳定的结构。一个测试用例至少应该包含用例 ID、测试问题、预期结果、前置数据版本、执行用户、权限边界、允许工具、风险等级和判定方式。

• 问题：用户会实际输入的任务描述。写法上尽量贴近真实用户的表达方式，不要写成技术规格。"查 A 仓库本月需要补货的商品"比"调用 WMS 的 TableBinding，筛选库存低于库存下限的物品"更接近真实。
• 预期结果：描述一个合格答案应该满足什么条件。这里的关键是描述条件而不是描述具体内容，因为合格答案可以有多种表述。"必须通过 WMS 的 TableBinding 获取数据，返回结果中库存均低于库存下限，华为手机不在列表中"是一个好的预期结果描述；"返回一个包含 SKU001、SKU003、SKU007 的表格"是一个过于具体的描述，只要数据没变就会失效。

这种条件式的预期结果有两个好处。它对 Agent 输出的表述方式有更高的容忍度，只要满足条件就算通过，不会因为措辞不同而误判失败。它也更容易维护，系统数据小幅变化时预期结果描述不需要频繁同步更新。但条件式预期不等于不需要稳定数据。测试环境应该使用固定 fixture 或可重置的数据集，预期结果要绑定数据版本。否则同一条测试用例今天通过、明天失败，很可能不是 Agent 退化，而是测试数据变了。

评判提示词的构成

评判模型收到的提示词，是评判质量的关键。一个有效的评判提示词包含以下部分。

• 任务背景：告诉评判模型它的角色是什么，以及评判的标准是什么。“你是一个 AI Agent 能力评估专家，需要基于以下信息，客观评判这个 Agent 是否正确完成了给定任务。”
• 测试问题和预期结果：把测试用例的两个字段直接附上。
• 相关本体片段：把这次任务涉及的实体和服务端命令的本体描述附上，让评判模型知道哪些调用路径是允许且合理的。这一点很重要——如果不提供本体，评判模型只能根据返回结果的表面内容评判，无法判断 Agent 是否用了合理的接口路径，也无法识别越权、绕过白名单或误用高风险工具的问题。
• CUI 交互记录和执行轨迹：Agent 和用户的完整对话，加上结构化的执行轨迹。这里不应该依赖或暴露完整的模型思维过程，而应该记录计划摘要、工具调用、参数、返回值、状态变化、拒绝原因和人工确认节点。这让评判模型能看到 Agent 做了什么，不只是最终结果。
• 业务系统调用日志：Agent 实际调用了哪些接口，传了什么参数，返回了什么。这是判断"Agent 是否走了正确路径"的核心证据。
• 评判要求：明确告诉评判模型要从哪些维度给分，每个维度的权重，以及输出格式要求。比如：工具选择正确性、参数准确性、结果正确性、权限与白名单合规、失败处理、是否触发必要的人工确认、交互质量。对于企业 Agent，权限合规和高风险动作处理不能只作为备注，应该进入评分维度。

下面是一个实际执行的测试用例对应的提示词，供参考：

你要基于以下内容为Agent的能力做客观的打分。

- 问题：找出需要补货的商品，直接展示给我。无需后续动作。
- 预期结果：必须通过wms的TableBinding得出结果数据；回答结果要直观。

## 相关 Ontology

这里是与测试用例相关的系统 Ontology，太长，省略掉了。

## CUI 交互记录

2026/4/17 11:43:04 common-use-agent "## 需要补货的商品

共 **2** 种商品库存低于下限，需要补货：

| 编号 | 名称 | 规格 | 单位 | 当前库存 | 库存下限 | 库存上限 | 缺货数量 |
|------|------|------|------|----------|----------|----------|----------|
| WP00049 | 鸡汤 | - | 盒 | 51 | 100 | 200 | 49 |
| WP00031 | 葡萄干 | 每包 500 克 | 包 | 14 | 50 | 75 | 36 |"

2026/4/17 11:40:36 user1 "查询库存表，找出需要补货的商品，直接展示给我。无需后续动作。"

## 业务 APP 调用日志

2026/4/17 11:41:10 user1 common-use-agent wms 292d620b-ea42-48f0-a690-9146da753b53 binding GetTableDataWithOffset "{
  ""bindingInfos"": [
    ""3261feec-650a-421c-b05f-7ea8b1bed3e5"",
    ""e2a759ee-098a-461a-9e2f-41ba37f9a099"",
    ""46d197e3-67de-4157-9fe2-4369ea245d39"",
    ""c9ed5b33-100c-4279-a0a0-a8de26d3a07b"",
    ""b4c12f06-ce59-4a05-ac32-ed0074e4c59b"",
    ""88a4582e-b91f-4adc-81d9-037536e8df2b"",
    ""a09b30c0-9657-4a9e-a827-c60aa1c3d339"",
    ""62188ffb-8889-4595-b459-e1c2845f36fb"",
    ""933d1dd9-1f4c-4365-b987-c6445a3e7315"",
    ""d561a322-50aa-42d3-a3e0-e770d7f7f2d1""
  ],
  ""currentRowInfo"": {
    ""currentTable"": ""物品表"",
    ""viewname"": ""物品_库存物品信息表格"",
    ""listviewLocation"": ""物品_库存|物品信息表格""
  },
  ""demandRowCount"": 0,
  ""currentDataLength"": 0,
  ""needRowVersion"": true,
  ""editorDataInfos"": null,
  ""sortCommandID"": null,
  ""orderByInfo"": null,
  ""offsetConditionInfo"": {
    ""targetPage"": 1,
    ""pageLimitRowCount"": 0
  },
  ""columnFilterQueries"": null,
  ""totalRowBindingInfos"": [],
  ""pageName"": ""物品_库存""

评判结果怎么解读

一个设计良好的评判提示词，会让评判模型输出结构化的评判结果。PPT 里展示的评判输出示例大致是这样的结构：

总体评分（满分10分），然后逐维度评分，每个维度附上判断理由，最后是综合评价。

评判理由比评分本身更有价值。一个 7 分的结果，如果理由是"Agent 正确调用了 WMS 的 TableBinding，参数传递准确，但返回结果里没有按用户要求的格式排序"，这指向的是一个具体的改进点。如果理由是"Agent 选择了错误的接口，用了销售记录表而不是库存表"，这指向的是本体里的一个语义模糊点，需要回工程里修改。

评判结果有两个用途。单次测试时，它要给出通过/失败判断，作为 CI 或发布前检查的门禁；长期看，它更有价值的地方是告诉团队"哪里出了问题，怎么改"。把评判理由系统化地记录下来，就能看出哪类错误出现频率最高，治理的优先级应该放在哪里。

这个测试本身是一个 AI Workflow

第17篇里讨论的 Workflow vs Agent 选型框架，可以直接应用到 LLM as a Judge 这个测试场景上。

测试编排的步骤是确定的：输入测试用例，运行被测 Agent，收集 CUI 交互记录和调用日志，把四类信息拼成评判提示词，调用评判模型，收集输出，格式化结果。每一步的输入输出格式固定，所以编排层适合用 Workflow。但这不意味着整个测试结果是完全确定的。评判节点本身仍然是 LLM 语义判断，会存在波动。工程上需要通过固定 rubric、结构化输出、低温度配置、必要时多次采样，以及人工校准来降低波动。

这个案例有一个额外的价值，那就是它验证了选型框架本身的有效性。LLM as a Judge 是一个涉及 LLM 调用的任务，但它的测试编排不应该用 Agent 来实现，而应该用 Workflow。不是所有用到 LLM 的任务都适合 Agent，这一点在实际项目里经常被混淆。

测试环境的配置要求

值得注意的是，LLM as a Judge 需要一个独立的测试环境，和生产环境严格隔离。

被测 Agent 在测试环境里运行，调用的是测试版本的业务系统（有测试数据，不影响生产数据）。评判模型不应该直接访问测试环境的业务系统，也不应该拿到未经处理的敏感数据。它只接收测试框架整理后的必要记录；如果必须评判包含敏感数据的结果，应该使用企业可控的私有模型或专有部署模型。

这个隔离有两个目的：

1. 测试用例需要确定的数据基础。如果测试数据随时变化，预期结果的描述就很难稳定
2. 测试过程中 Agent 可能产生写操作（创建单据、修改数据），这些操作不能影响生产环境

我们建议的配置是，生产环境和测试环境各自有独立的业务系统部署，Agent 服务器至少有两个实例分别对应两个环境，测试环境的本体文件和生产环境保持同步，但数据是隔离的。

从测试结果到治理行动

LLM as a Judge 的长期价值，不只是给出一个"通过/失败"的结论，更在于把 Agent 的错误模式显式化，为下一轮治理提供方向。

一个完整的测试循环是这样的，设计覆盖主流程的测试用例集，运行测试，收集评判结果，分析高频错误类型，回到工程里做针对性治理，重新生成本体，重新运行测试，对比前后的评分变化。

这个循环的频率取决于项目阶段。在初次接入和每次大版本发布之前，应该跑一次完整的测试。日常迭代时，可以只跑受影响的测试用例子集，不需要每次都全量测试。进入 CI/CD 之后，可以设置明确门禁：核心用例不能失败，高风险用例必须人工复核，整体评分低于阈值时阻断发布。

测试用例集本身也需要维护。随着业务系统功能增加，新的场景需要被纳入测试覆盖；随着 Agent 能力提升，原来难度低的用例可以替换成更有挑战性的用例。把测试用例集当作活文档维护，而不是一次性的产物。

一个值得注意的局限

LLM as a Judge 的评判质量依赖评判模型本身的能力和评判提示词的设计质量。一个写得不好的评判提示词，可能产生误判，如把正确的 Agent 输出判成失败，或者把错误的输出判成通过。

有几个常见的评判质量问题需要注意：

• 评判维度设计得太模糊，评判模型不知道该看什么，评分会不稳定
• 预期结果写得太具体，评判模型会把稍微不同的正确表述判成失败
• 不提供本体，评判模型只能看结果不能看路径，无法判断 Agent 是用了正确的方式得到正确结果还是用了错误的方式碰巧得到正确结果，后者在下一次类似任务时大概率会失败。

在正式使用 LLM as a Judge 之前，建议先建立一批人工标注的“黄金测试用例集”，让熟悉业务的人看同样的测试记录，给出通过/失败和理由，再和评判模型的结论对比。必要时，也可以用一致率或 Cohen’s kappa 这类指标粗略衡量 Judge 和人工评审的一致性。如果差异超过合理范围，说明评判提示词、评分维度或测试用例描述需要调整。

这个校准不是一次性的。评判模型、评判提示词、业务系统或本体版本发生变化后，都应该抽样复核。LLM Judge 不是绝对裁判，它是一个需要被持续校准的测试组件。