人工智能系统的“可停止”不能用一个按钮来证明。真正的熔断能力，是系统在异常行为、权限越界或任务影响扩大时，能够触发明确控制动作，并留下可复核证据。验证重点不在于界面上是否显示“暂停”，而在于暂停之后，智能体是否真的停止继续调用工具、访问数据或推进异步任务。
先定义什么叫“停止”
验证前应把控制目标拆开。暂停任务，意味着当前任务不再产生新的行动；撤销凭证，意味着智能体失去继续访问相关系统的资格；阻断工具调用，意味着高风险操作无法继续提交；恢复或回滚，则涉及已经发生的外部变更。四者不能混为一谈。一个系统即使能停止后续推理，也可能让已经提交的支付、邮件、数据修改或生产环境操作继续执行。
因此，测试应从完整任务链路开始，而不是只观察模型输出。让智能体执行一项包含多轮工具调用的任务，在中途触发暂停，检查后续调用是否被拒绝，异步任务是否仍在运行，访问凭证是否能够撤销，以及外部系统已发生的操作能否被识别和处置。测试结果应记录触发时间、停止范围、残留动作、责任人和日志证据。
用故障注入验证熔断
熔断机制必须在异常条件下主动触发，而不是依赖值班人员临时判断。可设计几类场景：连续调用多个工具、尝试访问无关数据、反复修改同一业务状态、执行超出任务目标的操作，或在人工审批缺失时继续推进。每个场景都应预先规定触发条件、阻断动作和升级路径。
还要验证控制权是否独立于智能体本身。若停止命令仍需经过同一个智能体转达，系统就可能在模型异常时失去控制。更可靠的设计应允许管理人员从独立控制面暂停任务、撤销凭证，并查看完整的提示词、工具调用、审批记录和结果日志。
把“可停”变成持续能力
上线前通过一次演示并不代表系统具备稳定的停止能力。模型、工具、数据源或业务流程发生变化后，应重新测试；开发、测试和生产环境也应分别验证。最终评估应回答三个问题：能否及时阻断新的行动，能否控制已经排队或异步执行的任务，能否准确追踪并处置已经产生的影响。只有这三层都能被验证，熔断才不是产品宣传语，而是可审计、可演练的运行能力。