结论先行
不要用最强模型做所有事。 把任务按难度分级，难的交给强模型思考，简单的交给轻量模型执行——这就像公司里总监做决策、实习生跑腿，各司其职效率最高。
这个能力在 Vibe Coding（让 AI 帮你写代码）场景下尤其重要，因为模型的推理能力越强，调用成本就越高、响应速度就越慢。学会”组合用模型”，是控制成本和提升效率的关键技能。
核心概念：能力密度匹配
先解释一个关键概念——能力密度匹配。
打个比方：你搬家时需要搬钢琴，也需要搬纸箱。钢琴得请专业搬运工（贵但专业），纸箱随便谁都能搬（便宜又快）。如果你让专业搬运工一个纸箱一个纸箱地搬，那就是巨大的浪费。
AI 模型也是一样：
| 模型级别 | 代表 | 擅长 | 成本 | 速度 |
|---|---|---|---|---|
| 旗舰模型 | Opus | 复杂推理、架构设计、创意任务 | 高 | 慢 |
| 标准模型 | Sonnet | 日常编码、中等复杂度任务 | 中 | 中 |
| 轻量模型 | Haiku | 文件搜索、格式化、简单查询 | 低 | 快 |
能力密度匹配的意思是：任务需要多少”思考力”，就分配多少”思考力”。不多给，也不少给。
一个真实的例子：用 Opus（旗舰模型）做一次文件搜索，和用 Haiku（轻量模型）做同样的搜索，结果几乎一样，但成本差了两个数量级（约 100 倍）。因为文件搜索根本不需要”深度思考”，Haiku 的能力完全够用。
原理：为什么强模型做简单事反而低效
强模型（如 Opus）之所以”强”，是因为它会消耗大量的 thinking tokens（思考令牌）和 reasoning tokens（推理令牌）来深度分析问题。这些 token 每一个都要花钱、都要花时间。
当你让强模型做一件简单的事（比如”把这个文件里的 var 全换成 const”），它的”大脑”还是会走一遍完整的思考链路——分析上下文、考虑边界情况、推理可能的影响……这些思考对简单任务来说完全多余，白白浪费了时间和金钱。
这就好比让一个博士后帮你做加减法——他当然算得出来，但你付的是博士后的时薪，做的却是计算器的活。
实战：Claude Code 的 Sub-Agent 调度策略
Claude Code 在这方面的设计很有参考价值。它不是”一个模型打天下”，而是根据任务类型动态选择不同的模型和执行方式。
三种 Sub-Agent 模式
1. Fork Agent —— 继承上下文，并行探索
当需要保留当前对话的上下文继续工作时（比如”在当前代码基础上同时探索两种方案”），Claude Code 会 fork（分叉）一个子 Agent。
类比：就像 Git 的分支——从同一个起点出发，各自独立探索，最后选最好的合并回来。
2. 内置 Agent —— 目标明确，独立执行
当任务目标很清晰、不依赖当前对话语境时（比如”搜索所有包含 TODO 的文件”），Claude Code 直接派出内置的专用 Agent，包括：
- Explore Agent：负责代码搜索和文件定位（用 Haiku 模型，便宜又快）
- Plan Agent：负责方案规划（继承父模型，需要思考力）
- Verification Agent：负责结果验证
3. Agent Team —— 多角色协作
当任务足够复杂时，Claude Code 会组建一个”团队”，让多个 Sub-Agent 分工协作、互相通讯。
类比：就像一个项目组——产品经理定需求、开发写代码、测试验结果，各自独立工作但通过”会议”（消息传递）保持同步。
模型选择策略
Claude Code 不是给所有 Sub-Agent 都用同一个模型，而是动态匹配：
- Explore Agent → Haiku（轻量模型）：文件搜索、代码定位这类任务，不需要深度推理，Haiku 的准确率已经足够
- Plan / Verification Agent → 继承父模型：规划和验证需要理解复杂上下文，所以用更强的模型
实用技巧：三种省钱又高效的配置
技巧一：环境变量指定子 Agent 模型
export CLAUDE_CODE_SUBAGENT_MODEL=haiku设置后，主会话继续用强模型做调度和决策，所有子 Agent 默认用轻量模型做执行。配置一行搞定，适合日常开发。
技巧二：Fork 模式复用缓存
当你对主会话说”从当前上下文 Fork 子进程处理”时，Fork 出的子 Agent 会共享父会话的 Prompt Cache（提示缓存，即已经计算好的上下文 token）。
这意味着：10 个并行 fork 的成本约等于 1 + 9 x 增量部分，而不是 10 x 完整上下文。在大规模并行场景下，这能省下大量费用。
技巧三：声明式 Agent 定义
在项目的 .claude/agents/ 目录下，你可以用 Markdown 文件定义专用 Agent，精细控制：
- 使用哪个模型
- 允许调用哪些工具
- 最大执行轮次
- 记忆范围和隔离方式
这适合那些会反复出现的固定角色，比如 Code Reviewer、Security Auditor。定义一次，长期复用。
常见误区
误区一：所有任务都用最强模型
“反正最强模型什么都能做，用它准没错。“——这是最昂贵的错误。简单任务用强模型，就像开坦克去买菜，到是到了，但油费够买一年的菜了。
正确做法：只在需要深度推理的场景（架构设计、复杂 debug、创意方案）使用旗舰模型。
误区二：每个任务都新开一个独立 Agent
新开 Agent 意味着全新的上下文，之前的对话信息全部丢失。如果任务依赖当前上下文，应该用 Fork 而不是新建。
正确做法：需要当前上下文 → Fork；不需要上下文 → 独立 Agent。
误区三：轻量模型不靠谱
很多人觉得小模型”太弱”不敢用。但对于文件搜索、代码格式化、简单文本处理这类任务，Haiku 级别的模型准确率已经非常高，而且速度是旗舰模型的数倍。
正确做法：先试小模型，效果不够再升级，别一上来就”杀鸡用牛刀”。
误区四：忽略国产模型
对于中低难度的任务，国内模型（如 DeepSeek、Qwen）完全胜任，响应速度还更快（物理距离近），成本也更低。没必要所有事都依赖海外旗舰模型。
总结
模型组合使用的核心逻辑：
- 分级：把任务按所需”思考力”分级——高（架构/创意）、中（日常编码）、低（搜索/格式化）
- 匹配：每个级别匹配对应能力的模型——旗舰、标准、轻量
- 并行：能并行的子任务拆开给多个轻量 Agent 同时执行
- 复用：通过 Fork 和缓存机制，避免重复计算上下文
随着 AI 能力越来越强，旗舰模型的 token 成本只会越来越高、供应也会越来越紧张。学会精细化分配模型的推理能力，就像学会管理团队一样——把对的人放在对的位置上，才是真正的效率。
FAQ
Q: 我怎么判断一个任务该用什么级别的模型？
简单标准：如果任务的”正确答案”几乎只有一个（比如搜索文件、格式化代码），用轻量模型；如果任务需要”权衡取舍”（比如架构选型、方案对比），用强模型。
Q: 模型组合会不会导致结果不一致？
会有这个风险。解决方法是：让强模型做”决策”，轻量模型做”执行”。执行类任务的输出是确定性的，不太受模型能力影响；而决策类任务由强模型保证质量。
Q: 除了 Claude Code，其他工具也能这样用吗？
可以。任何支持多模型调用的框架（如 LangChain、OpenRouter）都能实现类似的调度策略。核心思路是一样的：按任务难度路由到不同模型。
Q: Prompt Cache 是什么？为什么能省钱？
Prompt Cache（提示缓存）是指把已经处理过的上下文 token 缓存起来，后续请求如果前缀相同，就不需要重新计算。这样 Fork 出的子 Agent 只需要为”新增部分”付费，而不是为整个上下文重新付费。