VentureBeat 的企业 AI Agent 评估鸿沟暴露了生产环境故障问题

VentureBeat 发现了一个企业 AI Agent 评估鸿沟：50% 的受访组织部署了通过测试的系统，但这些系统仍然引发了面向客户的故障。这些 Agent 或大语言模型功能在此前一年中已经通过了内部评估。四分之一的组织不止一次遭遇此类故障。

这一发现对企业采用 AI 背后的一个令人安心的假设提出了挑战。通过评估并不一定意味着，当客户、实时数据、互联工具和不断变化的业务规则介入时，Agent 仍能可靠运行。

企业并未选择让人类牢牢掌控局面作为应对方式。调查发现，66% 的企业已经允许部分低风险 Agent 在零人工干预下部署，或正在构建相关能力，并计划在 12 个月内实现。只有 5% 的企业完全信任支撑这些决策的自动化评估。

这种不匹配正是核心矛盾。企业团队赋予 AI Agent 的自主权提升速度，超过了其改进决策依据的速度。

其结果并不仅仅是测试用例不足，而是一个现实场景对齐问题：受控评估测量的是一种环境，而生产系统创造的却是另一种环境。如今承受压力的是负责将前景可观的 Agent 演示转化为可靠服务的采购方、开发人员、风险团队和高管。

半数通过测试的 AI Agent 仍在触达客户后出现故障

这项调查最重要的发现是，对半数参与调查的组织而言，通过内部测试并不能预示安全的生产结果。

2026 年 6 月开展的 VB Pulse 调查涵盖了来自员工人数至少为 100 人的公司的 157 名合格受访者。其样本由受访者自行选择，而非随机抽取，因此相关百分比应被视为方向性证据。

即使存在这一局限，这一趋势也很难被忽视。根据这项企业评估调查，50% 的受访者曾部署过通过内部评估、但后来引发面向客户故障的 Agent 或 LLM 功能。

四分之一的受访者表示，这种情况发生过不止一次。该调查并未证明所有企业中都有一半经历了同样的故障率，但它确实表明，在 VentureBeat 接触到的组织中，评估漏检十分常见。

评估漏检是指缺陷绕过测试，并在实际运行条件下暴露出来。传统软件团队对此并不陌生，但生成式系统让问题更难定位。

普通应用程序通常将明确的输入映射为可预测的输出。AI Agent 则可以解读模糊的请求、选择工具、检索不断变化的信息，并通过多个步骤修改外部系统。每一个决策都增加了行为偏离预期的可能性。

例如，一个客户服务 Agent 可能在测试期间正确识别退款请求。在生产环境中，它还必须识别客户、读取当前政策、检查订单、遵守账户权限，并选择获得授权的操作。

即使某个中间步骤出错，最终回复看起来仍可能令人信服。因此，流畅的解释可能掩盖错误的数据库查询、被跳过的审批、过时的政策或未经授权的工具调用。

这种区别非常重要，因为客户体验的是完整工作流程，而不是基准测试分数。他们关心的是退款是否正确完成、其数据是否仍然保密，以及企业是否遵守了自身政策。

生产故障可能包括不准确的回答、造成损害的操作、不恰当的回应或未得到解决的请求。VentureBeat 发布的摘要并未提供完整的严重程度分类。

摘要也没有透露受影响组织的名称，或量化相关财务影响。读者不应认为每起事件都代表严重的服务中断或安全事故。

然而，这些故障直接影响客户，因此比开发过程中发现的错误后果更加严重。Agent 已经跨过了企业的发布门槛，并触达了测试团队之外的人员。

这一事实带来了本文的核心反转。内部评估本应为部署决策提供支持，但调查显示，通过这些评估往往无法预测真正重要的结果。

企业 AI Agent 评估鸿沟的本质是现实场景对齐

与增加测试数量相比，企业团队似乎更担心测试能否代表客户的真实行为。

