如果说业务层解决的是“系统要服务什么世界”，那么模型层解决的就是“系统凭什么能在这个世界里做判断”。
很多关于 Agent 的讨论，表面上都在讨论模型，但其实讨论得并不准确。
最常见的说法是：
- 这个 Agent 很强，因为用了强模型
- 这个 Agent 不稳定，因为模型不够强
- 这个业务做不了，因为模型不行
这些判断有时对，但经常只对一半。
因为模型能力从来不是一个单一维度。
一个模型可能推理很强，但结构化输出不稳定。 一个模型可能成本低、延迟小，但多轮状态保持差。 一个模型可能代码能力强，但在高风险业务里不够保守。 一个模型可能很擅长聊天，但不擅长精确执行工具调用。
因此，从模型层理解 Agent，第一步不是问“最强模型是谁”，而是问：
这个 Agent 依赖的到底是哪一组能力。这会带来一个非常重要的认识：
模型能力不是抽象智能，而是任务相关能力的组合。
一个成熟的 Agent 设计者，通常不会把模型视为一个“大脑黑箱”，而会把它拆成若干能力维度来评估：
- 推理
- 指令遵循
- 工具调用
- 格式稳定性
- 长上下文
- 多模态
- 实时性
- 多语言
- 风险敏感场景下的保守性
这也是为什么同样一个 Agent 架构，换一个业务场景，模型选择就可能完全不同。
所以，模型层的真正问题，从来不是“哪个模型最好”，而是：
什么样的模型能力结构，最适合这个任务世界和业务世界。这一点在近两年的官方材料里已经讲得非常明确。
OpenAI、Anthropic、Google、Microsoft 给出的模型选择框架虽然表述不同，但都指向同一个判断：
- 不是先问谁最强
- 而是先问任务需要什么
- 再问这些能力要以什么成本、什么延迟、什么稳定性获得
也就是说，模型选择本质上是一个约束优化问题。
这很重要。 因为它把“选模型”从抽象智力崇拜，重新拉回到了任务匹配。
举一个简单例子。
如果一个 Agent 的任务是对客服请求做一级分流，那么它真正需要的可能是：
- 稳定分类
- 高吞吐
- 低成本
- 低延迟
这时，如果团队执着于使用最强推理模型，往往会得到一个“智能过剩但系统不经济”的设计。
反过来，如果一个 Agent 要解决跨多个文件的真实代码修复问题，它需要的又会是另一组能力：
- 长上下文
- 强推理
- 工具交互
- 测试反馈理解
这时，简单追求低成本小模型就会迅速暴露能力不足。
因此，本章真正想建立的不是“模型排行榜”，而是一种模型视角：
模型不是一个统一的大脑分数，
而是一组可拆解、可比较、可组合、可权衡的能力包。先看第一层，能力维度本身。
官方模型比较页和模型选型文档已经把这件事写得很直白。 OpenAI 会同时列出 reasoning、speed、pricing、context window、tool support 等维度。 Anthropic 会把 capability、speed、cost 并列。 Google 会把 thinking budget、latency、cost、response quality 放在一起比较。 Microsoft 则进一步把 reasoning effort、latency、throughput、token length、cost、use case 对齐成工程表格。
这说明，模型能力至少不是单维的。
进一步看研究评测，HELM 这样的工作把问题说得更彻底： 模型评估本身就应该是多维的，包括准确率之外的校准、鲁棒性、公平性、毒性、效率等指标。
所以，本章第一个要记住的判断是：
模型能力不是一个总分，
而是一个多维画像。第二层，是任务能力。
很多团队谈模型时，只会说“聪不聪明”。 但 Agent 视角下，最少也要把任务能力拆成几大类。
第一类，是推理。
推理能力决定模型能否在多步条件、复杂约束、相互冲突的信息之间形成稳定判断。 BBH 这类高难推理基准说明，推理不是静态分数，而是与任务类型、提示方式、思考深度共同作用的能力。 Google 与 Microsoft 也都把 thinking budget / reasoning effort 做成显式配置项，意味着“推理深度”本身就是可调维度，而不是固定标签。
第二类，是工具调用。
很多人把“会调工具”理解得太浅。 ToolLLM、ToolEyes、τ-bench、BFCL 这些工作已经说明，工具调用至少包含：
- 何时用工具
- 选哪个工具
- 参数是否正确
- 格式是否稳定
- 多轮交互里是否持续一致
- 遇到规则与例外时能否收敛
也就是说，工具调用不是一个按钮能力，而是一组复合能力。
第三类，是结构化输出。
这一类能力在 Agent 里经常被低估。 很多系统失败，不是因为“不会说”，而是因为：
- JSON 不稳定
- schema 不一致
- 标签漂移
- 函数调用格式敏感
- 结果无法直接进入下一步系统
BFCL V4 这类研究已经把这个问题直接量化了： 很多模型“会函数调用”，并不等于“对不同格式和约束都稳健”。
换句话说，结构化输出不是附属能力，而是 Agent 能否进入系统闭环的底层能力之一。
第三层，是上下文能力。
这里最容易被误解。 很多人把长上下文能力直接等同于“窗口更大”。 但 Anthropic、OpenAI 以及一系列论文都在提醒：
上下文能力不是“最多能装多少”，
而是“放进去之后还能否找到、筛选、维持和使用好”。Anthropic 已经把重点从 prompt engineering 转到 context engineering。
OpenAI 在长期记忆材料里把记忆写成 distill / consolidate / forget / inject 的完整生命周期。
Lost in the Middle 和 NoLiMa 更进一步说明：
- 能接收长输入，不等于能利用长输入
- 位置偏置会显著影响模型取证能力
- 窗口扩大后，表面 recall 和真正关联推理并不是一回事
LONGMEM 这一类工作则说明，长期上下文能力往往需要外部记忆架构配合，而不是单靠一次性把所有 token 塞进窗口。
所以，从 Agent 视角看，上下文能力至少要拆成三层：
- 容量：最多能装多少
- 检索：能否在长序列里找到关键证据
- 管理：系统能否压缩、遗忘、回注高信号状态
第四层，是系统指标。
到了这里，模型问题就不再只是“对不对”，而是“在什么代价和速度下对”。
OpenAI 的模型文档、延迟优化指南，Anthropic 的模型总览和 prompt caching，NVIDIA 的 benchmarking 指标，vLLM 的 PagedAttention，Orca 的调度设计，都在说明：
- 模型选择不是单点问题
- serving stack 会改变可用性
- 缓存策略会改变成本
- 调度策略会改变吞吐
- 输入长度、输出长度、请求次数、并发量都会改变延迟
这意味着，对 Agent 来说，“模型能力”其实还包括一整层系统能力：
- 首 token 等待时间
- 持续输出速度
- P95/P99 尾延迟
- 总吞吐
- 单任务成本
- 并发退化情况
因此，选型对象不只是 foundation model，还包括承载它的服务模式。
这一点在 Agent 场景里尤为重要。 因为 Agent 天生就是：
- 多轮
- 多步
- 重复上下文
- 常常并行
- 经常调用工具
所以它对缓存、批处理、调度和上下文复用特别敏感。
第五层，是任务世界差异。
不是所有 Agent 都活在同一个输入输出世界里。
实时语音世界需要：
- 低延迟
- 全双工
- 可打断
- 韵律与非言语信号保留
多模态屏幕与文档世界需要：
- 图文联合理解
- UI/视觉定位
- 跨模态对齐
跨语种沟通世界需要：
- 多语言覆盖
- 噪声鲁棒性
- 跨模态翻译
物理执行世界则需要：
- 时空理解
- 感知到动作的映射
- 轨迹与安全约束
GPT-4o、Moshi、Qwen2.5-Omni、SEAMLESSM4T、Gemini Robotics 这些资料都在说明：
不同任务世界需要的不是“同一个更强模型”，
而是不同能力结构。这句话非常关键。 因为它意味着模型层的真正问题不是“选最大”，而是“选对能力组合”。
第六层，是风险敏感性与稳定性。
很多团队在这里会停留在“准确率够不够”。 但高风险 Agent 根本不只关心准确率。
它还关心：
- 模型是否校准
- 是否知道自己不知道
- 是否在不确定时会收敛
- 是否容易给出有说服力但错误的答案
- 是否有成熟的系统卡、安全评估、红队与缓解资料
Language Models (Mostly) Know What They Know、GPT-4 system card、Anthropic 的 Responsible Scaling Policy、Med-PaLM 2 和医疗概率预测研究，都在说明：
高风险场景下，模型能力还包括保守性、可校准性、可约束性和可审计性。换句话说，更强不等于更适合。 有时候，真正更适合高风险 Agent 的模型，不是上限最高的模型，而是：
- 更稳定
- 更可预测
- 更会表达不确定性
- 更容易被系统护栏约束
因此，本章真正想给出的模型视角，可以压缩成一个非常实用的公式：
Agent 模型选择 = 任务能力匹配
+ 上下文能力匹配
+ 系统指标匹配
+ 模态匹配
+ 风险轮廓匹配只要少掉其中任意一项，系统都可能在另一侧失衡。
最后，本章给出一个很实用的检查清单。
看一个 Agent 要不要换模型，不要先问“有没有更强模型”，而是先问：
第一，它到底缺的是推理、工具、结构化输出、长上下文，还是多模态。
第二，它到底卡在正确率、延迟、吞吐、成本，还是尾部稳定性。
第三，它的任务世界到底是文本世界、语音世界、图像世界，还是物理动作世界。
第四，它的风险边界到底要求模型更聪明，还是要求模型更保守、更可校准。
第五，问题到底出在模型本身，还是上下文管理、缓存、调度、编排和评测系统。
如果这五个问题回答不清，换模型往往只是昂贵的心理安慰。 如果这五个问题回答得很清楚，那么即便不追求“最强模型”，系统也更有可能找到真正适合自己的底座。