Claude Code 里，Subagents 和 Agent Teams 到底怎么选？有什么区别？

之前我写过几篇关于Multi-Agent的文章介绍了Multi-Agent的一些模式。但是前不久Claude Code推出了Agent Team模式当时我觉得这不就是Multi-Agent的模式的一种新实现而已。后面详细拆解后看到了todo.mdtask-list.md以及通讯机制收发件等机制才知道这是一种新模式。那么Sub-agents 和 Agent Teams到底有什么不同本文详细介绍一下。总体上来说这两种模式表面上看差不多但架构层面上它们解决的是完全不同的问题。1 Sub-agents独立上下文 压缩输出Sub-agent 本质上是一个专用的 Claude 实例运行在独立的上下文窗口里。举例来说想象你是一个研究负责人。你不会自己去读每一份原始资料而是把具体问题委托给研究员他们返回提炼好的结论你再汇总成一份完整的输出。Sub-agent 就是这个模式。每个 Sub-agent 拿到的是专属的系统提示词定义它的专业领域特定的工具权限干净、隔离的上下文窗口一个明确的任务任务完成后只有最终结果返回给主 Agent。不要中间推理过程不要步骤只输出压缩后的结论。Sub-agent 的核心价值不只是并行而是压缩。把大量的探索压缩成干净的信号不污染主 Agent 的上下文。一个硬约束Sub-agent 不能嵌套 Sub-agent也不能互相通信。所有结果都流回主 Agent主 Agent 是唯一的协调者。这个约束是设计上的考量不是缺陷。它让系统行为可预测你始终清楚信息流向和决策点在哪里。最小可用的 SDK 示例from claude_agent_sdk import query, ClaudeAgentOptions, AgentDefinitionasync def main(): async for message in query( promptReview the authentication module for security vulnerabilities, optionsClaudeAgentOptions( allowed_tools[Read, Grep, Glob, Agent], agents{ security-reviewer: AgentDefinition( descriptionSecurity specialist. Use for vulnerability checks and security audits., promptYou are a security specialist with expertise in identifying vulnerabilities., tools[Read, Grep, Glob], modelsonnet, ), performance-optimizer: AgentDefinition( descriptionPerformance specialist. Use for latency issues and optimization reviews., promptYou are a performance engineer with expertise in identifying bottlenecks., tools[Read, Grep, Glob], modelsonnet, ), }, ), ): print(message)description字段是路由信号。这里的 prompt 提到了security vulnerabilities所以主 Agent 会路由到security-reviewer而不是performance-optimizer。如果问的是延迟或性能瓶颈就选另一个。描述要具体这是路由的关键。2 Agent Teams长期运行 点对点通信Agent Teams 是完全不同的模型。Sub-agent 是用完即弃的短时 workerAgent Teams 则是长期运行的实例彼此之间持久存在、直接通信、通过共享状态协调。就像外包临时工和固定团队的区别后者在一个空间里持续协作。Agent Teams 有三个核心组件Team Lead协调工作、分配任务、汇总结果Teammates独立的 Agent 实例各自拥有上下文窗口并行工作共享任务列表跟踪待处理、进行中、已完成的任务以及任务间的依赖关系典型的生命周期Claude (Team Lead):└── spawnTeam(auth-feature) Phase 1 - Planning: └── spawn(architect, promptDesign OAuth flow, plan_mode_requiredtrue) Phase 2 - Implementation (parallel): └── spawn(backend-dev, promptImplement OAuth controller) └── spawn(frontend-dev, promptBuild login UI components) └── spawn(test-writer, promptWrite integration tests, blockedBy[backend-dev])注意test-writer上的blockedBy字段。测试人员要等后端完成后才能开始主 Agent 不需要手动管理这个顺序。和 Sub-agent 最大的区别在于直接的对等通信。Teammate 之间可以互相发消息、共享发现、提出阻塞、协商不需要所有事都经过 Team Lead。也可以直接和某个 Teammate 交互不强制通过 Lead。3 Sub-agents和Agent Teams怎么选Sub-agents 的特点即发即忘Agent 之间不通信无共享内存无持续状态每个 Sub-agent 存活在一个 Session 内Agent Teams 的特点Agent 持久存在累积上下文任务中途的发现会即时同步给 Teammate前端 Agent 发现 API 响应结构需要调整可以直接告诉后端 Agent 调整不需要 Lead 居中协调选择标准很简单任务是可以embarrassingly parallel极致并行的吗独立的研究流、代码探索、查询这类场景用 Sub-agent主 Agent 只需要最终汇总。任务需要持续协商吗Agent 之间要互相协调reconcile输出或者一个线程的发现会影响另一个线程该做什么这类场景用 Agent Teams。4 大部分Multi-Agent 设计失败的原因实话说大部分Multi-Agent设计失败不是因为开发技术不行而是因为按角色拆分工作而不是按上下文拆分。直觉上按角色拆分很合理Planner、Implementer、Tester看起来很清晰。但这就成了传话游戏信息在每个交接点都会衰减。Implementer 没有 Planner 知道的东西Tester 没有 Implementer 决定的东西质量在每个边界都在下降正确的思路是以上下文为中心拆分。可以问问自己这个子任务实际需要什么上下文如果两个子任务需要高度重叠的信息它们可能该属于同一个 Agent。如果它们可以用完全隔离的信息和干净的接口运作那就应该拆分。一个实际的例子是实现某个功能的 Agent也应该同时写这个功能的测试。它本来就有上下文。把这两个拆到不同的 Agent产生的交接成本比并行的收益还大。只有当上下文能够真正隔离的时候才应该拆分。5 五种常见模式不管用哪种范式下面这五种模式覆盖了大部分实际需求5.1 Prompt Chaining顺序执行每个步骤处理前一步的输出。当前一步依赖后一步的结果时用这个。5.2 Routing一个分类器决定任务该发给哪个专用 Handler。简单问题走又快又便宜的模型难的问题走能力更强的。这是对成本进行控制的核心手段。5.3 Parallelization独立子任务同时运行。可以是同一个任务跑多遍获得多样化输出voting也可以是不同子任务同时跑sectioning。5.4 Orchestrator-Worker中心 Agent 分解任务、委托给 Worker、汇总结果。这是 Sub-agent 和 Agent Teams 共同的主流架构也是大部分生产系统实际使用的方式。5.5 Evaluator-Optimizer一个 Agent 生成另一个评估并反馈循环迭代。适用于质量优先于速度、一次通过不够可靠的场景。6 什么时候才需要多 Agent这是大部分文章略过不讲的部分。很多团队花了几个月构建复杂的多 Agent 流水线最后发现用更好的 Prompt 调教单个 Agent 就能达到同等效果。从简开始。只有能够明确衡量出复杂性带来的收益时才往上加。真正需要多 Agent 的场景某个子任务产生的上下文信息对主任务无关保持在 Sub-agent 里防止上下文膨胀独立的研究或搜索任务确实受益于同时覆盖任务需要互相冲突的系统提示词或者单个 Agent 工具太多导致性能下降不需要多 Agent 的场景Agent 之间需要频繁共享上下文跨 Agent 的依赖产生的管理开销比执行价值还大任务足够简单一个 Prompt 调教得好的单 Agent 就能搞定涉及代码的场景并行 Agent 写代码会产生不兼容的假设。合并工作时那些隐式决策会产生难以调试的冲突。写代码相关的 Sub-agent 应该用来回答问题和探索而不是和主 Agent 同时写代码。7 三个常见的失败模式7.1 任务描述模糊导致 Agent 重复工作每个 Agent 需要明确的目标、期望的输出格式、关于使用哪些工具或来源的指引、以及关于不应该覆盖什么的明确边界。没有这些两个 Agent 会去研究同一个东西还互相不知道。7.2 验证 Agent 没有真正验证就宣布完成具体、明确的指令是必须的运行完整测试套件覆盖这些具体 case每个都过了才算完成。模糊的验收标准会产生误报。7.3 Token 成本太高怎么办解决方案是智能分层在真正重要的地方用最强模型把常规工作路由到更快更便宜的模型加上预算控制避免成本失控8 最后围绕上下文边界设计而不是围绕角色或组织架构设计。从一个 Agent 开始堆上下文直到它撑不住为止。从失败的地方开始拆解Agent。复杂性只加在解决了真实、可衡量问题的地方。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】