多智能体架构

1. 一句话理解

多智能体架构不是“把很多模型放在一起”，而是把一个复杂任务拆成多个职责明确的智能体，让它们通过路由、分工、通信和汇总来协作完成目标。

它的价值不在于智能体数量多，而在于：

每个智能体只负责自己最擅长的子任务
上下文和记忆可以分层管理
复杂任务可以被拆解、调度、复用和追踪
主入口可以把用户体验保持成一个统一窗口

2. 为什么需要多智能体

单智能体适合边界清楚、链路短、工具少的任务；一旦任务同时涉及多个业务域、多个系统、多个知识源，单个智能体就容易出现下面这些问题：

上下文越来越长，推理成本和延迟上升
工具调用越堆越多，边界变得混乱
一个提示词要同时覆盖太多职责，维护困难
结果正确但不可控，难以追踪每一步是怎么得出的

多智能体的思路，就是把“一个大而全的脑袋”拆成“一个协调者 + 多个领域专家”。

3. 常见架构

常见的多智能体架构可以先分成两类：

扁平架构
层级架构

这两类不是绝对对立，实际工程里经常混合使用。比较稳妥的理解是：

扁平架构更像“路由器 + 专家池”
层级架构更像“总控代理 + 下属代理”

3.1 扁平架构

扁平架构里，每个智能体相互独立，主入口主要负责识别用户意图并路由到合适的智能体。智能体完成任务后，通常直接把结果返回给主入口，再由主入口统一输出给用户。

可以把它理解成医院的导医台：

导医台负责问诊入口和分流
各科室负责具体问题
用户最终只需要面对一个入口

适用特点

领域边界清晰
每个子智能体职责单一
任务不需要跨多个子智能体持续协商
主要诉求是“快速找到最合适的专家”

优点

结构简单
易于扩展新的专家智能体
子智能体之间耦合低
路由逻辑清楚，便于排查问题

缺点

各智能体之间缺少天然协同
任务跨域时，主入口要承担较多整合工作
如果路由判断不准，就会把任务送错地方

3.2 层级架构

层级架构里，主入口不仅负责路由，还负责思考、拆解、决策和汇总，更像一个“总协调者”。

用户提出问题后，主入口会先理解整体目标，再拆出多个子任务，分配给不同的智能体；子智能体完成任务后把结果交回主入口，主入口决定是继续执行、重新分派，还是直接反馈用户。

可以把它理解成陪诊人员：

陪诊人员先理解用户整体诉求
再根据情况找不同科室
最后把检查结果整合起来给出下一步建议

适用特点

任务复杂，且往往需要多轮推进
子任务之间存在依赖关系
需要主入口统一保留用户意图和整体目标
结果需要整合、复核或继续派生任务

优点

用户只需面对一个统一入口
主入口可以做全局协调
能把跨域信息整合成更完整的结果
更适合工业场景里的连续诊断和串联分析

缺点

主入口上下文容易变大
任务链路变长后，响应会变慢
如果设计不好，主入口会变成“什么都管、什么都懂一点”的瓶颈
容易出现上下文污染

4. 架构示意

4.1 扁平架构

%%{init: {"theme":"base","themeVariables":{"fontFamily":"Microsoft YaHei, PingFang SC, Noto Sans CJK SC, sans-serif","primaryColor":"#E0F2FE","primaryTextColor":"#0F172A","primaryBorderColor":"#38BDF8","lineColor":"#64748B","secondaryColor":"#ECFDF5","tertiaryColor":"#FFF7ED"}}}%%
flowchart TD
  U[用户]:::user --> G[主入口<br/>Router]:::router

  subgraph P[专家池]
    direction LR
    A[智能体 A<br/>领域专家]:::expert
    B[智能体 B<br/>领域专家]:::expert
    C[智能体 C<br/>领域专家]:::expert
  end

  G --> A
  G --> B
  G --> C
  A --> G
  B --> G
  C --> G
  G --> R[统一结果输出]:::result
  R --> U

  classDef user fill:#111827,color:#FFFFFF,stroke:#111827,stroke-width:1px;
  classDef router fill:#DBEAFE,color:#1D4ED8,stroke:#3B82F6,stroke-width:2px;
  classDef expert fill:#ECFDF5,color:#047857,stroke:#10B981,stroke-width:1.5px;
  classDef result fill:#FEF3C7,color:#92400E,stroke:#F59E0B,stroke-width:2px;

4.2 层级架构

%%{init: {"theme":"base","themeVariables":{"fontFamily":"Microsoft YaHei, PingFang SC, Noto Sans CJK SC, sans-serif","primaryColor":"#F5F3FF","primaryTextColor":"#0F172A","primaryBorderColor":"#8B5CF6","lineColor":"#64748B","secondaryColor":"#EEF2FF","tertiaryColor":"#F8FAFC"}}}%%
flowchart TD
  U[用户]:::user --> M[主代理<br/>总协调者]:::manager

  M --> P{任务拆解}:::decision

  subgraph W[执行层]
    direction LR
    A[子智能体 A<br/>领域专家]:::worker
    B[子智能体 B<br/>领域专家]:::worker
    C[子智能体 C<br/>领域专家]:::worker
  end

  P --> A
  P --> B
  P --> C
  A --> M
  B --> M
  C --> M

  M --> D{是否继续分派}:::decision
  D -->|是| P
  D -->|否| O[结果汇总<br/>最终答复]:::result
  O --> U

  classDef user fill:#111827,color:#FFFFFF,stroke:#111827,stroke-width:1px;
  classDef manager fill:#EDE9FE,color:#5B21B6,stroke:#7C3AED,stroke-width:2px;
  classDef decision fill:#FDE68A,color:#92400E,stroke:#F59E0B,stroke-width:2px;
  classDef worker fill:#E0E7FF,color:#3730A3,stroke:#6366F1,stroke-width:1.5px;
  classDef result fill:#DCFCE7,color:#166534,stroke:#22C55E,stroke-width:2px;