只有 5% 的受访者表示完全信任自动化 Agent 评估。其余 95% 的受访者至少指出了一项影响其信心的局限。

与现实结果对齐不佳位居首位，29% 的受访者提到了这一问题。偏差或不一致以 21% 紧随其后，18% 的受访者则指出可解释性有限。另有 17% 的受访者提到评估过程中的数据泄露或隐私问题。

这些回答表明，企业 AI Agent 评估鸿沟的核心并不是测试覆盖率之争。企业可以生成数千条合成提示词，却仍无法重现影响生产行为的实际条件。

现实场景对齐描述的是评估结果与用户实际体验结果之间的关系。良好对齐的评估，能够为团队提供有关系统在部署环境、数据、权限和约束条件下可靠性的有效证据。

对齐不佳的评估仍可能具备可重复性。它可以生成整洁的仪表板和稳定的分数，却衡量着与实际产品仅有松散关联的行为。

静态测试集是造成偏差的原因之一。客户会提出测试设计者未曾预料的问题，以不同寻常的方式组合目标，并提供不完整或相互矛盾的信息。

环境则是另一个原因。生产数据库中包含缺失字段、重复记录、延迟更新，以及不同团队间不断变化的业务术语。互联应用程序可能返回错误，或在负载条件下表现不同。

权限也会重塑 Agent 的行为。使用简化工具的测试 Agent，与能够访问电子邮件、客户记录、日历、代码仓库或支付系统的生产 Agent，面对的选择并不相同。

多步骤执行会进一步放大这些差异。如果 Agent 正确完成每一步的概率为 95%，那么在十个相互依赖的步骤中，其整体可靠性将远低于 95%。

这一简化计算并不能模拟每一种 Agent 工作流，但它说明了为何不能根据孤立的工具调用准确率推断任务层面的成功率。

Agent 行为还具有非确定性，这意味着同一个请求在重复尝试时可能产生不同的执行路径。当客户期望系统始终稳定成功时，单次成功只能提供薄弱的证据。

Anthropic 的 Agent 评估指南区分了 pass@k 和 pass^k。pass@k 衡量的是多次尝试中是否至少有一次成功，而 pass^k 衡量的是每一次重复尝试是否都成功。

对于许多面向客户的系统而言，第二项指标更为重要。用户不可能提交多次退款请求，然后从中选择一个正确结果。

Anthropic 还建议检查环境的最终状态，而不仅仅是 Agent 声称的答案。Agent 可能宣称自己已经预订了航班，但数据库中实际上并不存在任何预订记录。

这种基于结果的方法揭示了对话式评估中反复出现的一个弱点。团队可能只评判回答听起来是否恰当，却忽略了 Agent 是否正确完成了底层操作。

多年来，相关研究一直在提出类似担忧。AI Agents That Matter论文指出，Agent 基准测试往往强调准确性，却忽视了成本、可复现性、留出集质量和特定应用需求。

这一问题在企业内部变得更加突出。生产就绪不仅意味着模型能否得出名义上的答案，还包括安全性、政策遵循、延迟、恢复行为和一致性。

自主权的提升速度超过了评估信心

调查中最强烈的警示，来自企业信任程度与其准备让 Agent 执行的操作之间的差距。

VentureBeat 询问企业，是否会允许自主 Agent 仅依据自动化评估结果部署代码或系统变更，而无需人工验证。

34% 的受访者表示，他们已经允许低风险 Agent 采用这种安排。另有 33% 正在构建计划于未来一年内支持这一模式的系统。

由于四舍五入，VentureBeat 将两组受访者合计为 66%。无论如何，约三分之二的受访者已经实现或正在接近零人工干预部署。

这一趋势看起来可能与仅有 5% 的受访者完全信任自动化评估相矛盾。实际上，多种激励因素可能推动企业在保障体系成熟之前迈向自主化。

