监督容量：你的审批关卡其实在花的那笔预算。
审核者是一台吞吐量可测、容量有限的仪器；一旦你的智能体每小时上报的决定多过这台仪器能做出的数量，你每加一道关卡买到的安全就比上一道更少——越过某个速率之后，买到的是负数。监督容量就是把那个吞吐量写成一个数字，而正是它把「一道作为控制的审批关卡」与「一道只是收据的审批关卡」分开。
步骤 1去数审核者的秒数，而不是关卡的道数。
关于人在回路设计的每一份指南回答的都是同一个问题：哪些动作该停下来等人。不可逆的、对外可见的、改变权限的、金额大的，都设关卡。这套判据是对的，也是不完整的，因为它对多少只字未提。两套跑着完全相同策略的部署——同样的工具、同样的判据、对话框里同样的措辞——在每小时 4 次上报与每小时 400 次上报之下，表现得像两个不同的系统。把它们分开的那个量，不在策略文档上。
把它写下来。监督容量就是你的审核者每小时真正能决断的上报数量：实际可用的注意力，除以一次称得上胜任的决定所花掉的注意力。分子容易估，而且总比看人头数要小——没人能在一小时里审六十分钟。分母才是难的那一半，因为一次决定的成本，取决于审核者在那句判词开始有意义之前，必须重建多少上下文。
# One reviewer, one shift, one honest decision cost. reviewers 1 attention available per hour 2400 s # 40 of 60 minutes seconds per competent decision 90 s # read the diff, check the two # records it touches, decide ---------------------------------------------------------- oversight capacity 26 decisions/hour # The fleet it is asked to cover: 40 agents x 12 actions/hour = 480 actions/hour gate rate 20% = 96 escalations/hour 2400 s / 96 = 25 s per escalation, against 90 s needed
请留意需求超过容量时不会发生什么。队列不会堵住，也没有任何东西报警，因为审批队列没有背压：审核者会悄悄把每一次决定从九十秒重新标价为二十五秒。吞吐量被保住了，而你本来要买的东西——一句胜任的判词——被安静地停产了。这正是超容量的监督为什么难以从仪表盘上看出来：审批延迟变好了。
如果你从没算过这个数字，你就不知道自己的关卡究竟算不算控制。想弄清楚，最快的办法不是做审计：从上周的日志里取出上报速率，用你真心相信存在的那点审核者注意力去除它，再把结果跟一次认真的决定要花多久摆在一起比。多数团队会发现自己正以容量的好几倍在跑，而且一直把跑出来的那些审批当证据用。
步骤 2越过容量，关卡会反转。
直觉上的模型是监督会优雅地退化——关卡多一点、摩擦多一点、决定差一点。而机理说的是另一回事。把审核者建模成会疲劳的、而不是不知疲倦的，实现出来的安全性就成了上报速率上的一条倒 U 曲线：覆盖面还便宜时它往上走，到顶，然后往下掉，因为边际上多出来的那一次上报，花掉的是队列里已有的那些决定本来指望着的注意力。Emre Turan 的《Oversight Has a Capacity: Calibrating Agent Guards to a Subjective, Fatiguing Human》（arXiv 2606.08919，2026 年 6 月 8 日投稿）推出的正是这个形状，还附带一个洪泛攻击：把一个有害动作埋进一长串例行审批里，它就会被橡皮图章放过；而只被问五次的审核者，每一次请求都会读。
读那篇论文该读机理，而不是量级——而且论文自己就是这么说的：那条倒 U 与那个洪泛结果，是一个合理疲劳模型的推论，摆出来是为了促成一次人类实验，而不是对人的测量；数据集是单一领域里 125 个手工标注的编码智能体动作，它展示的是测量工具本身，而非在估计某个总体。走得更远的，是同一份工作里另一个完全不需要疲劳假设的测量：在那 125 个经对抗性加权的动作上，审核者关于「哪些有风险」的一致性，算出来是 Fleiss' kappa 0.52——中等。三个胜任的人看同一个智能体动作，会对「它该不该被拦下」意见不一。
该坐下来好好想的是这个数字，因为它是任务的属性，而不是排班表累不累的属性。如果一致性只是中等，那么一道关卡的输出就有一部分是「今天谁值班」的函数，而你调好的那条阈值，正坐在一片你从未刻画过的噪声之上——这就是阈值设定问题的人类版本。
接下来是让这件事成为安全属性而非人机工程问题的那一半：上报速率是攻击者可控的。一个被攻陷或被注入的智能体，只要能制造两百次看起来无害的审批请求，就免费买到了对那一个真正要紧的请求的二十五秒审查。这是拒绝钱包在监督侧的对应物——不妨叫它拒绝注意力——它意味着你那个容量数字不只是一项人力投入。它是一项有对手的控制。
智能体不必被攻陷才能把你淹掉。一道范围划错的关卡会无意中做到这件事：某个团队的「每一次对外 HTTP 请求都设关卡」，把一个研究任务变成了一百个几乎一模一样的对话框，而那个把它们一一点掉的审核者，已经被你自己的设计训练成会把下一个也点掉。
步骤 3把四样东西量出来，而不是假设出来。
- 决断耗时，按上报类别看分布。不是看均值——均值会把众数藏起来。一簇五秒以下的决定，就是审核者超容量的签名，而且它就在你手里已有的数据里。
- 通过率。接近 100% 的通过率不是智能体守规矩的证据，而是这道关卡不具区分力的证据。要么策略拦错了动作，要么审核者已经不读了，两者都是值得为之写一句查询的发现。
- 决断那一刻的队列深度，与判词配对记下来。这是唯一一项能让你在自家流量里找到那条倒 U、而不必姑且信之的测量：如果通过概率随队列深度上升，你就在生产环境里、用经验数据，把自己的容量定位出来了。
- 审核者之间的一致性。把一小部分上报独立地分给两位审核者，然后算一致性。如果只是中等，就别再调阈值了，去修对话框给人看的是什么——通常的病因是：那个请求描述的是一个意图，而不是一份效果。
这四项都便宜，而且没有一项需要新工具：它们都是在那条你为决策收据本来就需要的决策日志上做连接查询。它们之所以很少被算出来，是因为没人拥有这个数字。监督容量没有天然的归属——它是一项以人力单位度量的安全属性，于是夹在安全团队与运维团队之间，哪边都没接住。
步骤 4有意识地花这笔预算。
容量是可以提高的，而杠杆几乎全在分母上。把一次决定的成本从九十秒砍到二十秒，就是不招人把容量翻两番；而且这跟「让那次决定变得正确」是同一件活儿：
- 把批准绑到一份算出来的效果上。一次试运行，如果展示的正是同一条代码路径将要施加的那份 diff，就把「重建」换成了「阅读」。一个描述模型打算做什么的对话框，把推算效果这件事留给了审核者自己——而那就是那九十秒里的大半。
- 打包成计划。一份可审阅的计划——「发这三封邮件、更新这两条记录」——的成本只是三十个独立对话框的一小部分，而且它给了审核者唯一那种能让单个动作有意义的上下文。它的 UX 那一半是审批与确认 UX；到了机群规模，它会变成一条带优先级的审阅队列。
- 先压需求，再谈扩覆盖。一个成熟部署里的多数上报，本来就不该成为上报。把工具收窄、把凭证收口，那个动作就变得可以无人值守地跑——影响半径是更便宜的那根杠杆，而且它压根不需要审核者。
- 给关卡定价。如果每一个被设关卡的动作花掉同样多的注意力，你就是在一个并不均匀的风险分布上，均匀地花这笔预算。按风险评分的权限就是你为那少数几个多花钱的办法。
- 设一个上限，并且现在就决定撞线时怎么办。正是这个决定，决定了这道关卡能不能活过一个忙碌的星期。当上报超过容量，智能体应当暂停、降级为只读，或者卸掉低风险任务——也就是失败趋关闭。常见的另一种做法，把溢出的那部分自动批准，并不是让这项控制退化；那是把它删掉，而且删得恰好在攻击者最希望它被删掉的时候。
容量同时也给机群规模定了一个诚实的上限，而这是让人不舒服的那部分。如果一位审核者每小时能决断 26 次上报，而你的智能体生产 96 次，你就只有三个选项、且只有三个：让决定更便宜、让上报更稀少，或者少跑几个智能体。买第四个选项——同一道关卡后面塞更多智能体——是一个「不再监督它们」的决定，而它通常在任何地方都没有被写下来。这笔交易的成本一侧在人工审查的成本里；而当检查本身必须动手时的那个版本，是当检查必须动手。
这周算一个数字。取上周的上报次数，用你真心相信的那点审核者注意力去除它，再把结果摆在「一次认真的决定要花多久」旁边。如果你超了容量，不要加关卡——把已有的一道绑到一份算出来的效果上，把其余的打包成计划，然后把「队列超过一个人能决断的量时机群该怎么办」这条规则定下来。一道没人有时间去决断的关卡不是监督，它是一行写着「当时有人在场」的日志。