智能体退出机制不是项目失败后的补救条款，而是企业在立项之初就应设计的治理边界。凡是能够读取企业数据、调用业务系统或执行操作的智能体，都必须回答三个问题：什么情况下暂停，如何安全停止，停止后业务能否恢复。没有这些安排，试点越深入，数据、权限和流程锁定越严重，退出成本也越高。
先定义退出触发条件
退出条件不能只写“效果不佳”，而应转化为可观察的业务标准。企业可以从四类信号判断是否暂停或终止：
- 能力失效：任务完成率下降、错误类型扩大、异常情况下无法主动请求人工介入。
- 经济性恶化：人工复核、定制开发和持续维护成本，已经抵消效率收益。
- 安全边界失守：出现越权访问、错误修改、未经授权发送或审计记录缺失。
- 业务环境变化：流程、系统、数据规则或组织责任发生变化，原有智能体不再适配。
这些条件应在试点和采购合同中提前约定，并明确由谁提出暂停、由谁审批终止，避免出了问题后仍因责任不清而继续运行。
退出设计要覆盖四个层面
第一是权限回收。智能体应使用可独立识别的身份，企业能够迅速撤销其数据访问权、系统操作权和自动执行权。权限最好按“只读、提出建议、人工确认后执行、自动执行”逐级开放，终止时也要能够逐级降权，而不是只能整体停机。
第二是业务回退。退出前应明确哪些任务恢复人工处理，哪些操作需要重新审核，未完成任务如何转交，避免智能体停止后形成流程断点。对高风险业务，必须保留人工复核和异常回退路径。
第三是数据处置。企业要核验智能体使用过哪些数据、产生了哪些记录、数据由谁保存，以及服务终止后能否删除或导出。相关责任、保留期限和供应商分包处理规则，应写入合同，而不能依赖口头承诺。
第四是替代与迁移。退出不等于删除账号。企业还要保留必要的操作日志、任务结果、规则配置和接口文档，使业务能够迁移到人工流程或其他系统。若供应商升级模型、改变服务条件或停止支持，也应触发重新评估。
真正成熟的退出机制，目标不是让企业随时放弃智能体，而是确保企业始终拥有选择权。先限定场景和权限，再用真实任务、异常任务和实际成本持续验证；一旦达不到预设标准，就暂停自动执行、保留证据、恢复人工，并依据审计结果决定修正、迁移还是终止。能安全退出，才说明这套智能体真正具备可治理性。