每一次 Tzar.Tech 合作的尾声都是 60 天的重叠 on-call。两支团队——我们和客户的——共享呼机。早期我们以为这是一种善意之举。后来发现这是整个合作中最重要的阶段。
下面是原因。
evals 套件抓不到的
evals 套件能抓住的是你 想到去测的。按定义,它抓不住你没想到的。
对大多数交付到生产的智能体系统而言,前 60 天会浮出:
- 没人预料到的输入。 用户上传了一份 400 页保加利亚语 PDF。某客户用 HTML 转义引号打到接口上。某集成把时间戳以微秒发送。
- 错误的频率假设。 一条“罕见”的路径其实占流量的 8%。一条“常见”的路径其实只有 0.1%。
- evals 负载未能复现的尾延迟。 压测里 100 RPS 时 p99 看起来还好;生产里 250 RPS 时,因连接池按错误分布调大小,p99.9 spike。
- 真实 prompts 下才显现的成本行为。 真实用户措辞问题的方式相对你的合成 evals prompts 让 prompt token 数翻了三倍。
这些不会在任何设计良好的 evals 套件里出现,因为 evals 套件是你已知世界的模型。前 60 天是系统遇见现实的时候。
重叠 on-call 实际起到什么作用
两件事,都重要:
1. 出问题时,离开的团队仍然在线。 新症状出现时,懂代码的工程师就在通话上。不是在两个时区外的 Slack 频道里——而是真的被呼了、正在主动看。修复被发出去,而不是变成一张工单。
2. 接手的团队在自己的语境里学会失败模式。 他们被呼。他们走 runbook(见 随每个智能体交付的 runbook)。需要时升级给我们。每一次事故都成为一次在原作者在线护航下的系统运维实战练习。
到第 60 天时,接手团队已经处理过足够多事故,知道什么难、什么易、什么可以忽略、什么值得呼叫高管。
我们不做什么
我们不做主 on-call。重叠期间我们是 备份。客户团队拥有这个系统。我们的角色是“能回答‘这正常吗’和‘这里的安全路径是什么’的资深 on-call”。
这很关键:如果我们做主,客户团队永远练不出这块肌肉。他们每次都会先呼我们,到第 60 天依然依赖我们。重叠是一扇教学窗口,不是一种服务。
数据怎么说
我们跨多次合作记录过这些数据。形态是一致的:
- 前两周:大约一半的呼叫到我们这。多数是澄清,不是真事故。
- 第 3–4 周:大约四分之一到我们这。客户团队已内化常见诊断。
- 第 5–8 周:不到 10% 到我们这。到的那些是真正值得改代码的新失败模式。
60 天之后,中位合作在接下来的一个季度里平均每月呼我们一次,之后几乎再不呼。系统是他们的了。
为什么是 60 天,而不是 30 天
我们试过一次 30 天。不够。
有些失败模式只在月份边界出现(账单周期、月度批量任务、季末报表负载)。30 天的重叠完全有可能在不遇到它们的情况下结束,留下客户团队对一类 将来一定会 发生的问题盲区一片,且届时没有资深后援可呼。
60 天能覆盖月份边界的失败,并给接手团队整整第二个月在我们做后援的情况下独自处理。它不对称,也不武断——这是我们发现的、足以真正转移所有权的时长。
这要花多少代价、我们为什么这么做
60 天的备份 on-call 是我们实打实没单独收费的工程时间。我们把它含进合作报价里。有些客户不信我们说这是必选——我们仍然坚持,而那些试图跳过它的客户,通常在第二个月就回头叫我们作为顾问回去。
我们宁可第一次就待满 60 天。