跨栈评估标准

定义旅行准备好的评估标准

我在查看任何模型输出之前先编写评估标准。评估标准必须包含三个独立的轴：任务成功、工具正确性和忠实度。每个轴都有自己的评分指南，该指南不提及模型名称、框架版本或确切的提示词语。我将这些指南保存在一个纯文本文件中，该文件与测试套件一起存储，以便任何人都可以检查它们。

核心属性

- 预注册标准 - 成功条件在第一次运行之前就写下来。 - 轴隔离 - 一个轴的评分永远不会影响另一个轴。

为什么任务成功必须基于结果

任务成功回答了一个简单的问题：代理是否完成了被要求的任务？我通过检查最终状态的清单来判断，而不是检查答案的措辞。例如，如果任务是“将用户的电子邮件地址更新为alice@example.com”，我会在运行后检查数据库记录。我不关心代理是否说“我已经更新了你的电子邮件”或“你的电子邮件现在是alice@example.com”。

具体的清单

- 预条件验证（例如，用户存在）。 - 后条件验证（例如，电子邮件字段等于alice@example.com）。 - 没有额外的副作用（例如，没有其他字段改变）。 - 可选：延迟低于阈值（例如，2秒）.

工具正确性作为单独的轴

工具正确性检查代理向外部API、函数或数据库的调用。我将每个调用视为一个小实验：代理是否选择了正确的工具，是否传递了正确的参数，是否以正确的次数调用了它？我遵循OWASP备忘录关于安全工具使用的指导，例如提示注入防御备忘录和SQL注入防御备忘录，以避免意外注入。

评分标准

- 选择正确的工具 - 1分。 - 所有参数与模式匹配 - 每个参数1分。 - 没有额外的调用 - 如果调用次数等于预期，则为1分。 - 没有禁止的副作用（例如，写入应保持只读的日志）- 1分。

忠实度：追踪每个声明

忠实度要求判断代理输出中的每个语句是否可以追溯到工具结果或提供给模型的上下文。我将输出视为一组声明，并检查每个声明与证据的对应关系。如果一个声明无法得到支持，我将其标记为幻觉。当代理总结文档、引用来源或回答需要外部数据的问题时，此轴最为重要。

逐步验证

- 将输出分解为原子句。 - 对于每个句子，列出它断言的事实。 - 将每个事实与工具输出中的行或提供的上下文中的片段进行匹配。 - 如果一个事实没有匹配，计为失败。 - 忠实度评分 = (支持的事实数量) / (事实总数)。

我记录原始计数，以便我可以看到忠实度的下降是否来自少数大幻觉或许多小失误。

什么这不是

我想明确说明旅行准备清单的限制。它不能保证代理是安全、廉价或快速的。它不能保证在每个可能的输入上100%准确。它不能替代专用的安全审查、成本分析或延迟基准测试。清单仅衡量我上面定义的三个轴。如果您需要知道代理是否泄露私钥，您必须运行一个单独的密钥管理检查，例如使用密钥管理备忘录。如果您需要知道代理是否保持在预算内，您必须在清单之外跟踪令牌使用或API调用成本。

简而言之，清单是比较代理质量跨栈的工具，而不是解决所有生产问题的万能解决方案。

构建可比较的轨迹

轨迹是指在一次运行中发生的所有事件的完整日志：初始提示、每个工具调用及其参数和结果，以及最终的模型输出。我将每个轨迹存储为一个具有固定模式的JSON对象，以便我可以自动比较运行。以下是我的模式示例。

字段 | 类型 | 描述 提示 | 字符串 | 发送到模型的确切用户或系统提示。 调用 | 数组 | 有序的工具执行列表。 调用[].工具 | 字符串 | 工具或API的名称。 调用[].参数 | 对象 | 传递给工具的参数。 调用[].结果 | 任意 | 工具的原始输出。 输出 | 字符串 | 模型返回的最终文本。 元数据 | 对象 | 可选标签，例如模型名称、框架版本、时间戳。

由于模式永远不会改变，我可以使用相同的脚本为每个轨迹计算三个轴的评分。我保留一组主轨迹，涵盖我发布的核心任务和我看到的常见故障模式。当我更改模型时，我重新运行相同的轨迹并将新评分与基线进行比较。

