章节摘要:MAS 区别于单智能体 AI 的核心,在于智能体之间要交互。这一章讲两件事:一是通信——智能体怎么"说话",包括消息格式、本体、言语行为 speech act 语义,以及 FIPA ACL 这类标准通信语言;二是交互机制——它们怎么协调行动,涵盖协作(合同网、拍卖)、竞争(博弈、拍卖)、协调(投票、社会法则)三类机制。读完你会知道为一群智能体设计协调机制时有哪些选项、各自适合什么场景。
阅读完本章,你应当能够:
交互先要能"说话"(通信),再说"怎么协作或竞争"(协调机制)——前者是基础设施,后者是协同逻辑。
讲清智能体通信的三要素、FIPA ACL 这类标准通信语言、本体在语义互通中的作用,以及知识共享的层次(从信号到知识)和隐私权衡。
拆解三类交互机制:协作(合同网、市场机制)、竞争(博弈、拍卖)、协调(投票、社会法则),给出每类的典型算法、适用场景和代价。
2.1 解决"怎么把信息传过去并让对方听懂"(通信层),2.2 解决"传过去之后怎么据此协调行动"(机制层)。前者是管道,后者是管道上跑的协同逻辑。
2.1 通信(管道) ──► 2.2 协调机制(逻辑) │ │ └── 先能交换信息,再据此协作或博弈 ──┘
值得在章首再强调一遍:MAS 的能力上限,一半由个体的脑子决定(第 1 章),另一半由个体之间"说什么、怎么说、信多少"决定(本章)。很多团队把预算全砸在更强的模型上,智能体之间的消息却还是随手拼的裸文本,结果是每个个体的智力都在通信噪声里打折。一个粗略但有用的经验:多智能体系统的性能问题,先查协议再查模型。
本章两节恰好覆盖通信的两半。2.1 讲"信息怎么准确流动"——格式、本体、意图,是通信的语法和语义;2.2 讲"信息到了之后怎么协同行动"——协作、竞争、协调,是通信的博弈后果。先语法语义、后博弈后果,这个顺序也是设计时的自然顺序:先把话说清楚,再谈怎么讨价还价。
抽象机制要落到自己的系统里才长得牢。建议边读边回答:我的智能体现在传的是什么层次的信息(信号、数据还是知识)?它们的目标关系是纯协作、纯竞争还是混合?现有协调机制的三个变量(带宽、共享、中心化)各拨到了什么位置?读完 2.1、2.2 再回头看这三个答案,多半会想改——那个想改的冲动,就是本章的产出。
本章涉及的交互机制数量多,先给一张总地图建立方位感,读两节时随时回来对照定位。

通信这章内容杂——本体、言语行为、合同网、拍卖、协商——容易读散。给一把钥匙:把所有内容挂到三层结构上。语言层解决"说什么":本体定义词汇,KQML 和 FIPA-ACL 定义消息的语用类型(请求、通知、承诺)。协议层解决"怎么说":合同网规定招标-投标-中标的对话流程,拍卖协议规定出价规则。机制层解决"说了之后怎么达成结果":协商、投票、市场清算。任何一节的内容都能定位到这三层的某一层,层与层之间是正交的——同一套语言可以跑不同的协议,同一套协议可以配不同的机制。考试和实战都爱在层间错配上做文章,比如"本体没对齐导致消息看不懂"是语言层问题,"招标了没人投标"是机制层问题,分层定位是排错的第一步。
理论上可以,工程上经常是个陷阱。共享库隐含了"全局可观察"的假设:所有智能体随时读到所有状态。这在智能体数量少、信任关系简单时可行,但会带来三个问题——写冲突集中(数据库成为串行化点,违背分布式的初衷)、耦合加剧(任何人改表结构所有人遭殃)、隐私和权限难表达(消息模型里"我告诉你什么"是显式决策,共享库里默认全裸)。消息通信贵一些,但把"谁知道什么"变成了一等公民。这是分布式系统里"共享状态 vs 消息传递"的经典之争在 MAS 里的镜像。