上一篇三大原语怎么选里，我们给 Subagents 下了定义：一个有独立上下文的分身，重活脏活交给它，主对话只回收结论。
但“知道该派分身”和“把分身用好”之间，还隔着一条实操的沟：配置文件里十几个字段都是干嘛的？为什么有的分身聪明有的笨？怎么让几个分身同时开工？这篇就用素材仓库里一个真实运行的分身，把这条沟填平。
先解剖一只分身：天气代理的完整配置
素材仓库的天气系统里有一个实际在跑的分身——weather-agent，它的定义文件不长，但五脏俱全：
---
name: weather-agent
description: Use this agent PROACTIVELY when you need to fetch weather data
for Dubai, UAE...
tools:
- "Read"
- "Skill"
model: sonnet
color: green
maxTurns: 5
permissionMode: acceptEdits
memory: project
skills:
- weather-fetcher
---
You are a specialized weather agent that fetches weather data for Dubai...
拆开看，这几行配置各管一件事：description 告诉主 Claude“什么时候该派我”；tools 圈定它能用什么工具：只准读和调技能，写文件？没这门手艺；model: sonnet 指定它用哪个模型跑（查天气不需要 Opus 级别的智商，省钱）；maxTurns: 5 给它设了止损线，最多干五轮必须收工；skills 是最妙的一笔——把查天气的操作手册直接预装进它的脑子，出厂即上岗；memory: project 让它每次报完温都记进项目记忆，历史数据越攒越全；color: green 纯属界面观感，任务列表里一眼认出这只绿色的分身。
一个不到二十行的文件，定义了一个有手艺、有边界、有记忆、有止损的岗位。这就是分身的全部家当：它不是什么魔法，就是一份写得足够好的岗位说明书。
16 个字段不用背，分四组就够
官方文档列了 16 个 frontmatter 字段，第一次看很容易劝退。但按“你给员工定什么”来分组，其实就四类：
身份组：name（必填，小写字母加连字符）和 description（必填）。description 是整个分身最重要的字段：主 Claude 就是靠读它来决定“这活归不归你管”。想让 AI 主动派活，就在里面写 PROACTIVELY；想让它只在你点名时出场，就把描述写收敛些。
权限组：tools（白名单，不写就继承全部工具）、disallowedTools（黑名单）、permissionMode（权限模式，比如 acceptEdits 让它免确认改文件）、maxTurns（轮数止损）。这组的职责是回答一个问题：你放心让它自己干到什么程度。
资源组：model（sonnet / opus / haiku 或 inherit）、effort（思考努力档位）、skills（预载技能，注意是全文注入不是随取随用）、mcpServers（外挂工具服务）、memory（持久记忆，user 跨项目 / project 进 git / local 本地私有）。
行为组：background: true 让它常驻后台跑；isolation: "worktree" 让它在独立的 git 工作树里干活，不碰你的工作区（没产生改动会自动清理）；color 管显示颜色；initialPrompt 是开机第一句话。
日常 80% 的场景，你只需要动身份组和权限组。资源组里的 model 值得一提：素材仓库的实践是“查数据用 haiku、写代码用 sonnet、啃硬骨头才上 opus”，分身的价值之一就是让不同价位的模型各司其职。
上下文隔离：分身真正的护城河
第 3 篇埋过一个钩子：分身干了什么，主对话是看不见的。这里把这笔账算清楚。
不用分身时，你让主 Claude 调研一个问题，它读 20 个文件、跑 12 次 grep、钻 3 条死胡同，每一步都实实在在占着主对话的上下文。等它终于给出结论，你的上下文也已经被过程垃圾塞满，离“变钝”更近了一步。
派分身时，这 35 次操作全部发生在分身自己的上下文里，主对话只收到一份干净的结论。素材仓库把它总结成一句话：**派活前先问自己，我要的是工具的输出本身，还是只要一个结论？**只要结论的活，都值得派分身。
这里面还藏着一个反直觉的用法：分身与分身之间也是隔离的，所以可以让一个分身写代码、另一个分身做审查——同样的模型，一个刚写完的思路骗不过一双刚睁开的眼睛。这相当于把“测试时间算力”买来当质量保险：多花一份算力，换一层独立视角的把关。
分身可以再派分身，但要控制层级
子代理可以继续派子代理，但不是无限套娃：当前默认最多嵌套到主对话以下三层；到达上限后，就不能继续派了。你也可以通过工具权限或配置把嵌套关掉。
嵌套适合能自然拆成子任务的工作，但每多一层都会增加成本和验收难度。普通的三路并行调研，仍建议让主对话当编排者：主 Claude 分别派三个分身，各收各的结论。分层清晰，权责分明，也方便你在任务列表里看清每个分身在干嘛。
出厂自带的五个分身，先认识再自建
很多人不知道 Claude Code 出厂就带了五个分身，写自己的之前值得先摸一摸：
| 分身 | 模型 | 特点 |
|---|---|---|
general-purpose |
继承 | 万能多步任务，调研和搜索的默认选择 |
Explore |
默认继承主对话模型 | 只读搜索专精：找文件、查代码、答“这代码库怎么组织” |
Plan |
继承 | 只读，专为规划模式服务：写代码前先探索方案 |
statusline-setup |
sonnet | 配置状态栏的小工具分身 |
claude-code-guide |
haiku | Claude Code 官方文档问答专员 |
两个细节值得玩味：Explore 默认继承主对话模型；如果想让搜索更省钱，可以自行配置它使用 haiku。它和 Plan 都是只读的：搜索分身不需要写权限，规划阶段也不该改代码。官方自己就在践行“按任务配分身、按需给权限”的原则。
让分身们同时开工：Agent Teams
一只分身是外包，一群分身就是外包公司。Claude Code 支持让多个分身并行干活，常见搭配是 tmux 加 git worktrees：每个分身在一个独立的工作树里改代码，互不踩脚。
典型场景：三个功能各派一个分身同时开发，你在任务列表里看着三个进度条一起跑。配合第 7 篇会讲的权限配置，你能做到“每个分身只能碰自己的目录”。 Boris Cherny 在推里多次演示过这个玩法——他管这叫并行开发，一个人带一支不需要发工资的队伍。
不过要提醒一句：并行是进阶玩法，前提是你已经会用单只分身并且知道怎么验收结果。先跑通一只，再扩编。
动手清单：从零配一只分身
- 创建方式两条路：直接对 Claude 说“帮我创建一个做 XX 的分身”，让它生成配置文件到
.claude/agents/<name>.md；或者自己在该目录编写 Markdown 配置文件 description写“什么时候用我”，而不是“我是谁”，它决定主 Claude 会不会想到派它- 工具白名单按最小权限给：搜索分身就别给 Write，审查分身就别给 Bash
- 简单任务配 haiku，写代码配 sonnet，别让分身的模型比任务贵
- 有固定操作流程的，用
skills预载进去，别指望它每次自己悟 - 要长期积累经验的（代码审查、项目问答），加
memory: project - 要并行开发的，上
isolation: "worktree"，改完自动合并回工作区 - 配完先用一个真任务试跑一轮，看
maxTurns够不够、工具权限缺不缺，再固化
分身配好了，下一篇我们看它的近亲：Skills——怎么把团队的操作知识写成 AI 随取随用的手册，以及那几条官方团队自己总结的反直觉设计原则。