2026 年生产级 AI 工作流的大模型选型：一份决策框架
每隔几周就有一款新的旗舰模型发布。每一次登顶排行榜，都会引发同一个 Slack 讨论：我们该不该切？
对于在生产环境里跑智能体系统的团队，答案几乎永远是：先别切，可能永远也不切。模型只是一个系统的输入之一，而系统的行为主要由它周围的一切决定——prompt、工具、检索层、审核路径、评测套件。换个模型只是换了其中一个输入，单凭这一件事，并不能修复一个本来就不靠谱、太贵、或者两者都有的系统。
2026 年的大模型生态已经足够成熟——几家头部实验室在运营级工作最需要的那些能力上接近打平。现在真正有意义的决策不再是"哪家实验室领先"，而是"哪个模型类别适合这条工作流程，以及成本结构如何"。
生产环境里真正重要的四件事
市场材料开篇都是基准测试分数。生产团队应该忽略它们。
重要的是模型在一个封闭的工作流程里、对系统真正会遇到的那些 case、做出来的事情——在业务可承受的成本和延迟下。这件事归结为四个标准。
工具调用的可靠性。 模型能不能在正确的时机、用正确的格式、传正确的参数发出工具调用？大多数智能体系统的 token 消耗主要花在工具调用上，而不是聊天。一个在推理基准上高 5% 的模型，如果在实际系统所依赖的结构化输出上失败率高 10%，对这个系统而言就是更差的生产模型。在你自己的 case 上测，不要在公开评测上测。
高负载下的延迟。 一个在单请求下 800 毫秒响应的模型，当系统以 50 路并发工作流跑、长上下文的时候，响应可能要 6 秒。延迟在智能体系统里是会累积的：一步变慢，一个 3 步的工作流就变成 20 秒的体验。要在负载下测，不要在隔离环境里测。
每个完成 case 的成本。 每个 token 的成本对智能体系统来说是个没用的数字。重要的是一个真正能跑通的工作流的成本。一个更贵的、2 步就跑完的模型，比一个便宜的、会循环、会重试、会失败然后要重跑的模型更省钱。要跟踪的是"每个完成 case 多少美元"，而不是"每次调用多少美元"。
分布漂移下的行为。 在你测过的 case 上表现好的模型，面对稍微不同的 case——不常见的输入格式、含糊的语言、系统没见过的边界 case——经常会退化。问题不是模型在实验室里好不好，而是它在不确定的时候是不是优雅。这里的"优雅"指的是：它会请求澄清，它会返回结构化的错误，它会路由给人工，它不会编造看起来很真但其实是胡说的东西。
一个模型在三个标准上赢、第四个上输得很难看，那它就不是适合生产的模型。大多数时候，第四个就是那个坑。
闭源旗舰 vs 开源
"开源还是闭源"这个框架对运营级工作基本无关。真正的问题是哪个模型类别——小而快、中等且能干、还是大且贵——适合这条工作流。
闭源旗舰模型在以下场景是合理的：工作流涉及长上下文、复杂的多步推理、需要真正解读能力的含糊输入，或者一个错误输出代价很高的场景。它不适合作为系统里每条工作流的默认选择。
开源和开放权重模型——无论是中等尺寸还是蒸馏出的小尺寸——对一大类生产任务来说已经够用了。结构化文档的抽取、分类、路由、简单的工具调用、摘要、短文本生成：这些都是已经被小到中等模型层级解决的问题，不值得花旗舰模型的钱。
我们用得最多的模式是混合的。系统前面一个路由器，简单的 case 路由给小且便宜的模型，只有难的 case 才升级到旗舰模型。这不是理论。我们做过一些文档密集的接入工作流，成本降了 60–80%，质量没有可观测的下降——因为简单的 case 真的简单，旗舰模型只会拿到那些真正需要它的 case。
这个模式的坑，是把路由器本身当成一个简单的东西。它不是。一个过激进的路由器，只不过是一通更贵的旗舰模型电话。一个过度保守的路由器，把难的 case 漏给一个没能力处理它的模型。路由器需要自己的评测套件、自己的监控、自己的审核路径。
上下文窗口是个坑
更大的上下文窗口被当作特性来卖。对生产级智能体工作来说，它常常是个负债。
长上下文模型在每次调用上更慢、更贵。它们还有一个被充分记录下来的倾向：对于埋在长上下文中间的信息，关注度会显著下降——这意味着系统最后不得不在 prompt 里再实现一遍检索。本来由检索替代的那些工作，做得更不可靠、成本还更高。
正确的模式仍然是：小且精心整理过的上下文，加上一层检索层——在正确的时间把正确的信息摆到模型面前。一个能好好处理 8k token 的模型，在生产环境里比一个能处理 1M token 但做不好的模型更有用——因为精心整理过的 case 更快、更便宜、更可预测。
真正的长文档工作流是例外——完整合同审阅、几千行代码的分析、大规模语料搜索。这些场景，长上下文是正确的工具，代价也是代价。
追新模型
每次新模型发布都会触发一波"我们要不要切"的讨论。绝大多数这种讨论都是干扰。
在生产环境的智能体系统里切模型不是免费的。它需要重跑评测套件、重跑回归测试，通常还要重写 prompt 里那些为旧模型风格调过的部分，并且重新校准人工审核阈值。它还会产生一段不确定性增加的时期——在这段时间里，系统的行为和监控仪表盘预期的不一样。对于一个在生产环境里跑的系统，这段不确定性时期本身就是成本。
频繁切模型的团队，往往是那些系统还没成为关键业务依赖的团队。一旦一个系统每天跑 1 万个 case，产出被客户和操作人员使用，切模型的代价就远远大于再跑一个 6 个月前的模型。
正确的切换时机是：新模型在你自己的评测套件——包含这个系统真正的 case，不是公开基准——上产生可观测的提升，并且这个提升大到足以覆盖迁移成本。这种事会发生，但不是每个季度。
选模型是一个系统决策
模型大概占一个生产级智能体系统的 10%。剩下的 90% 是 prompt 设计、工具定义、检索、编排层、评测套件、审核界面、监控。
痴迷于模型选择、忽略其余的团队，做出来的系统往往在生产里是脆弱的：在模型被测过的那些 case 上能跑，在没测过的 case 上会失败，并且会积累技术债，让系统越来越难演进。
把选模型当成一个系统决策的团队，做出来的系统在生产里是稳健的：在很广的 case 范围上能跑，失败的时候能优雅地失败，并且能随着模型生态变化而演进。系统里的模型是可替换的。模型周围的系统才是资产。
我们站的位置
2026 年的旗舰模型是好的。它们并没有比上一代好到足以单独成为迁移的理由。真正有意思的工作在模型周围——路由、检索、审核路径、评测套件。模型是组件。系统是产品。
如果你在为一条生产工作流选模型，正确的问题不是"哪个模型最好"，而是"在这条工作流真正遇到的 case 上、按照这四条标准的判断、在业务可承受的成本下、在我准备好的运营体系里，哪个模型最好"。大多数时候，答案是混合的：简单 case 用小且快的，难 case 用旗舰模型，两者之间的路由器作为架构的一等公民来对待。
这个答案在未来 12 个月里不会有太大变化。模型生态会变。选型的框架不会。