Sub-Agent VS Agent Team：多智能体架构和上下文边界

最近被问最多的一个问题是关于多智能体怎么搭。问题大同小异要不要拆拆几个谁主谁副要不要再来一个 lead我自己听到这种问题第一反应通常是先不答。因为大多数情况下问的人已经默认了一件事任务复杂所以应该多 Agent。这个默认恰恰就是问题最常出错的地方。读 Suryansh Tiwari 那条帖子的时候我对一句话特别有共鸣真正决定架构的不是要不要多 Agent而是这个任务到底需要哪种协作。听起来像废话但落到工程里区别非常具体。一个团队选错了协作方式模型再强也救不回来选对了单个 Sonnet 也能把活干得很干净。今天我想沿着这条线把多智能体的两种主形态——Sub-Agent 和 Agent Team——讲清楚。再往下走一层把我自己这两年踩过的几个典型坑连起来说一说。太长不看如果只能记一句我会这样讲多智能体架构里最先该判断的不是要拆几个而是这些子任务之间是否共享同一段上下文。能干净切开的用 Sub-Agent必须共享状态的才上 Agent Team。几个我现在比较有体感的点• 大多数多 Agent 系统搭歪了不是因为模型不够强是从第一层就按岗位在拆而不是按上下文边界在拆。• Sub-Agent 解决的是隔离、压缩、并行。它的价值不是多开一个 Agent而是把混乱的探索过程压成一个干净的结论。• Agent Team 解决的是持续协作和共享状态。它适合那种前一个人改完后面所有人都要立即知道的任务。• 把按角色拆 Agentplanner→developer→tester当默认套路最容易在每一次 handoff 里掉信息。质量不是被一次性砸坏的是在交接里慢慢漏光的。• 大多数生产级多 Agent 系统真正用到的就那几个原语prompt chaining、routing、parallelization、orchestrator-worker、evaluator-optimizer。名字越花哨的team / swarm / crew越容易掩盖建模本身没做完的问题。• 落到选型上我会先反问自己一句把这两个子任务交给同一个 Agent 一次性干会不会更省心如果答案是会那就别拆。大多数多 Agent 系统是被岗位思维搭歪的先说一个在团队里反复见到的画面。有人接到一个稍微复杂点的任务比如帮我审一遍这段认证模块的代码。第一反应不是去拆任务本身而是去拆角色• 一个 Planner负责定方案• 一个 Developer负责改代码• 一个 Tester负责跑测试• 再来一个 Reviewer负责最后把关。讲故事很顺PPT 也画得漂亮。但只要你真把这套接到 Claude 或者任何 LLM 后面跑一遍就会发现一个很尴尬的现象每一次交接信息都在变薄。Planner 知道这块代码之前刚被重构过所以某个看似奇怪的判断其实是有原因的可这条上下文没传到 Developer。Developer 在改的时候做了几个临时取舍比如这次先不改 token 校验顺序因为会影响下游的 SSO可这层取舍也没沉淀下来。到了 Tester它拿到的就是一份相对干净的代码外加一个干瘪的描述。它能跑测试但跑不出这次改动到底有没有踩到原有约束。最后 Reviewer 看到一个看起来都过了的结果心里反而更没底。这不是模型不够聪明这是组织方式从一开始就搭错了。岗位是按人类公司的分工切的但 LLM 不是真人它没有上下班没有共享的茶水间记忆也没法靠上次开会聊过来补齐信息。它能拿到什么上下文就只能基于什么上下文做事。所以原文里有一句我特别想转给所有刚开始做 Agent 编排的人Design around context boundaries, not roles.不要按角色设计要按上下文边界设计。这句话很短但翻译成工程语言是要重新问一遍• 这两件事需不需要看到对方的中间过程• 这两件事会不会因为对方做完了某一步就影响自己下一步• 如果交给同一个 Agent 一次性做完会不会更省心如果答案都偏向是那它们本来就该在一个 Agent 里强行拆只是把成本转嫁给沟通层。我们前些日子也讨论过类似的情况可以看看《多 Agent 不是虚拟公司从 Anthropic 五种模式看信息流怎么设计》Sub-Agent解决隔离 压缩 并行不是多开一个就更智能把上面这层想清楚之后再来看 Sub-Agent 才比较顺。Sub-Agent 的本质不复杂。它就是父 Agent 把一段定义清楚的工作扔出去子 Agent 在自己的独立上下文里跑完把结论——注意是结论不是推理过程——回收回来。它的几个硬约束很值得记住• 子 Agent 之间不能直接通信• 子 Agent 不能再生新 Agent• 所有流量必须经过父 Agent• 跑完只返回最终输出不带中间思考。这些约束乍一看像在限制能力其实是在保证可控性。我自己理解 Sub-Agent更愿意把它看成三件事的组合第一隔离。 子任务在自己的上下文里跑不会把一堆中间探索污染父上下文。这点对长任务特别关键。父 Agent 的上下文窗口是宝贵资源你不希望 it 被一堆我先看看、再翻翻、又试试的中间步骤撑满。第二压缩。 子任务返回的不是过程是结论。它把一段乱糟糟的探索压成一句干净的信号。这跟我之前聊 Skills 时讲的过程资产思路是一致的——真正值钱的不是中间想了什么是最后留下了什么可复用的判断。第三并行。 既然子 Agent 之间互不通信那它们就可以放心地并发跑。代码审查里让一个 Agent 看安全、一个 Agent 看性能、一个 Agent 看测试覆盖率三个并行跑完再汇总比串行串到天荒地老划算得多。原文里的那段示例代码其实就是这种模式from claude_agent_sdk import query, ClaudeAgentOptions, AgentDefinition async def main(): async for message in query( promptReview the authentication module for issues, optinotallowClaudeAgentOptions( allowed_tools[Read, Grep, Glob, Agent], agents{ security-reviewer: AgentDefinition( descriptinotallowFind vulnerabilities and security risks, promptYou are a security expert., tools[Read, Grep, Glob], modelsonnet, ), performance-optimizer: AgentDefinition( descriptinotallowIdentify performance bottlenecks, promptYou are a performance engineer., tools[Read, Grep, Glob], modelsonnet, ), }, ), ): print(message)这里有一个很容易被忽略的细节description 字段。它表面上像注释本质上是路由信号。父 Agent 怎么把任务分给哪个 Sub-Agent靠的就是这一段描述。写得含糊路由就含糊写得边界清楚分发也清楚。Sub-Agent 的 description 就是这个原则在编排层的延伸。Agent Team解决持续协作不是看起来更高级接下来才轮到 Agent Team。图片如果说 Sub-Agent 像把一段任务外包出去做完拿结果走人那 Agent Team 更像一个长期在一起干活的小组有 Lead、有队员、有共享的任务板谁动了什么大家都立刻看得到。它的几个关键差异• 上下文是共享的不是各管各的• Agent 之间可以直接对话不用都经过父级中转• 任务有持续的状态层进度、依赖、阻塞点都在上面挂着• 一个 Agent 改了什么会影响另一个 Agent 的下一步动作。这种结构适合什么适合那种做着做着会发现问题然后需要互相调头的任务。最典型的例子就是软件项目本身前端改了接口契约后端要立刻知道测试发现某个用例挂了开发要能即时拿到失败上下文产品发现需求理解错了整个链路要回退一步。这种场景里靠父代理统一中转是跑不动的等父代理把信息一层一层传下去黄花菜都凉了。但也正因为如此Agent Team 的成本远高于 Sub-Agent。它需要一个共享状态层不是简单的内存共享是要能处理冲突、可见性、版本化的那种它需要节点间的通信协议它需要一个 Lead Agent 来仲裁分歧、推动进度、识别阻塞它出错时调试链路也长得多因为问题可能不在某一个节点而在节点之间的协作上。我看到很多团队的问题恰恰是反过来的本来该用 Sub-Agent 的简单并行任务被强行套上了team / crew / swarm的概念最后跑出来的不是协作是噪音。所以选型上我有一句很土的口诀任务不互相依赖就别上 team任务必须互相依赖就别用 sub。听起来像废话但实际项目里能踩稳这条线的已经能避开 90% 的坑。让我反复想起来的是几种朴素的编排原语读完原文我自己有一个挺解气的感受作者没有把多 Agent 写成二选一神话。图片Sub-Agent 和 Agent Team 是两种结构没错但生产里真正在用的其实就那几个反复出现的原语1. Prompt Chaining顺序串A 做完给 BB 做完给 C。简单线性任务最常用比如先抽取 → 再翻译 → 再润色。2. Routing路由根据任务特征把它派给最合适的 Agent。客服系统里那种先识别意图再分流的逻辑本质上就是这个。3. Parallelization并行互不依赖的任务一起跑最后汇总。代码审查、文档多维度分析都是这个家族的。4. Orchestrator–Worker调度-执行一个 orchestrator 拆任务、派任务、收结果workers 各自闷头干。这个其实就是 Sub-Agent 的标准形态。5. Evaluator–Optimizer评估-优化先生成、再评估、再迭代。需要高质量产出的场景特别管用比如生成式报告、代码补全后的自检。这五种里没有任何一个是新东西。它们都是工作流里早就存在的模式只是这一波被重新放到了 Agent 编排的语境里。我想强调的一点是多 Agent 不是一个产品形态它是一组可组合的工作流原语。一旦把它当产品形态来理解团队就容易陷入我们也要搞个 team / 我们也要搞个 swarm的攀比。但如果把它当工具箱来理解问题就回到了我这个任务到底拼什么原语最合适。后者才是工程问题前者只是市场问题。一个更实用的判断框架如果让我把这套思路压成一张能贴在工位上的小表大概是这样你在问的问题该考虑的方向这个任务能不能一个 Agent 干完能就先这样别提前优化子任务之间需不需要看到彼此的中间过程不需要 → Sub-Agent需要 → Agent Team子任务跑的时候要不要互相影响不要 → 并行 Sub-Agent要 → Team是不是只是想看起来更高级是 → 退回单 Agent先把任务模型搞清楚每一步要不要严格按业务规则走模型不能自由发挥要 → 加确定性中间层不要硬塞给 team这张表的核心其实就是一句话先把任务结构搞清楚再决定 Agent 结构。 不要反过来。图片我之前讲 Harness 的时候也聊过类似的判断模型越强外面的脚手架越重要。多 Agent 编排是脚手架的一部分但它不是脚手架本身。一上来就堆编排常常意味着任务建模没做完。什么时候根本不需要多 Agent最后必须留一段给反向决策。不是所有任务都需要多 Agent。事实上我现在判断要不要上多 Agent 的第一个问题是单个 Agent 能不能干完只要这个答案是能且体感不差就别折腾。多 Agent 带来的并不只是性能收益还有一长串隐藏成本• 编排逻辑要写、要维护、要监控• Agent 之间的契约要定义、要版本化• 调试链路变长问题定位成本上升• 上下文要在多个 Agent 间一致地流转否则就会出现信息差导致动作错的怪 bug• 治理成本审计、回滚、计费跟着翻倍。我个人的经验是当任务高度依赖、协调成本远大于收益或者上下文压根没法切干净的时候单 Agent 反而是最稳的选择。很多人觉得这是退而求其次我倒不这么看。一个能跑通、能调试、能持续迭代的单 Agent比一个看起来很热闹但谁都说不清在做什么的多 Agent 体系要更接近真的在解决问题。最后写到这里我自己其实是在给多智能体架构做一次降温。这一波 Agent 热名词太多、范式太多、架构图太多。Team、Swarm、Crew、Society、Hive……每隔两周就有一个新词冒出来。但回到工程其实只有一个最朴素的问题我手上这个任务要的是隔离、压缩、并行还是要的是持续协作、共享状态、互相影响前者用 Sub-Agent后者用 Agent Team两者都不要的时候直接单 Agent。再往上配一两个朴素的编排原语多数生产场景就够了。如果非要给今天的讨论加一句结尾我会借作者那句话再说一遍围绕上下文边界设计而不是围绕角色设计从简单结构开始只在确定需要时再加复杂度。听起来像句鸡汤。但只要你真做过几次多 Agent 编排应该都能感受到这句话背后那一层一层的代价。少一点看起来更高级多一点任务真的需要比什么都管用。说到底架构这件事一直没什么银弹。没有最好的架构只有最适合当前任务的架构。软件工程里这条老话搬到 Agent 世界一样成立——甚至更成立因为 Agent 把协作成本这件事放大得更明显了。一个团队、一个任务、一段时期合适的结构可能就是不一样的。今天用 Sub-Agent 跑得很顺过半年业务长出新依赖可能就要换成 Team反过来也成立原本以为非协作不可的流程把任务模型拆清楚之后单 Agent 就够。所以与其把 Sub-Agent 和 Agent Team 当成两个标签去站队不如把它们当成两种工具按需取用。架构不是越精巧越好是越能匹配你手上这件事越好。学习资源推荐如果你想更深入地学习大模型以下是一些非常有价值的学习资源这些资源将帮助你从不同角度学习大模型提升你的实践能力。一、全套AGI大模型学习路线AI大模型时代的学习之旅从基础到前沿掌握人工智能的核心技能​因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取二、640套AI大模型报告合集这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示​因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取三、AI大模型经典PDF籍随着人工智能技术的飞速发展AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型如GPT-3、BERT、XLNet等以其强大的语言理解和生成能力正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取四、AI大模型商业化落地方案作为普通人入局大模型时代需要持续学习和实践不断提高自己的技能和认知水平同时也需要有责任感和伦理意识为人工智能的健康发展贡献力量。