依赖一个巨型AI模型处理所有任务是一种陷阱。对于简单任务而言，它过于昂贵且缓慢；而对于复杂任务，当事情出错时，它存在太大的风险。
图源：Chris J Walker
每当我看到一个新的智能体项目启动时，我几乎总能预测到第一个架构决策：选择一个单一的巨型模型，将其与一些工具连接，然后不断调整提示词直到勉强可用。我自己也曾这样做过。这看起来简洁明了，采购流程简单，团队也只需关注一个基准指标。
但一旦开始面对真实流量，这种架构就会迅速出现运行故障。
生产环境中的智能体失败并不是因为模型"不够好"，而是因为运行环境存在各类不可控的复杂因素：请求格式不断变化，时延预算相互冲突，工具时好时坏，成本骤然飙升，策略约束频繁变动，故障模式层层叠加。单一模型架构将所有这些问题都集中到了一个故障点上。实际上，这最终会演变为可用性风险、成本风险和治理风险。
改变我看法的是从演示成功指标转向运营成功指标。在演示中，我只关心"模型回答是否正确"；而在生产环境中，我必须关心"整个系统是否安全、准时、以可接受的单位成本完成"。这是一个截然不同的问题，需要截然不同的设计。
一、失败模式不是"智能不足"，而是"方差过大"
许多工程团队将模型选择视为排行榜问题：挑选质量评分最高的模型，然后统一标准化。这在一定程度上是对的，但智能体工作负载并非单一狭窄的任务，而是包含复杂度分布极广的各类任务。
针对某一具体产品，约70%的用户任务属于常规分类、检索和转换；另有20%需要适度的推理能力并穿插工具调用；最后10%则是棘手的边缘案例，需要长上下文、规划和重试机制。我们最初尝试将所有任务都路由到一个大型模型，因为它在演示和测试中给出了最佳的平均质量。结果完全可预测：我们为简单任务支付了高昂的成本和延迟，而最困难的10%任务仍然表现出脆弱的行为。
核心问题并非平均质量，而是方差。生产流量存在峰值、工具故障和对抗性用户。如果每个请求都必须依赖具有单一延迟曲线和单一价格曲线的模型，那么尾部行为将主导用户体验。实际上，用户记住的是你的p95和p99表现。【后注。】
这也是NIST的AI风险管理框架等运营指导在智能体设计中最终发挥作用的原因之一：它推动团队将可靠性、监控和治理视为首要关切，而非上线后的补救工作。一旦将智能体视为承担风险的系统，单一模型集中化就会看起来像是故意产生的技术债务。
我还发现，单一模型设置会降低事故响应效率。如果模型质量下降，究竟是模型更新问题、提示词退化、检索漂移、工具接口契约失效、上下文截断异常还是评估盲区？在一个巨型执行链路上，所有环节都紧密耦合，而耦合在事故期间代价高昂。
二、生产环境中的智能体是系统，而非提示词
最终让我团队真正转变观念的是这一点：智能体是一个受策略编排的系统，而非一个碰巧调用工具的提示词。一旦接受这一点，多模型设计就不再显得是为了复杂而复杂，而更像是你在任何领域都会期望看到的系统工程实践。
对于推理流程，我经常借鉴ReAct论文中的模式：将思考与行动交错进行，然后通过工具结果来锚定决策。在生产环境中，我发现当你将不同角色解耦到不同模型时，这种模式表现更佳。例如：
小型快速模型负责意图识别、策略检查和工具参数规范化
中型模型处理大多数基于检索的合成任务
高能力模型专用于升级场景、模糊请求或高影响输出
确定性层负责防护栏、模式验证和脱敏处理，无论使用哪个模型
这里的核心思想是建立隔离边界。如果高能力模型发生故障或成本激增，核心流量仍可通过较低层级继续流动，实现服务优雅降级。如果小型模型错误地路由了部分任务，回退机制和置信度阈值可以用降级行为而非完全失败的方式进行恢复。
可观测性在这里同样重要。智能体团队往往只记录最终答案，并将其称为监控，这是对可观测性信号的拙劣利用。你需要追踪编排步骤、工具调用、检索版本和策略决策的全链路。我个人默认采用类似OpenTelemetry的原则，因为分布式追踪能快速暴露模型路由问题。如果没有这些，你就只能在传闻轶事中摸索调试。
另一个惨痛教训是：治理策略的变化速度比模型合同快几个数量级。法务或安全团队可能在毫无预警的情况下要求新的脱敏规则、保留期限或禁止行为。如果一个模型深度嵌入每个推理流程的每个阶段，策略变更就会变成大规模、痛苦的迁移。而在具有清晰接口的多模型架构中，策略变更主要只是路由和控制平面的更新。
三、一个能在实际运营中存活下来的实用多模型架构
对于询问如何起步并避免过度设计的团队，我建议采用分阶段方法，让复杂度与风险成正比。
1、第一阶段：控制与生成分离。维护一个控制层，负责路由、策略、预算和重试。让生成模型在定义良好的接口后保持无状态，这使你能够在不改变业务逻辑的情况下更换模型。
2、第二阶段：能力分层。定义至少三个类别：快速廉价型、均衡型和高端推理型，基于任务类别、置信度和影响进行路由。如果置信度低或操作高风险，则升级；如果请求是常规性的，则保持在较低层级。
3、第三阶段：故障感知执行。为每个外部依赖构建显式的超时、熔断器和回退响应：模型API、向量存储、内部工具和身份服务。如果检索失败，按有界规则响应，而非假装确定。如果高端模型不可用，则在需要时降级到人工交接路径。
4、第四阶段：生产级评估。离线基准数字很好，但对于智能体系统来说还不够。你需要包含真实工具行为、延迟依赖和策略边缘案例的场景测试套件。我个人要求每个路由都有成功率、p95延迟、token成本、升级率和策略违规的指标。只有这种程度的可观测性才能让你负责任地调整路由阈值。
5、第五阶段：经济控制。大多数智能体成本超支并非来自单个非常昂贵的调用，而是来自重试、长上下文和递归工具循环。设置每会话和每步的token预算，按路由限制重试次数，并在规划器中强制执行停止条件。成本治理应该是自动的，而非每月的意外惊喜。
我经常听到的反对这个观点的一个主要原因是多模型设置难以管理。根据我的经验，如果架构足够清晰，情况往往相反。当行为表面隐藏在提示文本中时，治理是困难的；当路由决策、策略检查和升级标准可见、可版本化和可测试时，治理才是可操作的。
另一个反对意见是来自多个供应商或多个模型系列会增加供应商锁定风险。这是一个合理的担忧，但根据我的经验，当你维护内部模型抽象并保持提示词、评估框架和工具模式可移植时，锁定风险反而更低。单一模型堆栈往往一开始感觉更简单，但随着时间推移会变得与提供商特定行为高度耦合。
我最后被问到的一个问题是：什么时候单一模型仍然可行？我认为，对于低流量的内部助手、非关键工作流或任务范围狭窄的早期原型，单一模型是可以接受的。但对于有正常运行时间、合规性和成本目标的面向客户的智能体来说，它不是一个可持续的默认选择。
如果必须用一句话总结，那就是：生产环境中智能体的可扩展性是一个控制平面问题，但常被误诊为模型选择问题。单一模型可以非常出色，却仍然无法满足你的系统目标。只有具备强大路由和策略控制的多模型架构，才能让你同时在质量、可靠性和成本三个维度上实现规模化。
睿观：在真实的业务场景中，系统的稳定性（尤其是最坏情况下的表现）远比平均性能更重要。简单来说，用户不会因为你 99% 的请求都很快而原谅那 1% 让他们苦等半分钟的卡顿。
平均质量 (Average Quality):
这通常指模型在基准测试（如 MMLU）中的得分，或者在压测中所有请求的平均响应时间。它代表了“理想状态”或“大多数情况”下的表现。
方差 (Variance):
在这里，它指的是性能的不稳定性。具体表现为，大部分请求处理得很快，但总有少数请求会因为各种原因变得极慢。这种性能上的巨大差异就是“方差”。
为什么方差是核心问题？
想象一个智能客服，它回答 100 个问题，99 个都在 1 秒内完成，但有 1 个问题因为触发了模型的复杂推理或系统资源竞争，导致用户等了 30 秒。虽然平均响应时间可能只有 1.3 秒，看起来很优秀，但那 1 个等待 30 秒的用户体验是灾难性的，他很可能因此放弃使用你的产品。
P95 和 P99 是统计学中的百分位数，专门用来衡量这种“方差”或“长尾延迟”。
P95 (第95百分位响应时间):
表示 95% 的请求响应时间都低于这个值。换句话说，有 5% 的请求比这个时间还要慢。
P99 (第99百分位响应时间):
表示 99% 的请求响应时间都低于这个值。这意味着只有 1% 的请求会遭遇比这更慢的响应。
用户记住的是 P95 和 P99 表现，正是因为这两个指标反映了服务在最差情况下的用户体验。优化 P99 意味着要解决那些最棘手、最偶然的性能瓶颈，这直接决定了服务的可靠性和用户口碑。
在大模型服务中，导致“方差”和“长尾延迟”的原因比传统软件更复杂：
请求负载差异巨大
与传统 API 处理相似工作量的请求不同，大模型的每个请求“工作量”天差地别。
简单请求：
用户问“你好”，模型只需生成几个 token，瞬间完成。
复杂请求：
用户要求“写一份关于人工智能伦理的 2000 字报告”，模型需要处理长文本输入并生成大量输出，耗时可能是前者的几十倍甚至上百倍。
如果只用一个模型处理所有请求，简单请求就不得不为复杂请求“排队”，导致 P95/P99 指标飙升。
生产环境的复杂性
正如前文所述，生产环境充满不确定性：
流量峰值 (Traffic Spikes):
瞬间涌入的大量请求会导致系统资源（如 GPU 显存）紧张，引发排队和延迟。
工具故障 (Tool Failures):
如果 AI 智能体需要调用外部工具（如数据库、搜索引擎），任何一个工具的延迟或故障都会拖慢整个请求的处理速度。
对抗性用户 (Adversarial Users):
恶意用户可能发送精心设计的、旨在消耗大量计算资源的提示词，导致服务变慢甚至瘫痪。
结论是，依赖“具有单一延迟曲线和单一价格曲线的模型”是危险的。这引出了当前企业级 AI 应用的一个重要设计思想：多模型架构。
这种架构的核心思想是“让合适的模型做合适的事”，通过分层和路由来降低方差：
快速廉价模型：
处理 70% 的简单、常规任务（如分类、简单问答）。它们响应极快，成本低。
平衡模型：
处理 20% 需要一定推理能力的任务。
高能力模型：
仅用于处理 10% 最复杂、最困难的“长尾”任务。
通过这种设计，绝大多数用户的请求都能得到快速响应（优化了 P50 和 P95），而那 10% 的复杂任务虽然慢，但不会拖垮整个系统，从而保证了整体服务的稳定性和可预测性。这正是从关注“平均质量”到控制“方差”的工程化实践。
