AI Agent 模型切换事故复盘：你的 agent 何时悄悄换成了高费用模型？

背景：所有 agent 用的是同一个模型

最近在用多 agent 协作平台做项目，团队有十几个 agent 各司其职。出于一致性考虑，所有 agent 的模型配置统一硬编码为同一个模型名——这是我建团队时定下的约束，当时觉得「统一」是好事。

这个配置写死在每个 agent 的定义里，不是运行时动态获取的。也就是说，如果那个模型名在上游突然不可用了，系统会自动 fallback 到其他可用模型。

我以为这叫「容错」。实际上，这叫「失控」。

事故：任务在跑，账单在飙，没人知道

某天下午，我像往常一样创建了两张子任务单。一切正常——agent 没报错、任务在跑、输出看起来也没问题。

但当天晚上，我收到了 API 的账单通知。

费用翻了三倍。

我第一反应是「是不是有人多跑了任务」。查了一下，任务数量没变，单次调用的 token 消耗也没变。唯一的变量是：模型变了。

原来硬编码的那个模型名，在下午某个时刻被上游从注册表里移除了。系统没有报错，因为它有一个 fallback 机制——自动切换到当前可用的模型。问题是，那个「可用的模型」是最贵的一个。

没有人收到告警。没有人收到通知。系统就这么静悄悄地切换了，一切照常运行。

真正可怕的不是模型挂了，而是它换了一个高费用的模型，而且无人察觉。

为什么这件事比宕机更危险

模型宕机是显性故障——agent 报错、任务失败、你能立刻感知到问题。

但静默切换到高费用模型是隐性故障：

没有报错：系统正常运行，任务正常完成，所有指标看起来都「没问题」
没有告警：模型网关不会告诉你「我刚把你切换到了另一个更贵的模型」
成本延迟暴露：费用是按天甚至按周结算的，你可能在一周后才注意到账单异常
归因困难：当你发现费用飙升时，很难回溯是哪次切换导致的，因为中间没有日志、没有通知

在我们的 case 里，从模型被移除到我发现费用异常，中间隔了大概 6 个小时。这 6 个小时里，所有 agent 都在用那个最贵的模型跑任务。

根因：配置硬编码 + 无成本监控

事后复盘，根因有两个：

1. 配置硬编码 + 无条件 fallback 所有 agent 的模型名写死在定义里，没有环境变量、没有配置中心、没有明确指定的 fallback 模型。当主模型不可用时，系统「聪明地」自动选择了当前可用的模型——但没有考虑成本因素。这不是容错，这是失控。

2. 没有模型变更告警 模型网关的变更没有推送到使用者。如果有一个监控「当前实际使用的模型是否和配置一致」的机制，应该在切换发生的几分钟内就收到告警，而不是等我看到账单才发现。

我学到的教训

#	教训	行动
1	「统一配置」在上游变更时变成「统一风险」	关键配置走环境变量或配置中心，支持按 agent 粒度控制
2	系统自动 fallback 不等于安全	明确指定 fallback 模型，并监控实际使用的模型是否与预期一致
3	费用监控和可用性监控一样重要	设置每日费用告警；模型切换后立即通知
4	「一切正常」可能是最危险的信号	定期审计 agent 实际使用的模型，而不是只看配置文件
5	出事后先取证、再方案、再执行	不要跳过「确认」直接「修」

固化的规则

这次事故之后，我把一条规则写进了核心 agent 的指令里：

未经明确确认，禁止切换或修改任何 agent 的模型配置。模型异常只报告与取证，不先行改动；给出方案等待确认。

这条规则的核心思想是：配置变更必须有人类确认环节。自动化修复是好意，但绕过确认的自动化修复，在模型选型这种关键决策上，可能造成比不修更大的问题——尤其是当「更大的问题」是静悄悄发生的时候。

这次事故暴露的问题很典型：最危险的故障不是系统挂了，而是系统换了一种方式继续运行，而你完全没有察觉。 如果你也在用多 agent 系统，建议检查一下：你的 agent 在主模型不可用时会 fallback 到什么？那个 fallback 的模型，费用是多少？你有没有监控实际使用的模型和预期是否一致？