智能体不下班后，企业得先约定谁有权打断它

一个智能体夜里持续监控客户工单：它发现某个高优先级订单被延迟，自动催办、改派、生成回访说明。第二天早上，团队看到的是“任务已完成”。可如果这张订单昨晚被销售承诺了特殊条款，或客户已在人工通道提出暂停，真正该被追问的并不是它为什么没做完，而是：谁本来有权叫停它？

“离开电脑也能继续干活”正在从概念变成产品能力。AWS 9月更新的 Amazon Quick，让计划任务和监控智能体在云端运行，电脑合上后仍把结果送到工作流；同时配上活动流、用户级权限与数据防泄漏控制。AWS 的发布说明指向一个明确变化：企业开始购买的不是一次回答，而是一段无人盯守的运行时间。

能持续运行，不等于可以持续放行

这不是单纯的“定时任务升级”。OpenAI 9月推出 Agents API 时，把长会话、工具使用、子智能体协同和可保存的中间结果放进同一套运行底座；其案例中也出现了跨数小时或数天的物流工作流。官方介绍说明，智能体的状态会累积，工作会跨过班次、人员和业务条件的变化。

一旦工作持续，风险就不再只发生在“发起那一刻”。原本合规的上下文可能过期，原本可执行的动作可能因客户、库存、合同或政策变化而失效。AWS 的安全团队因此建议把响应做成分级机制：有些行为可立即自动控制，有些必须升级给人；并强调每个智能体都需要独立身份、临时且受范围限制的凭证。其安全框架提醒我们，真正要设计的是运行中的刹车，不是上线前的一次审批。

我的判断是：持续运行智能体的最小治理单位，不是“它被授予了什么权限”，而是“在什么情境下，谁能暂停、谁能恢复、谁能为未中断负责”。

给每个常驻智能体一张“中断权卡”

我建议企业不要把暂停按钮藏在运维后台，而是为常驻智能体明确一张“中断权卡”。它至少回答四个问题：第一，哪些业务信号触发自动暂停，例如客户撤回、敏感字段变化、预算超限或命中黑名单；第二，哪些角色可一键暂停，业务负责人、安全人员和一线接管人各能停什么；第三，暂停后保留哪些上下文与已执行动作，避免恢复时重复下单、重复沟通；第四，恢复是否需要二次确认，以及由谁签收新的业务条件。

这张卡和“异常告警”不同。告警解决的是看见问题；中断权解决的是在问题尚未被完全解释时，谁有资格让动作先停下来。它也不同于单次动作护栏：护栏限定一笔调用能不能发生，中断权处理的是任务跨越时间后，外部世界已经变了怎么办。

把“暂停”做成组织能力

从行业信号看，企业正在更深地委派工作：OpenAI 对企业使用的汇总分析显示，截至6月，Codex 已占其企业客户 Codex 与 ChatGPT 合计输出 token 的64%；领先企业每活跃用户的输出量是典型企业的8.3倍。这份报告也特别提醒，token 并不等于业务价值。委派更多工作之前，企业更该先确认“停下来”的决策能否同样顺畅地发生。

在 STARBOX 的组织—BOX—智能体三层里，组织层应确定中断权限、升级时限与恢复签收人；BOX 保存任务状态、业务条件、已执行动作和中断原因；智能体只在当前有效条件下继续执行。DDABC 则把人工暂停、误暂停、恢复后返工和遗漏升级的记录回流，持续修正触发条件。这样，暂停不是“把 AI 关掉”，而是让组织在变化发生时仍能把控制权留在自己手里。

智能体终于可以不下班了。接下来的问题是：当你的业务先变了，谁能让它立刻停下，并且知道该怎样安全地再出发？