首先是运行速度。当 Agent 处理大量请求、频繁部署变更或跨多个应用程序执行例行操作时，人工审批可能成为瓶颈。

其次是自动化的预期价值。如果工作流要求人工审批 Agent 的每项操作，其节省的时间可能少于采购方的预期。

第三是竞争压力。供应商越来越多地将 Agent 定位为能够完成工作的系统，而不仅仅是提供建议。如果企业采购方希望获得其承诺的收益，就必须赋予 Agent 一定的行动能力。

第四是组织职能割裂。产品团队可能负责发布速度，而安全、合规、客户支持和风险团队则承担故障带来的后果。

这些因素并不意味着零人工干预部署本身就不负责任。一个权限有限、操作可逆且控制机制可靠的专用 Agent，可能无需人工审核每项任务也能安全运行。

问题在于企业如何定义“低风险”。一项技术上常规的变更，如果涉及客户数据、身份验证、通信或其他依赖系统，就可能产生严重后果。

风险也是动态的。一个最初仅用于总结内部文档的 Agent，之后可能获得检索工具、写入权限，或触发下游工作流的权限。

每增加一项能力，都会改变其运行边界，也就是 Agent 被授权执行操作的条件范围。为早期版本设计的评估，可能已无法继续支撑同样的部署决策。

这正是企业 AI Agent 评估鸿沟演变为治理问题之处。真正的问题不在于 Agent 是否曾经通过某个分数阈值。

团队必须决定允许执行哪些操作、哪些证据足以支持这些权限，以及当生产证据与最初评估相矛盾时应采取什么措施。

NIST 的自愿性 AI 风险框架将监控视为贯穿生命周期的活动。其核心指南要求建立有文档记录的评估流程，并在生产环境中监控系统功能和行为。

这种框架将责任置于机器学习团队之外。产品负责人必须定义可接受的结果，领域专家必须明确政策边界，运营团队必须在发布后发现故障。

高管还需要区分任务自动化与决策问责。智能体可以自动执行操作，但组织仍需对客户结果负责。

因此，这项调查同时向供应商和买家施加了压力。供应商必须提供更强大的评估和可观测性工具。买家则必须判断这些工具衡量的是自身工作流，还是某种通用演示。

系统健康监控无法验证回答质量

智能体可以保持在线、快速响应并完成工具调用，但仍然产生错误结果。

VentureBeat 的调查发现，只有 23% 的受访者会在智能体部署后对其生成的回答进行实时质量检查。另有 51% 的受访者监控系统健康状况，却不实时检查输出质量。

系统健康通常涵盖正常运行时间、延迟、请求追踪、网关错误、token 使用量和工具可用性。这些指标有助于团队判断服务是否正常运行。

但它们无法判断回答是否准确、建议是否符合政策，或已完成的操作是否与用户请求一致。

客户服务智能体可以说明这种区别。监控可能显示模型请求成功、数据库响应有效，并且退款工具返回了 HTTP 成功状态码。

但客户仍可能收到错误的退款，因为智能体选择了过时的政策，或误解了哪笔购买存在争议。

同样的问题也出现在编码智能体中。部署流水线可能记录到一次成功的提交、已完成的测试，以及发布后服务可用。

这些信号无法证明该变更遵守了未记录的业务规则、能够处理真实流量模式，或避免了隐蔽的安全回归。

因此，生产环境中的质量监控必须检查结果，而不仅仅是基础设施。所需检查的结果取决于具体工作流。

对于支持智能体，有用的信号可能包括问题解决的正确性、未经授权的承诺、升级处理的准确性以及重复联系。对于研究智能体，则可能包括来源质量、事实依据和遗漏的证据。

对于会更改记录的智能体，系统应检查操作后的状态。团队还需要记录哪些数据、政策、工具和模型版本影响了决策。

这种记录通常称为追踪，即产生某项结果的一系列步骤和工具交互。追踪有助于调查人员确定故障是在哪个环节进入工作流的。

