Claude Code的隐藏功能:让AI组团帮你干活

大家好，我是子昕。

上周我用Claude Code分析一个老项目，十几万行代码那种。

我让它搜支付模块相关的逻辑，它翻了几十个文件，搜完之后我发现对话上下文已经被撑满了。

后面再问问题，回答质量直线下降，有效信息全被搜索结果淹没了。

这个问题其实一直存在：AI的上下文窗口就那么大，塞太多中间过程进去，后面的对话质量必然下降。

后来我反应过来，Claude Code有两个专门解决这个问题的功能：Subagent和Agent Teams。

很多人不知道，但用过之后真的回不去了。

简单说：

• Subagent（子智能体）：让Claude派一个“分身”去干活，干完把结果带回来，你的主对话保持干净
• Agent Teams（智能体团队）：让多个子智能体组成团队，分工协作，适合复杂的多模块任务

今天把这两个功能掰开了讲。

一、Subagent：派个分身去干活

解决什么问题

你在和Claude对话，遇到一个子任务——比如搜索代码、审查某个模块、调查一个bug。

如果让Claude直接在当前对话里做，所有搜索过程、中间文件内容全堆在上下文里，越聊越臃肿。

Subagent的思路：不在主对话里做，派一个独立的子智能体去做。

它有自己独立的上下文，干完活把结果返回给主Claude，主Claude看完之后把关键信息总结给你。你的主对话从头到尾是干净的。

可以同时派多个，互不干扰。

怎么用

直接跟Claude说就行：

帮我搜索项目中所有支付相关的代码，不要污染当前对话

或者更直接：

用子智能体帮我做个代码审查，看看 src/auth/ 目录有没有安全隐患

Claude会自动判断需不需要派子智能体，自动选择合适的类型，自动生成任务描述。你不需要写任何参数。

一个容易疑惑的点：子智能体看不到你和主Claude之前的对话内容，但它能访问你的整个项目目录——能读文件、搜代码、执行命令。

它只是不知道你们聊过什么。

主Claude在派它出去的时候，会自动把必要的背景信息写进任务描述里，所以子智能体拿到的指令是完整的。

如果你好奇Claude内部是怎么调用的，长这样：

// 这是Claude内部的调用格式，你不需要自己写Agent({description: "搜索支付代码",subagent_type: "Explore",prompt: "搜索项目中所有支付相关的代码，包括接口定义、回调处理..."})

这段代码是Claude自己生成和执行的。你只管用自然语言说需求。

70多种专业类型

Claude提供了70多种子智能体类型，常用的几个：

注意：Explore和Plan不能编辑文件，但别以为它们只会读代码——它们能执行命令、搜网页、做各种查询，只是不能改你的代码。

前台和后台

默认前台运行：主Claude等子智能体完成后才继续。

也可以后台运行：主Claude不等，继续做别的事，子智能体完成后自动通知。适合耗时的代码库探索。

二、Agent Teams：组团协作

Subagent是单兵作战，Agent Teams是多个子智能体组队协作。

什么时候需要组团

一个子智能体能搞定的事，用Subagent就行。

但有些任务天然需要分工。

比如给项目加一个功能，涉及后端接口、前端组件、测试用例，三个方向可以并行，但之间又有依赖关系（前端得等后端接口出来才能对接）。

这种任务拆给一个子智能体效率太低，组团才合理。

怎么用

最简单的方式，直接描述你的需求：

创建一个Agent团队，扮演不同的角色来阅读这篇文章，反馈阅读后的感受，给到编辑者Agent，汇总反馈修改文章。调整后继续通知其他人阅读，反复几轮，给我最终结果。

Claude会自动处理所有协调工作：创建团队、拆分任务、设置依赖关系、派出合适类型的子智能体、协调它们之间的配合。

全部完成后，汇总结果告诉你。

你也可以更细致地控制，手动指定怎么拆任务、用什么类型的子智能体。

但大多数情况下，让Claude自动处理就够了。

背后发生了什么

虽然你不需要操心这些，但了解一下有助于理解它的工作方式：

1. 主Claude创建团队，设定任务列表和依赖关系
2. 每个子智能体查看任务列表，找到没有被阻塞的任务，领取并开始工作
3. 完成后标记任务完成。主Claude作为“项目经理”收到通知，协调后续——比如发现前端任务的依赖已解除，就安排前端子智能体开始
4. 子智能体之间也可以直接通信，比如后端完成后把接口细节传给前端
5. 全部任务完成后，主Claude执行团队关闭和资源清理

整个过程中，主Claude扮演项目经理的角色——分配任务、协调进度、传递信息。你作为用户，只需要描述需求，然后等结果。

如果中间遇到需要你决策的问题，Claude会来问你。

一个具体的例子

你说：「给项目添加用户头像上传功能」

