Claude Code 省钱实战，用 Subagent 交接代替直接切换模型

切换模型的“省钱”陷阱：为什么直接降级反而更贵？

在高频使用 Claude Code 进行开发时，很多资深开发者都有一个直觉性的“省钱策略”：当处理完复杂的架构设计或核心逻辑编写（通常由 Opus 模型完成）后，面对一些简单的收尾工作，比如格式化代码、写单元测试或整理注释，手动将模型切换到 Haiku 或 Sonnet，试图利用低价模型节省 Token 费用。

这个逻辑听起来无懈可击：大材小用是浪费，小材大用才划算。但在 Claude Code 的底层机制下，这往往是一个昂贵的误区。

要理解这个反直觉的现象，必须深入Prompt Caching（提示词缓存）的工作原理。Claude Code 的缓存并非基于简单的 Key-Value 映射，而是基于前缀匹配。你可以把一次会话的上下文想象成搭积木：最底层是 System Prompt 和工具定义，中间是漫长的历史对话，最顶层是你当前的指令。API 计费时，只要底层的“积木”没有变动，上层的历史对话就能享受极低的缓存读取费率（通常比全价计算便宜一个数量级）。

然而，模型切换会直接打断这个前缀。

当你决定从 Opus 切换到 Haiku 时，对于 API 而言，这不仅仅是换了一个“大脑”，而是开启了一个全新的会话上下文。Haiku 模型没有之前那几十万 Token 的“记忆缓存”。为了让它理解当前的项目状态、文件结构和之前的决策逻辑，你必须将之前所有的对话历史重新发送给 Haiku。

这意味着什么？意味着那些原本可以享受“缓存读取优惠价”的历史 Token，现在必须全部按“全价输入费”重新计算一遍。

让我们算一笔具体的账。假设你与 Opus 进行了长对话，积累了 100k Tokens 的上下文，其中 90k 命中了缓存。

• 方案 A（错误做法）：直接切换模型。新模型需要重新处理这 100k Tokens 的上下文。即使 Haiku 的单价很低，但 100k 的全价输入费用，往往远超让 Opus 直接利用缓存处理剩余简单任务的费用。更糟糕的是，如果任务稍微复杂，Haiku 因为缺乏深层上下文可能导致幻觉或错误，修复错误的成本更是无法估量。
• 方案 B（正确做法）：保持主会话不变，利用Subagent（子代理）进行任务交接。

这就是为什么在 Claude Code 的高阶用法中，“切换模型”从来不是首选，而“任务交接”才是核心。真正的降本路径，不是让廉价模型去重读历史，而是让昂贵模型把历史压缩成精华，再交给廉价模型去执行。

Subagent 交接术：用“摘要”代替“重载”

既然直接切换模型行不通，那么如何在不丢失上下文的前提下，利用低成本模型处理后续任务？答案在于Subagent Handoff（子代理交接）机制。

这一模式的核心思想是：让主 Agent（Opus）充当“项目经理”，负责总结现状；让子 Agent（Haiku）充当“执行工程师”，只关注具体任务。

1. 交接的正确姿势

不要试图把整个聊天历史塞给新模型。正确的流程是利用 Claude Code 的内置能力，启动一个指定了低成本模型的 Subagent。

在主会话中，你可以明确指示：

“当前核心逻辑已完成，接下来需要编写单元测试。请启动一个 Haiku 模式的子代理，我将把当前的任务背景和关键文件状态总结给你，由它来完成测试代码的编写。”

此时，主 Agent（Opus）会执行一个关键动作：生成交接摘要。它不会机械地复制粘贴历史记录，而是基于对项目的深刻理解，提取出子任务所需的最小必要信息。这包括：

• 当前修改过的文件列表及其核心变更点。
• 尚未完成的待办事项（Todo）。
• 关键的架构约束和已知的坑点。

这个摘要通常只有几百到几千 Token，却承载了数万 Token 历史对话的精髓。随后，这个简短的摘要被发送给新启动的 Haiku Subagent。

2. 成本结构的根本性逆转

