Claude SubAgent vs Agent Team

原创已于 2026-06-30 16:47:46 修改 · 239 阅读

6 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

于 2026-06-30 16:47:34 首次发布

AI 时代程序员必备技能

Codex、Claude Code、Cursor、Hermes Agent、OpenClaw等工程化实战专栏，讲透 AI 如何接管脏活累活

一键订阅

导读

大多数人一遇到复杂任务，就会想到使用多代理系统。
这几乎总是错误的直觉。
正确的问题并非“我应该使用多个代理吗？”，而是“这项任务实际上需要什么样的协调？”
这个问题的答案决定了架构的方方面面。

Claude 提供了两种截然不同的多代理范式：子代理和代理团队。
它们表面上看起来相似，但架构上解决的问题完全不同。

本文将详细解释子代理和代理团队的区别，以及如何根据任务需求选择合适的架构。

SubAgent：通过隔离实现并行

子代理是运行在独立上下文窗口中的专用 Claude 实例。

想象一下，你是一名研究主管。你不会亲自阅读每一个一手资料，而是将具体问题分配给研究人员。他们返回提炼后的发现，你将这些发现整合成连贯的输出。
子代理正是这样工作的。

每个子代理都有：

• 定义其专长的系统提示
• 可访问的特定工具集
• 清晰隔离的上下文窗口
• 一项任务

from claude_agent_sdk import query, ClaudeAgentOptions, AgentDefinition

async def main():
    async for message in query(
        prompt="Review the authentication module for security vulnerabilities",
        options=ClaudeAgentOptions(
            allowed_tools=["Read", "Grep", "Glob", "Agent"],
            agents={
                "security-reviewer": AgentDefinition(
                    description="Security specialist. Use for vulnerability checks and security audits.",
                    prompt="You are a security specialist with expertise in identifying vulnerabilities.",
                    tools=["Read", "Grep", "Glob"],
                    model="sonnet",
                ),
                "performance-optimizer": AgentDefinition(
                    description="Performance specialist. Use for latency issues and optimization reviews.",
                    prompt="You are a performance engineer with expertise in identifying bottlenecks.",
                    tools=["Read", "Grep", "Glob"],
                    model="sonnet",
                ),
            },
        ),
    ):
        print(message)

description 字段告诉父代理调用哪个子代理。
这里，提示中提到“安全漏洞”，因此父代理会调用 security-reviewer，而并非 performance-optimizer。

如果提示询问的是延迟或瓶颈问题，那么另一个代理会被选中。
description 是路由信号，保持其具体性非常重要。

Agent Team：通过通信实现协调

代理团队是一种截然不同的模型。

子代理是完成任务后就消失的短期工作者，而代理团队是持久存在的实例，它们直接相互通信，并通过共享状态进行协调。

这就像聘请承包商完成孤立的任务，与组建一个在同一房间内协作的团队之间的区别。

一个代理团队有三个组成部分：

• 一个团队领导，负责协调工作、分配任务和整合结果
• 独立的代理实例（队友），每个都有自己的上下文窗口，可以并行工作
• 一个共享的任务列表，跟踪待处理、进行中和已完成的任务，以及任务之间的依赖关系

一个典型的生命周期如下：

Claude (Team Lead):
└── spawnTeam("auth-feature")
    Phase 1 - Planning:
    └── spawn("architect", prompt="Design OAuth flow", plan_mode_required=true)
    Phase 2 - Implementation (parallel):
    └── spawn("backend-dev", prompt="Implement OAuth controller")
    └── spawn("frontend-dev", prompt="Build login UI components")
    └── spawn("test-writer", prompt="Write integration tests", blockedBy=["backend-dev"])

注意 test-writer 上的 blockedBy 字段。
这是共享任务列表进行实际协调工作的方式：测试编写者不会在后端代理完成之前开始工作，而团队领导无需手动管理此顺序。

与子代理的最大区别在于代理之间的直接通信。
队友可以相互发送消息、分享发现、提出阻碍，并进行协商，而无需将所有内容都通过团队领导路由。

你还可以直接与单个队友互动，不必所有事情都通过领导代理。

核心区别

这样思考子代理和代理团队的选择：

子代理是用完即弃的。

• 你给它们分配任务，它们完成任务并报告结果
• 代理之间没有对话
• 没有共享内存
• 没有持续的状态
• 每个子代理在单个会话中诞生并消亡

代理团队是协作型的。

• 代理持续存在并随时间积累上下文
• 任务中的发现会立即反馈给队友
• 前端代理可以告诉后端代理“API响应结构需要更改”，后端代理可以自行调整，而无需等待团队领导调解

选择它们的最清晰方式是：

• 当工作可以轻松并行化时，使用子代理：例如独立的研究流、代码库探索或父代理只需摘要的查找任务
• 当工作需要持续协商时，使用代理团队：代理需要协调输出才能继续，或者一个线程中的发现改变了另一个线程应该做的事情

从第一性原理设计 Agent 系统

大多数多代理设计失败的原因是，人们根据角色而并非上下文来拆分工作。

直观的做法是根据角色拆分工作：规划者、实施者、测试者。这看起来很有序，但会导致信息在每次交接时降解的“电话游戏”。

• 实施者没有规划者知道的信息
• 测试者没有实施者做出的决策
• 质量在每个边界处下降

正确的思维方式是以上下文为中心的分解。

问一问：这个子任务实际上需要什么上下文？如果两个子任务需要深度重叠的信息，它们很可能属于同一个代理。如果它们可以使用真正隔离的信息，并且它们之间有干净的接口，那么就可以进行拆分。

一个实际的例子：实现功能的代理也应该为该功能编写测试，因为它已经拥有相关上下文。
将实现和测试拆分为两个代理会创建一个交接问题，其成本可能超过并行化带来的收益。

只有在上下文可以真正隔离时才进行拆分。

The five orchestration patterns

无论使用哪种范式，以下五种模式涵盖大多数实际需求：

1. Prompt chaining：顺序步骤，每个调用处理前一个输出。当顺序重要且步骤相互依赖时使用。

2. Routing：分类器决定哪个专用处理器处理任务。简单问题交给更便宜、更快的模型。复杂问题交给更强大的模型。这是防止成本爆炸的关键。
3. Parallelization：独立的子任务同时运行。要么同一任务多次运行以获得多样化的输出（投票），要么不同的子任务同时运行（分段）。
4. Orchestrator-worker：中央代理分解任务，委托给工作者，并综合结果。这是子代理和代理团队的主导架构，也是大多数生产系统实际使用的架构。
5. Evaluator-optimizer：一个代理生成，另一个代理在循环中评估并提供反馈。当质量比速度更重要且单次通过不够可靠时，这种模式非常有用。