Enterprise AI teams are giving agents more freedom at the same moment their confidence in automated testing is collapsing.企业 AI 团队在赋予智能体更多自主权的同时，对自动化测试的信心却在急剧崩塌。
Half of enterprises have deployed an AI agent or LLM feature that passed internal evaluations and yet still caused a customer-facing failure — one in four more than once — according to the June 2026 VB Pulse survey of 157 qualified enterprise respondents at companies with 100 or more employees.根据 2026 年 6 月 VB Pulse 对 157 家拥有 100 名以上员工的企业受访者进行的调查显示，半数企业曾部署过通过内部评估的 AI 智能体或大模型功能，但最终仍导致了面向客户的服务故障——其中四分之一的企业甚至发生过不止一次此类故障。
The sample is self-selected rather than a probability sample, so the findings should be read as directional, not precise.该样本属于自选样本而非概率样本，因此调查结果仅具方向性参考意义，而非精确数据。
But enterprises are not responding by slowing automation: 66% of respondents already permit some production deployment without human review or are building systems intended to do so within the next 12 months. Only 5% say they fully trust the automated evaluations that would make those release decisions.然而，企业并未因此放慢自动化进程：66% 的受访者表示，他们已允许在无需人工审核的情况下进行部分生产部署，或正在构建旨在未来 12 个月内实现此目标的系统。但仅有 5% 的受访者表示，他们完全信任那些用于决定发布与否的自动化评估结果。
That mismatch is the evaluation gap: the autonomy ceiling is rising faster than the assurance beneath it. 这种错位就是所谓的“评估鸿沟”：自主性的上限上升得太快，而其底层的保障机制却未能跟上。
It also fits a broader thesis that will be explored at VB Transform 2026: enterprises ship agents first, while the control layers around identity, evaluation, cost, context and orchestration are arriving later. The next year will be a retrofit cycle, with buyers shifting budget toward the systems that make agentic deployments governable and dependable.这也符合将在 VB Transform 2026 大会上探讨的一个更广泛的论点：企业往往优先发布智能体，而围绕身份验证、评估、成本、上下文和编排的控制层则姗姗来迟。未来一年将是“补齐短板”的周期，买家会将预算转向那些能让智能体部署变得可治理、可信赖的系统。
Why a passing evaluation is not a working agent为什么评估通过并不代表智能体工作正常
Traditional software testing usually asks whether a defined input produces an expected output. Agent testing is harder because the system may choose its own sequence of steps, call tools, retrieve data, alter state and respond differently from one run to the next.传统的软件测试通常是检查给定的输入是否产生预期的输出。而智能体测试难度更大，因为系统可能会自行选择步骤序列、调用工具、检索数据、更改状态，并导致每次运行的结果各不相同。
An agent can make several individually plausible decisions and still reach the wrong result. It may retrieve the correct account but update the wrong field. It may draft a valid refund request but send it without approval. It may call five tools successfully before a sixth step leaks sensitive information or leaves a workflow incomplete.智能体可能会做出几个看起来合理的决策，但最终却得出错误的结果。它可能检索到了正确的账户，却更新了错误的字段；它可能起草了一份有效的退款申请，却在未经批准的情况下直接发送；它可能成功调用了五个工具，但在第六步时泄露了敏感信息或导致工作流中断。
The survey shows enterprises already recognize this limitation. The most common reason for distrusting automated evaluation is poor alignment with real-world outcomes, cited by 29% of respondents. Bias or inconsistency follows at 21%, lack of explainability at 18%, and data leakage or privacy concerns at 17%.调查显示，企业已经意识到了这一局限性。29% 的受访者表示，不信任自动化评估的最主要原因是其与实际业务结果的脱节。其次是偏差或不一致性（21%）、可解释性不足（18%）以及数据泄露或隐私担忧（17%）。
That hierarchy matters. Enterprises are saying the score often does not predict what happens when a customer, employee or business process encounters the agent in production — not that automated scoring is too slow or expensive.这种排序至关重要。企业想要表达的是：自动化评分往往无法预测当客户、员工或业务流程在生产环境中接触到智能体时会发生什么——问题不在于自动化评分太慢或太贵。
NIST makes a similar point in its Generative AI Profile: measurements gathered in controlled environments may not transfer cleanly to deployment because behavior changes with prompts, users, context and operating conditions. Its guidance calls for field testing, post-deployment monitoring and clear processes for escalating failures.NIST（美国国家标准与技术研究院）在其《生成式 AI 概况》中也提出了类似的观点：在受控环境中收集的测量数据可能无法直接迁移到生产部署中，因为行为会随着提示词、用户、上下文和运行条件的变化而改变。其指南呼吁加强现场测试、部署后监控，并建立明确的故障升级流程。
VB Transform · July 14–15 · Menlo Park · LLMs, ops & evalsVB Transform · 7 月 14-15 日 · 门洛帕克 · 大模型、运维与评估
Standard benchmarks fail. Amazon and Waymo explain what they test instead.标准基准测试已失效。亚马逊和 Waymo 分别解释了他们的测试方法。
The evals track goes deep on the four dimensions of reliability — consistency, robustness, predictability, safety — and how teams at Amazon and Waymo are operationalizing them in production.“评估”专题将深入探讨可靠性的四个维度——一致性、鲁棒性、可预测性、安全性，以及亚马逊和 Waymo 的团队如何在生产中落实这些标准。
See the full agenda →查看完整议程 →Capability is not consistency能力不等于一致性
A single successful run proves that an agent can complete a task. It does not prove that it will complete the task reliably.单次运行成功只能证明智能体能够完成任务，并不能证明它能可靠地完成任务。
Anthropic’s guidance on agent evaluation distinguishes between measuring whether a system succeeds at least once across repeated attempts and whether it succeeds every time. That distinction is essential for customer-facing or operational workflows. A model that occasionally produces an excellent answer may still be unacceptable if the same task fails unpredictably on the next attempt.Anthropic 在其智能体评估指南中区分了“在多次尝试中至少成功一次”与“每次都能成功”两种情况。对于面向客户或关键业务的工作流而言，这种区分至关重要。一个偶尔能给出完美答案的模型，如果下一次尝试时却不可预测地失败，那么它依然是不可接受的。
Enterprise teams should therefore treat repeatability as a first-class metric. That means running the same scenario multiple times, varying phrasing and context, testing tool failures, and measuring whether the final business outcome remains correct even when the route changes.因此，企业团队应将“可重复性”视为核心指标。这意味着需要多次运行同一场景，改变措辞和上下文，测试工具故障情况，并评估即使路径发生变化，最终的业务结果是否依然正确。
The evaluation set also has to evolve. Every production incident should become a permanent regression test. Customer escalations, failed tool calls, incorrect approvals and data-handling mistakes should feed back into the pre-deployment suite rather than remaining isolated support cases.评估集也必须不断演进。每一次生产事故都应转化为永久性的回归测试。客户反馈的升级问题、失败的工具调用、错误的批准操作和数据处理失误，都应反馈到部署前的测试套件中，而不是仅仅作为孤立的工单处理。
Autonomy should expand by risk, not by ambition自主性的扩展应基于风险，而非野心
The survey does not imply that every agent action should require a person. Human review cannot scale across millions of low-consequence decisions.本次调查并不意味着智能体的每一个动作都需要人工干预。在数以百万计的低影响决策中，人工审核无法实现规模化。
But zero-human operation should be earned by demonstrated reliability and bounded by the consequences of failure.但“零人工”操作必须建立在经证实的可靠性基础上，并受到失败后果的约束。
Low-risk actions such as drafting internal summaries or categorizing documents can tolerate broader autonomy. Financial transactions, customer communications, code deployment, access-control changes and data deletion need stricter thresholds, repeated consistency tests, policy checks, rollback mechanisms and clear human escalation paths.对于起草内部摘要或文档分类等低风险操作，可以容忍更高的自主性。但涉及金融交易、客户沟通、代码部署、访问权限变更和数据删除时，则需要更严格的阈值、重复的一致性测试、策略检查、回滚机制以及明确的人工升级路径。
The risk isn't evenly distributed by company size, either. Larger enterprises — those with 2,500 or more employees — are moving toward zero-human deployment fastest, at 70% versus 64% for smaller companies, and they're also shipping more agents that go on to fail a customer, at 54% versus 48%. 风险在不同规模的企业中分布也不均衡。大型企业（员工人数在 2,500 人及以上）向“零人工部署”迈进的速度最快（70%，小型企业为 64%），但他们发布后导致客户故障的智能体比例也更高（54%，小型企业为 48%）。
That is the warning for enterprise leaders. Removing the human from the loop does not remove uncertainty. Without stronger assurance, it converts uncertainty into an automated production decision.这对企业领导者是一个警示：将人工排除在流程之外并不能消除不确定性。如果没有更强有力的保障，这只会将不确定性直接转化为自动化的生产决策。
The market will keep pushing toward greater autonomy because the economic incentive is real. The organizations best positioned won't be those that remove people fastest — they'll be the ones that treat repeatability and regression testing as seriously as deployment speed.市场将继续推动更高的自主性，因为其背后的经济激励是真实的。最终胜出的企业，不会是那些最快剔除人工的企业，而是那些将“可重复性”和“回归测试”看得与“部署速度”同等重要的企业。
