上生产前的 AI Agent 评估

AI agent 评估会让有版本记录的任务按照明确预期运行，并记录 agent 是否选择了正确工具、遵守约束、完成任务且避免禁止的影响。有效的评估套件结合确定性断言、重复试验、必要时的模型判定，以及对争议用例的人工审核。

首批用例应来自真实故障和高影响工作流，而不是与生产无关的知识问答列表。

OpenAI 的构建 agent 实用指南建议先建立评估基线，并随着 agent 复杂度增加持续使用评估。下面的评分设计将这项建议落到实处。

选择评分方式前先定义行为

每个用例都需要：

对于订单状态 agent，确定性评分器可以断言它调用了 get_order、从未调用 update_order、传入经过身份验证的订单 ID，并返回权威状态。模型判定可以为表达清晰度评分，但当 trace 能准确判断是否发生禁止写入时，不应让模型判定来决定。

使用代码检查工具名称、参数 schema、策略决策、结构化字段、数据库变更、延迟上限和禁止调用。这些检查可以重复执行，也容易调试。

如果存在多个有效答案，应使用边界明确的评分标准，写清必需事实、不可接受的结论、语气约束和 agent 可用证据。不要只用“质量 1 到 10 分”这种模糊评分。

对于难以编码的语义属性，可以使用模型判定，再根据人工标签进行校准。对判定模型隐藏处理方案名称，要求它提供结构化解释，并追踪意见分歧。判定模型可能发生漂移，也可能与被测系统共享偏差，因此不能作为安全或财务影响的唯一门禁。

将新类别、模型判定分歧和高影响失败交给人工审核。记录裁决结果，并将稳定决定转换为更清晰的断言或评分标准。

一次通过无法估算可靠性。对于涉及模型选择、随机检索或可变工具的用例，应重复运行，并报告试验数、成功数和不确定性，而不只是一个百分比。

保留一组固定核心用例用于发布对比，另设发现集探索新行为，避免测试提示词组合变化伪装成趋势。这同样适用于生产提示词监控：测试问题变化可能比系统变化更明显地影响表面可见性或成功率。

完整任务评分会掩盖故障在哪一阶段引入。应分别评估：

对于工具选择错误，先冻结执行并只测试选择。对于重复写入，应使用隔离后端并中断操作。工具选择错误调试指南和生产环境检查清单提供了具体用例。

离线评估套件在发布前针对 fixture、mock 或隔离资源运行，适合对比和安全注入故障。在线评估则在部署后抽样真实 trace，以发现流量变化和离线用例遗漏的场景。

不要让在线判定自动触发高影响操作。按照明确策略对生产数据脱敏和抽样，并将疑似回归交给人工审核或受控回滚流程。

模型、提示词、工具、schema、检索、策略、重试行为和提供商版本变化后，都应运行评估套件。在相同用例和重复试验上，将候选版本与当前基线比较。

发布门禁可以要求禁止操作为零、确定性检查无回归，并将质量或成本评分变化限制在一定范围内。结果应按任务类型拆分，因为稳定的平均值可能掩盖一条工作流中的严重回归。

可观测性发现故障后，保存脱敏 trace、初始状态和预期行为，并在修复缺陷前添加用例，防止后续模型或提示词变更让问题再次出现。

可观测性指南介绍了重建这类 fixture 所需的 trace 字段。

先从十个代表性用例开始，而不是数百条模糊提示词。其中应包含正常路径、上下文缺失、未授权请求、工具冲突、提供商超时、写入结果未知、恶意检索内容，以及不应调用任何工具的请求。

下方的提示词会在不编辑仓库的情况下，将一个现有故障转换为完整用例。断言确认可信后，实现过程就很直接，团队也由此获得一条具体的回归门禁。