【大模型专题】大模型怎么选（2026 年 10 月版）：从 20 个模型里挑对那 3 个，以及 Agent 按角色分模型的实操矩阵

[大模型怎么选（2026 年 10 月版）：从 20 个模型里挑对那 3 个，以及 Agent 按角色分模型的实操矩阵](#大模型怎么选（2026 年 10 月版）：从 20 个模型里挑对那 3 个，以及 Agent 按角色分模型的实操矩阵)
- [前言：为什么"选模型"这件事在 2026 年彻底变了](#前言：为什么"选模型"这件事在 2026 年彻底变了)
- - 先声明一件事：下面出现的所有对照表都是示例，不是配方
- [一、先把事实基线立住：2026 年 10 月的模型版图](#一、先把事实基线立住：2026 年 10 月的模型版图)
- - [1.1 Anthropic 的 5.5 家族：分层最干净的一条产品线](#1.1 Anthropic 的 5.5 家族：分层最干净的一条产品线)
  - [1.2 三档结构已经成型，但每家的切法不同](#1.2 三档结构已经成型，但每家的切法不同)
  - [1.3 国产模型：价格结构完全不同的一套逻辑](#1.3 国产模型：价格结构完全不同的一套逻辑)
  - [1.4 关于 benchmark：跨厂比分数基本都是错的](#1.4 关于 benchmark：跨厂比分数基本都是错的)
  - [1.5 同一个"1M 上下文"，三家的计价方式完全相反](#1.5 同一个"1M 上下文"，三家的计价方式完全相反)
  - [1.6 2026 年新增的一个选型维度：价格日历](#1.6 2026 年新增的一个选型维度：价格日历)
- [二、选型的五个维度（不是 benchmark，也不是价格）](#二、选型的五个维度（不是 benchmark，也不是价格）)
- - [2.1 维度一：失败成本（这是第一优先级）](#2.1 维度一：失败成本（这是第一优先级）)
  - [2.2 维度二：上下文规模，以及你能否缓存它](#2.2 维度二：上下文规模，以及你能否缓存它)
  - [2.3 维度三：turn 类型分布](#2.3 维度三：turn 类型分布)
  - [2.4 维度四：工具调用密集度](#2.4 维度四：工具调用密集度)
  - [2.5 维度五：价格结构，而不是单价](#2.5 维度五：价格结构，而不是单价)
- [三、Agent 的模型选型：按角色分，但角色不等于 agent](#三、Agent 的模型选型：按角色分，但角色不等于 agent)
- - [3.1 六种角色，三层模型](#3.1 六种角色，三层模型)
  - [3.2 反面案例：为什么"全部 subagent 都用 Opus"是错的](#3.2 反面案例：为什么"全部 subagent 都用 Opus"是错的)
  - [3.3 角色矩阵的参考实现](#3.3 角色矩阵的参考实现)
- 四、成本数学：为什么"便宜的模型"经常更贵
- - [4.1 唯一正确的度量：每个成功任务的成本](#4.1 唯一正确的度量：每个成功任务的成本)
  - [4.2 单次 subagent 运行的真实成本](#4.2 单次 subagent 运行的真实成本)
  - [4.3 缓存碎裂：中途换模型是笔糊涂账](#4.3 缓存碎裂：中途换模型是笔糊涂账)
  - [4.4 一个关键区分：换 effort 不碎缓存，换模型才碎](#4.4 一个关键区分：换 effort 不碎缓存，换模型才碎)
- [五、组合矩阵：只有 1 个模型怎么办，2 个怎么办，3 个怎么办](#五、组合矩阵：只有 1 个模型怎么办，2 个怎么办，3 个怎么办)
- - [5.1 组合矩阵总表](#5.1 组合矩阵总表)
  - [5.2 只有 1 个模型：把 effort 和上下文当成两个"虚拟模型"](#5.2 只有 1 个模型：把 effort 和上下文当成两个"虚拟模型")
  - [5.3 只有 2 个模型：一强一弱，按"要不要写"切](#5.3 只有 2 个模型：一强一弱，按"要不要写"切)
  - [5.4 只有 3 个模型：完整矩阵，但要防"配置侵蚀"](#5.4 只有 3 个模型：完整矩阵，但要防"配置侵蚀")
  - [5.5 5 个以上：从"按角色"升级到"按 turn"](#5.5 5 个以上：从"按角色"升级到"按 turn")
- 六、十个静默陷阱：配置写对了，运行时不按你写的走
- - [6.1 陷阱清单](#6.1 陷阱清单)
  - [6.1.1 新增的三条，为什么值得单列](#6.1.1 新增的三条，为什么值得单列)
  - [6.2 陷阱 1 详解：alias 是 2026 年最贵的一个字符](#6.2 陷阱 1 详解：alias 是 2026 年最贵的一个字符)
  - [6.3 陷阱 2 详解：环境变量从"最高"掉到"第三"](#6.3 陷阱 2 详解：环境变量从"最高"掉到"第三")
  - [6.4 陷阱 3 详解：一行 shell 配置毁掉整个分层](#6.4 陷阱 3 详解：一行 shell 配置毁掉整个分层)
  - [6.5 陷阱 4 详解：最常跑的 subagent 从不降级](#6.5 陷阱 4 详解：最常跑的 subagent 从不降级)
  - [6.6 陷阱 5 详解：tokenizer 变了，你的预算全错](#6.6 陷阱 5 详解：tokenizer 变了，你的预算全错)
  - [6.7 陷阱 7 详解：级联的经济性有前置条件](#6.7 陷阱 7 详解：级联的经济性有前置条件)
  - [6.8 不用 Claude Code 的话，这十条还剩几条](#6.8 不用 Claude Code 的话，这十条还剩几条)
- 七、什么时候不该做路由（省下的钱可能不如你搭的成本）
- 八、一周落地路线
- 九、总结：三句话
- 参考资料

大模型怎么选（2026 年 10 月版）：从 20 个模型里挑对那 3 个，以及 Agent 按角色分模型的实操矩阵

一句话结论先放这儿：2026 年选模型，已经不是在榜单上找一个第一名，而是在设计一层阶梯。 你要回答的不是"哪个模型最强"，而是"我这个系统里，哪几类活该交给哪一档模型，边界在哪，越界了怎么办"。

前言：为什么"选模型"这件事在 2026 年彻底变了

去年这个时候，同行问我"模型怎么选"，标准答案是去看 LMArena 排名，然后选前两名里便宜的那个。这个答案在 2026 年已经失效了，原因不是榜单不准，而是市场结构变了。

四件事同时发生：

第一，价格分层取代了价格战。 2024 到 2025 年是一路降价，2025 年 9 月 DeepSeek V3.2-Exp 那次约 80% 的永久性降价是低点。到 2026 年，方向反过来了：旗舰在涨，小模型在跌。Kimi K3 的输出价从上一代拉到了 100 元/百万 token，涨了三倍多；DeepSeek V4 系列引入了峰谷计价，高峰时段输出价 27 元，非高峰 13.5 元，差一倍；智谱一年内三次提价。同一时间，OpenAI 在 7 月 30 日把 Luna 砍了 80%，把预算档做到了输入 0.10 美元。

中国信通院那份《大模型词元服务性能监测报告（2026 年）》里有个数字很说明问题：国内词元归一化均价从 2025 年下半年的 6.8 元涨到 13.46 元，涨了近一倍，但同期日均消耗量从 2025 年 12 月到 2026 年 6 月涨了近 4 倍。量价齐升。这意味着"等降价"这个策略已经死了，你不能靠等，只能靠分层。

第二，1M 上下文变成标配，但"能吃下"和"能理解"是两件事。 现在 Anthropic 的 5.5 全系、OpenAI 的 GPT-6 全系、Gemini 4 Argon、DeepSeek V4-Pro、Kimi K3 都是百万级窗口。窗口大到一定程度之后，它不再是选型依据------因为大家都有。真正的差异变成了：给定 80 万 token 的仓库，它能不能准确地定位到跨文件的那三处依赖。更隐蔽的差异是同一个 1M 窗口，三家的计价方式完全相反（见 1.5 节），这一条比能力差异更容易吃掉你的预算。

第三，thinking 和 effort 变成了独立旋钮。 这件事被严重低估。同一个模型，effort 设成 low 和 high，在长 agent prompt 上的行为差异可能比换一个模型还大。Anthropic 的文档里有一句警告说得很直白：在长 agent prompt 下，低 effort 的模型"更容易跳过搜索、提前停止、跳过检查"。所以"选模型"这件事，实际上已经裂成了两个决策：选哪一档模型 ，和给这一档模型多大思考预算。

第四，也是本文写作过程中被现实打脸的一条：整个前沿在两个月内换了一代。 我最初的稿子用的是 GPT-5.6 那一代的价格表，写完之后发现 OpenAI 已经在 9 月 3 日发了 GPT-6 Astra、9 月 22 日发了 GPT-6 Sol 和 Luna、9 月 29 日发了 GPT-6.1 Sol、10 月 26 日又发了 GPT-6.1 Terra；Anthropic 在 9 月 1 日到 10 月 7 日之间把 5.5 全系发齐；Google 在 10 月 14 日 GA 了 Gemini 4 Argon。

这件事本身就是全文最重要的前提：任何一张价格表的保质期大约 60 天。 所以你在这篇文章里真正该拿走的不是那几行数字，是判断方法------数字用来建立量级感，方法用来在下一代表格出现时重新算一遍。我下面所有涉及价格的地方都会标注核对日期，你可以对照着看哪些已经该重算了。

先声明一件事：下面出现的所有对照表都是示例，不是配方

我后面会给出一张"orchestrator 用 A、implementer 用 B、reviewer 用 C"的矩阵。那张表的表头是角色，不是工具名；你该拿走的是判断依据，不是那几行单元格。

原因很简单：你的 agent 拓扑和我看到的那套大概率不一样。一个跑在 CI 里的三分钟分诊任务，和一个跑在 Argo 上、能自主折腾两小时的编排 DAG，对"该用哪档模型"的答案可以完全相反。所以我每一节都会给足按什么原则选 ，并且在第五章专门给组合矩阵------只有 1 个模型怎么排、2 个怎么排、3 个怎么排、5 个以上怎么排。你对号入座，别照抄。

还有一个上位概念值得先说清楚，因为它能解释后面所有细节：

用户问的"什么 agent 适合什么模型"，表面是"角色 → 模型"的映射问题，本质是「模型是 agent 的运行时资源，不是 agent 的属性」。

这两句话的差别，决定了你的架构长什么样。如果把模型当 agent 的属性，你会写 agent.model = "xxx"，一次性绑定，改一次要动代码。如果把模型当运行时资源，你会写"这个 turn 属于哪一类，就给它哪一档"，模型可以在同一个 agent 的不同 turn 之间变化，也可以在同一 turn 的不同重试次数上变化。后一种是 2026 年唯一能扛住价格波动的写法。

一、先把事实基线立住：2026 年 10 月的模型版图

写选型文章最容易犯的错，是拿一张过期的榜单一顿分析。所以这一节我只做一件事：把当前各家真实的价格和能力摊开，让你看清楚分层的形状。

数据口径说明：Anthropic 部分来自官方定价页与模型文档（2026 年 10 月核对）；国产部分综合各家官方定价与公开白皮书（2026 年 9-10 月）；benchmark 引自第三方横评（数据快照 2026 年 9 月）。价格单位统一为"每百万 token 的输入 / 输出"，未特别说明则为美元。

1.1 Anthropic 的 5.5 家族：分层最干净的一条产品线

Anthropic 在 9 月 1 日到 10 月 7 日之间把 5.5 家族发齐了（Fable 5.1 → Opus 5.5 → Sonnet 5.5 → Haiku 5.5），这条线是当前最适合拿来讲"分层"的样本，因为四档之间差得很规整，而且每一档的缓存价在这一轮都被大幅下调。

价格核对日期：2026-10-01 至 2026-10-26 之间的官方定价页。

模型	输入 / 输出	缓存读取	上下文 / 最大输出	默认 effort	定位
Claude Fable 5.1	10 / 50	0.25（2.5%）	1M / 128K	high	天花板，只在"想不出来就完了"时用
Claude Mythos 5.1	10 / 50	0.25	1M / 128K	high	与 Fable 5.1 同权重，护栏更松，需资质审核
Claude Opus 5.5	4 / 20	0.20（5%）	1M / 128K	medium	官方推荐的起手模型
Claude Sonnet 5.5	2 / 10	0.10（5%）	1M / 128K	high（API）/ medium（CC）	干活主力，性价比点
Claude Haiku 5.5	0.10 / 0.50（≤100k） 0.50 / 2.50（>100k）	0.01（>100k 时 0.05）	1M / 128K	medium	分诊、检索、摘要
Claude Opus 5（上一代）	5 / 25	0.50	1M / 128K	---	比 Opus 5.5 更贵，没有理由再用

四个容易被忽略的细节，每一个都会影响你的账单：

一、缓存读取价这一年被砍了三刀，这不是巧合。 Fable 5 的缓存读取是 1.00，Fable 5.1 是 0.25，砍 75%；Opus 5 是 0.50，Opus 5.5 是 0.20，砍 60%；Sonnet 5.5 在 10 月 7 日从 0.20 砍到 0.10，砍 50%。三家厂商同时在做同一件事，说明它们都看清了一个事实：agent 负载的主要 token 消耗是反复重读同一段上下文，不是生成。 所以"缓存价"这个数字对 agent 场景的权重，远远大于标价。

二、Anthropic 从 4.6 代起取消了长上下文加价。 1M 窗口全程按标准价计，一个 90 万 token 的请求和一个 9 千 token 的请求，每 token 同价。这一条和 OpenAI 的 272K 断点、Google 的 200K 断点形成了鲜明对比，1.5 节专门讲。

三、Opus 5.5 的 thinking 关不掉，而且拒收 forced tool use。 想省钱只能降 effort（/effort low）。另外，Opus 5 时代支持的"强制工具调用"和"high 以下关闭 thinking"两种请求形态，Opus 5.5 都不接受------从 Opus 5 迁过来必须改代码，这是个容易漏的迁移坑。

四、官方推荐的起手模型已经不再是"最贵那个"。 Anthropic 的模型概览现在写的是：大多数工作负载从 Opus 5.5 开始，Fable 5.1 留给高强度推理和长周期 agent。这是一个信号------厂商自己都在反对"默认用最强"。

顺带一个很有说服力的反例，来自 Anthropic 自己的 CursorBench 数据：

配置	得分	每任务成本
Fable 5.1，max effort	51.8%	17.28 美元
Opus 5.5，high effort	56.0%	约 4 美元
Opus 5.5，medium effort	52.5%	约 3 美元

贵五倍的模型，分数还低了 4.2 个百分点。这不是个例，是"effort 匹配度"比"模型档位"更重要的直接证据------你拿 Fable 的 max effort 去打 Opus 的 high effort，本身就不是同一个比较。 对比不同模型时先把 effort 对齐，否则你测的是配置差异，不是模型差异。

1.2 三档结构已经成型，但每家的切法不同

把各家当前产品线并排放，你会看到同一个三层结构，只是切的位置和命名不一样：
#mermaid-svg-p9R4siz4yTHHT6Gh{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-p9R4siz4yTHHT6Gh .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-p9R4siz4yTHHT6Gh .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-p9R4siz4yTHHT6Gh .error-icon{fill:#552222;}#mermaid-svg-p9R4siz4yTHHT6Gh .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-p9R4siz4yTHHT6Gh .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-p9R4siz4yTHHT6Gh .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-p9R4siz4yTHHT6Gh .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-p9R4siz4yTHHT6Gh .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-p9R4siz4yTHHT6Gh .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-p9R4siz4yTHHT6Gh .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-p9R4siz4yTHHT6Gh .marker{fill:#333333;stroke:#333333;}#mermaid-svg-p9R4siz4yTHHT6Gh .marker.cross{stroke:#333333;}#mermaid-svg-p9R4siz4yTHHT6Gh svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-p9R4siz4yTHHT6Gh p{margin:0;}#mermaid-svg-p9R4siz4yTHHT6Gh .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-p9R4siz4yTHHT6Gh .cluster-label text{fill:#333;}#mermaid-svg-p9R4siz4yTHHT6Gh .cluster-label span{color:#333;}#mermaid-svg-p9R4siz4yTHHT6Gh .cluster-label span p{background-color:transparent;}#mermaid-svg-p9R4siz4yTHHT6Gh .label text,#mermaid-svg-p9R4siz4yTHHT6Gh span{fill:#333;color:#333;}#mermaid-svg-p9R4siz4yTHHT6Gh .node rect,#mermaid-svg-p9R4siz4yTHHT6Gh .node circle,#mermaid-svg-p9R4siz4yTHHT6Gh .node ellipse,#mermaid-svg-p9R4siz4yTHHT6Gh .node polygon,#mermaid-svg-p9R4siz4yTHHT6Gh .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-p9R4siz4yTHHT6Gh .rough-node .label text,#mermaid-svg-p9R4siz4yTHHT6Gh .node .label text,#mermaid-svg-p9R4siz4yTHHT6Gh .image-shape .label,#mermaid-svg-p9R4siz4yTHHT6Gh .icon-shape .label{text-anchor:middle;}#mermaid-svg-p9R4siz4yTHHT6Gh .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-p9R4siz4yTHHT6Gh .rough-node .label,#mermaid-svg-p9R4siz4yTHHT6Gh .node .label,#mermaid-svg-p9R4siz4yTHHT6Gh .image-shape .label,#mermaid-svg-p9R4siz4yTHHT6Gh .icon-shape .label{text-align:center;}#mermaid-svg-p9R4siz4yTHHT6Gh .node.clickable{cursor:pointer;}#mermaid-svg-p9R4siz4yTHHT6Gh .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-p9R4siz4yTHHT6Gh .arrowheadPath{fill:#333333;}#mermaid-svg-p9R4siz4yTHHT6Gh .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-p9R4siz4yTHHT6Gh .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-p9R4siz4yTHHT6Gh .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-p9R4siz4yTHHT6Gh .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-p9R4siz4yTHHT6Gh .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-p9R4siz4yTHHT6Gh .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-p9R4siz4yTHHT6Gh .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-p9R4siz4yTHHT6Gh .cluster text{fill:#333;}#mermaid-svg-p9R4siz4yTHHT6Gh .cluster span{color:#333;}#mermaid-svg-p9R4siz4yTHHT6Gh div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-p9R4siz4yTHHT6Gh .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-p9R4siz4yTHHT6Gh rect.text{fill:none;stroke-width:0;}#mermaid-svg-p9R4siz4yTHHT6Gh .icon-shape,#mermaid-svg-p9R4siz4yTHHT6Gh .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-p9R4siz4yTHHT6Gh .icon-shape p,#mermaid-svg-p9R4siz4yTHHT6Gh .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-p9R4siz4yTHHT6Gh .icon-shape .label rect,#mermaid-svg-p9R4siz4yTHHT6Gh .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-p9R4siz4yTHHT6Gh .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-p9R4siz4yTHHT6Gh .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-p9R4siz4yTHHT6Gh :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 验证失败才升级
卡住了才升级
第三档：分诊（读、找、分类、摘要）
Haiku 5.5

0.10 / 0.50
GPT-6 Luna

0.10 / 0.50
Gemini 3.8 Flash

0.75 / 3.75

（促销价）
第二档：主力（写代码、跑工具、做评审）
Sonnet 5.5

2 / 10
GPT-6.1 Sol

2 / 10
GPT-6.1 Terra

1 / 5
第一档：天花板（决策密集、失败代价高）
Fable 5.1

10 / 50
GPT-6 Astra

10 / 50
Opus 5.5

4 / 20
Gemini 4 Argon

4 / 20

（促销 2 / 10）

注意这张图的方向：箭头是升级方向，不是调用方向。调用方向和它相反------默认从第三档起步，只有遇到它搞不定的东西才往上走。这个反转是 2026 年成本控制的核心，第四章会算给你看。

这张图里最值得琢磨的不是能力分布，是第二档的塌陷：

八月的时候，GPT-5.6 Sol 和 Claude Opus 5 都在 4-5 美元输入这个位置，那是当时的"能干活的档"。到十月，GPT-6.1 Sol 和 Claude Sonnet 5.5 都是 2 / 10，GPT-6.1 Terra 甚至做到了 1 / 5，而它们的能力已经能覆盖八月需要 5 / 25 模型才能干的活。两个月里，主力档的价格掉了一半，能力还涨了。

这条对选型的含义很直接：如果你的架构是"默认用旗舰"，你正在为一个已经不值这个价的位置付钱。 现在第一档和第三档之间留出了巨大的空洞，而大部分生产负载落在这个空洞里------它们既不需要第一档，也扛不住第三档，第二档才是它们真正的家。

三档之间的价格倍差也因此被拉大了：Haiku 5.5 对 Sonnet 5.5 是 20 倍，Terra 对 Astra 是 10 倍。只要你的流量分布里第三档能吃掉 60% 以上，整体成本就能降一个数量级。 而第三档能不能吃掉 60%，取决于你的任务切分做得细不细，不取决于模型。

1.3 国产模型：价格结构完全不同的一套逻辑

国产这一档不能直接套美元价格表看，因为计价方式不一样。DeepSeek 有峰谷、Kimi 有缓存命中价、Qwen 有阶梯、MiniMax 有永久折扣，直接比单价会得出错误结论。

模型	输入（元/百万 token）	输出（元/百万 token）	上下文	价格结构特点
DeepSeek V4-Pro	4.5（非高峰）/ 9（高峰）	13.5 / 27	1M	峰谷计价，缓存命中 0.025-0.15 元
DeepSeek V4.1-Flash	1（空闲）/ 2（高峰）	4 / 8	1M	9 月 10 日发布，性价比极值，周末全天按空闲价
Kimi K3	20（未命中）/ 2（命中）	100	1M	缓存命中价差 10 倍，长上下文专用
GLM-5.3	8	28	1M	中文场景优化
Qwen3.7-Max	12（现价 6，五折）	36（现价 18）	1M	限时折扣，Batch 再五折
MiniMax M3	2.1	8.4	---	永久五折，≤512K 一档
豆包 Seed 1.6 Flash	0.075	0.75	---	商用里价格地板级
MiMo V2.5	0.08（美元）	0.24（美元）	128K	绝对价格最低

三个判断：

第一，DeepSeek 的峰谷计价是一件有架构含义的事。 高峰时段（周一至周五 9:00-12:00、14:00-18:00）价格翻倍。这意味着如果你的批量任务可以调度，把它挪到夜间或周末，同样的模型直接省一半。这不是"选模型"，这是"选调度策略"，但它对成本的影响大于换模型。2026 年 6 月国内 token 日均消耗到了 500 万亿级别，能错峰的团队拿到的价格优势是实打实的。

第二，Kimi K3 是典型的"长上下文专用价"。 缓存命中 2 元、未命中 20 元，10 倍差。你要做整仓分析，必须让 prompt 前缀字节级稳定，否则每次都是 20 元。这也解释了为什么"缓存卫生"在 2026 年比"选模型"更值钱------第五章会具体讲。

第三，DeepSeek 的市场份额已经一超多弱。 2026 年 API 市场份额 86.8%，日均输出词元 3.05 万亿，是其余所有厂商之和的 6.6 倍。这个事实的实践含义是：如果你要接国产模型做默认档，DeepSeek 的兼容性和社区踩坑记录是最全的，出问题的概率最低。选型不只是选能力，也是选"出问题时百度得到答案"。

1.4 关于 benchmark：跨厂比分数基本都是错的

先给一张当前能拿到的新一代数据，然后我要说一个不太讨喜的结论。

评测	模型	分数	可比性
Terminal-Bench 4.0（同一 harness）	GPT-5.6 Terra，max effort	21.5%	同 harness 可比
Terminal-Bench 4.0（同一 harness）	GPT-6.1 Terra，max effort	50.3%	同上，代际跃迁 28.8 个点
Terminal-Bench 4.0（同页公布）	Claude Haiku 5.5	39.2%	同 harness 可比
Terminal-Bench 4.0（同页公布）	Claude Sonnet 5.5	70.6%	同上，跨档差 31.4 个点
AA Coding Agent Index v2.0	GPT-6 Luna	31	同评测方可比
AA Coding Agent Index v2.0	GPT-6.1 Terra	48	同上
AA Coding Agent Index v2.0	GPT-6.1 Sol	54	同上
AA Intelligence Index v4.2	Gemini 4 Argon，high	53	同评测方可比
AA Intelligence Index v4.2	Claude Sonnet 5.5	56	同上
AA Intelligence Index v4.2	Claude Opus 5.5	58	同上

这张表最该注意的是它内部的矛盾：Sonnet 5.5 在某个公布的 Terminal-Bench 4.0 上是 70.6%，而 Opus 5.5 在另一个口径下比 GPT-6.1 Terra（50.3%）只高 3.2 个百分点。同代里更贵的模型，分数反而更低？

答案是：这两个数字不在同一个 harness、同一个 effort、同一个子集下，它们根本不能比。 Terminal-Bench 有多个版本和子集，effort 从 medium 到 max 差出一大截，重试策略各家不同。

由此得出本文对 benchmark 的态度，只有三条：

一、只在同一评测方、同一 harness、同一 effort 下比较。 跨厂横向比"最高分"是最常见的错误，因为没人保证两家的分数是同一套配置跑出来的。就连 Anthropic 和 OpenAI 自己公布的数字，也常常因为 effort 默认值不同（Fable 默认 high，Opus 默认 medium）而不可比------对比不同模型前先把 effort 对齐。

二、看代际跃迁，不看绝对排名。 GPT-5.6 Terra 到 GPT-6.1 Terra 的 21.5% → 50.3% 是一个可信的信号：同一个 harness 下涨 28.8 个点，说明端到端的自主执行能力确实换代了。这种"同模型同 harness 的时间序列"比任何横向排名都有信息量。

三、看趋势不看点位。 第三方横评（2026 年 9 月快照，20 个模型）里那批 4.x 代数据是：Opus 4.6 的 SWE-bench 78.7% / Terminal-Bench 56.8%，GPT-5.4 Pro 77.8% / 52.4%，Gemini 3.1 Pro 75.6% / 47.8%，DeepSeek V3.2 72.6%。这批数字现在都过期了，但它揭示的结构没变：头部两三分之内的分差是噪声 （harness 选择、重试策略、prompt 格式都能造成这个量级的差异），而 Aider Polyglot 高的模型擅长改已有文件、Terminal-Bench 高的模型能被信任去跑自己的构建测试循环。

最后这一条才是 benchmark 对 agent 选型的真正用途：不是挑第一名，是判断"这个模型能不能自己把活干完"。

1.5 同一个"1M 上下文"，三家的计价方式完全相反

这一节是我在核对数据时发现的最大盲点，也是本文最想让你记住的一节。

三家都宣传"1M 上下文"，但超出某个阈值之后怎么收钱，完全是三套逻辑：

厂商	长上下文策略	断点	超过断点后的计价
Anthropic（4.6 代起）	全程同价，无加价	无	90 万 token 和 9 千 token 每 token 同价
OpenAI（GPT-6 系）	阶梯加价	272K 输入	输入和缓存翻倍、输出 1.5 倍，且整个请求按高档计
Google（Pro 档）	阶梯加价	200K 输入	3.1 Pro 从 2/12 变 4/18；4 Argon 目前平价但促销到期会变

具体到 GPT-6.1 Terra 的 272K 规则，细节值得单独敲一遍：

上下文窗口 1,050,000 token，但输入上限是 922,000（输出 128,000）
一旦 prompt 超过 272K 输入 token，输入价从 1 变 2、缓存读取从 0.05 变 0.10、输出从 5 变 7.5
加价作用于整个请求，不是只算超出部分
缓存不豁免

这意味着什么？假设你有一个 30 万 token 的仓库分析任务：

在 GPT-6.1 Terra 上，整个请求按 2 / 7.5 计，比标价贵一倍
在 Claude Sonnet 5.5 上，还是 2 / 10，一分不加
在 Claude Opus 5.5 上，还是 4 / 20，一分不加

所以一个反直觉的结论：做长上下文工作流时，贵的那家可能更便宜。 你以为 Sonnet 5.5 的 2 / 10 比 Terra 的 1 / 5 贵一倍，但一旦你的 prompt 常态超过 272K，Terra 实际是 2 / 7.5，两边几乎打平，而 Sonnet 的上下文利用质量更好。

这就是我在 2.5 节要说"价格结构比单价重要"的原因。也是为什么我在开头提醒："1M 上下文"这五个字里没有信息，信息在断点位置和断点后的算法里。

1.6 2026 年新增的一个选型维度：价格日历

这一条以前不存在，现在必须有。

因为 2026 年大量的低价是促销价，有明确到期日：

项目	现价	变更	生效日
Gemini 3.8 Flash	0.75 / 3.75（促销）	回到 1.50 / 7.50，翻倍	2027-01-01
Gemini 4 Argon	2 / 10（促销）	变 4 / 20，正好等于 Opus 5.5	2026-12-01
GPT-5.6 Sol	4 / 20（促销）	促销至少到 2026-11-21	待定
Claude Sonnet 4.5	---	退役	2026-11-30
Claude Haiku 4.5	1 / 5	退役（Haiku 5.5 已替代）	2026-10 后
OpenAI Assistants API	---	关停	已关（2026-08-26）
OpenAI TTS / Whisper / GPT-5.1 系	---	陆续退役	2027-01 至 2027-04

两个推论：

第一，做预算时必须用"促销后价格"做压力测试。 你现在按 Gemini 4 Argon 的 2 / 10 做的成本模型，12 月 1 日会翻倍。如果你的方案在这个价格下不成立，那它不是方案，是窗口期套利。

第二，退役日历比价格表更容易造成事故。 Sonnet 4.5 在 11 月 30 日退役，Haiku 4.5 已经进入退役通道。硬编码了旧 model ID 的系统会在某天直接报错------不是降级，是报错。这件事在第六章的陷阱清单里有对应条目，检测成本很低，漏掉的代价很高。

二、选型的五个维度（不是 benchmark，也不是价格）

我见过太多团队在选型会上吵 benchmark 分数，最后按价格拍板，上线两周后被 agent 的返工率打回来。真实有用的判断维度是下面五个，顺序也是优先级。

2.1 维度一：失败成本（这是第一优先级）

一句话：这个环节出错时，你要付多少代价？

不是"这个任务难不难"，是"错了会怎样"。这两件事在小模型上经常背离------一个任务很简单但错了很致命，就不该给便宜模型。

具体分三档：

无人复核的写入路径 → 只能上第二档以上。 一个 subagent 直接改代码、直接发消息、直接写数据库，且上面没有 reviewer，把它放在 Haiku 上是拿 Terminal-Bench 39.2% 的能力去赌。这是我最常见的错误配置。
有确定性校验的路径 → 可以下探到第三档。 如果后面紧跟一次 pytest、一次 tsc --noEmit、一次 schema 校验，那便宜模型跑错就被拦住了，损失只是多一次重试。
输出直接给人看、人一定会读 → 第三档没问题。 人本身就是校验器。

这一条的价值在于它会把"角色"和"模型"解耦。同样是"改代码"这个角色，跑在 CI 里带测试门的，和跑在本地没有测试的，该配不同模型。角色不是唯一变量，"有没有门"才是。

2.2 维度二：上下文规模，以及你能否缓存它

1M 窗口普及之后，真正稀缺的不是窗口大小，是缓存命中率。

这里有个 2026 年必须知道的定价陷阱，我拿它当典型案例讲：Haiku 5.5 的价格是按单次请求的 prompt 长度分档的，100k 是条硬线。

prompt ≤100k：0.10 / 0.50
prompt >100,001：整个请求所有 token 按 0.50 / 2.50 计，涨 5 倍
判定时包含 cache read 和 cache write------缓存救不了你
逐请求判定，不按会话平均

为什么 subagent 特别容易越线？因为它启动时就带着 system prompt、工具定义、CLAUDE.md，然后每读一个文件都在累加。一个 explorer 打开十五个中等大小的文件，还没开始回答就已经过了 100k。

实际算一下：平均 prompt 20 个请求 × 60k token，Haiku 5.5 成本约 0.04 美元；同样跑 150k，成本变 0.28 美元。对 Sonnet 5.5 的优势从 17 倍坍缩到 3 倍。模型没换，只是跨过了价格线。 这时候你不如直接买 Sonnet，换更强的模型。

这件事的上位含义是：上下文管理和选型是同一个决策的两个面。 你不能先选模型再想上下文，因为模型的定价结构决定你的上下文策略。第一章说的"Cognition 的 Devin Fusion 大约省 35%"、"社区实测 Claude Code Explore 模式降本 2 到 2.5 倍"，靠的都不是换模型，是让便宜的模型处理长度可控的上下文。

2.3 维度三：turn 类型分布

一个 agent 的每一轮，行为类型是不一样的。粗略可以分四类，它们的模型需求差很远：

turn 类型	典型占比	特征	建议档位
规划 / 拆解	5-10%	输出短，但决定后面全部工作的方向	第一档，高 effort
写 diff / 改文件	20-35%	输出长，要求精确，错误代价高	第二档
读文件 / 跑测试 / 检索	50-60%	输出结构化，量大，可校验	第三档
摘要 / 分诊 / 格式化	5-10%	机械转换	第三档，低 effort

有个公开案例把这套分布吃得很透：某 coding agent 把 turn 分成 plan-time 10%、write-diff 30%、execute-test/read-file 55%、format-summary 5%，对应到四档模型加不同 effort，单任务成本从 2.40 美元降到 0.31 美元，验收基准上质量持平。

关键是那个"持平"。 降本 87% 而质量不掉，不是因为便宜模型聪明，是因为它只被允许做它擅长的那 55%。你要是让它做规划，一样崩。

所以选型前必须先量化你的 turn 分布。如果读操作占比不到 30%，你做三层路由的收益会被配置成本吃掉------这一点第八章会展开。

2.4 维度四：工具调用密集度

这条经常被漏掉，但对 agent 是决定性的。

一个模型解 80 个 benchmark 题的能力，和一个模型在 40 轮工具调用里不跑偏的能力，不是同一回事。Kimi K2 Thinking 是个好例子：SWE-bench 只有 66.8%，但 LiveCodeBench 做到了 84.2%。这种"单题强、端到端弱"的画像，说明它适合"你给它一道封闭题"，不适合"你让它自己找题"。

反向的例子是 GPT 系：很多人抱怨它在某些榜上不是第一，但工具生态和 function calling 的稳定性让它成了工具密集场景的默认选择。第三方横评里有一句判断我觉得很准：如果工作流是 tool-heavy，优先考虑 Sol 系；如果是长时间自主跑、要减少资深工程师盯梢，优先考虑 Opus 系。

判断方法：看你的 agent 平均每任务多少次工具调用。 低于 5 次，工具密集度不构成约束；高于 20 次，把 Terminal-Bench 或者类似的端到端指标当成硬门槛，别只看 SWE-bench。

2.5 维度五：价格结构，而不是单价

这一条是 2026 年新增的，因为价格结构变复杂了。同一个模型，五种计价机制能差出三倍：

峰谷价：DeepSeek V4 系列，高峰翻倍，周末全天按空闲价
阶梯价 ：OpenAI 的 272K 断点、Google 的 200K 断点。注意 OpenAI 是整个请求按高档计，不是只算超出部分
缓存差：Kimi K3 命中 2 元 vs 未命中 20 元；Claude 系缓存读取已低到输入价的 2.5%-5%
门槛价：Haiku 5.5 的 100k 线，跨过去整个请求涨 5 倍
促销到期：Gemini 3.8 Flash 元旦翻倍、Gemini 4 Argon 12 月 1 日翻倍

在换算成"我要花多少钱"之前，必须先回答五个问题：我的请求会不会跨峰谷？会不会跨阶梯断点？前缀稳不稳定、能不能缓存？会不会跨门槛？我依赖的价格是不是有到期日？这五问里有任何一个是"会"，单价表就没意义。

举个具体的对照，说明为什么"单价低"经常等于"实际贵"：

场景	GPT-6.1 Terra	Claude Sonnet 5.5	谁更便宜
常态 prompt 60K	1 / 5	2 / 10	Terra，便宜一半
常态 prompt 300K（超 272K 断点）	2 / 7.5（整个请求）	2 / 10	几乎打平
缓存命中率 90% 的 agent 循环	缓存 0.05	缓存 0.10	Terra 仍便宜，但差距收窄
12 月 1 日后的同级对比	不变	不变	取决于 Gemini 4 Argon 是否还在选项里

所以正确的问法不是"哪个便宜"，而是"我在哪个区间、能不能缓存、价格有没有到期日"。这三个问题的答案会随你的请求形态变，同一个模型在不同形态下可以是最便宜也可以是最贵。

五维汇总成一张自查表：

维度	问自己的问题	答错的后果
失败成本	这个环节错了谁兜底？	便宜模型在无人复核路径上捅娄子
上下文与缓存	单请求会不会越断点？前缀稳不稳？	跨线后价格翻倍，缓存策略白做
turn 分布	读操作占比多少？	低于 30% 时路由收益抵不上配置成本
工具密度	平均多少轮工具调用？	单题强的模型端到端跑飞
价格结构	峰谷/断点/门槛/缓存/促销哪几条会踩？	单价算对了，账单算错了

三、Agent 的模型选型：按角色分，但角色不等于 agent

现在进入用户问的核心问题。我先把结论摆出来，再解释为什么它不是一张可以照抄的表。

一个 agent 的模型，应该按"它这一轮在干什么"来分，而不是按"它是谁"来分。 角色矩阵是起点，运行时路由才是终点。

3.1 六种角色，三层模型

从大量 coding agent 的实践里能归纳出六个反复出现的角色。我把它画成矩阵，你看到的是能力需求，不是绑定关系：
#mermaid-svg-fiRrdsEVyjHAkIHf{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-fiRrdsEVyjHAkIHf .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-fiRrdsEVyjHAkIHf .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-fiRrdsEVyjHAkIHf .error-icon{fill:#552222;}#mermaid-svg-fiRrdsEVyjHAkIHf .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-fiRrdsEVyjHAkIHf .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-fiRrdsEVyjHAkIHf .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-fiRrdsEVyjHAkIHf .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-fiRrdsEVyjHAkIHf .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-fiRrdsEVyjHAkIHf .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-fiRrdsEVyjHAkIHf .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-fiRrdsEVyjHAkIHf .marker{fill:#333333;stroke:#333333;}#mermaid-svg-fiRrdsEVyjHAkIHf .marker.cross{stroke:#333333;}#mermaid-svg-fiRrdsEVyjHAkIHf svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-fiRrdsEVyjHAkIHf p{margin:0;}#mermaid-svg-fiRrdsEVyjHAkIHf .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-fiRrdsEVyjHAkIHf .cluster-label text{fill:#333;}#mermaid-svg-fiRrdsEVyjHAkIHf .cluster-label span{color:#333;}#mermaid-svg-fiRrdsEVyjHAkIHf .cluster-label span p{background-color:transparent;}#mermaid-svg-fiRrdsEVyjHAkIHf .label text,#mermaid-svg-fiRrdsEVyjHAkIHf span{fill:#333;color:#333;}#mermaid-svg-fiRrdsEVyjHAkIHf .node rect,#mermaid-svg-fiRrdsEVyjHAkIHf .node circle,#mermaid-svg-fiRrdsEVyjHAkIHf .node ellipse,#mermaid-svg-fiRrdsEVyjHAkIHf .node polygon,#mermaid-svg-fiRrdsEVyjHAkIHf .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-fiRrdsEVyjHAkIHf .rough-node .label text,#mermaid-svg-fiRrdsEVyjHAkIHf .node .label text,#mermaid-svg-fiRrdsEVyjHAkIHf .image-shape .label,#mermaid-svg-fiRrdsEVyjHAkIHf .icon-shape .label{text-anchor:middle;}#mermaid-svg-fiRrdsEVyjHAkIHf .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-fiRrdsEVyjHAkIHf .rough-node .label,#mermaid-svg-fiRrdsEVyjHAkIHf .node .label,#mermaid-svg-fiRrdsEVyjHAkIHf .image-shape .label,#mermaid-svg-fiRrdsEVyjHAkIHf .icon-shape .label{text-align:center;}#mermaid-svg-fiRrdsEVyjHAkIHf .node.clickable{cursor:pointer;}#mermaid-svg-fiRrdsEVyjHAkIHf .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-fiRrdsEVyjHAkIHf .arrowheadPath{fill:#333333;}#mermaid-svg-fiRrdsEVyjHAkIHf .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-fiRrdsEVyjHAkIHf .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-fiRrdsEVyjHAkIHf .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-fiRrdsEVyjHAkIHf .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-fiRrdsEVyjHAkIHf .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-fiRrdsEVyjHAkIHf .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-fiRrdsEVyjHAkIHf .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-fiRrdsEVyjHAkIHf .cluster text{fill:#333;}#mermaid-svg-fiRrdsEVyjHAkIHf .cluster span{color:#333;}#mermaid-svg-fiRrdsEVyjHAkIHf div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-fiRrdsEVyjHAkIHf .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-fiRrdsEVyjHAkIHf rect.text{fill:none;stroke-width:0;}#mermaid-svg-fiRrdsEVyjHAkIHf .icon-shape,#mermaid-svg-fiRrdsEVyjHAkIHf .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-fiRrdsEVyjHAkIHf .icon-shape p,#mermaid-svg-fiRrdsEVyjHAkIHf .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-fiRrdsEVyjHAkIHf .icon-shape .label rect,#mermaid-svg-fiRrdsEVyjHAkIHf .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-fiRrdsEVyjHAkIHf .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-fiRrdsEVyjHAkIHf .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-fiRrdsEVyjHAkIHf :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 计划质量决定下游上限
派活
交给
派活
派活
发现缺陷打回
Orchestrator 主会话

规划 · 分派 · 综合
Planner / Architect

出方案 · 定边界
Implementer

写 diff · 改文件
Reviewer / Verifier

审 diff · 找缺陷
Explorer

找文件 · 追调用链
Triage

读日志 · 分类 · 摘要
第一档

高 effort
第二档

medium effort
第三档

medium/low effort

六个角色的模型分配理由，逐条说清楚，因为理由比分配重要：

Orchestrator（主会话）为什么要用最强的？ 因为它是唯一读所有 subagent 输出的地方。一个 subagent 的总结再有价值，也要看读它的模型能不能理解。你把 explorer 换成便宜模型省了钱，但 orchestrator 读不懂它的结论，钱就白省了。有个说法很到位：每个 subagent 的总结，只有读它的模型那么有用。

Planner 为什么要用最强 + 最高 effort？ 计划质量决定下游一切的上限。这一步省下来的钱，会在 implementer 返工三次的时候加倍还回去。而且规划 turn 占比只有 5-10%，用最贵的模型成本增量很小------这是整个架构里性价比最高的地方。

Implementer 为什么用第二档？ 这是 Anthropic 自己给 Sonnet 5.5 的定位：agentic coding 场景，任务明确用 medium，任务更难或用 high。不是不能用第一档，是"能用第二档解决的活，用第一档是拿钱买心安"。

Reviewer 为什么和第二档同档但 effort 更高？ 因为审查者的任务是"抓住实现者漏掉的东西"。同档模型 + 更高 effort，是让它在同一个能力水平上想得更久；如果审查的是安全或并发这类高价值代码，才值得升到第一档。用便宜模型做 reviewer 是反模式------Haiku 挑不出 Sonnet 的错。

Explorer 和 Triage 为什么用第三档？ 因为它们的输出天然可校验：文件路径对不对、行号对不对、分类标签对不对，一眼能看出来。这是"便宜模型 + 确定性校验"最经典的组合。但要注意 2.2 节那个 100k 陷阱，这是 explorer 唯一会翻车的地方。

3.2 反面案例：为什么"全部 subagent 都用 Opus"是错的

这条必须单独讲，因为有相当多团队在这么做，理由是"省心"。

Anthropic 在《Optimizing for cost and intelligence》里的实测结论是：orchestrator-worker 模式只在两种情况下省钱------一是有长成本尾的例行工作，二是工作量大于单个上下文窗口。反过来，如果任务是"一条依赖链、能塞进单个上下文、没有长成本尾"，那么"只用 orchestrator 的模型、把 effort 调低"在每一个测过的案例里都更划算。

这句话的推论很锋利：如果你发现某个 subagent 反正要跑第一档模型，先别急着配模型，先问它该不该是个 subagent。 很可能主会话自己用更低 effort 干完更便宜。

还有一个数据点可以帮你打消"用最强模型当 worker"的念头：拿 Fable 5.1 做 Opus 5.5 执行者的 advisor，在内部 agentic-coding benchmark 上只高 1.7 分------官方措辞是"在 run-to-run 噪声的边缘"------但成本大约是 2.1 倍。1.7 分换 2.1 倍钱，这个交易只有在"错一次赔一条业务线"的时候才值得。

3.3 角色矩阵的参考实现

下面是三个可以抄的 subagent 定义。我刻意用完整 model ID 而不是 alias，原因在第六章会讲（alias 在不同 provider 上会解析到不同代模型，一次静默漂移价格差 10 倍）。

markdown 复制代码

---
# .claude/agents/Explore.md
# 覆盖内置 Explore，这是最常跑的 subagent，也是最容易被按 Opus 计费的地方
name: Explore
description: Read-only codebase search. Use for "where is X defined", "what calls Y", and mapping a module before edits.
tools: Read, Grep, Glob
model: claude-haiku-5-5
effort: medium
autoCompactWindow: 100000
---
Search the repository and answer with file paths and line numbers.
Quote the 3-10 lines that prove each claim. Do not summarize code you did not open.
If you could not find something, say which patterns you searched for.

markdown 复制代码

---
# .claude/agents/implementer.md
name: implementer
description: Makes a scoped code change from a written spec, runs the affected tests, and reports the diff.
tools: Read, Edit, Write, Grep, Glob, Bash
model: claude-sonnet-5-5
effort: medium
---
Implement exactly the change described. Run the tests that cover the files you touched.
Report: files changed, test command, pass/fail output, anything you were unsure about.

markdown 复制代码

---
# .claude/agents/reviewer.md
name: reviewer
description: Reviews a diff for correctness bugs before it is committed. Use after every implementer run.
tools: Read, Grep, Glob, Bash
model: claude-sonnet-5-5
effort: high
---
Review the current diff against the stated intent. Report only defects you can point to
with a file and line, plus the input that triggers them. No style comments.

三个文件的差别值得对照着看：Explore 只有三个只读工具、带 autoCompactWindow: 100000（注意写 100000，写 100k 会被解析成 100）；implementer 有写权限、effort medium；reviewer 工具集比 implementer 窄（不给 Edit/Write，防止它顺手改代码）、但 effort 提到 high。权限收窄和 effort 提升，是给同一档模型划出不同角色的两个手段------很多时候你不需要换模型，改这两个参数就够了。

四、成本数学：为什么"便宜的模型"经常更贵

这一节是全文的骨。前面所有关于分层的说法，如果没有数字支撑就是空话。

4.1 唯一正确的度量：每个成功任务的成本

单 token 单价是没有意义的。有个说法我很认同：如果一个模型 8 步解决 bug，另一个便宜模型要 25 步而且失败率更高，最终成本可能差不了多少。正确的公式是：

复制代码

Cost per Successful Task
  = (模型 token + 推理 token + 工具调用开销 + 重试) / 成功率

分母是成功率，这是关键。它会把"便宜但爱错"的模型自动惩罚掉。

把它写成代码，方便你在选型时直接套：

python 复制代码

# cost_per_task.py ------ 按"每个成功任务成本"比较模型，而不是按单价
from dataclasses import dataclass


@dataclass
class Model:
    name: str
    price_in: float          # 美元 / 百万 token
    price_out: float
    cache_read: float        # 缓存读取价，通常是输入价的 1/10 或更低
    steps_to_solve: float    # 实测平均步数
    success_rate: float      # 实测成功率，这才是分母


def cost_per_success(m: Model, ctx_tokens: int, out_tokens: int,
                     cache_hit_ratio: float = 0.85) -> float:
    """计算单个成功任务的期望成本。

    ctx_tokens 是每步输入的上下文规模，out_tokens 是每步输出规模。
    注意：每步都要重放上下文，所以输入成本是 steps 倍------这是 agent 成本的大头。
    """
    cached = ctx_tokens * cache_hit_ratio
    fresh = ctx_tokens * (1 - cache_hit_ratio)
    per_step = (
        cached * m.cache_read
        + fresh * m.price_in
        + out_tokens * m.price_out
    ) / 1_000_000 * m.steps_to_solve
    return per_step / m.success_rate


MODELS = [
    # 名字随意，数字请用自己的实测值替换
    Model("tier1-opus",  4.00, 20.0, 0.20, steps_to_solve=8,  success_rate=0.92),
    Model("tier2-sonnet", 2.00, 10.0, 0.10, steps_to_solve=11, success_rate=0.85),
    Model("tier3-haiku",  0.10,  0.50, 0.01, steps_to_solve=19, success_rate=0.61),
    Model("tier3-haiku-over100k", 0.50, 2.50, 0.05,
          steps_to_solve=19, success_rate=0.61),
]

if __name__ == "__main__":
    for m in MODELS:
        one = cost_per_success(m, ctx_tokens=60_000, out_tokens=1_500)
        print(f"{m.name:26s} 每成功任务 {one:6.3f} 美元")

跑一下你会看到很有意思的结果：当 Haiku 的成功率掉到 0.61、步数涨到 19 时，它和 Sonnet 的差距远没有单价那个 20 倍那么大。而当它的上下文跨过 100k、单价变成 5 倍时，它可能直接输给 Sonnet。这就是为什么我说"便宜的模型经常更贵"------不是修辞，是算出来的。

4.2 单次 subagent 运行的真实成本

上面是模型级比较，这里是运行级。假设一次 subagent 运行共 20 个请求，每请求平均 prompt 60k（其中 55k 命中缓存、5k 新建缓存），每请求输出 1.5k：

平均 prompt	Haiku 5.5	Sonnet 5.5	Opus 5.5	Fable 5.1
60k tokens	0.04	0.66	1.32	3.03
150k tokens	0.28	0.84	1.68	3.48

两个数字值得记：

60k 时，Haiku 比 Sonnet 便宜约 17 倍，比 Opus 便宜约 34 倍。
150k 时，Haiku 对 Sonnet 的优势坍缩到 3 倍。 模型没变，跨了价格线而已。

也就是说：让 Haiku 做 explorer，收益 100% 来自"你能不能把它的单请求压在 100k 以下"。压得住，它是 17 倍便宜；压不住，它只是 3 倍便宜，还附带能力短板。这个"压得住"就是 autoCompactWindow 加窄工具集的意义。

4.3 缓存碎裂：中途换模型是笔糊涂账

很多人以为"简单对话用便宜模型、复杂问题切回贵模型"很聪明。实际上在长会话里这是个坑。

Claude Code 的文档写得很明确：每个模型有自己的缓存。 用 /model 切过去之后，下一次请求要把整段对话历史重新读一遍，一个缓存都命中不了。

算一下：对话已经 20 万 token。

留在 Opus 5.5：下一轮这 20 万按缓存读取计，约 0.04 美元。
切到 Sonnet 5.5：这 20 万要按 Sonnet 的缓存写入价重新写一遍，约 0.50 美元。
切换这一轮多花 0.46 美元。此后每轮按输出 2k token 算，Sonnet 比 Opus 每轮省约 0.04 美元------要聊十二轮才回本。

结论很反直觉但很重要：长对话里不要来回切模型。 想用便宜模型，就在新会话开头选好；或者把便宜的活交给 subagent------subagent 有自己的上下文，不会逼主会话重读历史。这也是为什么"按角色分模型"要优于"按话题切模型"：角色隔离了上下文，话题没有。

4.4 一个关键区分：换 effort 不碎缓存，换模型才碎

上一节会让很多人得出一个悲观结论："那我只能一开始就定死一个模型，后面不能调整了。"这是错的，而且错得很关键------有一个旋钮可以在不碎缓存的前提下随时调，那就是 reasoning effort。

OpenAI 的官方指南里写得很明确：

In the API, you can change reasoning effort mid-conversation without breaking cache.

这句话的分量比它看起来大得多。它把"用 effort 做分层"这个方案，从"单模型下的次优妥协"变成了"有官方保证的最优路径"：

你要做的调整	缓存影响	被允许的时机
同一模型内改 effort	不碎缓存	任意时刻，随时可调
同一模型内改 speed / fast mode	不碎缓存	任意时刻
换模型（哪怕同厂同代）	全量冷读	只在新会话开头，或子代理内
换供应商	全量冷读 + 缓存不互通	只在报错降级时

这条把整个第五章的策略重写了一遍：

能靠 effort 解决的，就别靠换模型解决。 一个 200K 上下文的会话，中途从 medium 提到 high，成本增加的是那几轮多出来的思考 token；中途从 Sonnet 换到 Opus，第一轮就要多花 0.46 美元重建缓存。前者是增量，后者是重罚。

什么时候必须换模型？只有两种情况：

能力真的不够------effort 拉满还是不行。这时候换模型是唯一出路，代价认了。
上下文规模跨档------比如你的 prompt 常态 300K，而当前模型有 272K 断点，换个没有断点的模型是结构性省钱，不是妥协。

除此之外，绝大多数"我想让模型更聪明一点"的需求，用 effort 都能满足，而且免费附赠缓存保留。

顺带说一个实践细节：OpenAI 的 effort 档位是 none / low / medium（默认）/ high / xhigh / max 六档，比 Anthropic 的五档多一个 none。这意味着在纯格式化、纯抽取这种任务上，OpenAI 可以真的关掉思考，而 Claude 的 Opus 5.5 关不掉（只能降到 low）。如果你有大量机械转换流量，这个 none 档是有实际价值的。

同一个逻辑在工程侧的证据是 Coinbase 的案例：他们的路由系统把缓存命中率从 5% 提到 60%，在用量增长的情况下费用几乎腰斩。里面最关键的一条实践是"在一个任务内把所有调用钉在同一个模型上"，保住缓存热度。缓存亲和性和模型选择是互相制约的------你每做一次路由决策，都要问它会不会打断缓存。

五、组合矩阵：只有 1 个模型怎么办，2 个怎么办，3 个怎么办

这一章是本文最该被反复看的部分。因为第三章那张角色矩阵有个隐性前提：你有三档模型可用。 大部分团队没有。

真实情况是：预算批了一个供应商、或者公司网关只开了一个模型、或者你只是个个人开发者只订了一家的订阅。这时候"按角色分模型"这句话就变成了废话。所以下面按你手里的模型数量分档给方案，每个方案都标注收益来源------因为收益来源不同，注意事项也不同。

5.1 组合矩阵总表

手里有几个模型	推荐排法	收益来源	最大风险	关键配置
1 个（只能选一个）	选中档，靠 effort 分层	effort 差 + 上下文管理	缺天花板，硬任务卡死	用 effort/prompt 而非模型做区分
2 个（一强一弱）	强档做 orchestrator + 规划 + 审查，弱档做检索/分诊	高频只读工作降本	弱档越 100k 价格线	弱档窄工具 + autoCompactWindow
2 个（同档不同家）	主模型 + 同档备用模型做 failover	可用性，不是成本	缓存不共享，切换有成本	会话内钉住，只在报错时切
3 个（三档齐全）	完整角色矩阵：强→规划，中→执行+审查，弱→检索	角色隔离 + 分层路由	配置复杂度、模型名单漂移	每个角色独立 fallback 链
5 个以上	按 turn 运行时路由 + 级联	全链路最优	没有度量就是自嗨	必须有 per-tier 指标

下面逐个展开。

5.2 只有 1 个模型：把 effort 和上下文当成两个"虚拟模型"

如果你只能用一个模型，最重要的认知是：effort 不是模型的附属设置，它是一个独立的成本旋钮，效果接近换档。

先纠正一个常见误解：很多人以为"选了便宜模型就该配低 effort 省钱"。在长 agent prompt 里这是错的。Anthropic 的文档明确警告：低 effort 下模型"更容易跳过搜索、提前停止、跳过检查"。也就是说，低 effort 的省钱是拿"少干活"换来的，省下的 token 会在返工里花回去。

一个能用的单模型策略是三条：

选第二档，不选第一档也不选第三档。 第一档在单模型配置下会被所有流量反复消耗，成本不可控；第三档扛不住写入路径。第二档是唯一能覆盖全部角色的。
用 effort 做角色区分。 规划时 /effort high，执行 /effort medium，分诊 /effort low。同一模型，三种工作模式。注意 Opus 5.5 的 thinking 关不掉，只能降 effort；Haiku 5.5 在 high 及以下可以关；OpenAI 系还能降到 none。

这一条现在有官方保证：4.4 节引的那句话------换 effort 不碎缓存------意味着这是唯一一个可以随时调、且不付缓存重建代价的旋钮。单模型方案的全部合理性都建立在这句话上。
用上下文隔离代替模型隔离。 没有便宜模型可用，就把"上下文压小"当成降本手段。窄工具、窄 prompt、autoCompactWindow，让单个请求的输入规模降下来。输入规模降一半，成本就降一半，这跟换便宜模型是等效的。

bash 复制代码

# 单模型下的 effort 分层：不需要改任何配置文件，运行时切换
# 规划/设计阶段
/effort high

# 正常编码
/effort medium

# 分诊、日志分类、批量摘要
/effort low

这套方案的边界要认清楚：单模型在"需要决策密集 + 需要海量检索"同时出现的任务上会露馅。 比如一个既要读懂 30 万 token 仓库、又要做架构判断的重构，第二档模型要么上下文不够用（压不进去），要么判断不够强。这种任务出现频率不高，出现了就人工介入，别指望配置解决。

5.3 只有 2 个模型：一强一弱，按"要不要写"切

这是最常见的配置，也是最容易配错的。正确切法是按写权限切，不是按任务难度切。

原因是：难度你判断不准，写权限是确定的。一个 subagent 有没有 Edit/Write 工具，是配置文件里明写的，不会有歧义。

角色	用哪个	为什么
orchestrator / 主会话	强	它读所有输出，理解力是上限
planner	强（继承）	计划定死下游
implementer	强	有写权限，错了代价高
reviewer	强	要能挑出实现者的错
explorer	弱	只读，输出可校验
triage / 摘要	弱	机械转换，输出可校验

你会发现这张表里"弱"只干了两个角色。这看起来收益不大，但实际上这两个角色占了 55-60% 的 turn 量。按 4.2 节的数字，60k 上下文下弱档比强档便宜 34 倍，拿下 55% 的流量就能让整体账单降一个档次。社区的实测结论也吻合：这种"强模型 + 便宜代理"的配对，2 到 2.5 倍降本，质量保持 85-95%。

但有两个必须做的配套：

markdown 复制代码

---
# 弱档 subagent 的两个保命配置
name: Explore
tools: Read, Grep, Glob          # 只给三个只读工具，工具定义越少，每请求固定开销越小
model: claude-haiku-5-5
effort: medium                    # 别用 low，长 prompt 下 low 会跳过搜索
autoCompactWindow: 100000         # 卡住 100k 价格线；写 100000，不要写 100k
---

工具集收窄。 工具定义是每个请求的固定开销。给 explorer 五个工具，每请求多烧几千 token；三个工具够用。
autoCompactWindow 设到价格线。 这是让弱档"待在便宜档位"的唯一手段。注意它不是硬保证------触发压缩那一轮仍可能略超阈值。

第二种"两个模型"的配置是同档不同家做 failover。这不是省钱方案，是可用性方案，别混为一谈。要注意的是：不同家的缓存不互通，切换那一次是全量冷读。所以正确做法是"会话内钉住，只在报错/超时时切"，而不是"按负载轮询"。

5.4 只有 3 个模型：完整矩阵，但要防"配置侵蚀"

三档齐全就可以上第三章那张完整矩阵了。这时候真正的敌人不是选型，是配置侵蚀------你写的配置被别的东西悄悄覆盖掉。第六章整章讲这个。

三档方案的核心不是"分配"，是每个角色一条独立的 fallback 链。原因：级联降级需要优雅降级，而不是"报错了就整体重试"。
强档-Opus 5.5 中档-Sonnet 5.5 确定性门-测试与检查弱档-Haiku 5.5 路由器调用方强档-Opus 5.5 中档-Sonnet 5.5 确定性门-测试与检查弱档-Haiku 5.5 路由器调用方 #mermaid-svg-wgELLF6uHs95sIbj{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-wgELLF6uHs95sIbj .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-wgELLF6uHs95sIbj .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-wgELLF6uHs95sIbj .error-icon{fill:#552222;}#mermaid-svg-wgELLF6uHs95sIbj .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-wgELLF6uHs95sIbj .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-wgELLF6uHs95sIbj .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-wgELLF6uHs95sIbj .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-wgELLF6uHs95sIbj .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-wgELLF6uHs95sIbj .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-wgELLF6uHs95sIbj .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-wgELLF6uHs95sIbj .marker{fill:#333333;stroke:#333333;}#mermaid-svg-wgELLF6uHs95sIbj .marker.cross{stroke:#333333;}#mermaid-svg-wgELLF6uHs95sIbj svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-wgELLF6uHs95sIbj p{margin:0;}#mermaid-svg-wgELLF6uHs95sIbj .actor{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;}#mermaid-svg-wgELLF6uHs95sIbj text.actor>tspan{fill:black;stroke:none;}#mermaid-svg-wgELLF6uHs95sIbj .actor-line{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);}#mermaid-svg-wgELLF6uHs95sIbj .innerArc{stroke-width:1.5;stroke-dasharray:none;}#mermaid-svg-wgELLF6uHs95sIbj .messageLine0{stroke-width:1.5;stroke-dasharray:none;stroke:#333;}#mermaid-svg-wgELLF6uHs95sIbj .messageLine1{stroke-width:1.5;stroke-dasharray:2,2;stroke:#333;}#mermaid-svg-wgELLF6uHs95sIbj #arrowhead path{fill:#333;stroke:#333;}#mermaid-svg-wgELLF6uHs95sIbj .sequenceNumber{fill:white;}#mermaid-svg-wgELLF6uHs95sIbj #sequencenumber{fill:#333;}#mermaid-svg-wgELLF6uHs95sIbj #crosshead path{fill:#333;stroke:#333;}#mermaid-svg-wgELLF6uHs95sIbj .messageText{fill:#333;stroke:none;}#mermaid-svg-wgELLF6uHs95sIbj .labelBox{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;}#mermaid-svg-wgELLF6uHs95sIbj .labelText,#mermaid-svg-wgELLF6uHs95sIbj .labelText>tspan{fill:black;stroke:none;}#mermaid-svg-wgELLF6uHs95sIbj .loopText,#mermaid-svg-wgELLF6uHs95sIbj .loopText>tspan{fill:black;stroke:none;}#mermaid-svg-wgELLF6uHs95sIbj .loopLine{stroke-width:2px;stroke-dasharray:2,2;stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);}#mermaid-svg-wgELLF6uHs95sIbj .note{stroke:#aaaa33;fill:#fff5ad;}#mermaid-svg-wgELLF6uHs95sIbj .noteText,#mermaid-svg-wgELLF6uHs95sIbj .noteText>tspan{fill:black;stroke:none;}#mermaid-svg-wgELLF6uHs95sIbj .activation0{fill:#f4f4f4;stroke:#666;}#mermaid-svg-wgELLF6uHs95sIbj .activation1{fill:#f4f4f4;stroke:#666;}#mermaid-svg-wgELLF6uHs95sIbj .activation2{fill:#f4f4f4;stroke:#666;}#mermaid-svg-wgELLF6uHs95sIbj .actorPopupMenu{position:absolute;}#mermaid-svg-wgELLF6uHs95sIbj .actorPopupMenuPanel{position:absolute;fill:#ECECFF;box-shadow:0px 8px 16px 0px rgba(0,0,0,0.2);filter:drop-shadow(3px 5px 2px rgb(0 0 0 / 0.4));}#mermaid-svg-wgELLF6uHs95sIbj .actor-man line{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;}#mermaid-svg-wgELLF6uHs95sIbj .actor-man circle,#mermaid-svg-wgELLF6uHs95sIbj line{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;stroke-width:2px;}#mermaid-svg-wgELLF6uHs95sIbj :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} alt $门通过$ $门失败且重试未满$ $门失败且重试已满$ 任务（带 task_class）分类 read_only / write / plan read_only 直接派给弱档结构化结果返回，人复核 write 派给中档提交 diff，跑测试合并带失败输出重试升级到强档，附全部失败上下文新 diff plan 直接派给强档（高 effort）

这张图里有一个容易被忽视的设计：升级时要把失败上下文一起带上去。 很多人升级只发原任务，让强档从头想一遍，浪费了一次宝贵的失败信息。带上"试了什么、门怎么报错的"，强档的命中率会高很多。

对应代码：

python 复制代码

# cascade.py ------ 三档级联，带确定性门和失败上下文传递
import logging
from typing import Callable

log = logging.getLogger(__name__)

TIERS = ["tier3", "tier2", "tier1"]   # 从便宜往上


async def run_cascade(task: str, call: Callable, gate: Callable,
                      max_retry_per_tier: int = 2):
    """call(tier, prompt) -> 产出；gate(产出) -> (通过?, 失败详情)

    只有门是便宜且确定性的时候，级联才省钱。
    如果 gate 比层级差价还慢，直接单档跑，别级联。
    """
    history: list[str] = []           # 失败上下文，升级时必须带上

    for idx, tier in enumerate(TIERS):
        prompt = task
        if history:
            prompt = (
                f"{task}\n\n"
                f"此前在更低档位尝试失败，详情如下，不要重复同样的错误：\n"
                + "\n---\n".join(history)
            )

        for attempt in range(1, max_retry_per_tier + 1):
            out = await call(tier, prompt)
            ok, detail = gate(out)
            if ok:
                log.info("tier=%s attempt=%d 通过", tier, attempt)
                return out
            log.warning("tier=%s attempt=%d 门失败：%s", tier, attempt, detail)
            history.append(f"[{tier} 第{attempt}次] {detail}")

    raise RuntimeError("全部层级失败，转人工")


# 关键：gate 的成本必须被测量，不能被假设
def make_gate(commands: list[str]) -> Callable:
    import subprocess

    def gate(_out) -> tuple[bool, str]:
        for cmd in commands:
            r = subprocess.run(cmd, shell=True, capture_output=True, text=True)
            if r.returncode != 0:
                return False, f"{cmd} 失败：{r.stderr[-800:]}"
        return True, ""

    return gate

代码里那句注释是重点：gate 的成本必须测。 有个很实在的判断------"级联只有在验证门便宜且确定性的时候才省钱。如果验证比层级差价还慢，级联只是加了延迟没省钱。"所以如果你的测试套件跑 8 分钟，别对它做级联；如果你的测试跑 20 秒，级联就是纯赚。

5.5 5 个以上：从"按角色"升级到"按 turn"

到这一步，角色矩阵已经不够了。因为角色是静态的，而 turn 是动态的。同一个 implementer，第 3 轮在读文件、第 4 轮在写 diff、第 5 轮在跑测试，它们的模型需求不一样。

这就是模型路由（model routing）和角色分工（role routing）的区别：

维度	角色分工路由	复杂度 / turn 路由
决策对象	能力类型（谁干）	模型层级（这一轮给多强）
依据	任务性质	难度信号、输入长度、重试次数
实现位置	agent 定义文件	网关 / 框架 conditional edge / 前置分类器
变更频率	低（跟着架构走）	高（跟着流量走）

两者是正交的，可以叠加------一个角色也可以被指派不同层级，同一层级里不同的 turn 也可以用不同 effort。

落到工程上，路由逻辑别写死在业务代码里，放在网关层。这是 2026 年的标准做法，因为网关能做三件业务代码做不了的事：按团队计 token 账、统一 fallback、prompt 归一化。

yaml 复制代码

# litellm_config.yaml ------ 网关层做路由 + fallback，业务代码只认逻辑名
model_list:
  - model_name: tier3
    litellm_params:
      model: anthropic/claude-haiku-5-5
      api_base: os.environ/ANTHROPIC_BASE_URL
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: tier3
    litellm_params:
      model: deepseek/deepseek-v4-flash    # 同一逻辑档位的第二供应商
      api_base: os.environ/DEEPSEEK_BASE_URL
      api_key: os.environ/DEEPSEEK_API_KEY
  - model_name: tier2
    litellm_params:
      model: anthropic/claude-sonnet-5-5
  - model_name: tier2
    litellm_params:
      model: openai/gpt-6.1-terra       # 同档位第二选择，1 / 5，比 Sonnet 5.5 便宜一半
      api_base: os.environ/OPENAI_BASE_URL
      api_key: os.environ/OPENAI_API_KEY
  - model_name: tier1
    litellm_params:
      model: anthropic/claude-opus-5-5

router_settings:
  routing_strategy: simple-shuffle    # 同档位内轮询，做供应商分散
  num_retries: 2
  timeout: 600
  allowed_fails: 2
  fallbacks:
    - tier3: ["tier2"]               # 弱档全挂才升中档
    - tier2: ["tier1"]               # 中档全挂才升强档
    - tier1: ["tier2"]               # 强档挂了退回中档（宁可降级也不 500）

litellm_settings:
  drop_params: true                  # 不同供应商不支持的参数直接丢，别报错
  cache: true
  cache_params:
    type: local
    ttl: 3600

fallbacks 那三行值得琢磨。注意 tier1 的 fallback 是往下退到 tier2，不是没有 fallback。这个设计有实际意义：强档一般是限流最紧的（配额低、并发低），实践中它反而是最容易 429 的那一档。降级服务比 500 服务好，只要你的业务能接受"这一轮质量略降"。

python 复制代码

# gateway_client.py ------ 私有网关接入（企业内网常见形态）
# 业务代码只认 tier，不认模型名，换模型不动业务
import os
from openai import OpenAI          # 绝大多数网关都吃 OpenAI 协议

client = OpenAI(
    base_url=os.environ["GATEWAY_BASE_URL"],   # 例如私有网关的 /v1
    api_key=os.environ["GATEWAY_API_KEY"],
)

TIER_ALIAS = {"tier3": "tier3", "tier2": "tier2", "tier1": "tier1"}


def chat(tier: str, messages: list[dict], **kw):
    return client.chat.completions.create(
        model=TIER_ALIAS[tier],
        messages=messages,
        extra_body={                  # 网关侧的自定义参数，透传给上游
            "metadata": {"task_class": kw.pop("task_class", "unknown")},
        },
        **kw,
    )

这里有个实践建议：别名要按"能力档位"命名，不要按模型名命名。 叫 tier3 而不是 haiku，好处是换供应商的时候业务代码一行不用改。这一条看着是小事，但在模型半年换一代的节奏下，它省下的重构工时很可观。

六、十个静默陷阱：配置写对了，运行时不按你写的走

这一节是全篇最有实操价值的部分。因为前面所有方案，只要踩中这十个里的任何一个，都会静默失效------不报错，只是账单或者质量慢慢跑偏。

6.1 陷阱清单

#	陷阱	触发条件	检测方法	修法
1	alias 解析漂移	换 provider（Bedrock/Vertex/Foundry）后 alias 解析到旧代模型	打印实际解析到的 model ID	用完整 ID，或设 `ANTHROPIC_DEFAULT_*_MODEL`
2	环境变量优先级反转	2.1.251 版本升级后	看"强制 Haiku"是否还有效	需要时加 `CLAUDE_CODE_SUBAGENT_MODEL_FORCE`
3	全局 effort 抹平角色	shell profile 里设了 `CLAUDE_CODE_EFFORT_LEVEL`	对比分诊任务的 thinking token 量	不用全局变量，按定义文件设
4	内置 Explore 不降级	主会话跑强档	看 explorer 的计费档位	用同名定义文件覆盖内置
5	tokenizer 差异	从旧代模型迁到 5.5	同一文本 token 数对比	预算和压缩阈值全部重测
6	弃用不报警	硬编码了旧 model ID	定期跑一遍所有 model ID	建可用性探测任务
7	验证门比层级差价还贵	对慢测试套件做级联	记录 gate 耗时与省下的钱	慢门不级联，直接单档
8	促销价到期没重算	按 promo 价做了预算	核对促销截止日	用促销后价格做压力测试
9	跨厂断点规则不一致	为降本把长 prompt 迁到便宜模型	统计 prompt 长度分布	先看断点位置，再看单价
10	tool calling 走错端点	OpenAI 模型用了 Chat Completions	工具调用是否稳定触发	工具调用必须走 Responses API

6.1.1 新增的三条，为什么值得单列

陷阱 8：促销价到期。 这一条在 1.6 节列过日历。它的危险在于它是计划内的涨价------不是意外，是日程。你现在按 Gemini 4 Argon 的 2 / 10 做的成本模型，12 月 1 日自动变成 4 / 20。所以做预算时要用"促销后价格"跑一遍压力测试，如果方案在那个价格下不成立，它就是窗口期套利，不是架构。

陷阱 9：跨厂断点规则不一致。 这一条最容易被"降本"的动机推进坑里。假设你为了省钱，把一个 30 万 token 的仓库分析从 Claude 迁到 GPT-6.1 Terra（单价 1 / 5，看起来便宜一半）。迁完发现账单没降------因为过了 272K 断点，整个请求按 2 / 7.5 计。你以为在比 1 和 2，实际在比 2 和 2。

检测方法很土但有效：把你的请求按 prompt 长度画个直方图，看看有多少落在断点两侧。如果 60% 的请求都在断点之上，那"单价便宜"这个优势在你这儿根本不存在。

陷阱 10：tool calling 端点约束。 OpenAI 的文档写得很明确：Chat Completions 是支持的端点，但工具调用需要 Responses API。托管的工具（computer use、web search、file search、code interpreter、MCP）也都在那边。

这一条是硬阻塞------不是性能问题，是"跑不起来"。如果你沿用旧的 Chat Completions 写法接 GPT-6.1 Terra，你会发现工具调用不触发，而错误信息不会告诉你"端点选错了"。迁移前先确认这一点，能省一天。

6.2 陷阱 1 详解：alias 是 2026 年最贵的一个字符

这个必须展开，因为它一次能让你多花 10 倍钱。

haiku 这个 alias 只在 Anthropic 官方 API 上 等于 Haiku 5.5。在 Bedrock、Google Cloud、Claude Platform on AWS、Microsoft Foundry 上，它解析为 Haiku 4.5。

而 Haiku 4.5 是 1 / 5 美元------是 Haiku 5.5 低档的 10 倍。更糟的是 Haiku 4.5 根本不支持 effort 参数 ，你写的 effort: medium 完全无效，且上下文退回 200k。

也就是说：你以为自己在用 0.10 的模型跑分诊，实际在用 1.00 的模型跑，而且所有 effort 调优都是空转。这个错误不会报错，不会告警，只会在月底账单上出现。

修法两条：

bash 复制代码

# 方案 A：定义文件里写完整 ID（推荐，可复现）
# model: claude-haiku-5-5

# 方案 B：在平台上把 alias 钉到正确 ID
export ANTHROPIC_DEFAULT_HAIKU_MODEL="anthropic.claude-haiku-5-5"   # Bedrock 例

顺带说个反直觉的取舍：日常用 alias，需要可复现性时钉完整 ID。 因为 alias 的好处是"自动跟随官方升级"，坏处是"你不知道自己升级到了什么"。而在这套分层架构里，模型的档位是设计的核心，你不希望它自己变------所以 subagent 定义里我全部用了完整 ID。

6.3 陷阱 2 详解：环境变量从"最高"掉到"第三"

Claude Code 在 2.1.251 改了优先级顺序，现在是：

复制代码

① 单次调用的 model 参数
② agent 定义文件里的 model 字段
③ CLAUDE_CODE_SUBAGENT_MODEL 环境变量
④ 主会话模型

在 2.1.251 之前，环境变量优先级最高。所以很多团队"把所有 subagent 强制打到便宜档"的配置，在升级后静默失效了------定义文件里的 model 现在压过环境变量。

要恢复强制行为，得再加一个开关（2.1.257+）：

json 复制代码

{
  "env": {
    "CLAUDE_CODE_SUBAGENT_MODEL": "claude-haiku-5-5",
    "CLAUDE_CODE_SUBAGENT_MODEL_FORCE": "1"
  }
}

但要注意代价：force 开启后，所有定义里的 model 字段都被忽略，包括你 implementer 的 Sonnet。这会把三档架构压成一档。所以这个开关我只建议用在"所有 subagent 都是分诊"的 CI 场景，不要在开发环境开。

6.4 陷阱 3 详解：一行 shell 配置毁掉整个分层

CLAUDE_CODE_EFFORT_LEVEL 的优先级同时高于 定义文件的 effort 字段和单次调用的 effort 参数。

这意味着：你在 shell profile 里设了 high（很常见，因为"我想让模型好好想"），那你那个专门设成 low 的分诊 subagent 也会跑 high。在 Haiku 上这有两重代价：多烧 thinking token，以及更快逼近 100k 价格线。

更隐蔽的一层：subagent 继承主会话的 thinking 设置，没有 per-subagent 开关。 所以你以为在定义文件里控制了思考预算，其实没有。

检测方法很简单：抓一次分诊任务的 usage，看 thinking_tokens 是不是和规划任务一个量级。如果一样，说明你的 effort 分层没生效。

6.5 陷阱 4 详解：最常跑的 subagent 从不降级

按官方 subagent 文档，内置 Explore 使用主对话的模型。也就是说，主会话跑 Opus 5.5（或者 Fable 5.1），你委派的每一次代码搜索都按 Opus（或 Fable）计费。

而 Explore 是跑得最频繁、从不写代码的那个。这是投入产出比最高的一处修正：写一个同名定义文件覆盖它。

主会话跑 Fable 时更要注意：文档写明 Claude Code 会让内置 Explore 改用 Opus（通过 ANTHROPIC_BASE_URL 接网关时也一样）。而 Fable 是 10 / 50，Opus 是 4 / 20------这个自动降级已经帮你省了，但省完还是 Opus 价，不是 Haiku 价。

6.6 陷阱 5 详解：tokenizer 变了，你的预算全错

Haiku 5.5 用的是 Opus 4.7 引入的新 tokenizer，同样的文本，token 数比 Haiku 4.5 多约 30%。

这条的杀伤力在于它是乘性误差。你按 Haiku 4.5 的 token 密度算出来的预算、设的压缩阈值、估的成本，全部偏低 30%。而 30% 在一个以 100k 为硬线的模型上，足以让一整类请求从便宜档掉进贵档。

迁移时必做的一件事：拿 20 个真实请求跑一遍，对比新旧 tokenizer 的计数，把 autoCompactWindow、max_tokens、预算阈值全部按比例重设。

6.7 陷阱 7 详解：级联的经济性有前置条件

前面提过，这里给判断式：

级联只有在"验证门便宜且确定性"时才省钱。

具体怎么算：假设弱档比强档每任务省 0.9 美元，你的测试套件跑 3 分钟。如果这 3 分钟造成的延迟对你的业务没有成本（离线批处理），级联纯赚；如果是同步接口，3 分钟延迟换 0.9 美元，大概率不划算；如果测试套件跑 8 分钟且不稳定（有 flaky），级联就是负收益------你会因为假失败而频繁误升级，钱和延迟双输。

所以上路由之前的第一件事不是配模型，是测 gate 的成本和 flakiness。

6.8 不用 Claude Code 的话，这十条还剩几条

上面六节的检测方法和修法写得很具体，具体到 CLAUDE_CODE_* 环境变量、.claude/agents/*.md、autoCompactWindow 这些名字。如果你用的是 LangGraph、CrewAI、AgentScope、Dify 或者自研编排，这些字段一个都用不上。

但这件事要分清楚：这十条里，六条是平台无关的规律，四条是 Claude Code 的实现细节。

陷阱	性质	换成你的框架时，它长什么样
1. alias 解析漂移	通用规律	任何"用别名/逻辑名指向模型"的设计都会漂移。网关里的 `tier3` 名字映射到哪个真实 ID，换个供应商就可能变。检查点相同：打印实际解析结果
5. tokenizer 差异	通用规律	任何跨代迁移都会变。同一段文本换模型后 token 数不同，所有预算、阈值、压缩策略都要重算
7. 验证门成本	通用规律	任何级联/升级架构都受这条约束。这是经济学约束，不是工具约束
8. 促销价到期	通用规律	任何按 promo 价做的预算都会在某天失效。这是财务纪律，与框架无关
9. 跨厂断点不一致	通用规律	任何跨厂商迁移都要重算断点。断点位置是厂商策略，不是技术参数
10. tool calling 端点	通用规律	任何带工具的 agent 都会遇到。区别只在报错方式：有的报错，有的静默不触发
2. 环境变量优先级反转	实现细节	通用形态：多层配置的优先级顺序会随版本变。你的框架也有"全局配置 / agent 配置 / 单次调用参数"三层，升级时同样要复查
3. 全局 effort 抹平角色	实现细节	通用形态：全局开关会覆盖局部设定。你的框架里那个"全局 temperature"或"全局 max_tokens"就是同一个坑
4. 内置 Explore 不降级	实现细节	通用形态：框架内置的默认 agent 往往继承主模型。凡是你没有显式覆盖的内置角色，都在按最贵那档计费
6. 弃用不报警	实现细节	通用形态：硬编码 model ID 会在弃用时静默失败。Sonnet 4.5 在 2026-11-30 退役，`claude-3-haiku-20240307` 在 4 月退役时是直接报错，不会自动转到后继模型

所以判断标准可以简化成一句话：

某个能力是"必需品"还是"加速带"？ 分层的判断依据、成本公式、验证门约束是必需品------没有它们，任何框架下你都会算错账。具体的环境变量名和配置字段是加速带------有了省事，没有就自己实现一层，逻辑不变。

举两个具体的替代路径：

没有 subagent 机制 （比如你用一个循环自己调 API）：把"角色"做成不同的 system prompt + 不同的工具白名单，在代码里用 if task_class == "read_only" 选模型。功能等价，只是没有框架替你管上下文隔离------所以你要自己保证便宜档的上下文不跨 100k。
没有 per-agent effort 参数：用 prompt 控制思考深度是可行的退化方案（"先列出你要检查的三件事，再回答"，比 "think step by step" 有效），但它不如 effort 参数可控，成本也更难预测。这种情况下把预算留给"更小的上下文"而不是"更少的思考"，风险更低。

七、什么时候不该做路由（省下的钱可能不如你搭的成本）

这一节是给自己泼冷水。因为我上面讲了六章"怎么做分层"，但现实中相当多团队不该做。判断标准有五条，命中任何一条就先别做。

一、验证门慢或者缺失。 见 6.7。没有便宜确定性的 gate，级联只是加延迟。

二、单任务类型 + 低调用量。 三级路由会带来配置和协调开销。只有一种任务、每天几十次调用的管线，用一个固定档位的模型更简单，把搭建和维护成本摊进去往往还更便宜。这个结论有官方背书：orchestrator-worker 只在"有长成本尾"或"超过单上下文窗口"时才省钱。

三、模型名单频繁变动。 供应商弃用或重命名层级时路由会失效。没有自动化模型 ID 管理（alias 映射、带 TTL 的能力缓存）的团队，会把工程时间花在修补破损上，而不是交付功能。这条在 2026 年尤其真实------半年一代，你搭的映射表每季度都要改。

四、任务高度互相依赖。 有些任务不能按复杂度干净切分。典型例子是"每次文件编辑都需要推理"的重构：你让弱档去探索、强档去实现，结果是强档必须重新摄入弱档的发现，token 和延迟双增。切不干净的活，硬切比不切更贵。

五、不做运行时度量。 路由是设计时的成本控制，必须配对运行时的测量。如果不把"固定质量下的每任务成本"当成和正确性并列的评估轴，你的路由改动就是自嗨------涨了钱但质量没提升，你也不会知道。

有个很好用的度量方式：用量报告支持按模型拆分 token 之后，验证路由是否生效变得很直接------"把探索移到便宜档，token 就应该出现在那档下面"。如果没出现，说明配置被覆盖了（回到第六章）。

八、一周落地路线

如果读完想动手，按这个顺序走。这套节奏的关键是"先测量后建模"------直接上路由是最常见的失败模式。

天	做什么	产出	验收标准
Day 1	打点：给每个请求记 task_class、token 数、延迟、用的模型	原始日志	能回答"我的流量由哪几类任务构成"
Day 2-3	标注 200 条真实请求的难度与类别	分类样本集	能画出"任务类型 → 占比"的分布
Day 4	拿候选模型（覆盖你的价格区间）跑这批样本	质量-成本曲线	每个任务类型有一张自己的曲线
Day 5	按规则做两档路由，跑通级联 + 确定性门	可运行的 router	升级率能被记录（这是你的成本杠杆）
Day 6	测 gate 的耗时与 flakiness，调置信度阈值	阈值表	门耗时 < 层级差价对应的容忍度
Day 7	对比混合成本 vs 全强档基线，抽检质量	一份对比报告	成本降幅与质量损失的数都在纸上

三个提醒：

Day 2 的 200 条别挑"典型样本"。 要随机抽，因为你要的是分布，不是代表性案例。很多团队在这一步挑了自己印象最深的难例，结果估算出来的难度分布严重偏高，方案做得过度。

Day 7 的对比必须包含"质量损失"这一列。 只报成本降了 70% 不报质量掉了几个点，是在给自己埋雷。业界的合理区间大概是"误路由带来 5-10% 的质量税，但成本降 70-85%"------这个交易在任何量级下都划算，但你得知道自己在哪个位置。

上线后每季度重跑一次 Day 1 到 Day 4。 原因是模型价格在动、新模型在出、你的产品行为也在变。有数据说，跳过这一步的团队，路由准确率会在六个月内衰减 5 到 15 个百分点。在模型半年一代的市场里，"去年最优的切分"通常两个季度就过期了。

九、总结：三句话

第一句：选型的对象不是模型，是阶梯。 别再问"哪个模型最强"。问"我这套系统里，哪几类活的失败代价低到可以交给第三档，边界在哪，越界怎么办"。这三个问题的答案就是你的架构。

第二句：便宜的模型经常更贵，贵的模型经常更便宜。 前者因为成功率低、步数多、跨价格线；后者因为规划质量决定下游全链路的返工量。唯一能分辨的度量是"每个成功任务的成本"，不是单价。

第三句：所有配置都可能被静默覆盖，所以要度量，不要相信。 alias 会漂移、环境变量会反转、全局 effort 会抹平、内置 subagent 会继承主模型。这些问题一个都不报错。所以最后落地时，你真正要建的不是一张模型对照表，是一套能告诉你"钱花在哪一档、质量掉在哪一档"的观测。

至于"什么 agent 适合什么模型"这个问题本身------我给的答案是：别给 agent 绑模型，给 turn 绑档位。 Agent 是稳定的，模型是流动的；把稳定的东西绑在流动的东西上，你每半年要重构一次。反过来，你就只需要换网关里的三行配置。

参考资料

Anthropic 官方模型文档与定价页（Fable 5.1 / Mythos 5.1 / Opus 5.5 / Sonnet 5.5 / Haiku 5.5），核对日期 2026-10-01 至 10-26
Anthropic《Optimizing for cost and intelligence》------orchestrator-worker 的适用边界
OpenAI《GPT-6 系列模型指南》（官方，Astra / Sol / Terra / Luna 定价与 reasoning effort 建议）
OpenAI GPT-6.1 Terra 模型文档，2026-10-26 发布（含 272K 长上下文计价规则、Responses API 约束）
Google Gemini API 定价页，核对日期 2026-10-13（含 Gemini 4 Argon 与 Flash 系列促销条款）
Claude Code subagent 配置与 model resolution 文档（2.1.251+ / 2.1.257+ 版本行为变更）
《Claude Haiku 5.5 vs Sonnet 5.5 vs Opus 5.5 for Coding-Agent Subagents》，2026 年 10 月
AgentPatterns《Cost-Aware Agent Design: Route by Complexity, Not Habit》
AgentMelt《Model Routing》术语与三种常见模式
LayerFlow《LLM Routing & Fallback in Production: Implementation Guide》
StackSpend《The Latest in LLMs, October 2026》------换代与退役日历
第三方 LLM 横评（20 模型编码榜单，快照 2026-09-12）
《大模型词元服务性能监测报告（2026 年）》，中国信通院人工智能研究所
《中国 AI 大模型 API 价格白皮书（2026）》
TokenPAPA《LLM API Price Trends in 2026》《The State of Chinese AI Models》
各厂商官方定价页：OpenAI、Google、DeepSeek、月之暗面、智谱、阿里云、MiniMax、小米

数据时效提示：本文价格与版本核对于 2026 年 10 月 26 日至 29 日。按本文自己的说法，这类表格的保质期大约 60 天，请在落地前用官方定价页复核，尤其是断点价、峰谷价、缓存价、促销到期日这四类容易变的结构。

【大模型专题】大模型怎么选（2026 年 10 月版）：从 20 个模型里挑对那 3 个，以及 Agent 按角色分模型的实操矩阵

目录

大模型怎么选（2026 年 10 月版）：从 20 个模型里挑对那 3 个，以及 Agent 按角色分模型的实操矩阵

前言：为什么"选模型"这件事在 2026 年彻底变了

先声明一件事：下面出现的所有对照表都是示例，不是配方

一、先把事实基线立住：2026 年 10 月的模型版图

1.1 Anthropic 的 5.5 家族：分层最干净的一条产品线

1.2 三档结构已经成型，但每家的切法不同

1.3 国产模型：价格结构完全不同的一套逻辑

1.4 关于 benchmark：跨厂比分数基本都是错的

1.5 同一个"1M 上下文"，三家的计价方式完全相反

1.6 2026 年新增的一个选型维度：价格日历

二、选型的五个维度（不是 benchmark，也不是价格）

2.1 维度一：失败成本（这是第一优先级）

2.2 维度二：上下文规模，以及你能否缓存它

2.3 维度三：turn 类型分布

2.4 维度四：工具调用密集度

2.5 维度五：价格结构，而不是单价

三、Agent 的模型选型：按角色分，但角色不等于 agent

3.1 六种角色，三层模型

3.2 反面案例：为什么"全部 subagent 都用 Opus"是错的

3.3 角色矩阵的参考实现

四、成本数学：为什么"便宜的模型"经常更贵

4.1 唯一正确的度量：每个成功任务的成本

4.2 单次 subagent 运行的真实成本

4.3 缓存碎裂：中途换模型是笔糊涂账

4.4 一个关键区分：换 effort 不碎缓存，换模型才碎

五、组合矩阵：只有 1 个模型怎么办，2 个怎么办，3 个怎么办

5.1 组合矩阵总表

5.2 只有 1 个模型：把 effort 和上下文当成两个"虚拟模型"

5.3 只有 2 个模型：一强一弱，按"要不要写"切

5.4 只有 3 个模型：完整矩阵，但要防"配置侵蚀"

5.5 5 个以上：从"按角色"升级到"按 turn"

六、十个静默陷阱：配置写对了，运行时不按你写的走

6.1 陷阱清单

6.1.1 新增的三条，为什么值得单列

6.2 陷阱 1 详解：alias 是 2026 年最贵的一个字符

6.3 陷阱 2 详解：环境变量从"最高"掉到"第三"

6.4 陷阱 3 详解：一行 shell 配置毁掉整个分层

6.5 陷阱 4 详解：最常跑的 subagent 从不降级

6.6 陷阱 5 详解：tokenizer 变了，你的预算全错

6.7 陷阱 7 详解：级联的经济性有前置条件

6.8 不用 Claude Code 的话，这十条还剩几条

七、什么时候不该做路由（省下的钱可能不如你搭的成本）

八、一周落地路线

九、总结：三句话

参考资料