LLM 人工审批与异常接管设计：把模型建议变成可控业务动作
企业里的 LLM 常常不是“回答一段文字”这么简单：它会拟写客服补偿方案、生成授信材料摘要、给出工单处置建议、规划采购动作，甚至准备调用写操作工具。高风险场景中，模型输出必须先经过策略与人工审批，才能成为真正的业务动作。
这不是在流程末尾加一个“确认按钮”。一个可上线的人机协作系统需要定义什么必须审批、审批人看到什么上下文、模型/人工/工具并发时如何保持一致、超时如何升级、人工改写如何回流评测。本页聚焦业务审批和异常接管；工具权限与沙箱见 Agent 沙箱、执行准入与逃逸处置，数据出境与审计见 企业 AI 治理与审计系统设计。
一、先区分“建议”和“动作”
模型可以生成：
建议：向客户提供 100 元补偿，并更新订单状态为 resolved。
动作：调用 compensate(order_id, 100) + update_ticket(ticket_id, resolved)前者是非确定性文本/结构化建议，后者会修改真实世界。系统的信任边界应放在两者之间：模型只能提出计划，策略引擎决定是否允许、是否需要审批，执行器在批准后才以服务身份执行。
“模型置信度高就自动执行”通常不是充分条件。LLM 的 token 概率不等同于业务正确性，更不能替代权限、金额、合规、客户等级和数据敏感度等规则。
二、风险分级决定是否进入人工环节
可将每个拟执行动作计算成风险标签，而非只做一个二元开关：
| 风险层级 | 例子 | 默认处理 |
|---|---|---|
| R0 只读低风险 | 查询公开 FAQ、生成摘要草稿 | 自动完成，抽样复核 |
| R1 可逆低金额 | 创建草稿、推荐回复、低金额优惠 | 策略校验后自动或事后抽检 |
| R2 有业务影响 | 发券、修改工单、批量更新 | 指定角色审批或双人复核 |
| R3 高风险不可逆 | 转账、授信决定、删除数据、对外发布 | 强制人工批准、二次认证、完整审计 |
风险函数可综合 action_type、金额、目标对象、数据等级、模型/提示版本、检索证据、租户策略和异常信号。规则应由业务和合规共同维护，不能隐藏在 prompt 里。模型可以帮助解释风险，不能拥有最终策略解释权。
三、审批请求必须是不可变快照
审批人不能只看到“模型说可以”。一个审批卡至少要包含：
approval_id / action_id / request_id / trace_id
actor 与租户、目标资源、拟执行的结构化参数
策略命中与风险等级、授权范围、金额/影响面
模型、prompt、工具 schema、检索证据和版本号
生成时间、有效期、审批状态与可选的替代方案创建审批时应持久化不可变快照及其 hash。执行前再次校验审批绑定的参数是否仍一致；若模型重新规划、用户修改订单、工具 schema 变更或证据过期，应使旧审批失效并重新发起。否则会出现“审批了 A，实际执行 B”的 TOCTOU（check-to-use）漏洞。
四、状态机比“approved=true”可靠
draft -> policy_checked -> pending_approval -> approved -> executing -> succeeded
| | -> failed
v v
rejected expired / revoked状态迁移必须原子化并记录操作者、时间和原因。审批与执行并发时采用 compare-and-set 或乐观版本号：只有 approved 且版本一致的动作可被执行器领取；撤销、过期和拒绝不可被迟到的 worker 覆盖。
执行器要区分“尚未调用外部系统”“外部调用超时但结果未知”“明确失败”“已成功”。结果未知时绝不能盲目重试写操作，应先用幂等键查询或对账，避免重复发券、重复扣款。
五、审批权限与职责分离
审批人资格不是看 UI 上是否点得到按钮。服务端必须验证：
- 该用户是否属于目标租户/业务线，且拥有对应动作范围的 RBAC/ABAC 权限。
- 发起人是否不能审批自己提交的高风险动作。
- 是否满足金额阈值、双人复核、值班角色或地域数据权限。
- 审批会话是否已二次认证，审批 token 是否短期有效。
对 R3 场景推荐 maker-checker：模型/业务用户提出，审批角色复核，独立执行服务执行。所有三方身份都应进入审计链。不要把“管理员能做一切”作为默认权限模型。
六、人工接管不是只有批准和拒绝
真实业务中，人工通常还会：修改金额、替换收件人、补充证据、选择替代方案、要求模型重新生成、转派到专业队列。审批 API 应支持结构化 outcome：
{
"decision": "approved_with_changes",
"patched_arguments": {"amount": 50},
"reason_code": "LIMITED_COMPENSATION",
"comment": "客户等级与证据不足，按标准上限处理"
}人工改写后不能沿用模型原有签名或工具参数；应生成新的 action revision，重新做策略校验、权限判断和幂等键绑定。这样既避免参数漂移，也让“人工到底修正了什么”成为可分析数据。
七、超时、升级与异常队列
每个审批都要有 deadline。超时策略不是一律自动通过：
- R0/R1 可降级为草稿、延迟执行或回退到人工客服。
- R2 可按值班表升级到备选审批人，达到上限后拒绝或转异步。
- R3 默认过期拒绝，绝不因无人响应自动放行。
异常队列应单独处理：模型输出不完整、检索证据冲突、工具预检失败、策略引擎不可用、审批/执行结果不一致。队列项需要清晰的 owner、SLA、重试预算和解决码，不能只把异常写一行日志后让业务人员猜测。
八、工具执行的幂等与补偿
批准后的执行仍可能失败。将 approval_id + action_revision 映射为外部系统的 idempotency key，确保重复投递不会产生重复副作用。对于多步骤动作，采用 saga 思路：每一步有可验证结果和补偿动作，例如“创建草稿 -> 发送 -> 记录审计”；当后续失败时撤销草稿或标记人工清理，而不是假设可以回滚一切。
模型不能决定补偿策略。补偿与对账是确定性的业务流程，由执行服务、工作流引擎和人工异常队列控制。
九、从人工决定回流到质量闭环
审批数据很有价值，但不能直接当成无噪声训练标签。应记录：模型建议、证据、风险特征、人工决定、修改 diff、实际执行结果、后续投诉/退款/满意度。然后分层使用：
- 统计审批率、驳回率、改写率和处理时长，发现规则或 prompt 的问题。
- 将高质量、去敏、明确授权的样本加入离线评测集。
- 对反复被改写的字段优化 schema、检索或工具描述。
- 在正式训练前做偏差、隐私、代表性和数据污染审查。
目标不是把人工审批率压到零，而是在不降低风险控制的前提下，让低风险、可验证路径自动化，把专家时间集中在真正困难的边界案例。
十、可观测性与审计证据
| 指标/证据 | 回答的问题 |
|---|---|
| approval rate / reject rate / modify rate | 模型建议是否可用，规则是否过严或过松 |
| pending age 与 SLA breach | 哪些队列正在积压，值班是否不足 |
| policy hit distribution | 哪类风险/规则触发最多 |
| action outcome 与 compensation rate | 批准后是否真的成功、是否存在副作用事故 |
| approver disagreement | 规则是否模糊、模型是否缺乏证据 |
| immutable audit trail | 谁在何时以什么版本批准了什么参数 |
审计记录应该是 append-only，并按权限脱敏展示。保存完整 prompt、客户数据或模型思考过程不一定合规；优先记录必要的版本、哈希、结构化摘要、证据引用和访问日志。
十一、系统设计题回答框架
题目：“设计一个银行客服 Agent，对补偿、账户修改和高风险操作支持人工审批。”
- 澄清动作类型、风险阈值、审批 SLA、是否可逆、监管留存和租户隔离。
- 模型只产出 schema 化 action plan；策略引擎独立判定风险和审批要求。
- 生成带版本、证据、参数 hash 和过期时间的审批快照，进入状态机。
- 用 RBAC/ABAC、maker-checker 和二次认证验证审批人；支持批准、拒绝、改写、转派。
- 执行器仅领取 approved revision，用幂等键、预检、saga 和对账处理副作用。
- 超时按风险升级或拒绝，绝不让高风险请求自动放行。
- 用审批差异、结果和审计事件做可观测与评测回流，但对训练数据做脱敏与治理。
十二、面试高频追问
Q1：为什么模型置信度不能决定是否自动执行？
模型 token 概率只反映其生成分布，不能证明业务事实、权限、金额限制或监管要求满足。自动化资格必须由确定性策略、可验证证据和动作风险共同决定。
Q2：审批通过后，模型重新生成了参数怎么办？
旧审批绑定的是不可变 action revision。参数、工具 schema、证据或业务状态变化时，旧审批失效，新的 revision 要重新经过策略和审批；绝不复用“批准过一次”的布尔值。
Q3：如何避免人工审批成为系统瓶颈？
按风险分流：低风险自动化并抽检，中风险进入明确 SLA 的队列，高风险走专家审批；提供证据摘要、相似案例和结构化差异以缩短决策；用改写/驳回数据优化上游，但不降低必要控制。
Q4：审批超时能否自动通过？
取决于风险等级和业务契约。R3 不可逆动作默认过期拒绝；低风险可退化为草稿或延迟执行。关键是策略显式、可审计，不能由网络超时隐式决定。
Q5：批准后工具调用超时，能否直接重试？
先确认外部系统是否已执行。使用幂等键查询/对账；结果未知时进入异常队列或补偿流程。盲目重试写操作会产生重复副作用。
Q6：人工改写的数据如何用于模型优化？
先保留版本化 diff 和业务结果，再做脱敏、授权、质量和偏差审查。它适合构建 bad case 与离线评测集；是否进入 SFT/DPO 还要看样本规模、代表性和治理许可，不能自动把所有审批记录拿去训练。
十三、60 秒收束回答
我会把模型输出和真实业务动作分成两层：模型只能生成带证据的结构化计划，独立策略引擎根据动作类型、金额、数据等级和权限决定自动化或审批。审批对象是带参数 hash、版本、证据和有效期的不可变快照，状态机控制 pending、approved、executing、expired 等迁移；人工可批准、拒绝、改写或转派，改写后形成新 revision 重新校验。执行服务只消费已批准 revision，并用幂等键、预检、补偿和对账处理副作用。最后以审批率、改写率、SLA、执行结果和 append-only 审计构成运营与评测闭环。