Claude可能会这样拆：

任务1：实现后端上传接口（POST /api/upload）任务2：实现前端上传组件（依赖任务1完成）任务3：编写测试（依赖任务1和2完成）

然后派出三个子智能体：

• backend-dev（后端架构师类型）→ 领取任务1，开始干活
• frontend-dev（前端开发类型）→ 等任务1完成后，主Claude协调它开始任务2，同时把接口地址和参数格式传过去
• tester（测试自动化类型）→ 等任务1和2都完成后领取任务3

全部完成后，主Claude汇总所有改动告诉你。

三、踩坑实录

坑1：以为要自己写子智能体的prompt

刚接触Subagent的时候，我看到文档里有description、prompt、subagent_type这些参数，以为得自己精心设计调用参数。

花了半小时研究怎么写出好的prompt。

后来发现完全不用。你就跟Claude正常说话，“帮我搜一下支付相关的代码”，Claude自动决定用什么类型的子智能体、自动生成详细的prompt。

那半小时白花了。

当然，如果子智能体的输出不够理想，你可以给Claude更多背景信息，让它生成更精准的prompt。

但你不需要自己去写Agent({...})这种调用。

坑2：看到Idle以为挂了

第一次用Agent Teams，看到子智能体状态变成了“Idle”，心想坏了，是不是出bug了。查了半天。

结果Idle就是“活儿干完了，在等新任务”。完全正常。

主Claude会在需要的时候给它分配新任务或者发消息唤醒它。

坑3：让只读的子智能体去改代码

有一次我想让子智能体重构一段代码，Claude自动选了Explore类型。结果它分析得头头是道，就是不改——因为Explore是只读的，不能编辑文件。

后来弄明白了：需要改代码的任务，得用有写入权限的类型，比如debugger、frontend-developer这些。

现在我如果明确需要子智能体改代码，会在需求里提一嘴，Claude就会选对类型。

四、什么时候用，怎么选

我的策略：

• 改一个函数、修一个明确的bug → 直接让Claude做，不需要子智能体
• 搜索代码、分析模块、代码审查 → Subagent，保持主对话干净
• 多模块协作的复杂任务 → Agent Teams

一个简单的判断标准：

如果任务会产生大量中间过程，而你只关心最终结果——用Subagent。

如果涉及多个有依赖关系的子任务——用Agent Teams。

五、用了一段时间的真实感受

上下文隔离是最大价值

这不是锦上添花，是实打实解决痛点。

以前让Claude分析大项目，对话越聊越乱，回答质量肉眼可见地下降。

现在搜索类的活儿全扔给Subagent，主对话始终聚焦在有效信息上，体验完全不一样。

Agent Teams适合有一定规模的任务

几个文件的小项目用不上，但一旦涉及多个模块的改动，团队协作确实能帮你把复杂任务管理起来。

学习成本几乎为零

你不需要记什么TaskCreate、SendMessage——这些是底层机制，Claude自己用的。你只管用自然语言说需求，Claude来决定要不要组团、怎么分工。

角色在变

用了Agent之后，我发现自己更像项目经理了——描述需求、确认方案、验收结果。

代码是AI写的，但方向是我把控的。这种感觉挺奇妙的。

六、底层原理（感兴趣可以看看）

如果你好奇Agent Teams底层是怎么运作的，这部分简单聊聊。不感兴趣的直接跳过。

Agent Teams的所有状态管理，底层就是读写本地JSON文件。没有数据库，没有远程API。

~/.claude/├── teams/│   └── add-feature/│       └── config.json        # 团队配置：成员列表│└── tasks/    └── add-feature/        ├── 1.json             # 任务1        ├── 2.json             # 任务2        └── 3.json             # 任务3

一个任务文件长这样：

{"id": "1","subject": "实现后端上传接口","status": "in_progress","owner": "backend-dev","blockedBy": []}

任务状态就几种：pending（等待）→ in_progress（进行中）→ completed（已完成）。

子智能体领取任务改状态，完成了再改状态。

有依赖的任务会等前置任务完成后才能被领取。

你可以直接在终端查看进度：

cat ~/.claude/teams/add-feature/config.json   # 看团队成员cat ~/.claude/tasks/add-feature/1.json         # 看任务状态

说实话，第一次理解这个设计时我愣了一下。

复杂的多智能体协作，底层就是读写几个JSON文件？

但仔细想想真的合理——透明、简单、不会断连超时，出问题直接看文件甚至手动改JSON就能修。有时候最简单的方案就是最好的方案。

你平时让AI帮你干活，最头疼的是不是上下文越聊越乱？试试Subagent，可能会有惊喜。

点个关注呗，我会继续用我这半吊子水平为大家带来更多AI编程工具的第一手体验～

「点赞、转发、在看」和大家一起看