一、企业里的“紧急关机”不是拔电源
很多人听到关机，会想到把整个服务器断电。但企业 Agent 的风险通常不是服务器本身，而是某一类任务、某个账号、某个工具或某条自动化流程出现了异常。
因此，企业真正需要的不是一个粗暴的总开关，而是分层停止：
- 停止当前任务：让正在运行的长任务不再继续调用工具；
- 暂停某类动作：例如暂时禁止发送邮件、修改订单或提交付款；
- 撤销某个 Agent 的权限：保留查询能力，关闭写入和执行能力；
- 冻结凭证和接口：使已经发出的访问令牌立即失效；
- 切换人工流程：把未完成任务、资料来源和已做动作交给指定人员；
- 恢复或回滚数据：对可撤销的变更进行反向处理，并保留审计记录。
如果系统只有“关闭整个 AI 服务”这一种选择，往往太晚，也太笨重：要么异常动作已经完成，要么为了一个小问题把所有部门的正常工作一起停掉。
二、为什么 Agent 比普通聊天机器人更需要停机机制
普通聊天机器人答错一句话，通常只需要人工纠正；Agent 一旦接入工具，错误会变成动作。
例如：
- 读取了不属于当前员工权限范围的客户资料；
- 把内部邮件中的诱导内容当成系统指令；
- 识别错订单状态，重复创建发货或退款任务；
- 将一份未审核的方案发给客户；
- 在循环调用中不断消耗模型和接口预算；
- 把测试环境的凭证带进生产流程；
- 在模型、提示词或业务规则更新后，继续按旧逻辑执行。
这些问题的共同点是：系统不只是“说了什么”，而是“做了什么”。
此前网站已经讨论过 AI 权限分级，可以参考《GPT-6 Astra 发布后，企业为什么必须给 AI 权限分级》。但权限分级解决的是“平时能做什么”，紧急关机机制解决的是“异常发生时怎样马上收回能力”。两者不能互相替代。
三、第一层：先让任务停下来，而不是等它自然结束
1. 每个长任务都要有可识别的任务 ID
如果系统无法回答“现在到底有哪些任务在运行”，就谈不上停止。每次 Agent 执行都应有唯一任务 ID，并记录：
- 发起人和发起时间；
- 使用的模型、提示版本和工具版本；
- 任务目标和预计动作；
- 已读取的数据范围；
- 已调用的工具和返回结果；
- 当前步骤、重试次数和预算消耗；
- 是否需要人工审批。
任务 ID 不是为了让日志看起来专业，而是为了让系统能够精准停止某一个任务，而不是只能重启整个服务。
2. 停止信号必须能打断工具调用
有些系统页面上显示“停止”，实际上只是停止了前端等待，后台任务仍在继续。真正的停止至少要穿过任务队列、Agent 编排层和工具执行层：
- 当前模型生成可以结束；
- 后续工具调用不再发起；
- 已经发起的外部请求能够取消或被服务端拒绝；
- 重试机制不能在停止后重新拉起任务；
- 任务被标记为“已暂停/已取消”，不能伪装成成功完成。
如果某个外部接口无法取消，就要记录它已经发出，并把结果交给人工确认，不能把“无法取消”隐藏成“已停止”。
四、第二层：按动作类型暂停工具，而不是一刀切
企业不应该让 Agent 只有“能用”和“不能用”两种状态。可以把工具分成四个等级：
只读工具
搜索知识库、读取订单、查看库存、查询工单等。只读不等于没有风险，但通常可以在较小范围内保留。
建议工具
生成回复草稿、创建方案、整理待办、标记待复核记录。工具可以产生结果，但不直接影响外部系统。
提交工具
创建工单、提交审批、生成退款申请、准备发信任务。提交后可能进入人工流程，应当记录提交人、审批人和可撤回时间。
执行工具
付款、删除、正式发送、修改关键数据、发布内容、变更生产配置。这类工具默认要有更高等级的审批、额度、时间窗口和撤销机制。
如果出现异常，企业可以先关闭执行工具，保留只读和建议能力，让业务继续工作，而不是整个 Agent 全部停掉。这样既能止损，也能减少业务中断。
五、第三层：权限要能撤，凭证要能失效
最危险的情况之一，是页面上把 Agent 设为“暂停”，但它手里的 API Key、OAuth Token、数据库账号和云平台凭证仍然有效。
真正的紧急撤权至少要覆盖：
- 让当前会话和任务令牌失效；
- 撤销或降级 Agent 使用的用户身份；
- 禁止继续申请新的工具权限；
- 轮换已经可能泄露的密钥；
- 清理队列里等待执行的高风险任务；
- 检查是否存在其他服务账号共享同一凭证。
权限撤销后，还要验证它确实生效。不能只改一个数据库字段，就假设所有缓存、队列和第三方平台都已经停止。企业可以准备一次“撤权演练”：在测试环境里撤回一个工具权限，观察正在运行的任务、下一次重试、缓存会话和后台队列是否都按预期处理。
六、第四层：停止之后必须有人接管
关闭 Agent 不是结案，而是把任务交给另一条更可控的流程。人工接管至少要带走六类信息：
- 用户是谁，原始请求是什么；
- Agent 读取过哪些资料，引用了哪些版本；
- 已经生成了哪些建议，哪些已经被采纳；
- 已经调用过哪些工具，返回了什么结果；
- 系统为什么停止，是权限、异常、预算还是人工主动暂停；
- 接手人员需要在什么时候完成下一步。
如果人工接手后只能重新问用户一遍、重新查一遍、重新猜一遍，所谓人机协作就只是在转嫁成本。企业应该把人工接管当成正式流程测试，而不是页面上的一句“请联系客服”。
七、什么时候应该触发紧急停止
企业可以把触发条件分成三类。
1. 安全和权限触发
- 发现越权读取或敏感信息泄露；
- 发现提示注入导致工具行为异常；
- 凭证疑似泄露或账号行为无法解释；
- Agent 尝试执行未授权动作。
这类情况优先暂停相关工具和凭证，不能等业务人员慢慢观察。
2. 业务和数据触发
- 同一任务连续重复执行；
- 关键字段与原始系统不一致；
- 订单、付款、库存或客户状态出现异常变化；
- 模型、提示、知识库更新后关键样本退化；
- 人工确认发现严重错误达到约定上限。
这类情况可以先缩小动作范围，保留只读能力，同时进入人工复核和回归测试。
3. 成本和运行触发
- 单个任务重试次数超过上限；
- 单用户、单部门或单日调用费用异常；
- 队列积压、延迟和失败率连续超过阈值；
- 第三方模型或工具不可用，却仍在自动重试；
- 任务超出预计时间仍没有结果。
成本触发不是“舍不得花钱”，而是防止异常循环把一次业务错误放大成一张无法解释的账单。
八、老板要把“可撤销”写进项目合同
如果企业只在技术文档里写停机按钮，实际项目交付时很容易被忽略。合同和验收附件可以明确：
- 哪些任务、工具和权限必须支持单独暂停；
- 停止信号多久生效，哪些外部请求无法取消；
- 任务、工具、账号和凭证的日志保存多久；
- 发生异常时谁有权限暂停，谁负责通知业务部门；
- 人工接管需要带哪些上下文和资料；
- 已完成的写入动作如何查询、撤销或补偿；
- 模型和第三方服务变化后如何重新验收；
- 供应商停止服务或企业退出时，怎样拿回数据、配置和凭证管理权。
“支持人工干预”太模糊，“出现问题及时处理”也不能验收。企业要把触发条件、停止动作、责任人、响应时间和复测方式写成可验证的条款。
九、企业现在就能做的一次小演练
不必等到 AI Agent 全面上线，企业可以用一个低风险测试任务演练：
- 让 Agent 读取一份测试资料并创建一个待办；
- 任务执行到一半时暂停该任务；
- 撤销它对相关工具的权限；
- 检查队列、缓存、重试和凭证是否仍能继续动作；
- 让人工接管人员查看完整上下文；
- 对已经写入的测试记录执行回滚；
- 导出日志，确认每一步都能解释。
如果这次演练需要开发人员临时手工登录服务器、直接删队列或修改数据库才能停下来，说明系统的“紧急关机键”还没有真正做好。
十、真正成熟的 Agent，不是永远不出错
企业无法保证 AI 永远不会犯错，也不能把安全寄托在“模型足够聪明”上。更现实的标准是：
- 它平时只拥有完成任务所需的最小权限；
- 它的每次重要动作都能追溯；
- 它在不确定、越权和成本异常时会停；
- 人工可以快速接管；
- 已经发生的影响能够评估、撤销或补偿；
- 模型和业务变化后，系统会重新测试而不是盲目继续跑。
这才是“可控的智能”，也是企业从聊天工具走向业务系统时必须补上的基础能力。
华茂思捷科技提供企业 AI Agent、自动化流程、权限治理和业务系统整合服务。如果你准备让 AI 进入真实业务流程，可以先通过核心服务了解落地边界，也可以通过联系我们，先把权限、审批、停机、人工接管和退出机制谈清楚，再决定让 Agent 获得哪些能力。
