AI Agent 上线以后，团队经常会默认“有问题再找人”。这在试用阶段还能勉强应付，到了生产环境就很危险。告警来了没人看，接管时不知道谁有权限，问题处理完也没有复盘，下一次仍然从头慌一遍。
值班表不是大团队才需要的形式主义。只要 Agent 已经接入真实客户、真实数据或真实写入动作，就应该提前设计谁接告警、谁能暂停、谁负责恢复、谁来复盘。它和 观测指标、人工接管台、变更复盘 是同一套生产运行机制。
先把告警分成三层
不是所有告警都需要半夜把人叫起来。知识库命中率轻微下降，可以进入次日巡检；工具连续超时、成本突然升高、批量写入失败，就应该进入即时处理；涉及删除、外发、权限变更和客户可见错误，则要直接升级。
分层的目的不是降低敏感度，而是让人知道每类问题该怎么处理。告警如果没有优先级，最后会变成全员免疫。
接管人要有明确权限
值班人不一定要能改所有配置，但至少要能暂停工作流、查看关键日志、转派给负责人、记录处理过程。否则值班表只是通讯录，真正出事时还是要临时找管理员。
权限设计可以参考 授权边界 和 权限漂移巡检。临时授权要有到期时间，值班权限也要定期复核。
升级路径要写到任务里
很多事故处理拖慢，不是因为没人愿意负责，而是没人知道下一步找谁。模型异常找谁，工具失败找谁，知识库过期找谁，客户投诉找谁，应该在值班规则里提前写清楚。
如果团队已经有 SLA 分层，值班表就可以直接接上响应时限和升级路径。到了时间未处理，系统自动提醒下一层负责人。
复盘要留下可检索记录
处理完告警不等于事情结束。真正有价值的是复盘：触发条件是什么，影响范围多大，临时措施是什么，永久修复由谁负责，类似问题怎样提前发现。
这些记录后面会进入失败样本库和回归评估。如果每次只在群里说一句“已处理”，团队就永远积累不了生产经验。
总结
AI Agent 值班表的核心，是让生产问题有人看、有人接、有人能处理、有人复盘。它不需要复杂，但必须清楚。靠临时拉群撑起来的生产系统，迟早会在高峰期暴露问题。
