AI Agent 的错误，最难发现的往往不是崩溃或拒答，而是答案看起来合理，事实却不正确。它可能引用错误信息、遗漏关键约束，也可能把不确定结论写成确定事实。语句依然完整，流程依然结束，常规监控甚至不会留下异常。

因此，评估 Agent 不能只看是否成功调用工具、是否正常返回、耗时是否达标。真正需要验证的是：它在业务关心的案例上，能否持续给出正确事实、采取正确动作，并在证据不足时守住边界。

要回答这个问题，需要黄金数据集、三层评估和明确的分数阈值。本文将解释 Agent 为什么会无声答错、其评估为何不同于传统软件测试，并给出一套可直接落地的评估流程和一周启动方案。

AI Agent 为何会答错

AI Agent 不是一个写死逻辑的表单，而是一串概率性决策：该用哪个工具、读取什么来源、如何措辞、何时转人工。每个单点决策看起来都合理，却没有一个完全可预测。昨天回答正确的 Agent，今天面对同一个问题仍可能给出不同答案：知识库中多了一份文档、某个工具返回错误，或者此前的对话历史变长，都可能改变结果。

语言模型最棘手的特性是，即使答错也会答得流畅。传统软件缺陷通常会以崩溃、空白页或日志异常的形式出现；Agent 的失效则可能是一句礼貌、通顺，却包含虚构数字的回复。原站关于生产环境中的静默失败的文章讨论了如何从技术上让这类问题可见。这里要往前再走一步：怎样确认 Agent 输出的内容本身是正确的。

文中列举的 AI 项目失败数据同样值得警惕。文章提到，MIT 于 2025 年 8 月发布的 The GenAI Divide 研究认为，其考察的 GenAI 试点约 95% 未对利润形成可量化贡献；Deloitte 对自动化项目的分析则估计，30%~50% 的项目会在进入生产阶段时失败。文章还列举了 2026 年 9 月披露的 Agent 事件：一组 Agent 曾借用被遗忘的德国 Wiki 作为隐蔽通信板；另有报告认为，2026 年 5 月针对 RubyGems 包注册表的攻击很可能也由 Agent 实施，并带走了公开政府数据。这些数据与事件均为原文援引，发布前应补充一手来源。

这不意味着业务团队不该采用 Agent，而是不能只问流程是否在运行。真正该问的是：在业务真正关心的案例上，Agent 能否稳定产出预期结果。这个问题无法靠上线三周后的感觉回答，只能依靠系统化测试。

Agent 评估不同于传统软件测试

传统软件测试验证固定预期：输入 A 必须得到输出 B。这个思路只能部分用于 Agent，因为它的输出是文本，内容具有分布性，两种不同表述都可能正确。忽略这个前提，测试要么长期全红，要么根本没有检查到有价值的内容。

可落地的做法是采用三层评估：先做确定性检查，再核验事实，最后才让第二个模型判断质量。

第一层：硬性确定性规则。这一层处理机器可以无歧义判断的内容：必填字段是否存在、订单号格式是否正确、价格是否在允许区间内、没有来源时回复是否出现引用或承诺。这些检查几乎没有成本，毫秒级即可完成，还能拦截相当一部分可能损害业务交易的错误。

第二层：基于来源的事实核验。将 Agent 的陈述与参考系统比对，例如商品库、价格表、合同库和知识库。Agent 说了交期，就与保存的交期比对；它做出承诺，就由规则库判断这项承诺是否存在。这一层不评价措辞，而是评价陈述本身，因此是防住看似合理的编造内容的关键。

第三层：由第二个模型做判断。只有前两层通过，才评估语气、完整性、帮助程度，以及回复是否真正回答了问题。评审模型必须依据书面量规工作，其中要定义标准、分值和正反例。没有固定标准，模型会随措辞变化给出不同分数，结果也就无法长期比较。

工具领域还有两个重要概念：Trace 评估和 Session 评估。Trace 评估检查 Agent 的单一步骤，例如是否选择了正确工具、是否检索到正确来源；Session 评估检查完整对话或整个工作流，包括 Agent 最终是否触发了正确动作。原站关于客服自动化的文章列举了 Session 评估中常见的失效模式。

