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

关注

原创最新推荐文章于 2026-10-28 11:22:35 发布 364 阅读 AI 写同款· GEO 优化 ›

Agent Team 多智能体系统解析医疗领域的临床试验系统正是典型案例：分布在各大医院的智能体在本地完成数据分析，通过加密通道共享知识而不暴露患者隐私，Team Leader则协调这些分布式智能体完成新药研发的复杂计算。与传统的单体AI不同，这种由多个专业化智能体组成的协同网络，通过分工协作和动态调整，展现出接近人类团队的决策智慧，同时具备机器特有的精准与效率。整合万亿级数据节点，结合深度语义理解能力，可动态构建业务关系网络，为智能体提供精准决策支持，如在供应链场景中自动识别断链风险并生成应急预案。阅读详情

最近被问最多的一个问题，是关于多智能体怎么搭。

问题大同小异：要不要拆？拆几个？谁主谁副？要不要再来一个 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, AgentDefinitionasync 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 字段。它表面上像注释，本质上是路由信号。父 Agent 怎么把任务分给哪个 Sub-Agent，靠的就是这一段描述。写得含糊，路由就含糊；写得边界清楚，分发也清楚。

工具描述这件事，我之前在写《如何为 Agent 设计产品？》时就强调过：写给人看和写给 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。简单线性任务最常用，比如"先抽取 → 再翻译 → 再润色"。
1. Routing（路由）：根据任务特征把它派给最合适的 Agent。客服系统里那种"先识别意图再分流"的逻辑，本质上就是这个。
1. Parallelization（并行）：互不依赖的任务一起跑，最后汇总。代码审查、文档多维度分析都是这个家族的。
1. Orchestrator–Worker（调度-执行）：一个 orchestrator 拆任务、派任务、收结果，workers 各自闷头干。这个其实就是 Sub-Agent 的标准形态。
1. Evaluator–Optimizer（评估-优化）：先生成、再评估、再迭代。需要高质量产出的场景特别管用，比如生成式报告、代码补全后的自检。

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

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

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

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

也可以看看Anthropic的设计：《多 Agent 不是虚拟公司：从 Anthropic 五种模式看信息流怎么设计》

一个更实用的判断框架

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

你在问的问题	该考虑的方向
这个任务能不能一个 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 当成两个标签去站队，不如把它们当成两种工具，按需取用。

架构不是越精巧越好，是越能匹配你手上这件事越好。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

在这里插入图片描述

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～