在这种模式下，成本结构发生了质的变化：

• 主会话（Opus）：继续维持原有的长上下文，缓存命中率保持高位。生成摘要的成本极低，因为这是基于已有上下文的自然延伸。
• 子会话（Haiku）：启动时仅需处理极短的“交接摘要”和具体的任务指令。由于上下文极短，即使没有缓存，全价处理的总费用也微乎其微。

这种“压缩 - 传递”的机制，完美避开了“重载历史”的费用黑洞。实测数据显示，对于中等规模的迭代任务，采用 Subagent 交接相比直接切换模型，Token 成本可降低60%-80%，同时响应速度显著提升，因为子代理不需要在海量无关信息中检索线索。

3. 实战中的自动化触发

在高级工作流中，你甚至可以将这一过程自动化。通过配置Skills或自定义命令，当检测到任务进入“实施”或“测试”阶段时，自动触发 Subagent 调用。

例如，定义一个/test-with-haiku技能：

name: test-with-haiku description: 使用低成本模型快速生成单元测试 model: haiku context: fork # 内部逻辑自动包含当前文件的变更摘要

这样，开发者无需手动判断何时切换，系统会自动以最优的成本结构调度模型资源。这不仅省了钱，更重要的是保持了思维流的连续性——你不需要中断思路去配置新会话，一切都在当前的工程上下文中自然发生。

最小权限原则：子代理的安全围栏

引入 Subagent 不仅是为了省钱，更是为了安全。在复杂的开发场景中，让一个低成本模型拥有与主 Agent 同等的权限是危险的。Haiku 等快速模型虽然在简单任务上表现优异，但在处理复杂逻辑判断时，出现幻觉或误操作的概率相对较高。

因此，在启动子代理时，必须严格遵循最小权限原则（Principle of Least Privilege）。

1. 限制写入权限

Claude Code 的内置Explore模式和Plan模式为此提供了绝佳的原生支持。这些模式在系统提示词层面就明确了“只读”或“计划”的定位，并在代码层面通过disallowedTools黑名单剥夺了写入和编辑工具的权限。

当你启动一个用于代码审查或方案调研的 Subagent 时，应显式指定其运行在受限模式下：

• 禁止文件修改：确保子代理只能读取代码、分析逻辑，而不能直接执行write或edit操作。
• 屏蔽项目特定规则干扰：通过设置omitClaudeMd: true，防止子代理被项目中某些过于激进或特定的.claude/CLAUDE.md规则带偏，使其专注于通用的逻辑验证。

这种设计相当于给子代理戴上了“手套”。它可以随意翻看书本（代码库），但不能在书上乱涂乱画。只有当它输出建议后，由主 Agent（拥有更高智能和更全面视角的 Opus）来审核并执行实际的修改操作。

2. 爆炸半径控制

在多 Agent 协作中，任何一个节点的错误都可能产生连锁反应。通过 Subagent 隔离，我们将潜在的“爆炸半径”限制在了一个极小的范围内。

假设子代理在执行某个脚本时陷入了死循环，或者错误地解析了某个依赖关系，由于它运行在独立的沙箱上下文中，且权限受限，这种错误不会污染主会话的长期记忆，也不会破坏核心代码库。主会话可以随时终止子任务，重新发起一个新的、修正后的子代理请求，而无需回滚整个项目状态。

这种架构上的解耦，使得团队可以放心地在日常开发中大量使用低成本模型进行辅助工作，如日志分析、临时数据清洗、文档生成等，而无需担心安全性问题。

Profiles 配置实战：打造团队的降本增效模板

对于团队开发而言，将上述技巧固化为可复用的Profiles 配置是最大化收益的关键。通过在config.toml或项目级的配置文件中预定义不同场景的模型策略，可以确保每个成员都在最优的成本轨道上运行。

1. 分级模型配置策略

我们可以设计三套标准的 Profiles，覆盖绝大多数开发场景：

