主对话里的 Claude,可以派出"子代理"去单独干活:一个专员有自己独立的脑子,干完只把结论交回来。活多了,还能一次派一队并行。这一页本身,就是 5 个子代理并行写出来的。
子代理（sub-agent）就是主对话里的 Claude 临时"派"出去的一个分身助手，专门去单独完成一件事。它有自己独立的脑子和记忆，跟主对话互不打扰。干完活后，它只把最终结果汇报回来，主对话再转述给你。
想象一个老板，所有杂事都自己一件件做，桌上堆满各种资料。每翻一份新资料，脑子里要记的东西就多一分，很快就被塞得满满当当。事情一多，他反而容易顾此失彼、记混。
换个做法：老板把一件复杂的活外包给一位专员，让他自己关起门去查、去算。专员的草稿和中间过程都留在他自己桌上，老板看不到也不用管。专员做完只递上一句结论，老板桌面始终清清爽爽。
派一个子代理，听起来很专业，其实你只要说一句人话就够了。子代理就像你雇的临时帮手，你把活儿交给它，它干完把结果交回来。你不用懂它内部怎么运转。
直接对 Claude 说"派个代理去做某件事"，比如"派个代理把整个项目里提到飞书的地方都找出来"。也可以不指定，让 Claude 自己判断要不要派。
代理会独立去翻文件、跑多个步骤，这期间不用你操心。它就像帮手去仓库找东西，你在前台等着就行。
代理干完会把结果汇报回主对话，你直接看结论即可。它通常只给你提炼过的答案，不会把翻找的细节一股脑堆给你。
最万金油的帮手，能搜索、能分多步骤完成复杂任务。就像一个什么都能搭把手的全能助理。
只看不改，专门在大量文件里大范围搜索，只给你结论不堆细节。就像派个侦察兵先去摸清情况再回报。
只出方案、拆解步骤，自己不动手干活。就像请的设计师只画图纸，施工交给别人。
你现在做的事，就像开了一家小公司，所有活都你一个人扛——写代码、查 bug、改文案，样样亲力亲为。其实你完全可以给自己招几个"专员"：每个只懂一门手艺，平时待命，活来了就上。在 Claude Code 里建一个专员不用写代码、不用装软件，只要在一个固定文件夹里放一个文本文件（.md），写清楚"它叫什么、什么时候该找它、该怎么干活"就行。一次定义，长期复用。
下面这个例子，给你正在做的"换公司网站"建一个网站文案审阅专员——专门挑 HTML 文案的毛病:
---
name: website-copy-reviewer
description: 当需要审阅公司网站的 HTML 文案时使用本专员，比如把网站从 WordPress 换成自己写的 HTML 后，要逐页检查标题、按钮、介绍段落的措辞是否专业、有无错别字、风格是否统一。涉及挑文案毛病、润色网页用词时，请派它上场。
tools: Read, Grep, Glob
---
你是一名公司网站的文案审阅专员，专门帮非专业用户检查自己用 HTML 写的网站文案。
你的审阅守则：
1. 逐页通读 HTML 中面向访客的文字（标题、按钮、段落、提示语），先挑出错别字、语病和标点错误。
2. 检查用词是否专业、是否符合公司对外形象，避免口语化、含糊或夸大的表述，并给出更合适的改写建议。
3. 检查全站措辞和风格是否统一（例如同一功能不要一会儿叫"提交"一会儿叫"发送"），列出不一致之处。
4. 输出时按页面或段落分组，先指出问题、再给出修改建议，必要时附一句说明为什么这样改，方便用户直接采纳。
| name | 专员的名字，必填，用小写字母加连字符，这里叫 website-copy-reviewer 一看就知道是干文案审阅的。 |
| description | 必填，也是最关键的一句——Claude 全靠它来判断什么时候自动派这个专员，所以要把适用场景写具体写清楚。 |
| tools | 选填，限定它能用的工具；这里只给读取和搜索类工具，因为审文案只需要看不需要改文件。 |
| model | 选填，指定用哪个模型（sonnet/opus/haiku）；这里省略，表示沿用默认模型即可。 |
打开访达，进入用户目录下的 ~/.claude/agents/ 文件夹（没有就新建）。放这里是"全局"的，所有项目都能用；只想在某个项目里用，就放到"那个项目文件夹/.claude/agents/"里。新建文本文件，命名 website-copy-reviewer.md。
把上面示例的全部内容（从开头的三条短横线 --- 到最后一条守则）原样粘进去。再按需微调：description 补充你公司网站的具体情况，正文可加几条你特别在意的点，比如"公司名必须写成 Smart Oasis，不能写错"。
确认文件名是 website-copy-reviewer.md（扩展名 .md，别存成 .txt），保存即可。不需要任何安装或重启，存好就生效。
两种用法：① 点名让它上——"用 website-copy-reviewer 专员审一下我这几页 HTML 文案"；② 让它自动上——你只说"帮我检查下网站文案有没有毛病"，Claude 读到 description 觉得对口，就会自动把它派出来。
之前你只会派一个代理替你跑一趟腿。但当手头有好几摊互不相干的活时，你完全可以一次性把它们都派出去。这就像本来只请一个帮手挨个干，现在改成同时请来一队人各占一摊，活儿齐头并进，总时间一下子就压缩了。
想同时开干，前提是这几摊活之间谁也不等谁。就像炒菜和烧水可以同时进行，但切好的菜得等买回菜才能切。如果 B 必须用到 A 干完的结果，那它俩就只能排队，不能一起派。
派出去的每个代理都在自己的小天地里闷头干，互不打扰、互不知情。它们各自完成后，结果会统一交回主对话这里。主对话像总指挥，收齐所有人的成果再拼装到一起。
你正在读的这一页，就是用这招做出来的。整页有 5 个章节，互不依赖，于是一口气派了 5 个子代理各写一个，它们同时下笔，写完一起交回，再汇总成你眼前这一页。
把力度分成三档就好理解了：① 派一个代理跑一趟腿；② 临时即兴地一次派一队，这就是 multi-agent；③ 用一段脚本把一队代理正经编排起来，带循环、条件、扇出在后台跑，这就是 Workflow（工作流）。简单说，multi-agent 是随手同时叫几个人，Workflow 是写好流程让一队人按章程反复协作、互相核验。Workflow 我们已经在 02 那页 讲过了，这里不再展开。
从轻到重一共四档:① 主对话自己做 → ② 派一个子代理 → ③ 临时派一队 → ④ 用 Workflow 编排。活越大、越能拆成互不依赖的小块、越需要把关核验,就往后面的档位走;反之用前面的档位,省时省钱。
| 什么场景 | 选哪一档 | 为什么 |
|---|---|---|
| 查一个已知的小点（某个 DNS 记录怎么填、某命令参数啥意思） | ① 主对话自己做 | 范围明确、一步到位，开子代理纯属浪费时间和钱。 |
| 不熟领域大范围摸底（比对几家部署平台、调研隧道方案），或要个角色帮你把关 | ② 派一个子代理 | 活有点散、要翻不少资料，交给一个子代理集中搜集汇总更清楚。 |
| 几摊互不影响的活想同时推进（一边整理文案、一边查 DNS、一边研究隧道） | ③ 临时派一队 | 彼此不依赖，并行开几个代理各干一摊，总时间大幅缩短。 |
| 大工程要反复并行还要互相核验（整站迁移全流程逐项落地并交叉检查） | ④ 用 Workflow | 规模大、要多轮并行加核验，脚本编排后台跑最稳；但成本高，想清再启用。 |
前期摸底和单点问题用 ①② 就够：定不下部署平台时，派一个子代理把 Vercel、Cloudflare Pages 横向比一遍再给你建议。真正做整站迁移（HTML 就绪、部署、绑域名、DNS 切换、回滚预案）时这几块相对独立，可用 ③ 临时派一队并行推进；要反复跑、要交叉核验才升到 ④。切 DNS 风险最高，务必新站验证无误后再切，别让代理替你拍板执行。
把临时隧道升级成命名隧道、绑子域名、注册成开机自启服务，这是一条有先后依赖的链路，本质是一摊活，用 ② 派一个子代理把方案查清、步骤列全即可，不必上多代理。若同时还想顺带调研云端部署方案，它和隧道改造互不依赖，可用 ③ 并行开一个代理单独去查。
档位不是越高越好：能用 ①② 解决就别上 ③④，多代理和 Workflow 都更费时间和钱，按活的大小和能否拆分来定。
真实改动留给你按下执行键：切 DNS、改 Webhook、动线上服务，让代理出方案和步骤，最终执行由你自己来，别让它直接拍板上线。
派多代理前先确认互不依赖：一旦几摊活彼此有先后顺序，并行只会乱套，不如排成一条线交给一个代理。