然而，仅有追踪并不等于评估。一份完整的日志可以准确展示智能体如何得出错误结果，却无法检测该结果本身是错误的。

质量检查需要参考信号。该信号可能来自确定性规则、数据库验证、客户行为、专家审核，或经过人工判断校准的另一个模型。

没有任何一种评分器适用于所有任务。基于代码的检查非常适合明确定义的状态，而开放式输出通常需要评分标准和定期人工校准。

Anthropic 建议结合自动化评估、生产监控、用户反馈、A/B 测试、对话记录审查和结构化人工研究。其分层方法反映了一个现实：每种方法都存在盲区。

生产监控尤其有价值，因为它能够揭示预料之外的行为和不断变化的用户模式。它也具有被动性，因为问题可能在监控识别出来之前就已影响客户。

这种权衡凸显了分阶段部署的重要性。团队可以从较小的流量占比、受限权限，或需要审批的建议开始。

然后，组织可以将生产结果与评估预测进行比较。如果两者关系保持一致，就可以扩大自主权限。如果关系失效，团队也能在影响所有客户之前获得证据。

目标并不是在发布前消除所有故障，这通常并不现实。目标是在持续更新组织测试内容的同时，限制未知故障的影响。

增加测试用例无法修复错位的评估

有效的应对方式是围绕生产结果、重复可靠性以及授予每个智能体的具体权限，重新构建评估。

覆盖范围仍然重要。企业需要涵盖常见任务、高难度边缘案例、违反政策的情况、对抗性请求以及需要人工升级处理的场景。

然而，如果评分器奖励了错误的行为，再多的用例也无济于事。测试可以非常全面，却仍然无法发现智能体是否更改了正确的记录，或是否遵守了审批要求。

团队应从明确结果开始。每项测试都应定义智能体完成操作后必须存在的状态，以及构成失败的状态或操作。

结果应体现用户的目标。支持智能体不应仅仅因为生成了富有同理心的回复就通过测试。它应正确解决问题，或将问题转交给获得授权的人员。

评估还应足够贴近生产环境，以暴露集成故障。智能体需要使用真实可信的工具、权限、数据格式、错误响应和工作流约束。

这并不意味着必须将敏感的生产数据复制到不安全的测试系统中。组织可以使用去标识化的示例、受控沙箱，以及根据已观察到的故障模式构建的合成记录。

隐私问题仍需要谨慎设计。调查发现，17% 的受访者认为数据泄露或隐私风险是影响其信任自动化评估的最大限制因素。

可靠的流程必须保护评估输入、限制评分器的访问权限，并记录追踪数据的存储方式。评估基础设施本身也可能成为敏感信息库，因为其中包含提示词、业务规则和故障示例。

重复试验是另一项要求。一次成功运行可能掩盖非确定性行为，而这种行为经过多次尝试后会变得十分明显。

团队应追踪关键任务的一致性，并根据影响程度设定阈值。信息性建议和不可逆的账户变更不应采用相同的发布标准。

评估还必须测试拒绝执行的能力。智能体应能识别信息缺失、权限不足，或请求超出其授权范围的情况。

总是尝试完成任务的系统可能在能力测试中得分很高，却会带来更大的生产风险。均衡的测试集应同时奖励正确执行和正确拒绝。

人工审核应根据风险来设置，而不应通过一个全局开关彻底取消。团队可以要求不可逆操作、敏感数据访问、异常交易或低置信度决策必须经过审批。

当确定性检查确认达到预期状态时，较低风险的案例可以自动执行。这种区分应取决于后果和可逆性，而不是请求看起来有多常规。

生产故障应转化为回归测试。回归测试用于检查系统是否仍能正确处理其以前完成过的行为，或后来已经修复的行为。

这种做法将现实世界中的证据与部署前测试套件联系起来。它还有助于防止团队只修复单次事件，却没有保留从中获得的经验。