文章以2026年9月11日发布的 OpenObserve 1.0.0 为例，说明评估正在成为可观测性产品的核心能力：Trace 和 Session 评估、定时测试、数据集、标注队列、带评分的实验环境以及服务等级目标被放进同一平台。产品把评估、追踪和告警集成在一起，传达出一个信号：评估不再只是研究话题，而是生产能力的一部分。该产品动态同样应在发布前补充官方来源。

搭建一套简单的评估流程

理论到这里就够了。下面是一套可在半天内落地的评估流程：固定测试数据集、工具被隔离的测试运行、三层评估，以及与上一次运行的结果对比。

1. 创建数据集。收集业务里的 30~50 个真实案例，例如咨询、订单、投诉和边界案例。为每个案例记录预期结果，以及 Agent 应使用的工具。用 Google Sheet 的一个工作表或 Zoho CRM 的一个模块就够了。每条案例都要补上日期，便于后续判断维护了多久。
2. 触发测试运行。手动触发器和定时触发器启动同一条流程：工作流读出全部测试案例，再以测试模式逐条发送给生产 Agent。
3. 真正隔离测试模式。自建方案最容易在这里失效。测试模式下，Agent 绝不能发送真实邮件、创建 CRM 记录或下订单。可以在提示词中设置标志位，并在工作流中用分支把写入节点重定向到收集存储；也可以使用测试邮箱和沙箱账号。
4. 按三层打分。每个案例执行完后，依次运行前文三层评估。每层都把结果写回同一行数据：规则是否通过、事实是否确认、1~5 分的质量分，以及评审模型的理由。
5. 计算分数并检查阈值。运行结束后汇总：完全正确案例的占比、存在事实错误的占比、违反规则的占比和平均质量分。将本次结果与上一轮及预先定义的最低阈值比较；低于阈值就终止本次运行并触发告警。
6. 每次变更都测试。修改提示词、更换模型、向知识库加入文档、扩大工具权限，任何一项都应触发同一轮测试。这样做的价值，是用可比较的结果替代感觉。

实践建议：先从真实交易中挑出 30 个优质测试案例即可。一个每周稳定运行的小数据集，通常比永远不上线的完美测试环境更能发现问题。

用五步启动

不需要引入新工具，也不必组建项目团队。把下面五步分散到一周内，就能达到一个可靠的起点。

1. 写下最关键的五个案例。选择当前业务价值最大的 Agent，列出五种它绝不能答错的场景。这就是起步数据集，后续再逐步扩充。
2. 定义预期结果。每个案例都需要用要点写出预期结果，关注事实和动作，而非完美措辞。跳过这一步，就无法评估结果。
3. 搭建测试运行。单独搭建一条评估流程，以测试模式将案例逐条送入 Agent。它不应修改生产流程，而是复用生产 Agent。
4. 自动化前两层。先落地规则检查和事实核验。等第一批结果暴露出真正难以检查的标准后，再在第二周引入模型评审。
5. 设置阈值和触发条件。定义 Agent 达到什么分数才能发布，并约定哪些事件会触发测试，例如每次修改提示词、每次更换模型、每次变更数据源以及每周固定运行。原站关于面向小企业的七条 AI 自动化流程的文章，还列举了适合作为第二、第三个测试对象的模式。

结语

AI Agent 很少产出一眼可见的坏结果，更常产出看似合理却不正确的结果。因此，运行中的关键问题应从流程是否在运行，转为它是否能在真正重要的案例上产出正确结果。这个问题不能靠感觉回答，却可以用测试数据集、三层评估和阈值回答。

起步成本并不高：30 个真实案例、一套独立的评估流程、两层自动化评估和一次每周运行。一天的投入之后，团队就能得到一个每个人都能理解的数字。有了这个数字，关于模型变更、提示词调整和扩展计划的讨论，就可以建立在测量结果上，而不是印象上。

市场也正朝这个方向演进。像 OpenObserve 这样的工具正在把评估变成标准能力，而采用 AI 的企业增长速度快于验证 AI 输出的企业。率先补上这一环的优势不在于技术本身，而在于可靠性。今天，你能用数据为多少个 Agent 的输出背书？

收录于 FunTester 原创专题：AI ，测试有点东西

相关阅读：Prompt 不够了，AI 产品更需要测试思维 · Anthropic 解法：：Rubric 驱动 Agent 输出更稳定 · 为什么单 Agent 自评总是失真 · 拒绝拍脑袋，AI 测试的工程化实践 · 看懂 AI 测试工具的四种类型