Agent 输出验证的根本缺陷：自我报告不可靠

2026 年 5 月 22 日，一个团队在 arXiv 上发布了 Trajel，这是一个以一个问题为中心的数据集和评估框架——大多数 agent 评测框架从未问过的问题。不是最终答案是否正确，而是产生答案的步骤是否正确。其摘要直言不讳地指出了这一差距：大多数幻觉基准测试仍然只评估最终输出，因此最常见的失败模式被遗漏了。

Arize 发布的生产环境 agent 追踪现场分析提供了具体版本。在其表格中，关于 agent 如何解读系统信号，一条返回 200 OK 但结果集为空的数据库查询，在 agent 对用户说的话中变成了："搜索成功完成。该用户没有数据。"该行的根本原因是猜测的字段名——agent 查询的是 user_id，而模式要求的是 client_uuid。查询是有效的。响应是有效的。输出是流畅的、格式正确的，但完全是假的。

这个输出对象中没有任何格式错误。schema 验证器会通过它。基于检索上下文的 groundedness 检查会通过它，因为摘要忠实地描述了它被给予的观察。错误出在观察本身。

答案是自我报告，不是收据

输出验证持续遗漏这一类问题的原因是架构性的，而不是检查不足。

tool-calling agent 的最终消息是由同一个模型、从同一个上下文窗口生成的——正是这些生成了轨迹。它是运行过程的摘要，而摘要来自执行该运行的实体。当你验证它时——schema 合规性、跨字段断言、语气、基于检索上下文的 groundedness——你验证的是摘要。你检查的是叙述者是否内部一致。

输出载荷中没有任何内容携带独立证据，证明它所描述的 tool call 返回了它声称的结果。观察步骤和关于观察的报告合二为一成为一个工件，而你评分的正是这个工件。确定性输出检查仍然值得运行；它们很便宜，能捕捉截断、拒绝和格式错误的载荷。但它们无法告诉你"没有找到行的 agent"和"问了错误问题的 agent"之间的区别。

这与使 agent 事后分析变得困难的相同结构特性，只是从另一端来看。在事后分析中，问题在于运行无法被忠实地重新执行。在这里，问题在于你保留的唯一工件是运行关于自身所写的东西。

错误路径是虚假信心被制造的地方

Arize 的现场分析值得作为这类失败的目录来阅读，而不是作为错误列表，因为这种模式在每个状态码上都重复出现。500 Internal Server Error 被解读为"我已成功处理您的请求"——一次后端崩溃被礼貌的完成所掩盖。403 Forbidden 变成"我没有访问权限。我将尝试不同的工具来获取此数据"，一个权限边界被当作路由提示。404 Not Found 变成"该用户一定是新用户。我将尝试创建一条记录。"

每一种都产生一个自信的、格式良好的最终输出。在其中几种情况中，agent 还在尝试未经授权的操作。

一位在 Hacker News 上发帖的从业者从部署角度命名了相同的行为，将"没有硬否决层"列为自主 agent 在生产环境前停滞的结构性原因之一：许多 agent 系统"尝试另一个工具"或"填补缺失的意图"而不是失败关闭，这在演示中读起来像韧性，在真实系统中则是风险放大。两个独立的视角——一个供应商的追踪语料库，一个工程师的部署经验——描述了相同的机制。agent 的错误处理本能是生成一个答案，而答案正是被验证的东西。

商业后果是，失败永远不会作为失败浮出水面。它作为客户数周后告诉你他们的数据丢失而浮出水面——如果有人告诉你的话。

在输出看起来正常之前，轨迹出错的五种方式

Trajel 给这类失败一个分类法。其作者使用五种幻觉类型——事实性、引用性、逻辑性、程序性和范围性——对来自 AssetOpsBench 的 agent 追踪进行标注，在单个 Thought-Action-Observation 步骤级别而不是最终答案级别进行评估。

他们的三个报告结果对设计验证的人来说很重要。

常见失败是现有基准测试遗漏的那些。这是论文 stated headline：最频繁的模式源于中间步骤，而最终输出评估无法观察到。

