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 解决的是持续协作和共享状态。它适合那种"前一个人改完，后面所有人都要立即知道"的任务。

• 把按角色拆 Agent（planner→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( prompt="Review the authentication module for issues", optinotallow=ClaudeAgentOptions( allowed_tools=["Read", "Grep", "Glob", "Agent"], agents={ "security-reviewer": AgentDefinition( descriptinotallow="Find vulnerabilities and security risks", prompt="You are a security expert.", tools=["Read", "Grep", "Glob"], model="sonnet", ), "performance-optimizer": AgentDefinition( descriptinotallow="Identify performance bottlenecks", prompt="You are a performance engineer.", tools=["Read", "Grep", "Glob"], model="sonnet", ), }, ), ): 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 做完给 B，B 做完给 C。简单线性任务最常用，比如"先抽取 → 再翻译 → 再润色"。

2. Routing（路由）：根据任务特征把它派给最合适的 Agent。客服系统里那种"先识别意图再分流"的逻辑，本质上就是这个。

3. Parallelization（并行）：互不依赖的任务一起跑，最后汇总。代码审查、文档多维度分析都是这个家族的。

4. Orchestrator–Worker（调度-执行）：一个 orchestrator 拆任务、派任务、收结果，workers 各自闷头干。这个其实就是 Sub-Agent 的标准形态。

5. Evaluator–Optimizer（评估-优化）：先生成、再评估、再迭代。需要高质量产出的场景特别管用，比如生成式报告、代码补全后的自检。

这五种里，没有任何一个是新东西。它们都是工作流里早就存在的模式，只是这一波被重新放到了 Agent 编排的语境里。

我想强调的一点是：多 Agent 不是一个产品形态，它是一组可组合的工作流原语。

一旦把它当产品形态来理解，团队就容易陷入"我们也要搞个 team / 我们也要搞个 swarm"的攀比。但如果把它当工具箱来理解，问题就回到了"我这个任务，到底拼什么原语最合适"。

后者才是工程问题，前者只是市场问题。

一个更实用的判断框架

如果让我把这套思路压成一张能贴在工位上的小表，大概是这样：

这张表的核心，其实就是一句话：先把任务结构搞清楚，再决定 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大模型商业化落地方案

作为普通人，入局大模型时代需要持续学习和实践，不断提高自己的技能和认知水平，同时也需要有责任感和伦理意识，为人工智能的健康发展贡献力量。