如果上一章讨论的是“模型有哪些能力维度”，那么这一章要进一步回答：在真实 Agent 系统里，为什么模型选型永远不是“谁最强就选谁”，而是“选择一组能力组合”。
这不是一个修辞问题，而是一个被工程、评测、平台产品和现实约束共同证明的事实。
很多人第一次接触大模型时，容易形成一种非常自然的直觉：既然目标是把任务做好，那么理论上只要买最强模型，就能得到最好的系统。这个直觉在 demo 阶段往往成立，因为 demo 看的是局部效果，是一小段输入、一小次调用、一个表面上完成了的结果。
但 Agent 不是 demo。Agent 要跑在流程里，接工具，接数据，接人，接延迟预算，接成本预算，接风险边界，还要面对请求难度分布极不均匀的现实世界。到了这个层面，“最强模型”这四个字就开始失去解释力。
因为真实系统从来不只需要一种能力。
一个生产级 Agent，通常至少同时需要这些东西：足够的推理深度，足够稳定的结构化输出，足够可靠的工具调用能力，足够可控的长上下文处理能力，满足业务要求的时延表现，以及在高风险场景下足够保守的行为边界。问题在于，这些能力在同一个模型上并不总是同时最优，更不会总是在同一个价格、同一个延迟、同一个风险轮廓下同时最优。
所以，模型选型真正要做的，不是寻找一个抽象意义上的“最强者”，而是为任务找到一组最合适的能力组合。
这里的“组合”至少有三层含义。
第一层，是单模型内部的能力组合。
也就是说，即使只选一个模型，你实际上也不是在看它的总分，而是在看它在推理、工具、结构化输出、长上下文、多模态、安全性、速度、成本这些维度上的组合形态。很多最新官方文档其实已经不再鼓励用户按单一强弱选模型，而是直接把能力、速度、价格、上下文、吞吐、部署形态并列展示。厂商在表达方式上的变化，本身就说明一件事：模型不再被当作一个单值对象，而是一个多目标优化对象。
第二层，是多模型之间的组合。
现实里的请求不是均匀的。少数请求复杂、昂贵、高风险，值得调用更强模型；更多请求则简单、重复、结构固定、可规则化，完全没有必要一上来就调用最贵能力。于是，一个成熟系统自然会走向级联、路由、升级和降级策略。
这就是为什么越来越多的生产系统采用这样的结构：小模型做分类、路由、简单抽取、常规结构化输出；中等模型处理标准复杂度任务；大模型处理复杂规划、冲突消解、高价值生成和高风险场景。这里真正被选择的，不是一款模型，而是一套模型池加上调度策略。
第三层，是模型能力与系统能力之间的组合。
这一层最容易被忽视，也最关键。因为很多团队一遇到问题就先怀疑模型不够强，但现实里大量问题其实并不是“换个更强模型”就能解决的。例如，知识不够新，应该优先加检索；输出不稳定，应该优先加 schema 约束；工具调用乱跳，应该先收缩动作空间；流程不可审计，应该补审批链；高风险任务边界不清，应该加强规则、人审和权限。
换句话说，模型选型真正高阶的地方，不是“会不会挑模型”，而是“能不能判断这个问题到底该由模型补、还是该由系统补”。
这也是为什么本章要把“能力组合”这个概念拉得更宽一些。它不只指多个模型能力叠加，也指模型能力、工具能力、工作流能力、治理能力和业务边界能力之间的整体协同。
先说最基础的一点：为什么单一最强模型思路在生产里不成立。
第一，因为任务需求不是单维的。
一个客服 Agent 和一个财务审批 Agent，看起来都在“理解文本并输出结论”，但真正需要的能力结构完全不同。前者可能更看重时延、口径一致和简单工具调用；后者更看重结构化输出、规则约束、可审计性、保守性和升级机制。即使某个模型在通用排行榜上领先，也不代表它同时是这两个系统的最佳选择。
第二，因为请求分布不是均匀的。
不是每个请求都值得用最贵模型解决。现实请求里，通常只有一小部分是“真的复杂”，大部分任务其实是模式明显、规则稳定、信息边界明确的。把所有请求都送去最强模型，看起来统一，实际上是在用高成本能力处理大量低复杂度问题。这种资源配置在系统规模稍微起来之后，几乎一定失衡。
第三，因为系统目标不是只有质量。
很多团队说“我只要效果最好”，这句话常常隐含了一个前提：延迟、成本、吞吐、并发、合规、运维都不重要。但生产系统没有这种奢侈。质量必须和成本、延迟、容量、缓存命中率、上下文开销、失败恢复、可升级性一起考虑。一个理论上质量更高的模型，如果让系统成本不可控、SLA 无法兑现、上下文过长导致吞吐下降，最终就不是更好的选择。
第四，因为风险不是附属变量。
在高风险场景里，“能力更强”甚至未必等于“更适合”。更强模型可能更愿意作答、更擅长生成看似合理但未经验证的内容，而高风险系统真正需要的可能是更可预测的错误分布、更好的校准、更明确的拒答边界、更可靠的人审升级点。这时，选型本质上就不是选“最会答”的模型，而是选“最适合嵌入治理结构”的模型。
因此，成熟团队在做模型选型时，通常不会问“谁最强”，而会问一组更像系统设计的问题：
- 这个任务真正需要哪些能力维度
- 这些能力维度里，哪些必须由模型提供
- 哪些短板可以由检索、工具、schema、workflow、规则引擎或人工审批补齐
- 哪些请求应该默认走便宜模型，哪些请求值得升级
- 升级条件如何定义，降级条件如何定义
- 模型替换或版本更新后，怎样持续验证组合是否仍然成立
一旦问题这样提出，模型选型就从“采购思维”变成了“架构思维”。
这里尤其要强调路由和级联的意义。
过去很多团队把多模型系统看成一种高级玩法，仿佛只有特别复杂的公司才需要。现在这已经不是例外，而是在成本和质量之间取得可持续平衡的标准手段。相关论文和云平台产品都已经反复说明：便宜模型前置、强模型兜底，不仅能显著降低成本，而且在很多任务上几乎不损失质量，甚至因为更细粒度的分配机制而得到更好的总体表现。
从工程角度看，这背后的逻辑非常直接。假设 80% 的请求只需要中等能力，20% 的请求需要高能力，那么让全部请求都走最强模型，本质上是在让 80% 的请求支付不必要的成本和时延。更合理的策略，是先用轻量路由器或便宜模型判断请求复杂度，再把真正需要深推理或高保真输出的请求升级到更强模型。
这时，真正重要的就不再是“某个模型本身有多强”，而是系统是否具备以下能力：能否识别复杂请求，能否定义升级阈值，能否在失败时兜底，能否持续复评路由效果，能否在模型更新后保持整体组合仍然有效。
所以，模型选型本质上是在选“模型池 + 路由规则 + 升级策略”。
但这还不是终点。更深一层的是，模型池本身也不是全部答案。
很多失败的 Agent，并不是输在模型弱，而是输在系统没有把模型放在合适的位置上。一个典型例子是把模型当成万能决策器，让它既理解材料、又执行规则、又调用工具、又决定是否放行高风险动作。这样做的结果通常不是“全能”，而是每个环节都不够可控。
更成熟的做法，往往是把职责拆开。
例如，一个财务审批 Agent，可以让模型负责理解申请材料、抽取异常点、生成说明摘要；让规则系统负责金额阈值、权限矩阵、制度红线；让审批流负责人类最终确认；让审计系统记录每次依据与动作。这个系统当然用了模型，但它的可靠性并不来自模型“足够强”，而来自能力边界被清楚地拆开了。
同样，一个企业知识助手如果经常答错最新政策，第一反应不应该总是升级到更大的模型，而应该先问：是不是缺检索，缺高质量知识源，缺引用结构，缺文档切片策略，缺上下文组织。如果问题根源在知识供给链，那么再强的底模也只是更流畅地胡说。
这就是“不是所有短板都该靠更大模型解决”的真正含义。
它不是反对强模型，而是反对把所有问题都解释成模型规模问题。强模型应该被用在真正需要高价值推理和生成的地方，而不是替代规则、数据库、工作流、审批链和权限系统。
从这个角度看，模型选型至少包含四类组合判断。
第一类，是能力匹配判断。 也就是任务需要什么能力，候选模型是否真的在这些维度上足够好。
第二类，是经济性判断。 也就是在目标质量下，成本、延迟、吞吐、上下文开销和部署方式是否可承受。
第三类，是系统补强判断。 也就是候选模型的短板，能否通过检索、工具、schema、workflow、缓存、审计和人工监督来补齐。
第四类，是治理适配判断。 也就是它是否适合高风险边界，是否便于拒答、校准、升级给人、记录依据、控制权限和满足合规要求。
只有这四类判断一起成立，模型选型才真正完成。
因此，最成熟的选型顺序，通常不是“先挑模型，再看怎么勉强塞进系统”，而是：
- 先把任务拆成子任务
- 再给每个子任务定义所需能力和约束
- 再决定哪些由模型承担，哪些由系统承担
- 最后才去挑选模型池、路由和部署方式
在这个顺序里，模型第一次真正回到了它应该在的位置上：它不是一个被神化的万能核心，而是整个 Agent 系统中的高价值能力部件。
这也是为什么越来越多高水平团队都采用“先强后拆”的方法。先用最强模型建立效果上限，确认任务到底能不能做；再通过评测看哪些步骤并不需要这么强；然后逐步把简单步骤替换成更便宜、更快、更稳的方案。最终留下的，不是一个英雄模型，而是一套经过验证的能力组合。
所以，本章真正想建立的结论是：
模型选型的本质，不是从榜单上挑冠军，而是在业务目标、请求分布、成本约束、风险边界和系统补强能力之间，设计出一个可长期运行的能力组合。
只有这样理解选型，Agent 才不会做成“最强模型套壳”，而会变成一个真正有结构、有边界、有经济性、也有治理能力的系统。