第16章开篇即列出16.1主从/对等/流水线拓扑，16.2 Sub-Agent角色分工，直接点明多智能体系统的架构核心。本章通过四大部分解析智能体间通信、任务编排及主流实现，聚焦从单Agent到多Agent的演进与落地。

多智能体系统不再是单个大模型包打天下，而是把复杂目标拆成多个角色协同完成。信号明确指出，本章核心是解决多Agent协作问题，围绕拓扑结构、角色分工、通信机制和主流框架展开，直接切入从单体到分布式的演进路径。

主从、对等与流水线拓扑各有其协作边界

主从拓扑中，一个主Agent负责分解任务并下发指令，从Agent只执行具体子任务。这种结构边界清晰，适合任务有明确层级的情况，主Agent掌握全局状态，从Agent无需了解整体目标。实际运行时，主Agent成为单点，负载高时容易成为瓶颈。

对等拓扑则取消了中心，每个Agent地位相同，通过协商或共享黑板完成协作。边界在于通信开销，每个Agent都需要维护对其他Agent的认知，适合需要高度灵活调整的场景，但协调难度随Agent数量上升而指数增长。

流水线拓扑把任务切成固定阶段，每个Agent只处理上游输出并产生下游输入，像工厂装配线一样高效。它的边界是阶段间依赖严格，一旦中间环节出错，整个流水线都会卡住，不适合动态调整的任务。

三种拓扑在实际系统中往往混合使用。主从适合顶层规划，对等适合并行探索，流水线适合确定性加工环节。信号16.1把这三种结构作为本章第一个重点，说明架构选择直接决定了系统的可扩展性和鲁棒性。开发者必须根据具体业务先判断哪种边界最匹配，再决定采用哪种或混合拓扑，否则后续通信和编排都会事倍功半。

当前多数开源项目默认采用主从结构，因为实现最简单。但在需要创造性输出的场景，对等结构表现更好，只是调试难度显著上升。流水线则常见于RAG增强或多阶段数据处理流程中。理解这三种拓扑的协作边界，是搭建多智能体系统的第一步。

Sub-Agent角色分工决定任务拆解粒度

Sub-Agent是多智能体系统中实现角色分工的基本单元。信号16.2专门讨论角色分工如何影响任务拆解粒度。一个复杂目标被拆成若干子目标，每个Sub-Agent被赋予特定角色，如规划者、执行者、验证者或批评者。

角色分工直接决定粒度粗细。粒度太粗，单个Sub-Agent能力负担过重；粒度太细，通信和协调成本暴增。典型做法是让一个Planner Sub-Agent先输出任务分解树，然后根据树结构动态生成对应角色的Sub-Agent。每个Sub-Agent只拥有完成自己角色所需的最小提示词和工具集，避免能力冗余。

角色设计还涉及权限控制。某些Sub-Agent只能读共享内存，另一些可以调用外部工具，还有的专门负责评估其他Agent输出质量。这种分工让系统在面对开放性问题时仍能保持有序推进。信号明确把Sub-Agent角色分工列为本章第二大部分，说明它是从单Agent升级到多Agent的关键技术手段。

实践中，角色一旦固定就难以中途调整。很多团队在初期把角色分得过细，导致Agent之间频繁等待对方输出，整体效率反而低于单个强Agent。反之，如果只分出两三个大角色，又容易出现某个角色能力天花板被过早触达。找到合适的粒度，需要反复实验当前模型在具体领域的能力边界。

智能体通信协议是任务编排的瓶颈所在

智能体之间不能靠自然语言随意聊天，必须有结构化的通信协议。信号16.3重点讨论通信与任务编排。主流做法包括JSON Schema约束、共享向量数据库、事件总线或专用Agent中间件。

通信协议直接影响任务编排效率。采用自然语言通信时，模型容易产生幻觉，导致下游Agent收到错误指令。引入严格Schema后，解析成功率上升，但模型生成符合Schema的输出难度也随之增加。很多框架因此在通信层增加重试和自我修正机制。

任务编排通常分为静态编排和动态编排。静态编排在启动前就把整个流程写死，适合重复性高的业务；动态编排则允许Agent在运行时根据中间结果调整后续路径，这对通信协议的表达能力要求更高。信号把通信与任务编排并列为第三大部分，表明二者紧密绑定，通信协议设计不好，编排就无法可靠执行。

