处理量放大三倍，卡住的是复核那一环

翻到那份八月调查的中间几页，有两行数字挨在一起，读起来像互相矛盾。允许智能体在没有人工确认的情况下修改生产环境的组织，从七月的 75% 降到 56%。同一时期，使用厂商原生评测工具的比例从 31% 升到 59%。一个在退，一个在进。

需要说明这两个数字的口径，否则很容易读反。56% 指的是这样一群人：他们的组织已经在跑自主智能体，其中一部分已经允许特定生产变更只凭自动评测结果上线，另一部分正在为此做工程，希望一年内做到。75% 到 56% 这个下降，意味着打算这么做的组织变少了，不是已经做的收回了。

同一份调查里还有第三个数：期望在未来可见期内继续保留人工审批的受访者，从七月的 20% 涨到八月的 42%，翻了一倍多。问到未来一年哪一项可靠性投入增长最快，最多的人选了人工复核流程，30%，排在后面的是生产可观测性 26% 和自动评测流水线 21%。

三个数放在一起，指向的不是一次信心危机，而是一次产能结算。企业买了更多评测工具，同时给更少自动权限，然后把钱加到了人工复核上。这三件事在同一个方向：判断的活从系统挪回了人手里。

先看这份调查能支撑什么

它由 VentureBeat 的调研部门在八月做，样本 140 人，来自读者与面板成员的自愿报名，不是随机抽样。八月样本里 53% 是最终采购决策者，七月是 44%，人群构成变了，这会污染跨月的对比。

调查方自己做了这个检验：在决策者这个子群体内部，允许无人工确认发布或正在建设这一能力的比例，从 88% 降到 61%。同一个群体内部的下降幅度和整体接近，说明这不是换人造成的。但两份样本都是不同批次的自选人群，这仍不足以证明整个企业市场发生了同样的变化，也不足以证明原因是什么。

所以正确的读法是：这是一次方向性的观察，不是一次统计测量。它值得用来对照你自己的判断，不值得用来预测行业。

一进一退为什么不矛盾

买更多评测工具，同时收更少自动权限，看上去矛盾。其实是两个不同的问题被混在了一个词里。

评测回答的是：这套系统在我们抽样的输入上，通常对不对。这是关于准确率的问题，它的分母是你采样的那个分布。授权要回答的是另一个问题：如果这一次它错了，会发生什么，多久能恢复。相关，但不是同一个量。

同一份调查提供了两个支撑。在跑预部署评测的组织里，61% 在过去十二个月里至少遇到过一次这样的情况：功能通过了内部测试，随后在客户侧造成故障；其中 22% 遇到不止一次。也就是说，通过率不低，故障照样发生，因为故障来自分布之外。

另一个支撑更直接：只有 29% 的组织把实时输出质量检查作为主要监控手段。多数人监控的是可用性、报错率、延迟。这些指标能告诉你系统在运行，不能告诉你它运行得对不对。一套看不见输出对错的监控体系，撑不起一个不需要人看的授权模型。

权限收回来之后，复核需求去了哪里

收回自动上线权限，看起来是把风险关进笼子。它实际上只是把一个成本从一个科目挪到另一个科目：原来由系统单独承担的决定，现在要由人承担一部分，而人是有速率的。

更麻烦的是另一头。AI 让上游的处理量上升，这是产品在变好的信号，不是问题。同一个团队原来每天处理八百条工单，上了智能体之后变成两千四百条，因为响应变快了、渠道变多了、原来直接放弃的低价值工单现在有人处理。如果其中需要人看的比例还是 3%，待复核量就从每天 24 条变成 72 条。

复核的速率不跟模型一起涨。人看一条业务判断要三十秒到三分钟，这个数字这几年没变过，未来两年也不会变，因为慢的原因是阅读理解、责任判断和留痕，不是打字速度。模型提速的那部分，在复核这一环上完全接不住。

于是出现一个在 2026 年下半年反复出现的场景：模型更准了，评测更全了，授权更谨慎了，结果是业务开始抱怨审批慢。抱怨的对象看起来是流程，真实原因是队列。

队列在利用率越过某个点时才失控

排队论里有一个朴素的结论：等待时间近似按「利用率除以一减利用率」放大。假设看一条要 90 秒，利用率 50% 时平均等 1.5 分钟，70% 时 3.5 分钟，80% 时 6 分钟，90% 时 13.5 分钟，95% 时 28.5 分钟。产能看起来只差几个百分点，等待差了好几倍。

这解释了企业里反复出现的那个现象：复核队列在某个时刻突然失控，而此前一切正常。失控点不是需求翻倍那天，是利用率越过 85% 那天。人在这个时候的第一反应不是加班，是开始滑屏。

把这个结论落到配置上，只需要三个参数。到达率：每天需要人看的条目数。服务时长：一条平均看多少秒。有效工时：每个复核人每天按八小时乘 0.7 计，剩下三成花在切换、例外沟通和记录上。

举一个算得出来的例子。每天 2,000 条待复核，每条 90 秒，日需求是 50 小时。按 9 个人排，有效产能 50.4 小时，利用率 99%，按上面的换算，平均等待接近三小时，尾部会到半天以上。加到 10 个人，利用率 89%，平均等待降到 12 分钟。11 个人，81%，6 分钟。

