工程界讲角色边界，控制论讲博弈与稳定性：多智能体"协同"的两套语言
如果你最近在搭建基于大模型的多智能体系统，大概率读过这类工程文档：怎么定义角色、怎么传递消息、怎么选择编排结构。而如果你翻阅学术文献，看到的却是另一番景象：博弈论、一致性控制、稳定性分析、收敛性证明。
这不是巧合。工程社区和控制理论社区在讨论"多智能体协同"时，使用的几乎是两套不相交的语言。把它们并排放在一起看，你会发现各自回答了什么、又各自漏掉了什么。本文基于两份公开资料展开对照：Swarms 团队的博客《什么是多智能体系统？》，以及《自动化学报》的综述《多智能体协同研究进展综述：博弈和控制交叉视角》。
第一套语言：工程文档讲"怎么接"
Swarms 的博客给出的定义相当直白：多智能体系统是由一组相互独立的 AI 智能体组成的系统，每个智能体有自己的角色、指令，往往还有各自的模型，它们通过一套明确的结构进行沟通与协调，共同完成单个智能体难以独立胜任的任务。
这套话语的核心概念清单包括：
角色（Roles）作为边界。 博客强调，角色不只是一个标签，而是一条边界------"研究员"智能体的系统提示词不应该同时去规定最终格式，"审阅者"智能体的职责是评审输出，而不是从零生成内容。清晰的角色边界被描述为防止系统退化成"拆分成多次 API 调用的一个巨大、松散的提示词"的关键。
通信（Communication）作为交接。 一个智能体的输出如何变成另一个智能体的输入，可以简单到把文本回复直接传给下一个提示词，也可以复杂到维护一份群聊模式下的共享消息日志。传递什么、总结什么、丢弃什么，这些交接机制在实践中非常关键。
编排结构作为取舍。 博客列举了几类典型应用：研究与综合（调研、分析、写作各司其职）、文档与数据流水线（提取、校验、格式化每步可独立替换）、多视角评审（安全、风格、正确性并行审查后汇总）、带升级机制的客服工作流（一线处理常规问题，超范围的升级给更强的智能体），以及开放式任务中由主管智能体在运行时动态创建子智能体。
这套语言的回答能力在于结构和职责划分：任务怎么拆、信息怎么流、每一步怎么检查和替换。它对"系统应该长什么样"给出了具体可操作的清单。
第二套语言：控制理论讲"为什么收敛"
《多智能体协同研究进展综述：博弈和控制交叉视角》站在完全不同的角度。这里的"协同"不是任务分工，而是动态系统意义上的协调行为------多个具有动力学特性的智能体，在交互拓扑（可以变化）下达成一致或完成联合控制目标。
从综述的参考文献结构就能看出研究脉络的几条主线：
一致性（Consensus）与分布式控制。 例如线性多智能体系统在动态交互拓扑下、领导者---跟随者框架中的协同问题。经典的问题是：局部信息交换的规则满足什么条件，全局行为才能收敛？
分布式优化与决策。 例如有偏最小一致性的分布式最短路径规划------用局部的信息传递求解全局的图优化问题。
博弈论与控制的交叉。 多个智能体目标冲突或部分合作时，均衡、激励机制与稳定性如何同时成立。这是综述标题里"博弈和控制交叉视角"的直接落点。
通信与估计的联合设计。 例如通过因果推断实现完全去中心化的多智能体通信，以及分布式微分动态规划在大规模多智能体控制中的架构。
这套语言的回答能力在于性质保证：在什么条件下系统会收敛到期望状态、博弈达到均衡、控制器在干扰和拓扑变化下保持稳定。它不关心你的提示词写得好不好，它关心的是微分方程和图拓扑决定的动态行为。
对照表：两套语言各答了什么
| 维度 | 工程实践话语（Swarms 类） | 控制理论话语（自动化学报综述类） |
|---|---|---|
| 核心问题 | 怎么拆任务、怎么接消息 | 什么条件下收敛、何时稳定 |
| 基本单元 | LLM + 工具 + 记忆的 Agent | 具有动力学方程的智能体 |
| 交互模型 | 消息传递、共享日志、编排结构 | 交互拓扑、信息流图、博弈结构 |
| 评判标准 | 任务完成质量、可维护性、可替换性 | 稳定性、收敛性、均衡存在性 |
| 典型保证 | 经验性的，靠评审和测试 | 定理性的，有前提条件 |
有意思的是，两套语言各有一块明显的盲区：
工程话语漏掉了"性质"。 Swarms 博客里没有任何关于"这个流水线会不会收敛"或"多智能体互相评审会不会震荡"的形式化讨论。一个安全评审智能体和风格评审智能体给出矛盾意见、汇总智能体来回摇摆的场景，在工程清单里只能靠经验和测试兜底，而在控制理论里这是典型的稳定性问题。
控制理论漏掉了"语义"。 综述里的智能体是有精确动力学模型的物理或计算实体，信息是可量化的状态。而 LLM 智能体的"输出"是非结构化文本，它的"误差"是幻觉和格式错误------这些东西目前很难写进一致性分析的假设里。综述中的通信研究（如基于因果推断的去中心化通信）处理的是信息流的结构，而不是自然语言内容的质量。
实践建议：判断你的系统缺哪一层
- 如果你还没搭建系统，先从工程清单入手。Swarms 博客的原则值得记住：意义不在于智能体数量越多越好，而在于让系统的结构去匹配任务本身的结构。如果你的任务有明确的流水线形态（提取→校验→格式化），不要硬套群聊模式。
- 如果你的系统已经跑起来了但不稳定------比如评审环节来回反复、汇总结果对输入顺序敏感------你在缺的那一层。工程清单解决不了"振荡"，这本质上是一个收敛性问题。即使无法引入严格的理论工具，也可以借鉴控制论的思路：限制迭代轮数（相当于给反馈回路加截止条件）、引入裁决者（打破对称博弈）、对中间状态做快照（防止发散后无法回退）。
- 如果你的系统涉及多个目标冲突的智能体（比如成本优化智能体和质量优化智能体互相拉扯），这正是博弈论视角的主场。工程上你能做的是显式定义优先级和升级机制，类似 Swarms 博客里客服工作流的分诊逻辑；理论上这对应机制设计和均衡分析。
- 不要用错层的工具补错层的问题。 用稳定性定理去指导提示词写作没有意义，反过来，多加几个评审智能体也无法保证动态行为收敛。
适用范围与局限
需要说明的是，本文的对照基于两份资料：《什么是多智能体系统？》（Swarms 博客）代表的是 LLM 智能体工程社区的一支实践话语，《多智能体协同研究进展综述：博弈和控制交叉视角》代表的是自动化领域的一条研究脉络------两者都不是各自领域的全貌。控制理论界也有面向学习型智能体的工作，工程界也有人在探索形式化验证；这里只是把两份资料的差异作为一个观察切片。
另外一个诚实的限制是：LLM 多智能体系统与经典多智能体控制系统之间的鸿沟目前没有被完全填上------非结构化语言输出如何纳入收敛性分析，仍是开放问题。两套语言短期内不会合并，但看清它们各自回答了什么，至少能帮你在系统出问题时，知道该去哪一层找原因。
参考资料
以下链接为本文使用的公开资料。事实依据与检索摘录保存在本地记录中；资料内容与适用范围以原始页面为准。