在本页面
一封关于退货订单的回复，看起来已经可以发送：语法正确，友好，而且简短。在这个示例中，自动评分给它满分。但助手还告诉客户退款已经发出，尽管没人检查支付系统。
错误不在于句子写得差，而在于好工作的定义太弱。
在一段已收录的评估演示中，团队为撰写软件文档的代理建立评分。有意思的时刻，是懂这项工作的人描述质量意味着什么，而工具把描述变成准则。后来一次低分引出正确的怀疑：要修的是代理，还是评估本身？
评分准则是一套关于任务的理论。要测试它。
从一票否决的错误开始
团队常从容易打分的维度入手：清楚、语气、结构、完整。这些有用，但很少足够。
对示例中的退款回复，“没有支付凭证，不得声称退款已经完成”应排在文笔之上。对数据同步，“不要把账单邮箱映射到账户所有者邮箱”比字段映射解释是否好读更重要。
请领域专家提供三类案例：明显好的、明显错误的，以及知情人可能意见不一的。保留原始记录与每项判断的理由。若案例依赖可能变化的规则，就把规则版本与标签一起保存。
第一批可以小，却不能含糊。
- 任务负责人
好、坏及有争议的案例
- 确切检查 身份 · 许可 · 目标系统
代码强制事实
- 语义准则
只判断需要解释的部分
- 分歧复核
修正标签与准则
| 检查项目 | 更合适的负责方 | 理由 |
|---|---|---|
| 必要的许可存在 | 代码与权威记录 | 事实明确且影响重大 |
| 目标 ID 与来源身份一致 | 代码与测试记录 | 模型不该猜标识符 |
| 回复回答了客户问题 | 经人审核的准则，必要时加模型判定 | 含义需要解释 |
| 语气符合情境 | 经人审核的准则，必要时加模型判定 | 可接受形式不止一种 |
把 AI 引入现有工作流的指南也有助于区分模型应作的判断与代码应核对的原值和限制。模型置信度不会变成许可。
分数继承准则的盲点
合理的反对意见是：“人无法审查代理每次运行，我们需要能扩展的判定器。”是的，但要看扩展的是什么。
若准则奖励精致的回答，从不检查订单是否实际退款，自动化只会扩大遗漏。带两位小数的数字看着精确，仍可能在测错东西。
Google Cloud 关于判定模型评估的文档介绍一项实用检查：准备有人类评分的案例，运行模型指标，再比较分数。重点并非一个人的看法永远正确，而是模型得分需要外部标准才有分量。
检查分歧，不只看平均一致度。判定器通过了支持负责人拒绝的回复，就查缺了什么准则。两位专家意见不一，保留双方标签，找出解释不同的规则，不要默默取平均。
抽样与准则措辞同样重要。只收集日常成功案例，会让判定器显得可靠，困难案例却根本未被触及。应包括不完整记录、矛盾指令，以及正确做法是停止并提问的案例。另留一组准则作者未用来调校的案例，让熟悉示例中的改进也必须在别处证明。业务规则改变时，标签和预期结果都要更新；冻结的测试集可能奖励昨天的政策。
让结果留在评估中
同步代理的准则应追踪客户结果。正确联系人改变了吗？同意状态受尊重吗？失败记录能否重放，而不重复有后果的动作？
Brevo 连接器指南说明成功的 API 调用为何可能与缺失属性并存。只检查代理有没有调用端点，会错过结果；只检查目标系统，也可能错过碰巧得到正确数值的禁止路径。路径有风险时，两者都重要。
从一项狭窄任务和少数失败模式开始。与任务负责人一起给案例贴标签，把确切检查交给代码，只在语言或判断确有需要时使用模型。提示、模型或工具变化后，重跑相同案例。记录后来的失败揭示的准则缺口。
成本是先投入专家时间。收益是之后每个分数都有能解释的意义。
看板可以显示分数，只有准则告诉你究竟数了什么。
常见问题
谁应该定义 AI 代理的评估标准？
懂任务及其后果的人应定义可接受结果和一票否决的错误。工程师可以把判断转成可重复检查，并验证模型判定是否同人工评分一致。
高分能证明代理工作正常吗？
不能。分数衡量的是测试案例与准则的符合程度。薄弱准则、不具代表性的案例或校准不佳的判定器，都可能给有害结果高分。
哪些项目应由代码而不是模型检查？
准确的权限、记录标识符、必要的工具调用和目标系统状态，只要可能就用代码检查。模型适合处理精确规则无法确定的语义质量。