决定自主上限的是你的复核队列，不是你的模型。
无论智能体做得多好，一个人每小时真正能做完决定的条目数，都是你被允许交付多少工作量的硬性乘数——而几乎没有人在上线前估算过它，于是第一次扩量的结果是一堆积压，而不是一场胜利。有两个设计选择对这个数字的影响超过其他一切：按「复核最可能改变结果的地方」而不是按到达时间给队列排序；以及做一个用来做决定的界面，而不是一个用来读智能体推理过程的界面。这两件事做错，你买到的就是一枚橡皮图章，还外带一笔延迟开销。
在动手设计任何东西之前，先把这笔账算了。
一个智能体每天产出 400 条待复核条目，交给三名复核人员，每人在一个有会议、有疲劳的工作日里现实地能维持每小时约 40 次审慎决定，那你就有大约 960 次决定的产能去接 400 条。绰绰有余。把智能体的吞吐翻两番，你就沉下去了；而这次失败看起来并不像一个设计问题。它看起来先像积压，再像复核人员加快了速度，最后像一批从来不是复核的通过。
有三个数字从第一天起就该上看板，而通常只有第一个在上面：
- 队列深度及其斜率。只看深度是有歧义的。稳定增长的队列是一个你可以提前一周预测的产能问题；忽高忽低的队列则是一个你可以在调度器里修掉的批量问题。
- 按条目类型的每次决定耗时。这是你真正能通过设计撬动的那根杠杆。要看分布——中位数 20 秒而 p90 是四分钟，说明伤害全由某一种条目类型造成，而设计功夫就该花在那一类上。
- 从智能体产出到做出决定的时间。这是最终用户体验到的东西。在很多产品里，它才是这个功能真正的延迟，而模型的响应时间只是其中一个零头。
诚实的表述是：人工复核是一项有单位成本的采购输入，而不是你白得的一项安全属性——这正是人工复核的成本里的论点。这样定价之后，「全部都复核」就显出了它的真面目：一个把部署规模封顶在复核人员编制上的决定。这有时是对的，但至少应当是有意为之。
先进先出是错的策略，而它是所有人的默认选项。
到达顺序是从工单系统借来的公平规则，而在那里，你要对之公平的是正在排队等待的那个人。这里没有人在排队；你在配给的是注意力，而正确的策略是把它花在最可能改变结果的地方。一条智能体自信答对了的条目，和一条只差一个事实就要酿成昂贵错误的条目，值得复核人员的分钟数天差地别，而先进先出给它们标了同一个价。
# queue/priority.py — recompute on enqueue and on model version change def priority(item): # expected value of review = how likely we are to flip it, # times what flipping it is worth, minus what it costs to look p_flip = 1.0 - item.confidence # calibrated, not raw logprob stakes = item.blast_radius * item.reversibility_cost effort = item.expected_review_seconds return (p_flip * stakes) / max(effort, 1)
这三项各有各的位置。被推翻的概率需要一个经过校准的置信度，而不是模型的原始分数——如果你的置信度没有校准，就先从一个你信得过的代理量开始，比如智能体是否重试过、或者运行中途某个工具是否报过错。赌注里必须包含可逆性：一个能廉价撤销的动作，比一个内容相同但会发出邮件的动作更不值得复核。分母上的耗费，则是防止队列被一堆各要十五分钟的高赌注条目塞满、而四十次便宜的翻盘却没人去做。
有两道护栏能让它保持诚实。时效最终必须压过一切，否则低优先级条目会永远挨饿，直到有人翻出一份放了三周的待批。另外，必须有一小份随机样本完全绕过排序——否则你只会一直观察到模型没把握的那些条目，而对它有把握的那些一无所知，而一次静默的能力回退恰恰就住在那里。
为「做决定」而设计，不是为「读智能体的作业」而设计。
直觉是把一切都给复核人员：完整轨迹、每一次工具调用、推理过程。这感觉很透明，而它是个陷阱。读一条长轨迹要花上几分钟，却并不能可靠地改善决定——因为复核人员最后检查的是「过程看起来合不合理」，而不是「答案对不对」；而一个流畅的错误答案，配的正是一套流畅的错误过程。
请围绕那个决定来搭这块屏幕：
- 把主张平铺直叙地放在最上面。智能体打算做什么、或得出了什么结论，一行说清，用复核人员的词汇而不是系统的词汇。
- 那两三条足以改变它的事实。结论所依据的那段检索原文、它来自哪个字段、它与哪个值相矛盾。这才是复核人员真正的工作，而把它摆出来，就是二十秒的决定与四分钟的决定之间的差别。
- 出处放在一次点击之外，而不是摆在屏幕上。完整轨迹必须存在、必须能到达，因为一天里的第十条条目就是需要它的那条。但它不该是默认视图。延伸：渐进式披露。
- 让「不同意」和「同意」一样便宜。如果通过是按一个键，而拒绝要弹出一个带必填自由文本框的对话框，那你造的就是一台通过机器，而你的数据会显示出一个漂亮的通过率。
与其争论，不如直接测：取五十条已知正确答案的条目，一半给复核人员看完整轨迹、一半给「主张加证据」视图，测准确率与每次决定的秒数。跑过这个实验的团队通常会发现准确率持平而耗时减半——同时也会发现那一小类轨迹确实有帮助的条目类型，而那才是该把轨迹设为默认视图的地方，且仅限那几类。
98% 的通过率是一道坏掉的控制，不是一个好模型。
通过率是这个队列的生命体征，而它几乎总是被反着读。高通过率感觉像是对智能体的验证；一旦越过某个阈值，它意味着复核人员已经不再产生独立信息了。无论原因是智能体真的变可靠了，还是一个被要求每天按四百次「通过」的人按人之常情适应了下来，这个队列都已经不再是一道控制了——而从外面看，这两种原因长得一模一样。
用仪表而不是直觉去区分它们：
- 埋入已知有错的条目。按一个很小的、被记录的比例投放刻意做错、且真值已存档的条目。对这些哨兵的抓取率，是唯一能直接衡量复核是否还在运作的指标；把它摆在通过率旁边，这两个数就都不会被单独误读。
- 盯住停留时长与通过率的关系。通过率上升而每次决定的秒数下降，是橡皮图章的特征。通过率上升而停留时长保持不变，才是智能体真的在变好。
- 比较复核人员之间的差异。两个人在同一条目构成上持续存在分歧，要么是策略本身有歧义，要么是培训有缺口，两者都可修——但前提是队列记录了谁做了哪个决定。
当通过率是正当地高时，正确的反应是少复核，而不是把这套仪式继续下去。把那类条目改为抽样复核，让哨兵继续跑，把腾出来的产能花在复核人员仍然会改变结果的那些类型上。这就是渐进式自主里的那个棘轮，而每往前扳一格，靠的正是队列自身的这些指标。
这是一件被人连续用上几小时的专业工具，就按专业工具来造。
复核队列常被照着消费级界面来设计——慷慨的留白、一次一张卡片、鼠标驱动的通过按钮——然后交给一个要在里面坐六小时的人。做这类工作的人，最后想要的，就是所有做高频决策工作的人一向想要的东西。
- 键盘优先，常用路径上不出现鼠标。通过、拒绝、跳过、下一条。一个手不离基准键位的复核人员，大约是每条都要去够鼠标的人的两倍快。
- 预取，且不要整页跳转。条目之间两秒的整页跳转，在一天 400 次决定里就是十三分钟以上；更糟的是，它打断了让这份工作能持续下去的那种节奏。
- 把相同的批处理掉。当四十条条目同因同源——一个坏掉的检索来源、一个失灵的工具——就让一次决定解决这四十条，并在应用之前把这一组亮出来。这是这里能拿到的最大一笔吞吐收益，而它要求在入队时就按成因聚类。
- 用撤销，别用确认。一个确认对话框，是为了防住一次罕见的错误决定而向每一次正确决定征税。一个十秒撤销则一次也不征。参见撤销与可逆性。
- 永远保存位置。复核人员会被打断。丢掉进度是件小事，却会悄悄让这个队列变成人们避之不及的地方。
一次只拦下一条条目的拒绝，是被浪费掉的信号。
这个队列是你的系统所能产出的最高质量的标注数据：一位领域专家在使用现场对真实生产输出所做的判断。大多数实现只写下一个布尔值，其余全丢，于是同一个失败明天又来一遍，又被人手拒一次。
- 从一份简短的封闭清单里采集原因。从你实际的失败分类法里取五到八个成因，各配一个按键，自由文本可选、且绝不设为必填。封闭清单产出的是可归类的数据；必填自由文本产出的是空字符串和更慢的决定。
- 把不同原因路由给不同的负责人。「检索到了错误来源」是检索缺陷，「策略上不是这样」是提示词或策略变更，「工具返回了过期数据」两者都不是。一个笼统的拒绝桶会把这三种全藏起来。
- 把拒绝提升进评估集。一条被拒的条目连同它的修正就是一个测试用例，而这是通往「反映生产而非你的想象」的回归套件的最便宜路径——机制见生产反馈信号。
- 把回路显性地闭上。告诉复核人员，因为他们的拒绝，什么东西改变了。这个队列的吞吐依赖于一群相信这份工作有意义的人，而没有什么比「决定都石沉大海」的感受更快地拉低复核质量。
如果你这个季度要造一个：在动视觉设计之前，先把每次决定的秒数量起来、把已知有错的哨兵埋进去，因为这两件事都会改变你接下来要造的东西。然后用上面那个优先级分数替掉先进先出，再加上按成因批处理。这三项改动对队列吞吐的提升，通常超过任何一次条目视图的重设计；而且与重设计不同，它们会告诉你这份复核到底是不是真的。
延伸：审批与确认体验讲用户正在等待的那种同步场景，异步智能体体验讲它周边的工作流，人在环讲这道控制本该保证什么，标注与打标运营讲怎样把复核人力当成一个长期项目来经营。