• Architect Profile（架构师模式）：

  • 模型：Opus
  • 适用场景：项目初始化、核心算法设计、复杂 Bug 排查、重构方案制定。
  • 配置特点：启用完整的工具集，允许深度文件读写，保留超长上下文缓存。
  • 触发方式：默认模式，或通过/architect命令激活。

• Worker Profile（工人模式）：

  • 模型：Haiku / Sonnet
  • 适用场景：单元测试生成、代码格式化、简单函数实现、文档补全。
  • 配置特点：强制通过 Subagent 启动，继承主会话的摘要上下文，禁用非必要 MCP 工具，限制最大 Token 输出。
  • 触发方式：主会话中调用/implement或/test时自动挂载此配置。

• Reviewer Profile（审查员模式）：

  • 模型：Sonnet
  • 适用场景：代码审查、安全漏洞扫描、合规性检查。
  • 配置特点：只读权限（Read-Only），聚焦于静态分析和逻辑推演，禁止任何写操作。
  • 触发方式：/review命令。

2. 配置示例与落地

在实际的config.toml中，可以利用条件判断和宏定义来简化这一过程。虽然原生配置语法有限，但结合 Shell 脚本或封装好的 CLI 别名，可以实现动态切换。

例如，定义一个别名脚本cc-worker：

alias cc-worker="claude --model haiku --system-prompt 'You are a focused implementation agent. Context provided by manager.' --no-interactive-history"

更进阶的做法是利用 Claude Code 的Skills机制。创建一个名为cost-effective-dev的技能包，在其中定义好不同任务的路由规则。当用户输入“帮我写个登录接口”时，Skill 自动识别这是一个实施类任务，后台静默启动 Haiku Subagent 并注入必要的上下文摘要；而当用户问“这个架构有什么风险”时，则保留在 Opus 上下文中进行深入推理。

3. 团队级的成本意识

推行这套配置不仅仅是技术调整，更是开发文化的转变。它要求团队成员建立“上下文是有成本的”这一意识。

• 避免无效闲聊：在与高成本模型对话时，保持指令的精准和简洁，减少无意义的寒暄，这直接提升了缓存的有效利用率。
• 善用摘要：养成在长任务节点主动要求模型“总结当前进展”的习惯，这不仅有助于人类理解，更为后续的 Subagent 交接做好了数据准备。
• 定期清理：对于不再需要的长会话，及时归档或重启，避免维护过大的“僵尸上下文”占用预算。

通过这种精细化的管理，一个中型开发团队完全可以将每月的 AI 辅助开发成本控制在原来的 30% 以内，同时获得更快的响应速度和更安全的操作流程。

构建可持续的智能开发工作流

Claude Code 的强大之处，不在于它能单次生成多少代码，而在于它能如何融入并优化整个软件工程的生命周期。从最初的“暴力试用”到如今的“精细化运营”，我们对 AI 编程工具的理解正在经历一场深刻的变革。

真正的效率提升，来自于对工具特性的深刻洞察与合理编排。Subagent 交接解决了成本与上下文的矛盾，最小权限原则平衡了速度与安全的冲突，而Profiles 配置则将最佳实践固化为团队的肌肉记忆。

在这个工作流中，Opus 不再是事必躬亲的“全能保姆”，而是运筹帷幄的“技术总监”，负责把握方向、解决难题和审核质量；Haiku 等轻量模型则成为了高效执行的“初级工程师”，承担了大量重复性、标准化的编码任务。两者各司其职，通过清晰的接口和协议协同工作。

这种模式不仅适用于个人开发者，更是未来 AI 原生团队的标准作业程序（SOP）。随着模型能力的不断进化和 API 定价策略的调整，具体的参数可能会变，但“分层调度、按需加载、安全隔离”的核心架构思想将长期有效。

当你下一次面对高昂的 Token 账单，或者在长对话中感到模型响应变慢时，不妨停下来想一想：是否还在试图用一把锤子敲所有的钉子？试着退后一步，让主 Agent 做个总结，然后派出一个轻装的子代理去完成任务。你会发现，省钱只是副产品，随之而来的是更加清晰、可控且高效的开发体验。这才是驾驭 AI 编程工具应有的姿态。