组织应长期比较评估分数与客户结果。有用的衡量指标包括升级处理率、纠正操作、重复联系、投诉模式、回滚频率和政策例外。

合适的衡量指标会因工作流而异。关键步骤是检验更好的评估结果是否对应更好的生产结果。

如果相关性持续较弱，评估就没有发挥其发布决策功能。提高分数阈值也无法提供多少保护，因为底层衡量方式仍然存在错位。

独立研究支持以更广泛的视角看待就绪程度。一项提议的企业评估框架衡量成本、延迟、有效性、保障能力和可靠性，而不仅仅是准确性。

该论文是一篇预印本，不应被视为已经确定的证据。但其核心论点仍然反映了一个实际现实：智能体可以正确回答问题，却因为过于不稳定、缓慢、昂贵或不安全而不适合投入生产。

解决方案并不是一个通用基准。企业需要与自身数据、政策、用户和许可操作相匹配的评估系统。

三个信号将表明企业能否弥合差距

接下来的考验是，组织能否在进一步扩大智能体自主权限之前，将生产证据纳入发布决策。

第一个信号是实时输出和结果检查的增长。VentureBeat 发现，目前只有 23% 的受访者会实时检查回答质量。

如果这一比例上升，就表明企业正在超越正常运行时间仪表板。这将强化一种观点：当前的故障反映的是尚不成熟的保障实践，而非智能体技术不可避免的局限。

如果组织继续只监控基础设施，企业 AI 智能体的评估差距将持续存在。智能体可能始终保持可用，但客户仍会充当最终的质量控制环节。

第二个信号是零人工干预的部署是否仍仅限于可逆且边界明确的工作流。企业应发布或记录更清晰的低风险自主权限定义，包括权限、升级处理规则和回滚控制。

转向受限权限将表明组织正在根据后果匹配监督力度。在缺乏更强评估的情况下授予广泛访问权限，会削弱有关自动化正在负责任地扩张的说法。

第三个信号是重复发生的客户可见故障率。调查发现，四分之一的受访者曾在通过内部评估后遭遇不止一次事件。

未来的调查应区分事件严重程度、工作流类型、智能体权限、公司规模以及所使用的评估方法。基于概率的样本也将为更广泛的市场提供更有力的证据。

重复故障率下降将表明生产事件正在被纳入回归测试套件，并改变部署政策。重复故障率保持稳定或上升，则表明企业将故障视为孤立的缺陷，而不是衡量方式存在问题的证据。

Gartner 已经警告称，由于成本上升和商业价值不明确，到 2027 年底，超过 40% 的智能体 AI 项目将被取消。这项在Gartner 智能体预测中报道的预测，也指出部署尚不成熟且使用场景定义不清。

这一预测并不只与评估有关。但薄弱的评估仍会加剧成本和价值的不确定性，因为团队无法可靠地区分真正有能力的系统与令人印象深刻的演示。

企业买家现在应要求供应商提供重复试验结果、基于结果的评分、生产监控选项，以及来自与自身类似工作流的证据。综合基准分数可以提供背景信息，但无法回答这些运营问题。

开发人员应检查其测试环境是否复现了生产环境中的权限和故障路径。风险团队应了解智能体能够以多快的速度被停止、限制或回滚。

知识工作者应对此予以关注，因为他们往往最先发现这些故障。看似合理但实际错误的回答会制造隐性工作：员工必须核实内容、修复结果，并向客户解释错误。

这项调查并未证明自主智能体不适合企业部署。它揭示了一个更紧迫的问题：许多组织在没有证据表明其内部测试能够预测客户结果的情况下，就赋予了智能体自主权。

因此，实际问题很直接。在贵组织取消下一个人工检查点之前，能否证明其企业 AI 智能体评估流程能够预测生产环境中的实际情况，还是说下一位客户仍然是测试的一部分？