Claude Code Agent Teams vs Sub-Agents: Which Pattern Should You Use?Claude Code 智能体团队与子智能体：你应该使用哪种模式？
Claude Code agent teams let agents communicate directly via a shared task list. Learn when to use teams vs sub-agents and what the token cost difference is.Claude Code 智能体团队允许智能体通过共享任务列表直接进行交流。了解何时使用团队模式，何时使用子智能体模式，以及两者在 Token 成本上的差异。
Two Ways to Orchestrate Claude Agents — And Why the Choice Matters编排 Claude 智能体的两种方式——以及为何选择至关重要
If you’ve started experimenting with multi-agent workflows using Claude Code, you’ve probably run into a fork in the road: do you build with a sub-agent pattern, where one orchestrator spawns and directs other agents, or do you use agent teams, where agents coordinate through a shared task list?如果你已经开始尝试使用 Claude Code 进行多智能体工作流实验，那么你很可能面临一个分岔路口：是采用子智能体模式（由一个编排器生成并指挥其他智能体），还是采用智能体团队模式（智能体通过共享任务列表进行协作）？
Both approaches work. Both are supported in Claude Code. But they behave very differently under the hood, and picking the wrong one can cost you real money in tokens, slow your pipeline down, or introduce coordination bugs that are hard to debug.这两种方法都行得通，且都受 Claude Code 支持。但它们在底层运行机制上有很大不同，选择错误的模式可能会导致你在 Token 上花费真金白银，拖慢流水线速度，或引入难以调试的协作漏洞。
This article breaks down Claude Code agent teams vs sub-agents — what each one actually is, how the token economics compare, and which pattern fits which kind of problem.本文将深入剖析 Claude Code 智能体团队与子智能体模式——它们究竟是什么，Token 经济性如何比较，以及哪种模式适合哪类问题。
What Sub-Agents Are and How They Work什么是子智能体及其工作原理
The sub-agent pattern is the older, more familiar approach to multi-agent orchestration. At its core, it’s hierarchical: you have one orchestrator agent that breaks down a task, delegates pieces to specialized sub-agents, collects their outputs, and synthesizes a result.子智能体模式是一种更古老、更常见的多智能体编排方法。其核心是层级制：你拥有一个编排器智能体，负责将任务拆解，将部分任务委派给专门的子智能体，收集它们的输出，并综合得出最终结果。
Here’s the basic flow:基本流程如下：
- The orchestrator receives a task编排器接收任务
- It reasons about how to decompose the task它对如何拆解任务进行推理
- It spawns a sub-agent (or calls one sequentially) with a specific instruction它带着具体指令生成一个子智能体（或依次调用子智能体）
- The sub-agent completes its work and returns a result to the orchestrator子智能体完成工作并将结果返回给编排器
- The orchestrator incorporates that result into its own context and continues编排器将该结果合并到自己的上下文中并继续执行
Other agents start typing. Remy starts asking. 其他智能体开始打字。 Remy 开始提问。
Scoping, trade-offs, edge cases — the real work. Before a line of code.范围界定、权衡取舍、边界情况——这些才是真正的工作。在写下一行代码之前。
Each sub-agent call happens in a fresh context window. The sub-agent doesn’t know about other sub-agents unless the orchestrator explicitly tells it. Everything flows through the orchestrator.每次调用子智能体都在一个全新的上下文窗口中进行。除非编排器明确告知，否则子智能体不知道其他子智能体的存在。一切都通过编排器进行流转。
Where Sub-Agents Excel子智能体的优势所在
Sub-agents are a natural fit for tasks with clear sequential dependencies. If step B needs the output of step A, and step C needs step B’s output, the orchestrator can chain these cleanly — collecting each result and passing it forward.子智能体非常适合具有明确顺序依赖的任务。如果步骤 B 需要步骤 A 的输出，而步骤 C 需要步骤 B 的输出，编排器可以清晰地将这些步骤串联起来——收集每个结果并将其传递下去。
They’re also good when you need tight control. Because the orchestrator sees everything, it can catch errors, retry failed steps, and adjust the plan as results come in. The orchestrator is the single source of truth.当需要严密控制时，它们也表现出色。因为编排器可以看到一切，它可以捕捉错误、重试失败的步骤，并根据结果调整计划。编排器是单一事实来源。
The Hidden Cost of Hierarchical Control层级控制的隐形成本
Here’s where sub-agents get expensive: the orchestrator’s context window grows with every sub-agent it manages.这就是子智能体变得昂贵的原因：编排器的上下文窗口会随着它管理的每个子智能体而增长。
Each time a sub-agent returns a result, that result gets appended to the orchestrator’s running context. If you’re running 10 sub-agents that each produce 2,000 tokens of output, your orchestrator is now sitting on 20,000+ tokens of accumulated state — before it’s even written its final synthesis.每当子智能体返回一个结果，该结果就会被附加到编排器的运行上下文中。如果你运行 10 个子智能体，每个产生 2,000 个 Token 的输出，那么在编排器进行最终综合之前，它就已经处理了 20,000 多个 Token 的累积状态。
For complex tasks with many steps or high-output sub-agents, this blows up fast. You’re paying for those tokens every time the orchestrator makes another call.对于具有许多步骤或高输出子智能体的复杂任务，成本会迅速膨胀。每次编排器进行另一次调用时，你都在为这些 Token 付费。
What Claude Code Agent Teams Are什么是 Claude Code 智能体团队
Agent teams are a newer coordination pattern that Claude Code supports. The key architectural difference: agents on a team don’t communicate exclusively through a central orchestrator. Instead, they share a task list (or shared state store), and each agent can read and write to that shared structure directly.智能体团队是 Claude Code 支持的一种较新的协作模式。其关键架构差异在于：团队中的智能体并非仅通过中央编排器进行交流。相反，它们共享一个任务列表（或共享状态存储），每个智能体都可以直接读取和写入该共享结构。
Think of it less like a manager-and-employees hierarchy and more like a kanban board. Tasks sit in a shared queue. Agents pick up work, complete it, post their output, and make new tasks available for other agents. Any agent can see what’s been done.与其将其视为经理与员工的层级关系，不如将其想象成看板。任务位于共享队列中。智能体领取工作、完成工作、发布输出，并为其他智能体提供新任务。任何智能体都能看到已完成的工作。
This changes the coordination model fundamentally.这从根本上改变了协作模型。
How Task Sharing Works in Practice任务共享在实践中是如何运作的
In a Claude Code team setup, the workflow typically looks like this:在 Claude Code 团队设置中，工作流通常如下所示：
- A coordinating agent (or the human) seeds the task list with top-level work items协调智能体（或人类）将顶层工作项填充到任务列表中
- Each agent on the team polls or monitors the shared list for tasks it can handle团队中的每个智能体轮询或监控共享列表，寻找它可以处理的任务
- An agent picks up a task, does the work, writes its output to the shared state智能体领取任务，完成工作，并将输出写入共享状态
- Other agents read that output when they need it — they don’t need it routed through an orchestrator其他智能体在需要时读取该输出——它们不需要通过编排器进行路由
- New tasks are created as needed by any agent in the team团队中的任何智能体都可以根据需要创建新任务
Communication is lateral rather than vertical. Agents are aware of each other’s work through the shared state, not through explicit orchestrator routing.交流是横向而非纵向的。智能体通过共享状态了解彼此的工作，而不是通过明确的编排器路由。
What “Shared Task List” Actually Means“共享任务列表”的真正含义
In implementation terms, the shared task list is typically a structured data store — often a JSON object, a file, or a database row — that all agents can read from and write to. Claude Code’s approach allows agents to operate on this shared context without each agent needing to hold the entire history in its own context window.在实现层面，共享任务列表通常是一个结构化数据存储——通常是 JSON 对象、文件或数据库行——所有智能体都可以对其进行读写。Claude Code 的方法允许智能体在不要求每个智能体在自己的上下文窗口中保存全部历史记录的情况下，操作此共享上下文。
Each agent only needs to load the parts of the shared state relevant to its current task. The full history lives in the shared store, not in any individual agent’s context.每个智能体只需要加载与当前任务相关的共享状态部分。完整历史记录存在于共享存储中，而不是任何单个智能体的上下文中。
The Core Architectural Differences核心架构差异
Remy is new. The platform isn't. Remy 是新的。 平台不是。
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM. Remy 是多年平台工作的最新成果。 并非草率包装的 LLM。
Let’s put the two patterns side by side on the dimensions that actually matter.让我们从真正重要的维度将这两种模式进行对比。
| Dimension | Sub-Agent Pattern | Agent Team Pattern |
|---|---|---|
| Communication structure | Hierarchical (all through orchestrator) | Peer-to-peer (via shared state) |
| Context per agent | Orchestrator grows large; sub-agents stay small | Each agent loads only what it needs |
| Parallelism | Possible but orchestrator must coordinate | Natural — agents work independently |
| Error handling | Orchestrator catches and responds | Requires team-level error conventions |
| Debugging | Easier to trace (single control flow) | Harder to trace (distributed updates) |
| Token efficiency | Poor at scale (orchestrator accumulates) | Better at scale (distributed context) |
| Sequential task dependencies | Strong | Requires careful task ordering |
| Setup complexity | Lower | Higher |
Neither pattern is objectively better. The right choice depends on your task structure.没有哪种模式在客观上更好。正确的选择取决于你的任务结构。
Token Cost: The Real Difference at ScaleToken 成本：规模化下的真正差异
This is where the two patterns diverge most sharply, and it’s worth spending time on it.这是两种模式分歧最严重的地方，值得花时间深入探讨。
Token Accumulation in the Orchestrator编排器中的 Token 累积
In a sub-agent setup, every result flows back to the orchestrator. That means the orchestrator’s prompt gets longer with each round of delegation. In practical terms:在子智能体设置中，每个结果都会流回编排器。这意味着编排器的提示词会随着每一轮委派而变长。在实践中：
- Small pipelines (2–4 sub-agents, short outputs): The cost difference is negligible.小型流水线（2–4 个子智能体，短输出）：成本差异微不足道。
- Medium pipelines (5–10 sub-agents, medium outputs): The orchestrator can easily hit 30–50k tokens in its context by the end. At Claude’s pricing, that’s real money per run.中型流水线（5–10 个子智能体，中等输出）：编排器的上下文在结束时很容易达到 30k–50k 个 Token。按照 Claude 的定价，每次运行都要花费真金白银。
- Large pipelines (10+ sub-agents, large outputs): The orchestrator may hit context limits entirely, requiring chunking strategies that add complexity.大型流水线（10 个以上子智能体，大输出）：编排器可能会完全达到上下文限制，需要增加复杂性的分块策略。
This is not a hypothetical edge case. If you’re using Claude to process research documents, analyze codebases, or handle complex data pipelines, your orchestrator’s context can balloon quickly.这并非假设的边缘情况。如果你使用 Claude 处理研究文档、分析代码库或处理复杂的数据流水线，编排器的上下文可能会迅速膨胀。
How Agent Teams Distribute the Load智能体团队如何分配负载
In a team setup, no single agent accumulates the full context. Each agent loads only the task it’s working on and the relevant prior outputs it needs. The shared task list holds everything, but individual agents don’t need to read the whole thing.在团队设置中，没有单一智能体会累积全部上下文。每个智能体仅加载它正在处理的任务以及所需的先前相关输出。共享任务列表保存了一切，但单个智能体不需要读取全部内容。
This can reduce per-agent token costs significantly. For a pipeline where 10 agents each produce 2,000-token outputs:这可以显著降低每个智能体的 Token 成本。对于一个有 10 个智能体，每个产生 2,000 个 Token 输出的流水线：
- Sub-agent orchestrator cost: ~20,000 tokens in context by the final synthesis step子智能体编排器成本：在最终综合步骤时，上下文中约有 20,000 个 Token
- Team agent cost per agent: Each agent loads maybe 2,000–4,000 tokens of relevant context团队智能体每个智能体的成本：每个智能体仅加载约 2,000–4,000 个 Token 的相关上下文
Over many runs, this difference compounds. Teams can be 3–5x cheaper in token costs for large-scale parallel workloads.经过多次运行，这种差异会累积。对于大规模并行工作负载，团队模式在 Token 成本上可能便宜 3–5 倍。
When Sub-Agents Are Actually More Efficient子智能体在何时更有效率
It’s not all in the teams column. Sub-agents have a token advantage in specific scenarios:团队模式并非在所有方面都占优。子智能体在特定场景下具有 Token 优势：
- Short pipelines where the orchestrator’s context never gets large短流水线，其中编排器的上下文永远不会变大
- Sequential tasks where each step replaces the previous one (the orchestrator can truncate context)顺序任务，其中每一步都替换前一步（编排器可以截断上下文）
- Tasks requiring full synthesis — if the final agent genuinely needs to see all prior outputs, you’re paying for that context either way需要全面综合的任务——如果最终智能体确实需要查看所有先前的输出，无论如何你都要为该上下文付费
The efficiency math favors teams when you have many parallel, semi-independent subtasks. It favors sub-agents when you have a short, tightly sequential chain where the orchestrator’s growing context is a feature, not a bug.当你有许多并行的、半独立的子任务时，效率计算偏向团队模式。当你有一个简短、紧密衔接的顺序链，且编排器不断增长的上下文是一种特性而非缺陷时，它偏向子智能体模式。
When to Use Agent Teams何时使用智能体团队
Agent teams shine when your problem has these characteristics:当你的问题具有以下特征时，智能体团队表现出色：
Parallel, Independent Workstreams并行、独立的工作流
One coffee. One working app. 一杯咖啡。 一个可用的应用程序。
You bring the idea. Remy manages the project.你提供想法。Remy 管理项目。
If your tasks can be decomposed into chunks that don’t depend on each other, agent teams are a natural fit. Example: you’re processing 50 customer support tickets simultaneously. Each agent handles a ticket independently. There’s no reason to route them all through an orchestrator — they can just pull from the shared queue.如果你的任务可以分解为互不依赖的块，那么智能体团队是自然的选择。例如：你正在同时处理 50 个客户支持工单。每个智能体独立处理一个工单。没有理由通过编排器路由它们——它们可以直接从共享队列中获取。
Large-Scale Document or Data Processing大规模文档或数据处理
Research synthesis, code reviews across a large repository, batch data transformation — these all benefit from teams. Agents can work in parallel, write findings to shared state, and a final summarizer reads only what it needs.研究综合、大型代码库的代码审查、批量数据转换——这些都受益于团队模式。智能体可以并行工作，将发现写入共享状态，而最终的总结者只需读取它需要的内容。
Long-Running Workflows With Many Steps具有许多步骤的长期运行工作流
When a workflow has dozens of steps and accumulating all context in one orchestrator would be prohibitive, distributing state across the team keeps each agent’s context manageable.当工作流有几十个步骤，且在一个编排器中累积所有上下文会非常昂贵时，在团队中分发状态可以使每个智能体的上下文保持在可管理范围内。
When You Want Agents to Specialize当你希望智能体专业化时
Teams allow you to assign roles explicitly: one agent searches the web, another analyzes data, another drafts content. Each agent has a narrow job description and reads only the shared state relevant to its role. The orchestrator doesn’t need to micromanage every handoff.团队允许你明确分配角色：一个智能体搜索网络，另一个分析数据，再一个起草内容。每个智能体都有狭窄的职位描述，并且只读取与该角色相关的共享状态。编排器无需微观管理每一次交接。
When to Use Sub-Agents何时使用子智能体
Sub-agents are still the better choice in a significant set of scenarios.在许多场景中，子智能体仍然是更好的选择。
Complex Reasoning Chains复杂的推理链
If each step requires the agent to reason about all previous steps — not just the immediately preceding output — the orchestrator’s accumulated context is valuable. You want it all in one place.如果每一步都需要智能体对所有先前的步骤进行推理——而不仅仅是紧接前一步的输出——那么编排器累积的上下文就很有价值。你希望把所有东西都放在一个地方。
Dynamic Task Decomposition动态任务分解
When the orchestrator needs to decide mid-stream how to break up a problem (based on results it’s seeing), having everything in its context window is an advantage. Teams work better when the task structure is predictable upfront.当编排器需要在流程中间决定如何拆解问题（基于它看到的结果）时，将所有内容放在其上下文窗口中是一个优势。当任务结构在前期可预测时，团队模式工作得更好。
Simpler Pipelines更简单的流水线
For a three-step pipeline, the overhead of setting up shared task state, designing a team coordination protocol, and debugging distributed writes isn’t worth it. Sub-agents are faster to build and easier to understand.对于三步流水线，设置共享任务状态、设计团队协作协议以及调试分布式写入的开销是不值得的。子智能体构建更快，理解也更容易。
When Auditability Matters当可审计性很重要时
Sub-agent flows are easier to log and replay. Because everything passes through the orchestrator, you get a complete trace of the decision-making process. Teams require more sophisticated logging to reconstruct what happened and when.子智能体流更容易记录和重放。因为一切都经过编排器，你会得到决策过程的完整追踪。团队模式需要更复杂的日志记录来重构发生了什么以及何时发生。
Mixing the Two Patterns混合两种模式
In practice, complex systems often combine both approaches. A common architecture:在实践中，复杂系统通常结合了这两种方法。一种常见的架构：
- A top-level orchestrator handles the overall task structure and makes high-level decisions (sub-agent pattern)顶层编排器处理整体任务结构并做出高层决策（子智能体模式）
- Within one phase of the pipeline, it delegates to a team of parallel agents that work against a shared task list (team pattern)在流水线的一个阶段内，它委派给一个针对共享任务列表工作的并行智能体团队（团队模式）
- The orchestrator collects the team’s synthesized output — not every individual agent’s output — keeping its context manageable编排器收集团队的综合输出——而不是每个独立智能体的输出——从而保持其上下文的可管理性
This hybrid approach gives you the control of sub-agents at the top level and the efficiency of teams for parallel workloads inside.这种混合方法为你提供了顶层的子智能体控制力，以及内部并行工作负载的团队效率。
Frequently Asked Questions常见问题解答
What is a Claude Code agent team?什么是 Claude Code 智能体团队？
A Claude Code agent team is a multi-agent pattern where multiple agents coordinate by reading from and writing to a shared task list or shared state store, rather than routing all communication through a central orchestrator. Each agent works on its assigned tasks independently, posts results to shared state, and picks up new tasks as they become available. This enables parallel execution without a single agent accumulating all context.Claude Code 智能体团队是一种多智能体模式，其中多个智能体通过读取和写入共享任务列表或共享状态存储进行协作，而不是通过中央编排器路由所有通信。每个智能体独立处理分配的任务，将结果发布到共享状态，并在任务可用时领取新任务。这实现了并行执行，而无需单个智能体累积所有上下文。
What is the difference between a sub-agent and an agent team in Claude Code?Claude Code 中子智能体和智能体团队有什么区别？
- ✕a coding agent✕一个编码智能体
- ✕no-code✕无代码
- ✕vibe coding✕氛围编码
- ✕a faster Cursor✕一个更快的 Cursor
The one that tells the coding agents what to build.那个告诉编码智能体构建什么的家伙。
A sub-agent operates under the direction of a central orchestrator, which delegates tasks, collects results, and maintains the overall plan. All communication flows through the orchestrator. An agent team uses a peer-to-peer model where agents share a task list and can read each other’s outputs directly, without routing through a central coordinator. Sub-agents work well for sequential, tightly controlled pipelines; agent teams work better for parallel, independent workloads.子智能体在中央编排器的指导下运行，由编排器委派任务、收集结果并维护整体计划。所有通信都流经编排器。智能体团队使用点对点模型，智能体共享一个任务列表，可以直接读取彼此的输出，而无需通过中央协调器路由。子智能体适用于顺序、受控紧密的流水线；智能体团队更适用于并行、独立的工作负载。
Which pattern uses fewer tokens?哪种模式使用的 Token 更少？
Agent teams generally use fewer tokens at scale. In a sub-agent setup, the orchestrator’s context window grows with each result it receives, leading to high token counts for large pipelines. In an agent team setup, each agent loads only the context relevant to its current task from shared state, keeping individual context windows small. For workflows with 10+ parallel agents producing substantial outputs, teams can be 3–5x cheaper per run.智能体团队在规模化时通常使用更少的 Token。在子智能体设置中，编排器的上下文窗口会随着收到的每个结果而增长，导致大型流水线的 Token 计数很高。在智能体团队设置中，每个智能体仅从共享状态加载与其当前任务相关的上下文，从而保持较小的单个上下文窗口。对于有 10 个以上并行智能体产生大量输出的工作流，团队模式每次运行的成本可能便宜 3–5 倍。
Can you combine agent teams and sub-agents in the same workflow?你可以在同一个工作流中结合智能体团队和子智能体吗？
Yes, and for complex systems this is often the best approach. A common pattern is to use an orchestrator (sub-agent style) for high-level task management and decision-making, while delegating parallel workloads to agent teams internally. The orchestrator collects the team’s final synthesized output rather than each individual agent’s output, keeping its context manageable while still maintaining overall control.可以，对于复杂系统来说，这通常是最好的方法。一种常见的模式是使用编排器（子智能体风格）进行高层任务管理和决策，同时在内部将并行工作负载委派给智能体团队。编排器收集团队最终的综合输出，而不是每个独立智能体的输出，从而在保持整体控制的同时，使其上下文保持在可管理范围内。
When should I not use agent teams?什么时候我不应该使用智能体团队？
Avoid agent teams when your tasks are deeply sequential (each step requires the full output of all prior steps), when the pipeline is short enough that a sub-agent setup is simpler, when you need detailed auditability of every decision, or when task structure is highly dynamic and unpredictable. Teams work best when the decomposition is known upfront and tasks can run in parallel.当你的任务是深度顺序的（每一步都需要所有先前步骤的完整输出）、流水线短到子智能体设置更简单、你需要对每个决策进行详细审计，或者任务结构高度动态且不可预测时，请避免使用智能体团队。团队模式在分解已知且任务可以并行运行时效果最好。
How does shared state work in a Claude Code team?Claude Code 团队中的共享状态是如何工作的？
Shared state in a Claude Code team is typically implemented as a structured data store — a JSON file, a database, or a key-value store — that all agents in the team can read from and write to. An agent reads the tasks assigned to it and the prior outputs it needs, does its work, writes results back, and potentially creates new tasks. The full history lives in the store, not in any individual agent’s context window.Claude Code 团队中的共享状态通常实现为结构化数据存储——JSON 文件、数据库或键值存储——团队中的所有智能体都可以对其进行读写。智能体读取分配给它的任务和所需的先前输出，完成工作，写回结果，并可能创建新任务。完整历史记录存在于存储中，而不是任何单个智能体的上下文窗口中。
Key Takeaways关键要点
- Sub-agents use a hierarchical orchestrator → agent pattern, good for sequential tasks, easy to build and debug, but expensive at scale because the orchestrator accumulates all results in its context.子智能体使用层级编排器 → 智能体模式，适用于顺序任务，易于构建和调试，但在规模化时很昂贵，因为编排器会在上下文中累积所有结果。
- Agent teams use a shared task list for peer-to-peer coordination, good for parallel workloads, more token-efficient at scale, but harder to set up and debug.智能体团队使用共享任务列表进行点对点协作，适用于并行工作负载，在规模化时更具 Token 效率，但设置和调试难度更大。
- Token costs are the biggest practical difference: teams can be 3–5x cheaper for large-scale parallel pipelines.Token 成本是最大的实际差异：对于大规模并行流水线，团队模式可能便宜 3–5 倍。
- Hybrid patterns — an orchestrator managing a team of parallel agents — often give you the best of both.混合模式——由编排器管理并行智能体团队——通常能让你兼得两者之长。
- The right choice depends on your task structure: sequential + dynamic → sub-agents; parallel + predictable decomposition → teams.正确的选择取决于你的任务结构：顺序 + 动态 → 子智能体；并行 + 可预测分解 → 团队。
If you’re building multi-agent workflows and want to skip the infrastructure work, MindStudio gives your agents access to 120+ tools and integrations out of the box — whether you’re running sub-agents, teams, or a mix of both.如果你正在构建多智能体工作流并希望跳过基础设施工作，MindStudio 可以让你的智能体开箱即用地访问 120 多种工具和集成——无论你运行的是子智能体、团队还是两者的混合。
