# Sub-Agents vs Agent Teams: The Architecture Decision That Changes Everything
**作者**: Nainsi Dwivedi
**日期**: 2026-04-29T16:42:34.000Z
**来源**: [https://x.com/NainsiDwiv50980/status/2049529787300090344](https://x.com/NainsiDwiv50980/status/2049529787300090344)
---
Most AI Systems Are Built Wrong
Most people reach for multi-agent systems the moment a task feels complex. That’s usually the wrong instinct.
The real question isn’t “should I use multiple agents?” It’s “what kind of coordination does this task actually need?”
That answer determines everything about your architecture.
Claude-style systems give you two distinct approaches: sub-agents and agent teams. They may look similar, but they solve completely different problems.
Sub-Agents: Parallelism with Isolation
A sub-agent is a specialized instance that runs in its own isolated context. Think of it like delegation. You assign focused work, it returns a clean result.
Each sub-agent gets:
A system prompt defining its role
A limited set of tools
A completely isolated context
A single, well-scoped task
When it finishes, it returns only the final output, not reasoning or intermediate steps.
This matters because sub-agents are about compression, not just speed. They turn messy exploration into a clean signal.
There are strict constraints:
Sub-agents cannot talk to each other
Sub-agents cannot spawn new agents
Everything flows through the parent
This keeps the system predictable and clean.
Here’s what it looks like in practice:
```
from claude_agent_sdk import query, ClaudeAgentOptions, AgentDefinition
async def main():
async for message in query(
prompt="Review the authentication module for issues",
options=ClaudeAgentOptions(
allowed_tools=["Read", "Grep", "Glob", "Agent"],
agents={
"security-reviewer": AgentDefinition(
description="Find vulnerabilities and security risks",
prompt="You are a security expert.",
tools=["Read", "Grep", "Glob"],
model="sonnet",
),
"performance-optimizer": AgentDefinition(
description="Identify performance bottlenecks",
prompt="You are a performance engineer.",
tools=["Read", "Grep", "Glob"],
model="sonnet",
),
},
),
):
print(message)
```
The key detail is the description field. It acts as a routing signal.
Agent Teams: Coordination Through Communication
Agent teams are built for collaboration. Instead of isolated workers, you have agents that maintain context, communicate, and adapt in real time.
They include:
A lead agent that assigns and synthesizes
Teammates that execute tasks
A shared task layer that tracks progress and dependencies
This allows real coordination. A frontend agent can signal backend changes and things update instantly.
The Core Difference
Sub-agents and agent teams are fundamentally different.
Sub-agents are execution-focused:
Isolated
Stateless
One-shot
Parent-controlled
Agent teams are collaboration-focused:
Persistent
Interactive
Context-sharing
Peer-to-peer
Use sub-agents when tasks are independent. Use teams when tasks depend on each other.
Where Most People Go Wrong
Most systems are split by roles like planner, developer, tester. This creates context loss at every handoff.
The implementer doesn’t know what the planner knew
The tester doesn’t know what the implementer decided
Quality drops at every boundary.
The better approach is context-based decomposition.
Ask: What information does this task actually need?
If two tasks share deep context, keep them in the same agent. Split only when context can be cleanly separated.
The 5 Patterns That Actually Matter
1. Prompt chaining — sequential steps
2. Routing — send tasks to the right agent
3. Parallelization — run independent work together
4. Orchestrator–worker — one agent delegates
5. Evaluator–optimizer — generate and refine
When Not to Use Multi-Agent Systems
Sometimes a single agent is enough
Use multi-agent systems when:
You need context isolation
You have parallel tasks
You need specialization
Avoid them when:
Agents depend heavily on each other
Coordination overhead is too high
The task is simple
Final Principle
Design around context boundaries, not roles. Start simple and add complexity only when needed.
## 相关链接
- [Nainsi Dwivedi](https://x.com/NainsiDwiv50980)
- [@NainsiDwiv50980](https://x.com/NainsiDwiv50980)
- [10K](https://x.com/NainsiDwiv50980/status/2049529787300090344/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:42 AM · Apr 30, 2026](https://x.com/NainsiDwiv50980/status/2049529787300090344)
- [10.2K Views](https://x.com/NainsiDwiv50980/status/2049529787300090344/analytics)
- [View quotes](https://x.com/NainsiDwiv50980/status/2049529787300090344/quotes)
---
*导出时间: 2026/4/30 09:21:55*
---
## 中文翻译
# 子代理 vs 代理团队：改变一切架构决策
**作者**: Nainsi Dwivedi
**日期**: 2026-04-29T16:42:34.000Z
**来源**: [https://x.com/NainsiDwiv50980/status/2049529787300090344](https://x.com/NainsiDwiv50980/status/2049529787300090344)
---
大多数 AI 系统的构建方式都是错的
大多数人一遇到感觉复杂的任务，就会立刻求助于多智能体系统。这通常是一种错误的直觉。
真正的问题不在于“我是否应该使用多个代理？”，而在于“这个任务到底需要什么样的协调机制？”
这个答案决定了你架构的一切。
Claude 风格的系统为你提供了两种截然不同的方法：子代理和代理团队。它们看起来很相似，但解决的问题完全不同。
子代理：隔离环境下的并行处理
子代理是一个运行在自身隔离上下文中的专用实例。你可以把它想象成“委托”。你分配专注的工作，它返回一个干净的结果。
每个子代理拥有：
一个定义其角色的系统提示词
一组有限的工具
一个完全隔离的上下文
一个单一、范围明确的任务
当它完成任务时，它只返回最终输出，而不返回推理过程或中间步骤。
这一点很重要，因为子代理的核心在于“压缩”，而不仅仅是速度。它们将混乱的探索转化为清晰的信号。
这里存在严格的约束：
子代理不能相互通信
子代理不能生成新的代理
所有信息流都经过父代理
这保持了系统的可预测性和清晰度。
以下是实际应用中的样子：
```python
from claude_agent_sdk import query, ClaudeAgentOptions, AgentDefinition
async def main():
async for message in query(
prompt="检查认证模块是否存在问题",
options=ClaudeAgentOptions(
allowed_tools=["Read", "Grep", "Glob", "Agent"],
agents={
"security-reviewer": AgentDefinition(
description="查找漏洞和安全风险",
prompt="你是一位安全专家。",
tools=["Read", "Grep", "Glob"],
model="sonnet",
),
"performance-optimizer": AgentDefinition(
description="识别性能瓶颈",
prompt="你是一位性能工程师。",
tools=["Read", "Grep", "Glob"],
model="sonnet",
),
},
),
):
print(message)
```
关键细节在于 `description` 字段。它充当了路由信号。
代理团队：通过沟通实现协调
代理团队是为协作而构建的。这里不再是隔离的工作者，而是能够维护上下文、实时沟通和适应的代理。
它们包括：
一个负责分配任务和综合结果的领导代理
执行任务的队友
一个跟踪进度和依赖关系的共享任务层
这实现了真正的协调。前端代理可以发出后端变更的信号，相关内容会即时更新。
核心区别
子代理和代理团队有着根本的不同。
子代理专注于执行：
隔离
无状态
一次性
父代理控制
代理团队专注于协作：
持久存在
交互式
共享上下文
点对点
当任务相互独立时，使用子代理。当任务相互依赖时，使用团队。
大多数人错在哪里
大多数系统是按规划者、开发者、测试员等角色来划分的。这会在每次交接时造成上下文丢失。
实施者不知道规划者知道的信息
测试员不知道实施者所做的决定
质量在每一个边界都在下降。
更好的方法是基于上下文的分解。
问：这个任务实际上需要什么信息？
如果两个任务共享深层的上下文，将它们保留在同一个代理中。只有当上下文可以被干净地分离时，才进行拆分。
真正重要的 5 种模式
1. 提示词链接 —— 顺序步骤
2. 路由 —— 将任务发送给正确的代理
3. 并行化 —— 同时运行独立的工作
4. 编排者-工作者 —— 一个代理进行委托
5. 评估器-优化器 —— 生成与改进
何时不该使用多智能体系统
有时一个代理就足够了
在以下情况使用多智能体系统：
你需要上下文隔离
你有并行任务
你需要专业化
在以下情况避免使用：
代理之间高度依赖
协调开销过高
任务很简单
最终原则
围绕上下文边界进行设计，而不是围绕角色。从简单开始，仅在需要时增加复杂性。
## 相关链接
- [Nainsi Dwivedi](https://x.com/NainsiDwiv50980)
- [@NainsiDwiv50980](https://x.com/NainsiDwiv50980)
- [10K](https://x.com/NainsiDwiv50980/status/2049529787300090344/analytics)
- [升级到 Premium](https://x.com/i/premium_sign_up)
- [12:42 AM · Apr 30, 2026](https://x.com/NainsiDwiv50980/status/2049529787300090344)
- [10.2K Views](https://x.com/NainsiDwiv50980/status/2049529787300090344/analytics)
- [查看引用](https://x.com/NainsiDwiv50980/status/2049529787300090344/quotes)
---
*导出时间: 2026/4/30 09:21:55*