生产 Agent 必须有人工接管开关

生产 Agent 必须有人工接管开关很多团队做 Agent 上线方案时会把注意力放在模型选型、工具调用、知识库和 prompt 上。这些都重要但如果这个 Agent 会读真实工单、改订单状态、发客户消息、调设备接口真正该提前设计的是另一件事一旦它开始偏谁能接管接管后系统怎么停住。生产环境里最危险的不是 Agent 回答错一句话而是它在错误路径上继续执行了三步、五步然后没人知道应该从哪里切断。接管开关不是“人工兜底”四个字很多设计文档里会写“异常时转人工”。这句话太粗。真正可执行的人工接管至少要回答五个问题什么情况触发接管接管后 Agent 停哪些动作当前上下文怎么交给人人处理完以后怎么恢复接管过程有没有审计记录如果这些问题没有落到系统状态和操作按钮上所谓“人工兜底”通常只是一个口号。哪些信号应该触发接管我一般会把触发条件分成三类。第一类是模型不确定。比如证据不足、工具返回冲突、检索结果互相矛盾、模型自评置信度低。这类场景不一定有故障但继续自动执行会把一个不确定判断变成真实副作用。第二类是业务风险升高。比如涉及退款、删除、停机、修改配置、通知客户、触发设备指令、进入金融或合规流程。这些动作即使模型判断正确也应该有更高的确认门槛。第三类是系统异常。比如工具超时、幂等键冲突、连续重试失败、外部接口返回状态不一致、审计日志写入失败。这里不能只让 Agent 再试一次因为它可能已经处在半成功状态。一个简化的规则可以长这样typeTakeoverReason|low_confidence|conflicting_evidence|high_risk_action|tool_timeout|state_mismatch|audit_log_failed;typeTakeoverDecision{shouldTakeover:boolean;reason?:TakeoverReason;pauseWrites:boolean;pauseExternalMessages:boolean;requireSupervisor:boolean;};functiondecideTakeover(ctx:{confidence:number;evidenceConflict:boolean;actionRisk:read|draft|write|external;toolFailures:number;stateMismatch:boolean;auditWritable:boolean;}):TakeoverDecision{if(!ctx.auditWritable){return{shouldTakeover:true,reason:audit_log_failed,pauseWrites:true,pauseExternalMessages:true,requireSupervisor:true,};}if(ctx.stateMismatch){return{shouldTakeover:true,reason:state_mismatch,pauseWrites:true,pauseExternalMessages:true,requireSupervisor:true,};}if(ctx.actionRiskwrite||ctx.actionRiskexternal){return{shouldTakeover:true,reason:high_risk_action,pauseWrites:true,pauseExternalMessages:ctx.actionRiskexternal,requireSupervisor:true,};}if(ctx.confidence0.72||ctx.evidenceConflict||ctx.toolFailures2){return{shouldTakeover:true,reason:ctx.evidenceConflict?conflicting_evidence:low_confidence,pauseWrites:true,pauseExternalMessages:true,requireSupervisor:false,};}return{shouldTakeover:false,pauseWrites:false,pauseExternalMessages:false,requireSupervisor:false,};}重点不是这段代码本身而是接管条件必须能被系统判断、记录和复盘。接管后应该暂停什么人工接管不是把整个系统都关掉。更合理的做法是按动作风险分层暂停只读查询通常可以继续运行内部草稿可以继续生成但标记为待复核写操作暂停外部消息暂停设备、资金、订单状态类动作必须人工确认后再恢复。这样系统不会因为一个高风险动作而完全失明。人接管时仍然可以让 Agent 查日志、查工单、整理上下文但不能让它继续改外部状态。可以把运行状态建模成这样否是继续观察恢复自动终止任务Agent 正常执行触发接管条件?进入 takeover 模式暂停写操作和外部消息打包上下文给人工人工处理结果保持只读和草稿能力恢复指定动作权限关闭任务并记录原因上下文打包比按钮更重要只做一个“暂停 Agent”按钮还不够。真正让人能接住的是接管瞬间的上下文包当前任务目标已经调用过哪些工具每个工具的入参和返回摘要Agent 做出的关键判断尚未执行的下一步动作触发接管的具体原因相关工单、客户、设备或订单链接推荐的人类处理选项。否则接管人只能重新问一遍发生了什么响应时间会被拉长。一个接管事件最少应该这样记录{taskId:task_20260701_1033,agentRunId:run_8f21,takeoverReason:state_mismatch,pausedActions:[write_tools,external_messages],lastToolCall:{name:update_ticket_status,idempotencyKey:ticket_9172_to_pending_customer,result:timeout},evidence:[ticket status readback still open,customer notification not sent,audit log written],recommendedHumanAction:check ticket status in CRM before retrying}这类记录后续还能进入评估集哪些接管是真风险哪些是误触发哪些规则要放宽或收紧。恢复也要有边界很多事故不是发生在暂停时而是发生在恢复时。人处理完以后不应该简单点击“恢复全部自动化”。更稳的方式是恢复具体能力只恢复该任务只恢复只读工具只恢复某个低风险写工具只允许在当前工单继续高风险动作继续保留人工确认。也就是说恢复动作本身也应该是一次权限变更。上线前可以用这张表自查检查项通过标准接管触发条件至少覆盖低置信度、证据冲突、高风险动作、工具异常、状态不一致暂停范围能区分只读、草稿、写操作、外部消息上下文包人接手时能看到目标、证据、工具调用、下一步建议审计记录每次接管都有原因、时间、任务 ID、处理人和恢复动作恢复机制支持按任务、按工具、按风险等级恢复复盘入口接管事件能进入样本库支持后续调规则结论生产 Agent 不应该只有“运行”和“停止”两种状态。更可控的设计是低风险动作继续跑高风险动作能暂停人接管时有上下文恢复时有边界所有过程都能审计。这样 Agent 即使判断错也不会一路错下去。对生产系统来说这比把 prompt 再打磨一轮更重要。