主题
Subagents 子代理
Subagent 是一个独立上下文的子任务执行者。主会话把活派给它，它自己去读文件、跑命令，最后只把结论交回来。
核心价值：上下文隔离。
搜索一个函数在哪定义，可能要读 30 个文件。如果在主会话里做，这 30 个文件的内容会永久留在上下文里，后面每一轮都要为它们付费。交给 subagent，主会话只收到一句「在 service/auth.go:142」。
用法
直接说就行：
用一个子代理去搜索所有调用了 deprecated API 的地方，只告诉我文件和行号或者显式指定：
起三个子代理并行：一个查前端调用、一个查后端实现、一个查测试覆盖自定义 Subagent
放在 .claude/agents/<name>.md（项目级）或 ~/.claude/agents/<name>.md（个人级）：
markdown
---
name: sql-reviewer
description: 审查 SQL 变更的跨数据库兼容性。当改动涉及 migrations/ 或原生 SQL 时使用。
tools: Read, Grep, Glob
model: claude-haiku-4-5-20251001
---
你是数据库兼容性审查员。
检查这些点：
1. 是否用了 MySQL 专有函数（`IF()`、`GROUP_CONCAT`、`ON DUPLICATE KEY`）
2. 是否用了 PostgreSQL 专有语法（`RETURNING`、`::` 转换、数组类型）
3. SQLite 是否支持（`ALTER COLUMN` 不支持，只能 `ADD COLUMN`）
4. 保留字是否加了引号（`group`、`key`、`order`）
只输出问题清单，格式：`文件:行号 — 问题 — 建议改法`。
不要修改任何文件。frontmatter 字段
| 字段 | 作用 |
|---|---|
name | 代理名，用来 @ 调用 |
description | 什么时候用它，主模型据此自动委派 |
tools | 限制它能用哪些工具（不写 = 全部） |
model | 指定用哪个模型 |
用 model 省钱
这是 subagent 最实用的用法：把机械活派给便宜模型。
markdown
---
name: file-finder
description: 在代码库里定位文件和符号定义。
tools: Grep, Glob, Read
model: claude-haiku-4-5-20251001
---
你只负责定位，不做分析。
输出格式：一行一个 `路径:行号 — 一句话说明`。
最多 20 条。搜索这种活 Haiku 完全够用，价格是 Opus 的五分之一。主模型继续用 Opus 干需要脑子的事。
| 任务类型 | 建议模型 |
|---|---|
| 搜索、定位、列清单 | claude-haiku-4-5-20251001 |
| 读代码、总结、写测试 | claude-sonnet-4-6 |
| 架构设计、疑难 bug、代码审查 | claude-opus-4-8 |
快米兔 API 上的 subagent
Subagent 的每次调用都是独立的 API 请求，会按对应模型单独计费。 在 控制台日志 里能清楚看到 Haiku 和 Opus 的调用分别有多少——这是校验「省钱策略有没有生效」的最直接方式。
并行
多个 subagent 可以并行跑，适合：
- 跨模块调研：「前端怎么调的」「后端怎么实现的」「测试覆盖到没有」
- 多方案对比：让三个 agent 分别设计三种方案，主模型综合
- 大范围审查：按目录切片，每个 agent 审一块
并行起 4 个子代理，分别审查 router/ controller/ service/ model/ 四个目录，
每个只报告「明确的 bug」，不要报风格问题什么时候不该用
| 场景 | 为什么不适合 |
|---|---|
| 需要来回追问的任务 | Subagent 拿不到主会话的完整上下文，问不清楚 |
| 改代码 | 隔离上下文意味着它看不到你刚才的讨论，容易改跑偏 |
| 只读一两个文件 | 起 agent 的开销比直接读还大 |
判断标准：这个任务会不会产生大量「过程垃圾」而结论很短？会 → 用 subagent。
验证
列出当前可用的所有 subagent在 控制台日志 里按模型筛选，能直观看到 subagent 用的是哪个模型——如果你配了 Haiku 但日志里全是 Opus，说明 model 字段没生效（检查模型 ID 拼写）。