多智能体系统架构设计：从单体代理到协作网络

当一个智能体开始同时处理检索、数据分析、日程安排、内容生成、审批和外部系统调用时，问题往往不在于模型是否足够聪明，而在于它掌握的信息是否过多、职责是否过杂，以及执行过程是否可控。

多智能体系统的价值，并不是把一个任务机械地拆给更多模型，而是重新设计上下文、职责和控制权的边界。一个好的系统会让每个参与者只看到完成当前工作所需的信息，并将复杂过程收敛为可观察、可测试、可维护的协作流程。

先判断：真的需要多个智能体吗？

多智能体不是复杂应用的默认答案。对于工具数量不多、步骤明确、上下文稳定的任务，一个配备合适提示词和工具的单一智能体通常更简单、更便宜，也更容易调试。

当出现以下信号时，才值得考虑引入协作结构：

上下文不断膨胀：一个提示词需要容纳多个领域规则、工具说明和历史记录，模型开始混淆职责。
能力由不同团队维护：例如日历、邮件、CRM、数据库分别由不同业务团队负责，需要明确接口和独立迭代。
任务天然可并行：同一个问题需要同时查询代码仓库、知识库和协作记录，串行处理会拉高等待时间。
流程必须可控：某些步骤需要固定顺序、人工审批、状态持久化或严格的业务规则。

核心原则可以概括为一句话：多智能体设计首先是上下文工程，其次才是任务编排。

单一智能体与协作系统的差别

单一智能体将所有决策集中在一个角色中。它启动快，逻辑直接，但随着工具和领域知识增加，系统提示词会越来越长，定位错误也会越来越困难。

协作系统则更像"调度者加专家组"：调度者负责理解用户意图、决定何时调用谁、整合结果；专家只专注于自己的领域。例如，用户询问"明天的天气适不适合户外跑步"，调度者可以并行向天气专家和日期专家取数，再将结果交给生活建议专家形成最终结论。
#mermaid-svg-tRdj4tskBjV5hzdT{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-tRdj4tskBjV5hzdT .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-tRdj4tskBjV5hzdT .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-tRdj4tskBjV5hzdT .error-icon{fill:#552222;}#mermaid-svg-tRdj4tskBjV5hzdT .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-tRdj4tskBjV5hzdT .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-tRdj4tskBjV5hzdT .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-tRdj4tskBjV5hzdT .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-tRdj4tskBjV5hzdT .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-tRdj4tskBjV5hzdT .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-tRdj4tskBjV5hzdT .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-tRdj4tskBjV5hzdT .marker{fill:#333333;stroke:#333333;}#mermaid-svg-tRdj4tskBjV5hzdT .marker.cross{stroke:#333333;}#mermaid-svg-tRdj4tskBjV5hzdT svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-tRdj4tskBjV5hzdT p{margin:0;}#mermaid-svg-tRdj4tskBjV5hzdT .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-tRdj4tskBjV5hzdT .cluster-label text{fill:#333;}#mermaid-svg-tRdj4tskBjV5hzdT .cluster-label span{color:#333;}#mermaid-svg-tRdj4tskBjV5hzdT .cluster-label span p{background-color:transparent;}#mermaid-svg-tRdj4tskBjV5hzdT .label text,#mermaid-svg-tRdj4tskBjV5hzdT span{fill:#333;color:#333;}#mermaid-svg-tRdj4tskBjV5hzdT .node rect,#mermaid-svg-tRdj4tskBjV5hzdT .node circle,#mermaid-svg-tRdj4tskBjV5hzdT .node ellipse,#mermaid-svg-tRdj4tskBjV5hzdT .node polygon,#mermaid-svg-tRdj4tskBjV5hzdT .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-tRdj4tskBjV5hzdT .rough-node .label text,#mermaid-svg-tRdj4tskBjV5hzdT .node .label text,#mermaid-svg-tRdj4tskBjV5hzdT .image-shape .label,#mermaid-svg-tRdj4tskBjV5hzdT .icon-shape .label{text-anchor:middle;}#mermaid-svg-tRdj4tskBjV5hzdT .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-tRdj4tskBjV5hzdT .rough-node .label,#mermaid-svg-tRdj4tskBjV5hzdT .node .label,#mermaid-svg-tRdj4tskBjV5hzdT .image-shape .label,#mermaid-svg-tRdj4tskBjV5hzdT .icon-shape .label{text-align:center;}#mermaid-svg-tRdj4tskBjV5hzdT .node.clickable{cursor:pointer;}#mermaid-svg-tRdj4tskBjV5hzdT .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-tRdj4tskBjV5hzdT .arrowheadPath{fill:#333333;}#mermaid-svg-tRdj4tskBjV5hzdT .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-tRdj4tskBjV5hzdT .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-tRdj4tskBjV5hzdT .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-tRdj4tskBjV5hzdT .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-tRdj4tskBjV5hzdT .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-tRdj4tskBjV5hzdT .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-tRdj4tskBjV5hzdT .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-tRdj4tskBjV5hzdT .cluster text{fill:#333;}#mermaid-svg-tRdj4tskBjV5hzdT .cluster span{color:#333;}#mermaid-svg-tRdj4tskBjV5hzdT div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-tRdj4tskBjV5hzdT .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-tRdj4tskBjV5hzdT rect.text{fill:none;stroke-width:0;}#mermaid-svg-tRdj4tskBjV5hzdT .icon-shape,#mermaid-svg-tRdj4tskBjV5hzdT .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-tRdj4tskBjV5hzdT .icon-shape p,#mermaid-svg-tRdj4tskBjV5hzdT .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-tRdj4tskBjV5hzdT .icon-shape .label rect,#mermaid-svg-tRdj4tskBjV5hzdT .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-tRdj4tskBjV5hzdT .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-tRdj4tskBjV5hzdT .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-tRdj4tskBjV5hzdT :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 用户请求
调度者
天气专家
日期专家
建议专家
统一回复