实际系统中，通信延迟和上下文窗口限制是两大现实瓶颈。Agent数量超过5个以后，共享上下文迅速膨胀，模型容易丢失关键信息。部分框架开始尝试只传递摘要或差异信息，但这又引入新的不一致风险。目前还没有公认的最优通信协议，不同项目仍在各自探索。

主流多智能体框架仍处于快速迭代阶段

信号16.4介绍了当前主流多智能体框架。它们普遍支持上述拓扑、角色分工和通信机制，但实现细节差异明显。有的框架偏向代码生成场景，有的专注企业内部知识工作流，还有的专注于科学研究模拟。

这些框架大多采用Python作为宿主语言，通过LangChain、LlamaIndex或AutoGen等底层库构建Agent运行时。共同特点是都提供了可视化调试界面，用于观察Agent之间的消息流和状态变化。但在生产环境中，稳定性仍显不足，经常出现死循环或无限等待。

迭代速度快也意味着API频繁变化。开发者上个月写好的多Agent工作流，这个月升级框架后可能需要重构通信层。信号指出主流框架仍处于快速迭代阶段，这提醒团队在选型时不能只看当前功能，更要评估其维护节奏和社区活跃度。

部分框架开始提供云托管版本，降低部署门槛。但云版本在数据隐私和成本控制上又带来新问题。国内团队往往倾向于自建或基于开源项目深度定制，以满足合规要求。

单Agent到多Agent演进需跨越架构重构

从单Agent升级到多Agent远不是简单把模型数量增加一倍。信号章节大纲显示，这一演进需要重新设计拓扑、重新定义角色、重新实现通信层，整个架构都要重构。

单Agent时代，开发者只需优化提示词和工具调用即可。多Agent时代，必须先决定采用哪种拓扑，再为每种角色设计专属System Prompt，还要实现可靠的通信协议和错误恢复机制。任何一环缺失都会导致系统不可用。

核心挑战在于状态管理。单Agent的上下文就是全部状态，多Agent需要维护全局状态和各Agent局部状态的一致性。信号通过四大部分内容，实际是在提示开发者：演进路径不是线性增加复杂度，而是需要一次架构层面的跃迁。

很多团队在尝试后选择混合模式：核心规划仍由单Agent完成，执行环节拆成多个Sub-Agent。这种折中方案降低了落地难度，但也限制了多Agent理论上能带来的增益。完全拥抱多Agent，需要在工程能力和模型能力上同时达标，目前多数国内团队仍处于探索早期。

国内应用案例暴露多智能体落地难点

国内企业在客服、代码审查、法律文档处理等领域尝试部署多智能体系统。典型架构采用主从拓扑加固定角色分工，主Agent负责理解用户意图并拆解任务，Sub-Agent分别承担信息检索、内容生成、合规检查等工作。

实际运行中，任务分配不均衡的问题反复出现。某些角色长期空闲，另一些则持续过载，导致整体吞吐量远低于预期。通信协议不完善时，下游Agent经常误解上游指令，需要人工介入纠正。

另一个突出难点是成本控制。多Agent意味着每次请求都要多次调用大模型，即使使用较小的Sub-Agent模型，累计费用也远高于单Agent方案。国内企业普遍对ROI敏感，这成为大规模落地的主要障碍。

协作一致性也是现实挑战。不同Sub-Agent对同一事实可能给出矛盾结论，缺乏有效的仲裁机制。部分团队尝试加入评审Agent，但评审Agent本身又可能出错，形成新的循环。

信号章节大纲把通信、编排和主流框架作为重点，结合国内案例看，这些技术问题直接转化为落地难点。目前多数项目停留在POC阶段，真正进入生产环境的案例仍较少。未来若要在国内实现规模化应用，需要在框架稳定性和成本优化上取得突破，同时针对中文语境优化角色提示和通信格式。

多智能体技术仍在快速发展，信号提供的章节结构为开发者提供了清晰的学习路径。从理解拓扑边界开始，逐步掌握角色设计、通信协议，再到选择合适框架，最后结合实际业务分析落地难点，这条路径清晰且务实。

参考来源