Claude Code 子代理和代理团队：实用指南

你可能看到过“子代理”、“代理团队”、“编排”等词汇，并想知道自己是否错过了什么。简短回答：对于大多数任务来说，没有。但对于大型工作来说，是的，并且值得了解。

让我们在不使用术语的情况下解开它。

子代理到底是什么

子代理是一个具有自己上下文、提示和工具权限的专业助手。

当主代理遇到一个定义明确的子任务时，它会将其委派给子代理。子代理在自己的上下文窗口中工作，完成任务后仅返回结果。主代理不会被其完整历史污染上下文，只会得到结论。

这就是重点：保持主代理的上下文清晰。与其让一个代理在50,000个令牌的文件搜索中淹没，不如让一个子代理进行搜索并报告三行有用的信息。

你可以在项目的.claude/agents/文件夹中声明你的子代理。每个子代理都有一个名称、一个说明何时使用的描述和一个系统提示。

---
name: test-writer
description: 当需要编写或修复测试时使用
---
你编写测试。你以覆盖边缘情况为目标，
而不是快乐路径。你从不接触生产代码。

代理团队，进一步提升

代理团队是内置于Claude Code中的多代理编排器。仍在实验阶段，默认情况下禁用，但它是一个可靠的入门点。

其理念是：一个主代理分解一个大任务，将每个部分委派给一个专业代理（具有自己的模型、提示、工具），这些专业代理在共享文件系统上并行工作，结果返回给主代理。

如果“委派给专业人员”听起来像子代理，那是正常的。代理团队是将这个想法推到真正并行运行多个代理，而不仅仅是一个接一个。

除了内置的，还有第三方编排器如Multiclaude和Gas Town。它们有自己的见解，这使它们成为你开始时的良好起点：它们为你做决定，直到你建立自己的习惯。

什么时候需要（什么时候不需要）

让我们明确：对于95%的代理辅助任务来说，多代理编排是没有意义的。对于你大多数日常工作来说，单个代理更快更简单。

目前，多代理仍然是一种昂贵且实验性的方式来处理大型项目。

你需要它当：

• 项目分成真正独立的部分，涉及不同的文件。
• 单个上下文窗口无法容纳整个内容。
• 你想并行化一个广泛的重构或一个仓库范围的迁移。

你不需要它用于修复错误、专注的功能或任何可以在一个头脑中完成的事情。

陷阱在于为一个五分钟内单个代理就能完成的任务启动一个十代理的“团队”。你为任务从未要求的并行性支付了令牌和复杂性的代价。

真正的问题：可见性

这里有一个不被充分讨论的问题。当你运行几个子代理或一个代理团队时，你会失去线索。

一个主代理委派给五个专业代理。哪个在工作？哪个完成了？哪个在等待决策？在终端中你看到的是滚动的文本墙，而你无法分辨谁在做什么。

这就是视觉仪表板改变一切的地方。AgentsRoom将每个代理和每个子代理显示为自己的瓷砖，状态一目了然。你可以看到委派的发生，看到谁在等待你的回复，看到谁崩溃了。文本墙变成了一张可读的地图。

没有这种视图，多代理编排仍然是一个令人印象深刻但日常无法管理的演示。有了它，它就成为了一个你真正使用的工具。

从哪里开始

不要直接跳到一个八代理的团队。

从一两个子代理开始，用于精确、重复的任务：一个编写测试，一个搜索代码库。你会很快感受到对主代理上下文的提升。

一旦这种机制变得自然，为清晰分割的工作启用代理团队。关注谁在做什么，在执行前批准计划，并在审查成为瓶颈时立即停止。

多代理奖励那些在启动前进行结构化的人，而不是那些启动最多代理的人。