这种拆分不应只看"任务名称"，更应看信息边界。天气专家不需要阅读完整对话或邮件工具说明；建议专家只需获得整理后的日期和天气事实。上下文越干净，模型越容易稳定地完成职责。

五种常用协作结构

1. 子代理：由主代理集中协调

子代理模式适合存在多个独立业务域、但仍希望由一个主代理统一对话体验的场景。主代理将子代理包装成可调用工具，决定传入什么任务、何时调用，以及如何使用返回结果。

子代理通常应保持无状态：每次接到任务时都在一个干净的上下文中工作，把长链路推理、检索细节和试错过程留在内部，最后只将压缩后的结论返回主代理。这样既降低主对话的上下文负担，也避免中间过程污染后续判断。

在子代理很多时，可使用一个通用的 task 分派工具，而非为每个专家暴露一个工具。主代理只负责"把什么任务交给谁"，子代理注册表负责映射具体专家。这种方式便于团队独立扩展，也能进一步缩小主代理需要理解的工具集合。

同步调用适合后续步骤依赖子代理结果，例如"取数后分析"；异步调用则适合独立、耗时的后台工作，例如生成报告或执行批量处理。不要把异步简单理解为代码层面的 async/await，真正关键的是主对话是否必须等待该任务完成。

2. 交接：让行为随状态推进

交接模式适合有明确阶段的长流程，例如售后支持、开户、理赔或表单收集。系统维护 current_step 或 active_agent 一类状态字段；代理通过工具调用更新状态，下一轮请求再根据状态加载对应的提示词、工具和规则。

以技术支持为例，流程可以依次收集保修状态、识别问题类型、给出解决方案，必要时转人工。每一步只开放当前阶段所需的工具，避免模型越过流程直接执行不该执行的操作。

这类系统需要可靠的状态持久化。若只把状态留在内存中，服务重启或用户隔轮回复都会让流程断裂。工程上应为会话配置稳定的线程标识，并使用检查点或持久化存储保存业务状态和必要的对话摘要。