5. 通信与记忆

多智能体系统里，通信不是简单地“把消息转发出去”，而是要控制哪些信息该共享、哪些信息必须隔离。

比较稳妥的做法是：

主智能体保留全局目标和任务进度
子智能体保留自己领域内的短期记忆和工具上下文
子任务返回结果时，尽量返回“结论 + 关键证据 + 风险提示”，而不是整段原始对话
子会话最好通过裁剪后的上下文派生，而不是完整复制主会话

这能减少两个问题：

上下文污染
不必要的记忆膨胀

5.1 会话派生

在一些实现里，主会话会通过派生子会话的方式，把经过裁剪的上下文传给子智能体。这样既能共享关键记忆，又能避免把无关历史带进子任务。

这个机制特别适合工业场景，因为工业场景里经常会出现：

某个设备、产线、工艺参数需要连续追踪
用户会在前后几轮对话里不断补充细节
子智能体只需要和自己任务有关的那部分上下文

6. 工业场景里的典型组织方式

在工业系统中，多智能体通常不是“全域通用”地铺开，而是围绕业务域做组织。

常见模式是：

一个主智能体负责统一入口、协调和汇总
多个领域智能体分别负责拧紧、产线性能、设备报警、知识库查询、报表生成等任务
子智能体尽量绑定自己的领域工具和领域记忆
主智能体负责跨域关联和最终解释

这种结构特别适合下面这类场景：

用户先问一个具体设备问题
后续又要追溯报警、产能、质量或工艺原因
一个结论需要多个系统的证据拼起来才能成立

6.1 工业例子

假设用户先问“某把枪的异常螺栓特别多”，再继续问“这把设备的报警记录是什么”。

在层级架构里，主代理可以：

识别出这不是孤立问题，而是一个跨域诊断任务
把报警查询、拧紧数据查询、产线性能分析拆给不同子智能体
汇总多个结果后判断是否存在关联
再给出建议，而不是只返回单点查询结果

这类任务如果只靠扁平架构，也能做，但主入口要自己承担更多整合逻辑。

7. 选型建议

7.1 什么时候选扁平架构

业务域边界清楚
每个智能体职责很单一
用户主要是“找对专家”
任务链路短，结果不需要多轮协商

7.2 什么时候选层级架构

任务需要跨多个系统和领域
需要把结果串起来分析
需要持续跟踪同一个任务上下文
主入口需要对最终结果负责

7.3 工业系统里更常见的落点

工业场景里，层级架构通常更有优势，因为它更适合：

统一入口
分域处理
结果整合
追溯诊断

但如果只是“查询某个单点信息”，扁平架构会更轻、更稳、更容易维护。

8. 设计原则

8.1 职责单一

每个智能体最好只负责一个清晰领域，不要把“查询、诊断、建议、执行、审批”全塞进一个智能体里。

8.2 明确边界

要清楚每个智能体能做什么、不能做什么、数据从哪里来、结果如何验收。

8.3 控制上下文

上下文不是越多越好。能摘要就摘要，能裁剪就裁剪，能局部传递就局部传递。

8.4 结果可追踪

多智能体系统不是只追求“答对”，还要能解释：

哪个智能体处理了什么
用了哪些数据
结果为什么成立
哪些地方仍然不确定

8.5 允许人工收口

在工业场景里，最后一层收口经常仍然要保留人工确认，尤其是涉及：

风险判断
规则冲突
生产异常
需要操作执行的动作

9. 常见风险

9.1 上下文污染

主代理在多轮任务中接收的信息太多，容易把无关历史带入当前判断。

9.2 调度过深

链路太长会导致响应变慢，也会让排障变难。

9.3 过度拆分

智能体拆得过细，反而会增加通信成本，降低可维护性。

9.4 路由失准

用户意图识别不准时，任务会落到错误的子智能体，导致结果偏离预期。

9.5 记忆失控

如果没有摘要、裁剪和过期机制，长期运行后记忆会越来越重，系统变得难以管理。

10. 与工业智能体的关系

多智能体架构本质上是工业智能体的一种组织方式。

工业智能体的重点，不只是“会不会聊天”，而是能不能把多个系统、多个领域、多个任务串成一个可控的执行链路。

因此，多智能体常常和下面这些能力一起出现：

统一入口
工具调用
子任务路由
共享记忆
结果汇总
追踪与复盘

如果再往下一层走，它还会和技能沉淀、知识库、数据管道和权限控制结合起来，形成真正可运营的工业智能体体系。

11. 结论

多智能体架构的核心是分工，不是堆数量
扁平架构适合“路由 + 专家池”
层级架构适合“总控 + 子任务编排”
工业场景里，层级架构通常更适合跨域诊断和连续分析
真正要控制的是上下文、记忆、通信成本和结果可追踪性
最终目标不是让智能体看起来更复杂，而是让系统更可控、更可复用、更容易落地

工作笔记

#Domain Knowledge #工作笔记

多智能体架构

https://luischen.github.io/2026/07/01/manulism-work/20_Domain_Knowledge/29 AI与智能体/01 工业智能体/01 多智能体架构/

作者

Luis Chen

发布于

2026年7月1日

许可协议

HTTPS 知识索引上一篇

工业智能体总览下一篇