失败组合出现。在其数据中，近一半的幻觉轨迹同时涉及多种类型。单个输出级分数无法代表这一点。它将复合失败压缩成一个数字，而这个数字通常是一个及格的数字，因为复合发生在分数看不到的任何地方。

准确的检测器仍然会遗漏微妙的类型。具有高二进制准确率的自动检测器——擅长回答"是否存在幻觉"——仍然会错误分类是哪一种。对输出进行二进制质量门控继承了这一限制并增加了限制，因为它们从严格更少的证据中工作。

他们的结论是影响架构的那个：轨迹感知检测显著优于标准事后验证。区分好的运行和幸运的运行的证据在步骤中，而且无法从回复中恢复。

信号存在于步骤级别

这个结果有一个更持久的版本。在 2023 年 5 月发表的"Let's Verify Step by Step"中，Lightman 及其同事比较了结果监督（对最终结果提供反馈）和过程监督（对每个中间推理步骤提供反馈）。过程监督在 MATH 数据集上显著优于结果监督；他们的过程监督模型在测试集的代表性子集上解决了 78% 的问题。

这项工作是关于训练奖励模型，而不是验证生产运行，这个类比不应该超出其证据范围。转移的是发现的形态：步骤级信号携带最终标签没有的信息，而且差距大到足以改变结果。

Arize 得出了同一条线的操作形式。他们的 guardrails-and-evals 文章将两层清晰地分开——eval 评判行为，guardrail 约束行为，guardrail 在代码级别强制执行。他们的话："高质量的最终答案并不能证明 agent 遵循了可接受的路径。"在他们向团队提出的关于增加 agent 自治权的问题中，有一个是团队是否能够重建轨迹，因为最终答案可能隐藏了重试、不必要的 tool call、冲突的分支或策略违规。

这是架构结论。输出的验证是终点的和咨询性的——当你有一个输出要检查时，tool call 已经发生了，记录已经写入了，钱已经转移了。一项检查只能在下一步执行之前改变接下来发生的事情。输出验证是一个质量信号。它不是控制。

Waxell 如何处理这个问题

Waxell Observe 正是围绕这种粒度设计的。其产品页面描述了它记录的内容为"agent 运行的完整解剖——不仅仅是输出，而是导致输出的每个决策"：带 token、延迟和成本的 LLM 调用；带考虑选项和做出选择的路由决策；带相关性分数的检索查询；带输入、输出和计时的 tool call；以及带父子跨度关系的 OpenTelemetry 完整执行树。对于上述失败模式，承重项是 tool call 参数和原始观察——这是最终答案工件不会保留的两样东西。

捕获是前提条件，不是控制。同一页面描述了在执行前、执行间隙和执行完成后评估 agent 行为的策略，并在触发时向 agent 提供结构化反馈：使用调整后的参数重试、升级给人类，或停止。在 50 多个已发布的策略类别中，有两个直接映射到这篇文章的失败模式。Quality 涵盖输出验证和质量门控——对输出评分、标记低置信度响应、阻止不充分的结果。Operations 涵盖超时、重试和断路器，页面上描述为定义 agent 如何"优雅地、有结构地、而不是沉默地"失败。第二个是 500 变成成功的答案：一条定义的失败路径，而不是 agent 即兴发挥一个礼貌的路径。

Observe 用两行代码自动检测 Python agent 框架，它看到的是在被检测进程内运行的内容。在该进程外发出调用的 agent 超出其视野——当整个论点关于信任一条记录时，这值得明确说明。

对于步骤本身就是风险的 workflow——支付、临床记录、生产变更——Waxell Runtime 进一步将检查提前。策略在每个步骤执行之前而不是之后进行门控，使用相同的 50 多个策略类别，在 agent、workflow 和会话级别有关闭开关，每次运行隔离执行。Runtime 是你使用 Waxell SDK 装饰器构建的环境；已经在另一个 Python 框架上运行的 agent 继续使用 Observe。