3. 技能：按需加载专业知识

技能模式仍由单一智能体保持控制权，但将领域提示词、模板、规范和资源封装成可按需加载的能力。它特别适合 SQL 助手、编程助手、知识库问答和多格式内容创作等场景。

关键机制是"渐进式披露"：初始提示词只保留技能名称和简短说明；当任务真正涉及销售分析、库存管理或合规审阅时，智能体再加载对应的完整规则、数据结构和示例。相比一开始把全部知识塞入上下文，这能显著减少 Token 消耗和概念干扰。

技能并非只能是文本。它可以关联脚本、模板、数据源和动态注册的工具；也可设计为层级结构，例如先加载数据分析能力，再按需进入数据处理或可视化的子技能。实践中可按规模制定策略：小技能直接放入提示词，中等技能按需加载，大型技能则应支持分页、搜索或分层浏览。

需要注意，基础技能机制通常只能通过提示词建议"先加载再执行"，不能强制步骤顺序。若业务要求必须先完成资质校验再访问某类数据，就应结合状态机或自定义工作流建立硬约束。

4. 路由器：分类、并行查询与结果合成

路由器适用于知识天然分散、且一次请求可能涉及多个来源的场景。它先对输入进行分类或拆解，再将子问题发送给一个或多个专业处理节点，最后合成统一答案。

例如，对于"如何验证 API 请求"，系统可以并行查询代码仓库中的实现、内部文档中的规范以及协作平台上的讨论记录。每个节点返回统一格式的结果，汇聚节点负责去重、校验冲突并组织最终回复。

路由器与子代理的区别在于：路由器通常是一次性的分类和分发步骤，不负责长期维护对话状态；子代理模式中的主代理则持续维护对话上下文，并可在多轮交互中动态规划调用。若用户后续问题强依赖前文，通常让对话代理管理记忆，再把具体的多源查询交给无状态路由器，会更清晰。

5. 自定义工作流：把确定性规则与智能体结合

当上述模式无法满足要求时，可以用图式工作流定义顺序、分支、循环和并行节点。一个节点既可以是普通代码，也可以是一次模型调用，或是完整的工具型智能体。

这类架构适合风控、审批、复杂路由和多阶段处理等场景。它的优势是将必须确定执行的业务规则交给程序控制，将需要理解、生成或归纳的部分交给模型。不要让模型承担本可以由状态机、权限校验或条件分支可靠完成的职责。

审批、安全与可恢复性不能后补

能够发送邮件、创建日程、修改数据或调用外部服务的代理，必须在设计阶段考虑人工参与。对于高影响工具，可以在调用前中断执行，展示工具名称、参数和操作说明，等待审批、编辑或拒绝后再继续。

人工审批要与持久化配套：中断发生后，系统需要保存当前状态，确保用户稍后批准时能从正确节点恢复，而不是重新执行前置步骤。对外部副作用还应补充幂等键、权限检查、超时与重试策略，并记录完整的审计日志。

一套实用的选型顺序

面对一个新需求，可以按以下顺序决策：

先用单一智能体验证任务是否真的复杂到需要拆分。
需要领域专家、但希望统一对话入口时，选择子代理。
需要跨轮次推进固定业务阶段时，选择交接模式。
需要让同一智能体按需掌握不同知识时，选择技能模式。
需要一次性查询多个独立来源并合成结论时，选择路由器。
需要严格流程、复杂依赖或确定性控制时，构建自定义工作流。

真实系统通常会组合这些模式：主代理负责对话和任务协调，路由器负责并行检索，技能负责按需注入专业规则，关键动作通过人工审批中断，外层工作流则守住确定性的业务边界。

结语

多智能体系统的成熟标志，不是代理数量更多，而是每个角色的输入、输出、状态和权限都足够清楚。先把上下文边界设计好，再选择协作方式；先把确定性规则固化下来，再让模型在真正需要智能判断的地方发挥作用。