多智能体系统最危险的设计，不是让智能体犯错，而是没有定义“错到什么程度必须交给人”。人工接管边界不应由模型临场判断，而应写入任务编排、权限控制和业务流程，形成可执行的升级机制：什么情况下暂停，谁有权审批，人工需要看到哪些证据，以及接管后如何恢复或撤销。
先按风险划定边界
人工接管的核心标准不是智能体数量，而是动作的影响范围、可逆性和证据完整度。只提供分析建议的智能体，可以在较低风险下自动运行；涉及修改订单、账户、权限、生产配置，或触发付款、退款、合同和正式通知的动作，则不应仅凭模型输出直接执行。
尤其要区分“生成建议”和“提交变更”。智能体可以提出价格调整或订单处理方案，但真正写入业务系统前，应经过授权校验、版本校验和业务规则检查。对不可逆、影响范围大或涉及敏感数据的动作，应设置人工确认点，而不是等失败后再补救。
用可观测信号触发接管
接管条件应来自系统状态和业务证据，而不是模型自报的置信度。以下情形通常应暂停自动流程：
- 关键数据缺失、来源冲突或证据不足；
- 智能体之间出现事实、目标或权限冲突；
- 工具不可用、任务超时、连续重试或输出格式无法校验；
- 动态任务超过步骤、调用、成本或并发预算；
- 请求越过工具权限，或即将执行高风险副作用动作；
- 业务规则与模型建议不一致，且无法采用明确的保守策略。
“无法自动裁决”本身应是合法结果。强行让仲裁智能体生成统一答案，可能只是把不确定性隐藏起来。系统可以将任务转入人工审批、隔离队列，或等待业务系统补充数据。
接管必须能追责和恢复
人工审批界面不能只展示最终结论，还应展示任务来源、智能体链路、使用的数据、规则依据、影响范围和回滚方式。系统则要记录编排版本、模型与工具调用、输入输出、权限、重试、人工干预和最终批准者。
更重要的是，人工接管不是流程终点。任务应保留唯一标识、父子依赖和中间状态，使人工确认后能够从暂停节点继续，而不是重新执行全部步骤。对于已产生部分外部影响的流程，还要设计补偿动作，因为补偿并不总是等同于简单回滚。只有当“暂停、审批、恢复、撤销、追责”都能落到具体组件和角色上，人工边界才不是文档里的原则，而是真正有效的生产控制。