Agent 验证陷阱：200 状态码掩盖的错误答案

Agent 返回了 200 OK，但答案真的对吗？

我构建 agentic AI 系统已经有一段时间了，最让我忍不住写点东西的是：我们整个技术栈在告诉我们 agent 做了什么上非常出色，但在告诉我们它是否做对了这一点上几乎毫无用处。

可观测性工具会给你追踪信息——每次 tool 调用和每个 token，这对于在出问题后弄清楚发生了什么非常有帮助。Evals 会根据你过去某个时刻运行的测试集给你一个分数。但在生产环境中，在那一刻，当你的 agent 返回一个自信满满、格式良好、符合 schema 的 200 响应时，整个流程中没有任何东西在检查这个响应内部的答案是否实际正确。一个 200 可能包裹着一个自信但错误的答案，而你的仪表板仍然会闪起绿灯。

我做了个小实验来看这到底有多糟。我拿了一个便宜的、弱小的模型，让它处理一个真实的结构化任务，而我能够检查答案。它的正确率约为 69%，但看起来正确的频率要高得多。然后我给每个输出包装了一个有根据的检查，询问它是否真正满足约束条件，而不仅仅是看起来满足，之后重新运行那些失败的。正确率爬升到了 100%。我一直在琢磨的部分是，模型从未变得更聪明，验证做了所有的工作。

所以我一直回归到的观点是，一致性不等于正确性。一个 schema 有效、流畅、记录良好的答案仍然可能完全错误，而现代 agent 栈中几乎没有什么东西能够在它发生时注意到这一点。

我一直在思考运行时认证层会是什么样子——一个位于"记录了 200"和"通过了我们的离线 evals"之间的东西，回答一个似乎没人在问的问题：这个特定的输出，就在现在，实际上是否正确？

如果你在生产环境中运行 agent，我真的很想知道你是如何处理这个问题的，或者你是否大多只是学会了与绿灯仪表板相处。