给智能体设计退出机制，难点从来不是加一个停止按钮，而是回答三个问题：什么情况下必须停、停下来之后业务怎么走、满足什么条件才可以重新开。智能体与只输出文本的模型不同，它可能调用数据库、发送邮件、执行代码或改动业务系统，一旦失控，影响的不是一段文字，而是一连串真实动作。所以退出机制必须在上线前定义，而不是事故发生后再临时商量。
触发条件要写进制度，而不是留给临场判断
至少应覆盖几类信号：异常错误率连续上升、出现越权调用、敏感数据泄露、供应商发生重大安全事件，以及模型版本变化后未完成重新评估。这些条件需要同时绑定两件事——由谁判定，谁有权执行停用。常见的漏洞是条件列得很全，却没有人被明确授权按下停止键，或者停用要层层审批，等流程走完，损失已经发生。判定权和执行权分开设置通常更稳妥：业务负责人负责识别异常，安全或运维岗位负责执行。
退出不等于删除系统
更可行的做法是按影响面分级降级。可以先暂停自动执行，把任务切回人工处理；可以回滚到已验证版本；可以只关闭特定工具权限，保留只读查询能力；同时保留必要日志，供事后调查使用。对关键业务，还应提前准备不依赖大模型的备用流程，避免全面自动化之后失去业务连续性。还有一个容易被忽略的设计：把“建议动作”和“执行动作”分开，在高影响操作前设置确认环节，并记录模型输入、工具调用、输出结果和人工决策。一个判断标准是，如果系统必须靠员工持续盯屏才能不出事故，说明它的自动化程度已经超过了组织实际的监管能力。
恢复要重新验证，也要提前演练
退出之后不能默认沿用上一次的评估结果，恢复上线应重新走一遍准确性、安全性和稳定性验证。演练同样属于退出机制的一部分：人员不在线、模型输出异常、外部接口中断时，系统是否会自动暂停，而不是继续扩大影响。只有在故障场景下验证过的暂停路径，才算真正可用。
把这些条件、权限、日志和替代流程写成一页纸的档案，随模型版本和工具权限变化同步更新，退出机制才不会停留在文档里。