Agentic AI 验证框架：如何不靠「看起来不错」判断输出质量

在企业引入 agentic AI 处理核心业务系统时，「输出看起来不错」几乎成了项目推进中最常见、也最危险的判断方式。一位长期从事应用现代化咨询的架构师在最新文章中提出：agentic AI 的输出质量只与其验证机制相当，缺乏结构化验证的自动化改造会在静默中累积风险。文章基于其参与 COBOL 模块迁移等真实项目经验，梳理出一套面向 agentic AI 的迭代验证框架。

「看起来不错」的陷阱

文章以一个典型场景开场：客户挑选了一块「相对独立」的 COBOL 模块交给 agent 处理，五分钟内产出一份超过 2500 词的反向工程文档。客户专家扫了前 10–20 行，确认记录格式描述无误，便判定整体可用。然而模型最容易验证的部分通常也是最容易写对的部分，文档中其余内容是否准确、是否遗漏、是否产生幻觉，专家在短时间内无从判断。

这类情况在企业核心系统中尤其危险：模块的领域知识往往沉淀数十年，而 agent 用几分钟就给出完整叙述。验证负担如果全部压在专家身上，会迅速造成「AI 疲劳」，规模化也就无从谈起。

技术瓶颈：上下文腐烂与三类失效模式

随着上下文窗口被填满，LLM 会出现两类退化：

当占用率低于 50% 时，中间位置的 token 质量下降，模型保留开头和结尾，但丢失中间内容；
超过 50% 后，开头部分也开始衰减。

模型仍会输出自信、连贯的文本，这就是业内常说的「context rot」。无论上下文过满还是过少，最终都会落到三种失效模式上：

漏失（The miss）：技术上看似无误，但忽略了应当包含的内容，输出不完整；
幻觉（The hallucination）：生成了看起来合理但并不存在或并不正确的内容；
误读（The misinterpretation）：模型尽力遵循模糊指令，结果却与预期相左。

文章认为，正是这三种模式让验证成为不可省略的一环。

验证的三方角色

作者把验证拆解为三类参与者——人、AI 与确定性工具，并指出每两者组合都存在特定失效模式：

AI 漏掉了什么，被人幸运发现，模型往往只修补暴露的那一点，而不追问根因；
AI 产出在流水线中能编译通过、但事实错误，确定性工具很难拦住，问题由此进入生产；
自动化本身有门槛，「5 秒就能手工完成的事为什么要自动化」的旧观念，使得技术债往往要到很晚才被发现，也是 agentic AI 落地停滞的常见原因。

结论是：单独依赖任何一方都无法形成可扩展的验证，必须把人、AI 与确定性工具组合起来，才能在真实场景中回答「输出是否合格」这一问题。

一个迭代式的验证框架

作者强调验证必须是迭代的——跳过最基础的检查，上层的进阶校验就失去可靠性。跨领域验证 agentic AI 输出时，需要回答的核心问题本质上是一致的：

具体要检查的是什么？
构建这一检查的成本（金钱、时间、专业能力、生产数据访问权限）是多少？
由谁来执行——确定性工具、AI 还是人，抑或组合？

文章用「选最好的 LLM、跑最高的基准并不重要，重要的是你能不能判断它到底有多好」收束观点，把验证能力本身摆在与模型选型同等的位置。对于正在推进 agentic AI 落地的团队而言，这套框架的价值不在于给出标准答案，而在于把模糊的「输出对不对」拆成可逐项讨论、可分步治理的具体问题。

（正文基于原文核心论点重写，部分细节因原文截断未完整呈现。）