智能体行为的稳定性靠两层路由保住：Sierra 拆解多供应商 LLM 服务容灾的完整架构

一句话结论

传统软件的可靠性是「服务器挂了切流量」，但 AI 智能体的可靠性更微妙：一个智能体的行为由多个 LLM 协同产生，某个推理任务被静默切到别的模型，智能体的决策方式就会变。Sierra 的解法是把「模型选择」和「供应商适配」拆成两层独立组件，在供应商不稳定时保住每个任务用原来的模型，行为不漂移。

服务难题：多供应商现实，单一行为预期

LLM 通常可以通过多个服务商获取。比如一个 GPT 模型，既可以从 OpenAI 官方基础设施访问，也可以通过云托管部署访问。

实际中的故障很少表现为干净的全面宕机。更常见的是波动的限流额度、各区域不均衡的容量、流量切换时的路由不稳定。

当某个推理任务因为供应商受限被静默切到不同模型时，智能体的决策过程可能随之改变。这种场景下，简单的故障切换不够用。

要可靠地服务智能体，需要解决两个独立问题：一是对供应商不稳定做出反应，二是保护决定智能体行为的模型选择。Sierra 用两个组件分别处理。

多模型路由器：自动容灾但不改智能体行为

多模型路由器（MMR）负责执行 Sierra 智能体 SDK 为每个推理任务定义的模型优先级列表，并在主模型不可用时管理受控回退。

每个任务的模型选择基于两个输入：SDK 定义的任务级模型排序，以及来自拥塞感知选择器的实时健康与准入信号。

正常情况下，MMR 为任务选用首选模型。当首选模型受限时，MMR 评估是否允许回退；如果允许，就选下一个候选。

也有一些场景不适合回退。比如：任务需要的功能只有特定模型具备；用户可见的流式回复已经开始，中途换模型可能带来语气和一致性断裂。

这些情况下，MMR 不会切换到可能负面影响智能体行为的替代模型。

拥塞感知供应商选择器：识别宕机与限流

拥塞感知供应商选择器负责在容量波动和限流面前维持供应商层的稳定。

没有拥塞控制时，多供应商路由很容易退化为振荡，尤其在限流条件下。典型循环是：供应商 A 返回 429 → 标记 A 不健康 → 流量切到 B → B 过载 → A 的负载下降 → 标记 A 恢复健康 → 流量切回 A → 循环往复。

这个循环把过载在供应商之间来回转移，让路由不稳定。为了防止这一点，Sierra 引入了准入控制器。

准入控制器：AIMD 动态限流

准入控制器限制受限供应商能接收的流量，用类似 TCP 拥塞控制的加性增长、乘性减少（AIMD）机制维护动态准入分数。

每个候选供应商初始有一个令牌预算。触发限流时，预算乘以一个退避因子缩小；请求成功时，逐步加回令牌，慢慢恢复流量。

这样平滑了流量转移，避免不必要的故障切换，同时保持对首选模型的高效利用。

按优先级丢弃流量

必须削减流量时，每个请求附带一个优先级分数，低优先级流量先被丢弃。这个信号回传给 MMR，MMR 可以用另一个模型重试这些请求。

供应商容量受限时，低优先级流量（任务 B）先被丢弃，保住高优先级流量（任务 A），让客户侧的智能体行为保持一致。

稳定供应商流量的结果是：临时基础设施问题改变各任务所用模型、进而改变智能体行为的可能性被大幅降低。

不妥协的韧性

AI 智能体越复杂，韧性就越不能止步于在线率，必须延伸到行为层面。把模型意图与供应商适配分开后，智能体在基础设施实时切换时依然保持稳定。

对于在 Sierra 上构建智能体的团队来说，这意味着基础设施的不稳定永远不会以智能体行为不一致的形式暴露给用户。智能体下面的基础设施可能实时切换，但用户看到的行为始终如一。

原文信息

• 作者：Pierpaolo Baccichet（Sierra）、Richard Henwood（Sierra）
• 发布日期：2026-02-13 原文地址：