ai agent 人工审核环节怎么设计

Agent 跑得挺顺，但一到要真掏钱、真发消息、真改数据的动作，你就不敢让它自己决定——审核环节不是简单地加个「确认」按钮，插错位置要么把体验拖垮，要么等于没审。这篇讲插入时机的判断依据、审核队列怎么排队、驳回后怎么回灌，以及审核日志该记哪些字段。

Agent 跑得挺顺，一到真要掏钱、真要对外发消息、真要改生产数据的动作，你就不敢放手让它自己决定。这时候大家的第一反应是加个「确认」按钮，但插错位置的结果往往是：要么每步都弹窗把体验拖垮，要么该拦的没拦住，等于没审。审核环节的核心不是「有没有」，而是「插在哪一刀、什么条件下弹、弹了以后人不在怎么办」。

下面按动作筛选、插入层次、触发规则、队列排班、驳回回灌、日志字段、成本估算、上线清单这八块讲一遍。每块都给判断标准和可执行动作，你可以照着一条条对着自己的 Agent 核。文中不写死具体数字，凡是涉及价格、吞吐、比例的地方，都建议到站内对应页面看当时的实测值。

先分清哪些动作值得插一刀

不是所有工具调用都值得人工过目。判断标准过三个维度：动作能不能撤回、影响面有多大、有没有合规或合同要求必须留人签字。三个维度里只要「不可逆」加「影响外部」同时成立，基本就该先审再放。反过来，内部只读查询、改自己库里的草稿、能一键回滚的写操作，加审核只是白拖慢节奏。

• 不可逆且影响外部：对外发消息、提交表单、扣款、删除或覆盖数据、调用第三方下单接口，一律先审
• 影响面小但不可逆：只影响自己账号内部状态的写操作，可以按参数分档，只在特定条件下审
• 可逆但影响外部：先生成草稿再由人放行，审核点在「放行」那一步，不在生成那一步
• 完全可逆的内部操作：不加审核，出了问题靠回滚和日志追责
• 合规或合同点名要求留痕的动作：不管风险高低，都按固定流程走审核并留记录

同一个工具还要按参数分档，别一刀切。比如「发消息」这个工具，发给内部群和发给外部客户是两回事；「扣款」这个工具，小额自动放行、超过阈值才拦，也是常见做法。分档依据写进工具定义里，别散落在各处代码里。

审核插在哪一层：模型前、工具前还是工具后

三个可选位置：模型调用前、工具执行前、工具执行后。最稳的是工具调用前拦截——此时参数已经结构化，你拿到的是明确的函数名和参数，判断逻辑可以写得很死板，不必让模型自己声明「我要干大事了」。模型前审太早，信息不足；工具后补审只适合结果可撤回的场景。

有一条要特别强调：别把审核塞进提示词里靠模型自觉，比如写「如果要发邮件请先停下来问我」。模型跳步、改参数、或者把动作拆成两步绕过时，你没有任何抓手。审核必须是执行链路上的硬拦截，是代码里的 if，不是提示词里的一句请求。

什么条件下弹审核：规则怎么写才不烦人

审核弹得太勤，人会疲劳，最后变成无脑点通过，等于没审；弹得太少，又拦不住真正的风险。规则要用条件组合而不是单条件，典型的组合是：涉及外部收件人、金额或影响面超过阈值、这个工具是本次任务首次执行。三条同时满足才拦，只满足一条就自动放行。

1. 给每个工具定默认风险等级高、中、低三档，写进工具注册表。高风险强制审，中风险抽样审，低风险直接跑
2. 给高风险工具补组合条件在风险等级之上叠加参数条件，比如金额、收件人域名、目标表名，只有组合命中才拦
3. 把阈值抽成配置项金额阈值、抽样比例、白名单域名都放配置里，别写死在代码，上线后按误拦率调
4. 每周看一次误拦率误拦率高的规则要么放宽条件，要么改成抽样；漏拦的案例要能回填成新规则

什么情况下不适用组合规则：如果某个工具本身就是合规要求逐笔审核，那不用做条件判断，直接强制审，条件规则只对「可选审核」的工具生效。另外，抽样审的比例不要凭感觉拍，先按当前触发率算了人工单量再定，具体吞吐数据可以到站内的价格与容量页面看当时的参考值。

审核队列怎么排、人不在怎么办

