给 Claude Code 的子代理分配不同后端：在一把 key 上把便宜活派给便宜模型

在 Claude Code 里，子代理（subagent）是并行处理子任务的轻量执行单元。默认情况下，它们和主代理共用同一个模型。但很多子任务并不需要 Claude 级别的推理能力——用更便宜的模型跑这些活，可以显著降低整体成本。

如果你用的是支持多模型的 API 聚合站（一个 key 调用 Claude、GPT、DeepSeek、Qwen、GLM、Kimi），就可以在同一个 key 下，为不同子代理指定不同后端。

为什么要给子代理分后端

子代理的任务往往边界清晰、输出格式固定，比如：

• 从代码库或文档里检索相关片段
• 对长文件做摘要或提取要点
• 运行 lint 检查并整理报错
• 把结构化数据转成另一种格式

这些任务对模型“聪明程度”的要求不高，但对调用次数敏感。如果全部用 Claude 跑，成本会随子代理数量线性上升；把其中一部分换成更便宜的模型，整体开销会明显下降。

在聚合站上，你按官方价 ×1.3 扣费，贡献 key 按 ×1.1（优质 ×1.2）返 USDC。无论用哪个模型，计费倍率一致，所以选择更便宜的模型直接反映为更低的绝对成本。

哪些子任务可以放心交给便宜模型

判断标准是：任务是否容错、输出是否容易校验。

适合交给 DeepSeek/Qwen/GLM 的子任务：

• 检索与召回：从大段文本中找出相关段落。即使漏掉一两条，主代理也能补查。
• 摘要与压缩：把长文件压成要点。摘要质量有波动，但通常不影响最终决策。
• 格式转换：JSON 转 YAML、表格转列表等机械性工作。
• lint 与静态检查：运行工具并整理输出，模型只负责归纳报错信息。
• 简单分类与打标：给代码片段或文档打标签、判断类型。

建议留在 Claude 的子任务：

• 多步推理与规划：需要拆解问题、权衡方案的场景。
• 代码修改与重构：涉及语义正确性和边界条件。
• 需要严格遵循复杂指令的输出：指令越长、约束越多，弱模型越容易跑偏。
• 最终决策与汇总：主代理本身，以及负责合并子代理结果的节点。

一个实用的原则：如果子任务的输出错了，你能否在廉价的一步内发现并纠正？ 能，就适合下放；不能，就留在 Claude。

在 Claude Code 里怎么配

Claude Code 的子代理定义通常放在项目内的配置文件中（例如 .claude/agents/ 下的 markdown 文件），每个子代理可以声明自己的模型。配置方式取决于你使用的版本和聚合站的兼容层，常见做法有两种：

1. 在子代理定义里指定模型名：把 model 字段设成聚合站支持的模型标识（如 DeepSeek、Qwen、GLM 的对应名称）。
2. 通过环境变量或请求头覆盖：部分聚合站支持在请求级别指定后端，子代理可以通过独立的配置注入。

具体字段名和可用模型标识，请以你所用聚合站的文档为准。关键是：同一个 API key，不同子代理发往不同模型。

怎么验证路由真的生效

配置完之后，不要假设它生效了。用下面几种方法确认：

• 看聚合站的使用记录：大多数聚合站会按模型分别记录调用量和扣费。跑一轮任务后，检查便宜模型是否真的出现了调用记录。
• 对比响应特征：不同模型的输出风格、token 分布、延迟有差异。如果某个子代理的延迟和主代理几乎一样，可能根本没切换。
• 故意制造可区分的任务：让子代理返回它自己的模型标识（如果模型支持），或在提示词里要求它复述系统信息。
• 观察成本变化：跑一个固定任务集，对比切换前后的扣费。如果成本没降，路由大概率没生效。
• 检查错误日志：模型名写错时，聚合站通常会返回明确的错误，而不是静默回退。留意这类报错。

常见坑

• 模型名不匹配：聚合站的模型标识和官方名称可能不同，写错会导致请求失败或回退到默认模型。
• 子代理继承主代理配置：有些配置方式下，子代理会忽略自己的模型设置，直接继承主代理。需要确认优先级。
• 上下文长度差异：便宜模型的上下文窗口可能更小，检索类子代理如果塞入太多内容会被截断。
• 输出格式不稳定：弱模型更容易偏离 JSON 等格式要求，必要时加校验和重试。

小结

给子代理分后端不是“全换成便宜模型”，而是按任务容错度做分层：检索、摘要、格式转换、lint 这类活可以下放，推理、改代码、最终汇总留在 Claude。配完之后用使用记录和成本对比验证路由，避免配置写了却没生效。在按官方价 ×1.3 计费的聚合站上，这种分层能直接把子代理的调用成本压下来。