智能体开始全天候工作后，企业要先定义什么才算异常

智能体一旦可以在你合上电脑后继续跑，企业最容易犯的错是：把“持续运行”理解成“持续汇报”。早上打开工作台，几十条总结、提醒和状态更新已经堆满；真正需要人拍板的那一条，反而被淹没。会一直工作，不等于应该一直打扰人。

AWS 9月更新 Amazon Quick：计划任务和监控智能体可在云端持续运行，即使用户关闭电脑也把结果送进信息流；日简报每天刷新三次，企业套餐的月度智能体时长也从8小时升至18小时。这项产品更新指向一个很实际的变化：智能体的输出从一次性回答，变成了需要被管理的持续信号。

从“任务完成”变成“需要决策”

聊天式工具的终点通常很清楚：用户提问，系统回答，页面关闭。但长任务、定时巡检和事件触发式智能体没有天然终点。AWS 对新版 AgentCore Runtime 的描述很形象：智能体正从几秒钟的对话，走向运行数小时、无人值守、只在任务结束或遇到需要人决策时浮现的环境。它还披露，在其测试中，新运行时针对200MB到2GB镜像的P75冷启动约为2秒，而旧版约从5.4秒升至接近30秒；这是厂商基准测试，不代表所有部署环境。真正值得注意的不是速度数字，而是“何时浮现”的产品逻辑。

我的判断是：持续运行智能体最重要的交付物，不是一串日志，而是一份明确的“该由谁、在什么时候、依据什么来决定”的异常信号。

所以，企业不要只给智能体写“每天检查库存”“持续关注风险”这类任务描述，还要同时写一份信号契约。它至少包含四项：正常波动的区间；触发提醒的阈值和证据；负责接收并有权处理的人；如果无人响应，多久升级、升级到哪里。没有这四项，系统只是在更快地生产待办事项，而不是替团队减少判断负担。

异常不是“发现问题”，而是“进入接力”

9月15日，Diligent 发布的 GRC 智能体强调持续监控：它可监测风险数据、跟进逾期行动、升级问题，并把发现的变化连到审批和责任流程。该公司把目标表述为从定期评估转向持续管理，同时保留恰当的监督、批准和问责。这个案例提醒我们：监测本身不是终点，异常必须带着上下文进入可执行的接力，否则“实时”只会放大焦虑。

一张合格的异常信号，不该只写“发现风险”。它应告诉接收者：发生了什么、与哪条已确认基线相比发生了偏离、影响的是哪项客户承诺或业务指标、智能体已经做了哪些安全动作、还缺哪一个人工判断。这样，人看到的不是一条要求再调查的告警，而是一份可以接手的决策材料。低影响信号可汇入日报；会影响承诺、资金、权限或客户体验的信号，才应即时打断人。

给每个常驻智能体一份“何时叫人”的说明书

我建议企业在上线常驻智能体时，不只验收它能完成什么，还要验收它什么时候沉默、什么时候汇总、什么时候升级。先列出三类信号：可以自动记录的常规变化、需要班次汇总的趋势变化、必须即时升级的不可逆风险；再为第三类绑定接管人、最长响应时间与降级方案。随后用真实历史数据回放，观察阈值是否制造噪声，接管人是否真的能在规定时间内作出判断。

对 STARBOX 而言，组织层先定义哪些偏离需要业务签收、谁拥有升级权；BOX 层保存基线、阈值、证据、值班与处理结果；智能体层只负责持续观察、按契约汇总或升级。DDABC闭环则把被忽略的提醒、误报、延迟处置和成功接管一起回流：让阈值越来越贴近真实业务，而不是让通知越来越多。

企业真正要培养的不是“永不下线的AI员工”，而是一种更克制的运行秩序：平时安静地做准备，出现真正需要人负责的偏离时，带着证据把正确的问题交给正确的人。能做到这一点，全天候智能体才会增加组织的注意力，而不是消耗它。