在每次更改时运行评估

我将评估步骤集成到我的持续集成管道中。该管道在每次可以影响行为的提交时执行以下操作：

- 检出最新代码。 - 安装代理依赖项。 - 将代理运行在固定轨迹集上。 - 解析日志并计算任务成功率、工具正确性和忠实度评分。 - 将结果发布到仪表板并标记任何与前一个绿色构建相比下降超过五个百分点的轴。

这种做法可以尽早捕捉到回归。例如，当我切换底层检索库时，工具正确性轴从0.96下降到0.82，因为新库以不同的顺序返回结果，导致代理进行了额外的调用。下降出现在CI报告中，甚至在任何用户注意到问题之前。

我还保持了一个由二十个轨迹组成的人工评分保留集。每个月，我都会用一个人评分它们，并将平均值与自动评分进行比较。如果自动评判发生漂移，我会重新校准评分标准或重新训练评判模型。

操作员评估代理评分标准的检查清单

我在每个版本中都保留一份书面检查清单，以确保评估的准确性。这个清单故意很简单：确定所有者，确定证据文档，并确定回滚计划。如果一个步骤不能产生文件、票据或日志记录，那么它就不是一个步骤——它只是一个愿望。

在更改生产环境之前

- 冻结要测量的分支或配置修订版。 - 记录当前的故障模式，包括一个具体的输入和一个具体的输出。 - 确认作业运行的身份，并检查该身份是否可以访问不应访问的数据。 - 打开主要参考资料：https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html，https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html。

在运行检查时

- 更喜欢一个可复现的路径，而不是十个传闻截图。 - 在触发工具或查询之前，写下预期的安全结果。 - 捕获确切的命令、提示、模式或正在测试的正则表达式——而不是一个概括。 - 如果系统可以执行操作（发送、写入、删除、转移），则在同一路径中需要一个确认边界。

完成后

- 即使扫描结果干净，也要用所有者和日期记录残留风险。 - 不要将绿色检查转换为声称完整性的销售语言。 - 当模型、工具模式或验证规则发生变化时，重新运行相同的检查清单。

信号 | 记录内容 | 是否停止发货? 意外写入或发送 | 工具名称、参数、身份 | 是，直到被网关阻止 缺少对破坏性操作的确认 | 调用路径和绕过 | 是 未经信任的文本被视为指令 | 源表面和结果操作 | 是，适用于代理范围 扫描结果干净，判断开放 | 推迟的项目 + 所有者 | 仅当核心路径安全时

我如何向买家解释限制

当一个潜在客户问产品是否"涵盖一切"时，我会回答产品的边界：自动检查可以捕捉已知模式，但新的链式攻击和策略判断仍需要人工审查。这可以保持支持负载较低，并保持博客内容与产品实际功能一致。

如果您需要第二个意见，请将此文档与下面的参考资料和您自己的测试环境结合起来。不要仅仅因为模型写了一个自信的总结就跳过测试步骤。

参考资料

- https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html - https://docs.agents-squads.com/guides/config-files

常见问题

我们需要多少测试用例?

足够覆盖您实际发布的任务和它们失败的方式。几个精心选择的轨迹优于大量简单的轨迹。

我们可以用另一个模型来判断输出吗?

可以，但要记录判断者是模型，并保留一个固定样本由人类评分，这样您就可以判断判断者本身是否发生了偏移。

信仰度，具体来说是什么?

每个输出中的每个声明是否由工具结果或代理所给的上下文支持，而不是由模型自己的先验产生的。

我们应该只评分最终答案吗?

不。也要评分轨迹——工具调用是代理故障的主要来源。

评估应该多久运行一次?

在可能影响行为的每个更改时：提示、模型、工具列表或检索配置。

好的评分是否意味着代理是安全的?

不。它意味着代理在您测试的任务中表现良好。安全性、成本和故障处理是单独的评估。

参考

- NIST — 人工智能风险管理框架 - Stanford CRFM — HELM (语言模型的整体评估)

尝试产品：AgentGrade

2026-09-20 · 仅使用原始资料 · 不允许虚假流量指标 · 仅决策支持

相关文章

- 离线评估与在线监控对于AI代理 - 探索完整的AI微SaaS主题矩阵 →