多智能体架构：小白程序员必备的收藏指南，轻松掌握大模型协作精髓！

爱喝白开水a

309人浏览 · 2026-05-19 11:32:00

爱喝白开水a · 2026-05-19 11:32:00 发布

本文深入解析多智能体架构的核心，对比Sub-Agent与Agent Team两种主要形态，强调上下文边界的重要性。文章指出，架构决策应基于任务协作需求而非预设角色，并提供实用的判断框架。通过理解编排原语，如prompt chaining、routing等，读者可避免陷入复杂的架构陷阱，实现高效的大模型协作。

架构师（JiaGouX）

我们都是架构师！
架构未来，你来不来？

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

问题大同小异：要不要拆？拆几个？谁主谁副？要不要再来一个 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",
        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。简单线性任务最常用，比如"先抽取 → 再翻译 → 再润色"。
2. Routing（路由）：根据任务特征把它派给最合适的 Agent。客服系统里那种"先识别意图再分流"的逻辑，本质上就是这个。
3. Parallelization（并行）：互不依赖的任务一起跑，最后汇总。代码审查、文档多维度分析都是这个家族的。
4. Orchestrator–Worker（调度-执行）：一个 orchestrator 拆任务、派任务、收结果，workers 各自闷头干。这个其实就是 Sub-Agent 的标准形态。
5. 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 当成两个标签去站队，不如把它们当成两种工具，按需取用。

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

小白/程序员如何系统学习大模型LLM？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。