你有没有遇到过这种场面：项目做到一半，发现需要同时处理好几件事，于是兴冲冲地搭了一个「多Agent系统」，结果协调整了半天，代码倒是跑起来了，但输出结果总是差点意思，问题出在哪？

其实是架构选错了。

当你需要多个Agent协同工作时，脑子里第一个蹦出来的想法可能是「找一群小Agent来帮忙」。但等你真正动手，就会发现这些Agent之间互相扯皮，上下文传来传去最后变成一锅粥。更糟糕的是，你根本说不清楚每个Agent该干什么不该干什么。

别急，这不是你的问题，而是大多数人都没搞清楚一件事：Sub-Agents 和 Agent Teams 根本是两码事，它们解决的是完全不同的问题。

Sub-Agents：把任务外包出去的思路

Sub-Agents 就像是把你的一部分工作外包给一个专业临时工。你告诉它要做什么，它干完就给你结果，中间不废话，不汇报，也不会突然问你要不要顺便优化一下隔壁的代码。

每个 Sub-Agent 被创建时都会拿到三样东西：一个明确定义的角色描述、一套受限的工具列表、以及一个完全隔离的工作上下文。

好处是什么？你可以同时跑多个Sub-Agent，它们互不干扰，各自完成自己那部分工作，最后把结果汇总给主Agent。有点像厨房里同时处理多道菜，每道菜有自己的锅和灶，做完了直接端走，不会串味。

但Sub-Agents有一个严格的限制：它们不能直接互相说话。所有信息必须通过父Agent流转。这意味着如果你让两个Sub-Agent协作完成一个任务，它们其实并没有真正「合作」，而是在各自的真空里干活。

用 Claude Agent SDK 写出来大概是这样的：

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)

这里的 description 字段会告诉系统，这个任务该分配给哪个Sub-Agent。

Agent Teams：真正的协作团队

如果说Sub-Agents是临时工外包，那Agent Teams就是一个真正的项目组。团队里有负责人，有组员，有共享的任务面板，大家可以实时沟通、汇报进度、按需求调整方向。

Agent Teams的核心是一个Lead Agent加上若干个执行Agent，它们共享任务层，可以追踪进度和依赖关系。这意味着团队里的成员是真正在协同的：前端Agent发现后端接口有变化，可以立刻通知其他Agent，整个系统是实时响应的。

这就像你运营一个开放厨房，厨师们不只是各做各的菜，他们能看到彼此的进度，有人发现食材不够会喊一声，有人发现菜快糊了会帮忙补救。

关键区别在于上下文共享。Sub-Agents的上下文是互相隔离的，而Agent Teams的成员共享上下文，所以信息不会在传递过程中丢失。这对于需要多轮协作才能完成的任务特别重要。

什么时候该选哪个？

这个问题没有标准答案，但有一个简单的判断标准：如果你的任务可以拆解成完全独立的子任务，选Sub-Agents；如果子任务之间需要频繁沟通和上下文共享，选Agent Teams。

举几个例子。代码审查这个场景，安全性审查和性能优化审查其实是两件独立的事，它们不需要知道对方的具体发现，只要把结果汇总就行。这种情况用Sub-Agents就非常合适。

但如果你在做一个功能需要前端、后端、测试三方配合，每一方的进度都影响其他方，这时候Agent Teams的实时协调能力就派上用场了。

大多数人的错误在于按角色分解任务：创建一个Planner Agent，一个Developer Agent，一个Tester Agent。这样做的问题在于，每次任务在不同Agent之间传递时，上下文都会丢失一截。Planner知道的，Implementer不一定清楚；Implementer决定的，Tester也不一定理解。结果就是质量在每个交接点都在下降。

正确的方式是按上下文边界分解。问自己一个问题：这个任务实际需要什么信息？如果两个任务需要共享大量上下文，就让它们在同一个Agent里完成。只有当上下文可以真正独立分离时，才拆到不同的Sub-Agent或团队成员里。

五种被验证过的Agent协作模式

在实际项目中，有五种模式被反复证明是有效的。第一是Prompt Chaining，把一个复杂任务拆成多个步骤，按顺序执行，每一步都基于上一步的结果。第二是Routing，根据任务类型把它分发到不同的专业Agent。第三是Parallelization，让独立的子任务同时运行然后汇总结果。第四是Orchestrator-Worker模式，一个中心Agent负责调度多个执行Agent。第五是Evaluator-Optimizer，让一个Agent生成方案，另一个Agent负责评估和改进。

这些模式不是非此即彼的选择，你可以根据实际情况组合使用。关键是不要为了用多Agent而用多Agent，架构应该是任务的真实需求的反映。

什么时候干脆不用多Agent？

多Agent系统听起来很美，但并不是所有场景都需要它。如果你发现系统里的Agent互相依赖程度很高，协作开销已经超过了任务本身的复杂度，那还不如用一个强Agent完成所有工作。

单Agent就足够的场景包括：任务本身的复杂度不高，Agent之间的依赖关系复杂到难以维护，或者协调成本已经高过并行带来的收益。记住，架构是为了解决问题，不是为了炫技。

总结一下

如果你需要隔离执行、任务独立、一次性完成的工作，Sub-Agents是正确的选择。如果你需要持续协作、上下文共享、实时响应的团队作战，Agent Teams才适合你。

架构选择的核心是上下文边界的划分，而不是角色分工。把这个原则吃透，你的多Agent系统才能真正发挥价值，而不是变成一堆各说各话的孤立Agent。

想深入了解不同架构的适用场景，或者想看实际的代码实现案例？欢迎在评论区聊聊你的经验，也欢迎关注公众号「梦兽编程交个朋友」，一起探索AI工程化的更多可能。

顺便分享一个我常用的AI自媒体运营工具 ，覆盖内容排版、素材处理和效率提效。

如果你对Claude Code的新功能感兴趣，我之前也分享过一些实战心得，感兴趣可以去看看。

常见问题

Sub-Agents和Agent Teams的性能差距大吗？

Sub-Agents适合独立任务并行处理，Agent Teams适合需要实时协调的复杂工作。单纯从速度看，Sub-Agents通常更快，因为没有消息传递的开销。但如果任务之间需要大量上下文同步，Agent Teams的整体效率反而更高。

一个父Agent最多能管理多少个Sub-Agent？

这取决于具体场景和模型能力。Claude的文档建议单个父Agent控制5-10个Sub-Agent比较合理，超过这个数量协调成本会显著上升。如果确实需要更多，考虑分层管理或者改成Agent Teams架构。

Agent Teams的Lead Agent会不会成为性能瓶颈？

有可能。如果Lead Agent处理的事情太多，确实会成为系统的堵点。解决方案是让Lead Agent只做任务分配和结果汇总，把具体的执行工作完全交给团队成员，自己不参与具体任务的执行。