让工程师列出其智能体的故障模式，你会听到关于幻觉、错误的工具调用以及格式错误的 JSON 等回答。但若问及时间，你得到的往往是一个无奈的耸肩。然而，生产环境中的智能体出错时，最常见的情况并非大声报错——而是耗时过长。它陷入循环。它重试一个不稳定的工具。它等待一个从未流式传输出首个令牌的大模型调用。而你的评估套件是在事后对最终出现的任何输出进行评分，并给它打上绿色的通过标记。
这就是盲点：我们将延迟视为站点可靠性工程（SRE）仪表板关注的问题，将其与正确性割裂开来。但对于智能体而言，错过截止时间就是正确性失败。一份迟到 90 秒才到达的摘要通常比没有摘要更糟糕——用户已经离开，下游任务已经超时，重试机制已经导致重复扣费。时间指标应当纳入你的评估体系中，并且应位于技术栈的最底层。
时间是第一层级证据
如果你遵循了 agent-eval 背后的层级理论，你就会知道证据是根据独立性轴进行排名的——从智能体无法伪造的证据，到与其共享基础架构的观点——而不是根据成本轴。分为三个层级：
- 第一层级 —— 智能体无法伪造的外部可观察证明：有效的 JSON、文件存在、代码已编译、测试通过、在截止时间内完成、输出非空。
- 第二层级 —— 针对智能体未创建的基线的统计信号：与任务的嵌入相似度、长度和重复性、差异比较是否实际改变了任何内容。
- 第三层级 —— 模型即裁判：一种共享基础架构的观点。这仅是一个信号，绝非最终裁决。
请注意“在超时时间内完成”所处的位置。它属于第一层级，紧邻“有效的 JSON”。这并非偶然。墙钟截止时间是你拥有的最独立的信号——智能体无法与秒表争辩，无法通过推理绕过它，也无法伪造它。物理法则对此进行评判。在你的整个评估套件中，没有比“时间耗尽”更不可篡改的事实真相了。
至关重要的是，第一层级和第二层级构成了你的实时网关：确定性、成本约为零、速度足够快，可以置于关键路径中并阻止运行。超时检查是这一概念最纯粹的体现——根据定义，它已经处于关键路径中。第三层级，即裁判模型，则恰恰相反：按量计费、缓慢、非确定性、仅适用于离线场景。你绝不会将模型即裁判放在关键路径上来决定响应是否足够快。裁判模型甚至无法看到时钟。
“被评为绿色”的实际情形
陷阱就在这里。大多数评估框架接收 (输入, 输出) 并对输出进行评分。输出 是智能体最终返回的任何内容——因此从构造上讲，在开始评分之前，时间信息已经被丢弃。评估程序 literally 无法看到运行过程超过了截止时间，因为它只有在运行结束后才存在。
你必须对运行过程进行评分，而不是对返回值进行评分：
type RunResult<T> =
| { status: "ok"; value: T; elapsedMs: 免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