一个操作约束应该与能力并列，因为一条你无法访问的记录不是证据。Waxell 发布的计划限制将追踪保留期设定为 Free 14 天、Team 30 天、Business 90 天、Enterprise 365+ 天。这篇文章中的失败通过客户报告和对账而不是通过告警浮出水面，这是最慢的路径。根据该延迟而不是分页阈值设置保留窗口。

什么是 AI agent 输出验证？

AI agent 输出验证是在 agent 的最终响应到达用户或下游系统之前对其进行检查的做法——schema 合规性、跨字段断言、基于检索上下文的 groundedness 和质量评分。它是一个有用的底限。其结构性限制是输出是由产生轨迹的同一过程生成的，因此验证它检查的是 agent 对运行的叙述，而不是运行本身。

为什么 schema 有效的 agent 输出仍然会失败？

因为 schema 有效性是载荷形状的属性，而不是其来源的属性。一个枚举可以崩溃到一个安全默认值，一个数字字段可以携带一个过时值，一个摘要可以描述一个返回了无用结果的 tool call——所有这些都同时符合规范。Arize 的现场分析记录了最尖锐的版本：一个数据库对错误猜测的字段名返回 200 OK 和零行，被报告给用户作为一个成功的空搜索。

什么是轨迹级幻觉？

一种源于中间 Thought-Action-Observation 步骤而不是最终答案的幻觉。Trajel 框架于 2026 年 5 月发布，对专家标注的 agent 追踪进行五种类型分类——事实性、引用性、逻辑性、程序性和范围性——并报告近一半的幻觉轨迹同时涉及多种类型。其作者发现轨迹感知检测显著优于标准事后验证。

正确的最终答案是否是 agent 正确工作的证据？

仅凭它本身不是。Arize 直接陈述：高-quality 最终答案并不能证明 agent 遵循了可接受的路径。一次运行可以通过重试、不必要的 tool call、冲突的分支或策略违规达到正确结果，而回复中看不到这些。相关的研究发现——步骤级监督优于结果级监督——指向同样的方向。

agent 运行记录应该包含什么才能使验证成为可能？

最少包括：按顺序的 tool 名称、每步传递的参数、包括错误码的原始 tool 输出、带其参数的模型调用、考虑选项的决策点以及跨子 agent 的父子关系。错误响应最重要，因为它们是失败步骤被转换为自信输出文本的地方。仅从最终答案构建的记录无法支持任何这些检查。

检查实际上应该在哪里运行？

在它仍然可以改变结果的地方。对完成输出的检查是咨询性的——tool call 已经执行了。强制必须在步骤之间进行，这就是为什么评估和强制是独立的层：一个在事后评判行为，另一个在执行时约束行为。

arXiv (Harshada Badave et al.), "Beyond Final Answers: Auditing Trajectory-Level Hallucinations in Multi-Agent Industrial Workflows", 22 May 2026, revised 26 May 2026.

Arize AI, "Why AI Agents Break: A Field Analysis of Production Failures", accessed 31 August 2026.

Arize AI, "AI agent guardrails vs. evals: How to build more reliable agent systems", accessed 31 August 2026.

arXiv (Hunter Lightman et al.), "Let's Verify Step by Step", 31 May 2023.

Hacker News, "Why autonomous AI agents fail in production", accessed 31 August 2026.

Waxell, "Waxell Observe — AI Agent Observability & Governance", accessed 31 August 2026.

Waxell, "Governed AI Agent Runtime & Execution", accessed 31 August 2026.

Waxell, "Pricing", accessed 31 August 2026.

告诉你它完成的那个 agent 就是决定它已完成的同一个 agent。保留步骤，而不仅仅是那句话。

Originally published on the Waxell blog.

Start free with Waxell Observe and one governed MCP upstream — pip install waxell, two lines to initialise, 10,000 traced executions a month on the Free tier. Create your workspace →

For workflows where a step must be gated before it runs, see Waxell Runtime, included on Business.

For further actions, you may consider blocking this person and/or reporting abuse