ai agent 并发人工审核怎么做

Agent 一放量，最尴尬的不是模型答错，而是审核的人根本看不过来：请求堆在待审队列里，超时了没人处理，前端还在轮询。这篇不讲该不该审核，只讲并发上来之后工程上怎么接——哪些走人审、队列怎么排、审核端怎么提效、卡住了按什么顺序查。

Agent 一放量，最尴尬的不是模型答错，而是审核的人根本看不过来：请求堆在待审队列里，超时了没人处理，前端还在傻等轮询。这篇不讲该不该审核，只讲并发上来之后工程上怎么接。

核心思路是把人审当成一个有限吞吐的下游服务来对待：上游并发不能长期超过人工处理速率，超出的部分必须提前设计好去向。下面按分流、排队、兜底、排查四段讲。

先决定哪些请求才值得进人审队列

很多人第一反应是按模型置信度分流，置信度低就送人审。这个做法在高并发下会崩，因为模型自评偏乐观，真正危险的请求往往自信满满。更稳的判据是后果：出错之后能不能撤回来、影响范围有多大。

置信度和风险标签的正确用法

• 置信度、风险标签只用来排队列优先级，不单独当放行依据
• 分流规则表要能热更新，改阈值不该触发服务重启
• 规则变更要有版本号，出事能回溯当时用的是哪套
• 规则表本身要做单测，边界值写清楚是「大于」还是「大于等于」

什么情况下这套不适用：内部只读工具、纯草稿类操作，本来就没有不可逆后果，强行塞人审等于给系统加一个没人用的收费站。判断标准很简单——问一句「这条请求错了，我需要半夜爬起来处理吗」，答案是「不用」就别进人审。

队列怎么排、审核端怎么批量消化

默认先进先出在高并发下是错的。一条十分钟前创建、剩余审核窗口很短的请求，应该排在刚进来、时间还很充裕的请求前面。按 SLA 剩余时间排序，才能把最坏情况压住。

1. 给每条待审项打 SLA 倒计时进队时写入截止时间，队列按剩余时间升序取。验证方式：人工制造一批晚到的请求，确认它们能插到队首。
2. 合并同批任务的上下文把同一批次、同类动作的请求聚合到一个界面，一次批准一组。验证方式：统计平均处理条数，从一条一条点变成一批一批过。
3. 按审核人速率反推并发上限记录每个审核人每分钟处理条数，上游并发配置不能长期高于这个总吞吐。验证方式：看队列深度是否长期单调上升。
4. 审核端加租约机制任务被领走后带一个租约时间，超时未处理自动释放回队列。验证方式：模拟审核端断线，确认任务不会永久锁死在某个人的名下。

批量放行要小心一个边界：同批任务里只要有一条命中高风险标签，就不该整批放行，而是把它拆出来单独看。批量操作的按钮旁边最好显示「本批含 N 条高风险」，避免审核人闭眼点确认。

人没空审时，系统该降级还是该挂起

超时没人处理是必然会发生的，区别只在于你提前定义了行为，还是让请求烂在队列里。开工前先把兜底动作分成几类，按业务后果选，而不是按工程师偏好选。

超时拒绝

直接返回失败，适合出错代价高、用户可重试的场景

超时降级到只读

动作不执行，但把结果以只读形式返回，适合查询类

超时转异步补审

先挂起，等人工处理完再异步通知，适合不能拒绝也不能放行的业务

降级动作必须幂等。重试和补偿重放时，同一个请求不能被执行两次副作用。做法是给每个动作一个幂等键，执行前先查是否已处理过。

• 兜底比例做成指标，持续超标说明上游并发给高了，要回头压并发而不是加审核人
• 合规要求逐条留痕的业务只能挂起排队，不能自动放行，这类场景不适用超时降级
• 降级路径要有开关，紧急时能一键切成全部挂起
• 每次降级写一条审计记录，包含触发原因和当时队列深度

判断标准可以简化成三步：这条请求错了能不能撤？能不能拒？拒了业务方能不能接受？三问都是「能」，才可以考虑自动放行，否则一律挂起。

埋点和排查：卡住时按这个顺序看

卡住时的排查顺序比监控面板好不好看重要得多。先看队列深度和最长等待时长，再看审核端在线人数，最后才看上游并发有没有突增。顺序反了容易误判成模型问题。

每条请求至少记录四个字段：进入时间、被谁领走、处理耗时、最终去向。有这四个字段，事后复盘不用猜。介入率、平均处理时长、超时率三个数放同一张看板，一起涨基本就是并发给多了。

具体到你的业务该定什么阈值、当前中转站和工具链的实测表现如何，可以到 /tools/speed-test 和 /price-watch 核对当时的数字，别直接照搬别人的配置。