AI代理评估是产品的一部分
内容提要
该文讨论AI代理（Agent）的评估问题。文章指出，演示成功不代表系统可靠，需将评估纳入交付流程。建议建立可重复的评估系统，使用固定场景和真实任务，记录完整追踪信息，区分确定性检查与主观评分，并设置发布门槛。强调用真实数据测试，将生产故障纳入回归案例，并注意数据安全。最终目标是确保每次发布都尊重用户依赖的边界。
延伸解读
评估是产品的一部分
文章强调，AI代理的评估不应是发布前的临时检查，而应作为交付流程的固定环节。演示只能证明代理在特定条件下工作过一次，无法保证后续版本持续满足用户需求。将评估系统视为产品的一部分，意味着每次发布都要经过可重复的测试，确保行为边界被尊重。
真实任务优于大型基准
作者建议，测试集应优先使用真实任务，如支持工单和日志，而非大量用户不会发送的提示。十个真实任务比大型基准更有价值，因为它们能反映实际工作负载和边缘情况。同时，测试应覆盖多轮交互、缺失数据和工具超时等场景，以验证代理在复杂条件下的表现。
追踪记录是调试的关键
文章指出，仅评估最终答案会遗漏代理决策过程中的偏差。记录完整的追踪信息——包括模型版本、提示配置、检索来源、工具调用及参数——能让团队在分数下降时定位具体变化步骤。这也有助于识别评估器本身的失败，例如模型升级后判断不一致。
发布门槛需区分风险等级
作者建议，发布门槛应根据风险设定：对于权限绕过、跨租户检索等高风险行为，应设置绝对禁止的硬性门槛；而对于延迟、回答长度等指标，可允许一定容差。通过区分确定性检查和主观评分，团队能更清晰地判断新版本是否可发布，避免因平均分提升而忽视严重违规。
Q&A
为什么演示成功不能证明AI代理可靠？
演示只能说明代理在特定条件下工作过一次，无法保证后续版本在变化的环境中持续保持用户所需的行为。例如，检索配置或模型升级后，代理可能跳过引用或选错工具，直到用户反馈或监控才暴露问题。
如何建立可重复的AI代理评估系统？
建立可重复的评估系统需要：运行固定场景，覆盖代码、工具和权限；记录足够证据；使用真实任务而非大型基准；冻结文档和工具响应等fixtures；将生产故障纳入回归案例；并区分确定性检查与主观评分。
为什么评估AI代理时要区分结果和过程？
因为代理可能通过错误过程得到正确结果，例如检索了错误文档但答案正确，或调用了不必要的工具。这些运行在转录中看似成功，却掩盖了弱点，可能在其他请求下暴露问题。因此需要追踪过程，而不仅仅是最终答案。
AI代理评估中应记录哪些追踪信息？
应记录请求和系统指令、模型和应用构建版本、提示和检索配置（包括工具模式）、每个检索来源及其版本、每次工具调用及其参数和结果、权限检查和最终响应，以及延迟、令牌使用和成本。这些信息应能回答实际问题，无需从无关日志重建运行。
如何设置AI代理发布的通过门槛？
发布门槛应基于风险设置：确定性检查（如权限、政策合规）必须绝对通过，不允许失败；质量指标（如任务完成率、延迟）可设阈值；对于模糊变化，需要人工审查。例如，如果新版本绕过权限门，即使平均分提高也不能发布。
为什么说十个真实任务比大型基准更有价值？
因为大型基准可能包含用户从未发送的提示，而十个真实任务来自实际工作负载，更能反映真实使用情况。真实任务可以从支持工单、工作流日志、事件报告和用户对话中获取，包括普通请求和边缘情况。
AI代理评估中如何处理数据安全？
评估记录可能包含客户数据，因此需要与代理本身相同的控制：版本化记录、仔细的范围访问、考虑在持久化前编辑敏感值，并应用适当的加密、访问控制和保留策略。数据库强制访问控制（如行级和列级策略）可以提供额外保护。
有哪些工具可以用于构建AI代理评估工作流？
文章提到Promptfoo、DeepEval、LangSmith和Braintrust等工具，它们支持运行场景、捕获追踪，有些还使用模型评分。此外，Oracle AI Database提供向量搜索和混合搜索能力，可用于构建代理RAG模式。
