你的智能体平台忘了配置的值班轮换

AI 平台团队有四名工程师。他们七个月前发布的内部 Agent 现在每天为 200 名员工回答问题。在第一个月，创始工程师亲自处理了每一个 Slack 消息——周二晚上 11 点，周日上午，甚至公司团建的晚上。随后，她因推动采用率方面的贡献而晋升为资深工程师（Staff Engineer），三周后，她在下午 6 点后就不再查看频道了，因为那是资深工程师该做的。原本打算取代她的值班轮换（on-call rotation）从未正式化，因为运营模式总是打算在“试点之后”再解决。

当 Agent 针对四分之一的用户静默降级的那天——一个悄然落后的检索索引，或者改变了拒绝行为的模型版本切换，或者是架构轮换后现在返回空数组的工具——投诉并不会降临到平台团队的传呼机（pager）上。它们落在帮助台队列中，由那些无法访问 Agent 追踪（traces）、不知道什么是系统提示词（system prompt）、并且被 IT 部门告知该 Agent “由 AI 团队负责”的人员处理。从第一个用户投诉到第一位工程师查看 trace，中间过去了 16 个小时。平台团队没有人玩忽职守；只是根本就没有人在执勤。

这是每个 AI 平台团队离晋升仅一步之遥的失败模式。构建 Agent 的工作有预算；但运营它的工作却没有。知道如何调试它的团队，其班次结构无法可持续地进行调试。而拥有客户关系的团队则无法清晰地看到系统，从而无法进行分流。这两个事实之间的差距，就是用户信任悄然消逝的地方，这是一个伪装成工具问题的招聘问题。

构建团队和运营团队曾是同一个团队，直到他们不再是

这种模式在十年的 SRE 历史中随处可见，并被重新压缩到了 18 个月中。在任何新平台的第 1 年，构建它的人就是运营它的人，因为他们是唯一能做到的人。他们出于善意处理传呼。他们编写 Slack 分流线程进行跟踪。他们内化失败模式的速度比记录文档的速度还要快。这看起来像是一个有效的运营模式，因为平台足够小，善意是可以扩展的。

然后平台增长。采用率达到拐点。创始工程师在公司内部变得引人注目，并开始被招募到其他领域，或者晋升到明确降低战术响应优先级的角色。新员工入职了代码库，但没有掌握系统如何损坏的隐性知识。对 6 个用户有效的 Slack 分流线程对 200 个用户不再有效。团队中没有人计算过：如果创始工程师停止响应，处理事件的首响应时间是多少？

Google 的 SRE 手册在这方面的计算非常明确，而且已经存在了十多年。一个可持续的 24/7 值班轮换在单一地点至少需要八名工程师，或者在两个地理位置分散的地点各需六名工程师，以实现全球轮换（follow-the-sun）。少于这个人数，轮换频率就会变得有害——工程师携带传呼机的频率太高，以至于班次之间的恢复时间崩溃，人员流失加速。“25% 值班原则”——即任何时刻有四分之一的工程师在待命——之所以存在，是因为这大约是一个健康团队在不影响项目进度的情况下，能从项目工作中转移出的最大注意力比例。

一个只有四人的 AI 平台团队不符合这个数学逻辑。它做不到。选择不在于“好的值班”和“优秀的值班”之间，而是在于“没有值班”和“一个明确承认团队太小并采取招聘、联合或缩减覆盖范围的值班结构”之间。

在发生第一次事件之前配备值班人员，而不是之后

解决这一问题的原则与 SRE 组织在 2010 年代学到的一样：运营模式应随系统一起发布，而不是在系统发布之后。对于一个从试点转向生产的内部 AI Agent 来说，这意味着在第一批 50 名用户上线之前，而不是在发生第一次事件之后，需要落实三件具体的事情。

带有影子周（shadow weeks）的明确轮换。 即使是在一个四人团队中，有记录的主/备轮换和为期一周的班次也比非正式的“谁先看到谁处理”模式好得多，因为它让负载的不公平性变得可见。如果你的四人团队让每个人每隔一周担任一次主要负责人——这个负载是 Google SRE 建议值的两倍——那这本身就是你需要向领导层申请人力所需的证据。轮换是人事讨论的强制函数；缺乏轮换则让团队可以用善意来掩盖差距，直到善意耗尽。

前六周的影子轮换。 将每一个主要班次与来自合作伙伴团队的影子人员配对——一个 SRE、一个来自相邻组的平台工程师，或一个具有 shell 访问权限的高级支持工程师。影子人员不需要调试 Agent。他们必须学习针对实时事件的运行手册（runbook），这样第二个月就不再依赖于发布它的那四个人。小团队中隐性知识的半衰期很短；延长它的方法是让团队以外的人获得 45 分钟受监督的事件处理时间。

书面的传呼 SLA。 不是“我们会处理的”。平台团队对组织其他成员做出的书面承诺——“P1 在 15 分钟内处理，P2 在 4 个工作小时内处理，P3 在下一个工作日处理”。数字本身的重要性次于将其写下来的行为，因为写下来就是为此配备人员的行为。一个无法兑现其必须书面承诺的 SLA 的团队，在发生第一次事件之前就知道自己的人手不足。

服务台是静默退化首先暴露的地方

加载中…