这个算式的价值不在精确，在于它把「我要几个人」从一次组织讨论变成一个除法。多数团队从来不做这个除法，人按感觉配，三个月后发现积压，再用加班消化。加班让单件时长上升，队列继续变长，于是加班的结论被写成「这个团队效率不高」。

复核这件事能压缩的只有两成

把一条复核拆开看，它由三个动作组成：读上下文、做判断、留记录。三者的可压缩性差得很远。

读，要看清输入、相关历史和上游字段。这一段的成本取决于系统给的上下文质量。信息散在四个页面，读完要一分钟；聚在一屏，二十秒。改善空间在这里，而且不靠人。

判，是责任动作，压不下来。能压它的只有两条路：降低判断难度（缩小动作范围、给出带条件的推荐），或者降低判断频率（抽样）。两条路都不是训练能解决的。

记，理由要留给人看，但格式可以固定。用结构化表单代替自由文本，用预置的拒绝理由代替手写，这一段能从四十秒降到十秒。

三段合起来，一条 90 秒的复核大概能降到 70 秒上下，也就是两成。这个数字有用，因为它说明复核产能不是靠管理改进能解决的问题，只能靠配置解决：改上下文供给、改动作范围、改抽样比例。

合并队列比加人更省

还有一个几乎不花钱的手段，经常被跳过：把分散的复核队列合并成一个池子。

理由在波动上。三条业务线各自有高峰也各自有低谷。分开配人，每条线都要按自己的峰值留余量，空转的部分不能互相借用。合并之后，三条线的峰值很少同时到，波动相互抵消，池子的到达率比三条独立的线平稳得多，同样的利用率下等待更短。

代价是专业度。合并之后一个人要处理三类判断，单条处理时长上升，判断一致性下降。所以合并的边界是知识是否重叠：客服退款和发票校验不重叠，合并只会让人变慢；同一类审批在不同区域的版本重叠，合并划算。

这一条常被跳过，因为组织架构按业务线划，队列跟着架构走。结果是每条线都在喊缺人，而总人数并不少。

产能见底之后的三种症状

队列被压满之后，组织通常先出现三种症状，而它们都不会被记成故障。

第一种是绕行。业务等不及，自己在系统外把结论定了，系统只用来留痕。三个月后这条绕行路径变成真正的流程，复核队列里的条目还在涨，但它们已经不影响任何决定。这时候系统的失败率会变好看，因为难的那部分不再经过它。

第二种是盖章。复核的人开始连续通过，只扫一眼格式。通过率升到 98%，报表上像质量在改善，实际是判定能力退出了这个环节。这一条在数据里不可见，因为没有人记录自己看了几秒。

第三种是延迟被当成正常。四小时的时限变成两天，然后在周报里改口径写成按工作日计。改口径那天通常没人讨论，它看起来只是统计方式的选择。

三种症状的共同点是：它们让指标变好。这也是为什么复核产能的问题很少被当成问题提出来，直到某个季度出了一次没人预料到的错误。

什么时候不该建复核队列

不是所有动作都值得排队等人看，三个例外要说清楚，否则这套算法会变成给一切加人的理由。

动作可逆、金额小、影响限于内部的，抽样就够。全量复核的成本会超过错误本身的成本，而这种浪费会挤占真正需要复核的那部分产能。

复核人之间结论不一致的时候，先统一标准。三个人三个判断，队列再长也测不出质量，只是在收集噪声，顺带让人对复核这件事失去信心。

还有一条反直觉的：错误代价低于复核成本的时候，不要复核。分层的意义是把有限的人集中到不能错的那部分，不是平均分配。平均分配的结果是每一件都有人看一眼，每一件都没被认真看。

我们的判断

我们的判断是，2026 年下半年这批企业收紧自动权限，原因不是对智能体的信心下降，而是复核队列先见底了。信任问题可以用评测回答，产能问题只能用人回答，而扩产能要经过招聘周期，比模型迭代慢一个数量级。

这带来一个反直觉的推论：如果你的复核队列长期是空的，通常是两种状态之一，要么授权太保守，要么根本没有在测输出。一个正常扩张的 AI 工作流，队列应该持续有少量积压，那是产能被用满的证据。

三个动作可以本周做完。第一，量出到达率：过去三十天每天需要人看的条目数，取中位数而不是平均值，平均值会被月末高峰拉歪。第二，量出服务时长：随机抽二十条，计时复现一遍，得到秒数，不要用估计。第三，用上面的除法算出所需人数，跟现有人数比。差三个以上，就在减授权范围和加人之间选一个，不要靠加班同时解决两件事，因为那会同时降低两个指标。

留给买家的问题是：你的复核队列现在多长，从进入到被看平均要等多久？能说出一个具体时长，说明有人把它当一个系统在管；说不出，说明它一直在靠人的韧性运转，而韧性不是产能。

参考来源

VentureBeat, The share of enterprises trusting AI agents to make production changes on their own has fallen from 75% to 56%, VB Intelligence finds（八月调研，140 名自选受访者；含 61% 通过内部评测后仍出现客户侧故障、29% 以实时输出质量检查为主要监控、人工复核 30% 为增长最快投入）

M/M/1 queue, Wikipedia（等待时间与利用率的关系，本文用的是其简化形式：等待近似等于服务时长乘以利用率除以一减利用率）