审核请求进了队列，排序不能先到先审。合理的排序权重是「等待成本 × 风险等级」：会过期的请求（比如限时优惠下单、时效性通知）排在前面，同样会过期的里面风险高的再排前面。这个权重最好在请求入队时就算好，审核人打开队列看到的顺序就是处理顺序。

更关键的是超时降级。审核人不在线是常态，你不能让请求无声挂死。超时策略三选一，并且写死在配置里：超时自动拒绝、超时转人工兜底、超时降级成只读建议。三种策略适用场景不同，选哪个取决于这个动作失败一次的代价。

• 审核人不在线要有升级路径，比如转第二责任人，或在群里推送提醒
• 值班表要覆盖主要使用时段，非工作时段的不紧急请求允许排队到次日
• 队列积压超过阈值要告警，别等人打开面板才发现堵了几百条
• 同一个审核人身上别堆太多待办，超过上限就分流

驳回之后：反馈怎么回灌给 Agent

驳回不能只回一个「失败」。审核人点了驳回，要顺手选一个结构化原因：参数错误、时机不对、权限不够、内容不合适、本次不处理。这个原因随驳回结果一起返回给 Agent，模型才知道下一步该改参数重试，还是该收尾并告知用户。

驳回还要分两类处理。一类是「改完可重试」，允许 Agent 按反馈调整参数后重新提交，这种情况下要设重试上限，避免来回弹窗；另一类是「本任务终止」，直接收尾，禁止再发起同类请求。两类驳回在日志里标记清楚，方便后续统计。

• 驳回原因枚举化，不要让审核人手写长文本，模型读不懂自由文本
• 改完可重试的驳回，回灌时要带上具体改哪里，比如「金额超阈值，请拆成两笔」
• 本任务终止的驳回，直接结束当前任务并通知用户，不进入重试循环
• 驳回记录定期汇总，拿来改工具描述和提示词，减少同类驳回

审核日志至少记哪几个字段

日志是排查审核环节问题的基础，字段少了根本没法定位。最小集合包括：请求标识、触发审核的规则名、当时的工具名与关键参数、审核人是谁、决定结果、决定耗时、后续执行结果。有了规则名，你才能算出每条规则拦了多少、误拦多少。

还有一条容易忽略：审核环节的耗时单独打点。端到端慢了，你要能分清是模型推理慢、工具执行慢，还是卡在人这边等审核。三个耗时分开记，优化的时候才知道往哪下手。日志里别整段存敏感参数，涉及金额、收件人、密钥的字段按需脱敏或只存摘要。

审核环节的成本与吞吐怎么估

审核是有成本的，不只是人力，还有被拖慢的任务时长和用户等待。估算顺序是：先拿每日工具调用量乘以触发率得到人工单量，再用单人每小时能处理的条数倒推需要几个人盯。这两个数都是变量，触发率你调，处理速度看流程设计，别拍脑袋。

调触发率之前先想清人力上限。把触发率调高容易，但审核队列一旦成为整个 Agent 的瓶颈，用户体验会断崖式下滑——用户等的是你的审核人，不是模型。比较稳的做法是先在小范围灰度里压低触发率，观察误拦和漏拦，再逐步放开自动放行范围。

估算预算时如果拿不准当前各家模型和套餐的按量价，到 /official-api 和 /tools/model-cost-calculator 按当时的数字核一遍，别拿旧印象做决策。不同中转或官方渠道的价格与稳定性差异，也可以在 /sites 和 /rankings 页面对照当时的评测结果。

上线前的检查清单

最后一节给一份可以直接对着勾的清单。它不保证你的 Agent 不出错，但能保证出错的时侯你手里有抓手，而不是事后才发现某个高风险动作一直在裸奔。

• 高风险工具全部有审核或白名单兜底，权限与鉴权在网关层再拦一道，两道不合并
• 每条审核规则有明确的规则名，能被日志统计到
• 审核超时、队列积压、驳回率异常各有监控告警，告警有人接
• 审核日志字段齐全，模型耗时与审核耗时分开打点
• 驳回原因枚举化，回灌路径测试过，重试有上限
• 灰度先跑只审不放行，观察触发率和误拦率，再逐步放开自动放行范围

这几条里最容易漏的是「权限在网关层再拦一道」。审核是流程控制，不是安全边界。审核通过不等于有权限执行，网关层的鉴权该做还是要做，两层职责别混。反过来，网关层也别承担审核逻辑，否则规则改一次要发一次网关，迭代速度会被拖死。