简介分布式人工智能与智能体是人工智能的重要方向这份PPT直击大型智能问题的并行性、分布性与开放性系统梳理了分布式人工智能的三大分支分布式问题求解强调大粒度协作群体将待求解问题分解为子问题并综合部分解多智能体系统关注自治个体的协作、对抗与开放生命周期并行人工智能聚焦基于符号主义与联结主义的并行计算体系。同时详细阐述了智能体的强弱定义、思考型、反应型与混合型的分类特点以及多智能体系统的组织形成、协商与任务分配机制。资源包仅含1个pptx文件共295KB内容结构完整、逻辑清晰适合高校学生、科研人员及人工智能从业者作为课程教学、自学入门或技术汇报的参考。目前已有112人学习可帮助快速搭建分布式智能与多智能体系统的知识框架深入理解智能体的心智状态与理性行为建模。1. 从 DAI 到 AI Agent为什么 2025 年还要回来翻这份课件从 1980 年 MIT 那场 DAI 国际会议算起分布式人工智能已经走了四十多年但直到今天几乎所有认真做 Agent 开发的人最后都要回来补这节课。原因很简单单机单模型的智能已经打到天花板多 Agent 协作、多机调度、联邦式推理这些真实场景面对的正是 DAI 当年概括出的三个问题——并行性、分布性、开放性。这份讲义的含金量在于它没有停留在概念罗列而是把 DAI 从 DPS、PAI 到 MAS 的演进脉络以及 Agent 从 BDI 到反应式再到分层混合的建构路径完整串了一遍。对想转 AI Agent 开发的工程师或正在设计多智能体系统的架构师来说这份材料可以直接当入门骨架照着它的框架去补框架选型和协议设计基本不会跑偏。2. DAI 的三个分支DPS、PAI 与 MAS 的边界和分工DAI 一词在 1980 年 MIT 的 “The Workshop on Distributed Artificial Intelligence” 上被正式推到台前Avouris N.M 后来从个体的自治性和粒度出发把 DAI 的研究切成了三块分布式问题求解DPS、多 Agent 系统MAS和并行人工智能PAI。这三者的分界线经常被搞混尤其是 DPS 和 MAS——二者表面都在做“多个计算体协作求解”但在协作是否可预知、控制是否集中这两点上存在着本质区别。2.1 DPS自顶向下“分解—求解—综合”的老牌方案DPS 的研究目标很朴素创建一个粒度较大的协作群体把待求解问题拆成互不重叠的子问题分配给群体里的个体去算每个个体输出局部解最后按事先定好的规则把局部解综合成全局解。关键约束在于这种协作是可预知的个体之间不需要协商本质是一种“命令/服从式”的调度关系环境条件已知算法专用整体设计自顶向下展开。用一个典型的并行分治示意就能看清 DPS 的骨架import concurrent.futures def solve_subtask(sub_id: int, data: list) - float: # 子问题局部求解每个 worker 独立处理一段数据 return sum(x * sub_id for x in data) / (len(data) 1) def dps_orchestrator(tasks: list[list], workers: int 4) - list[float]: # 求解器的角色负责任务分解与结果综合 with concurrent.futures.ThreadPoolExecutor(max_workersworkers) as pool: futures [ pool.submit(solve_subtask, i, task) for i, task in enumerate(tasks) # 分解按索引指派子任务 ] partial [f.result() for f in futures] # 收集部分解 # 综合所有子解按固定策略合并为全局解 return partial if __name__ __main__: tasks [[1, 2, 3], [4, 5, 6], [7, 8, 9], [10, 11, 12]] print(dps_orchestrator(tasks, workers4))solve_subtask对应 DPS 中的部分求解器dps_orchestrator用线程池做任务分发模式是“分解 → 并行求解 → 综合”个体间没有协商环节也没有动态的角色调整。workers参数决定并行度但 DPS 的并行度通常在设计期就定死这也是它和 MAS 拉开差距的地方——DPS 的“智能”在编排者手里不在个体手里。这个模式的强项是算法确定、结果可复现适合场景固定的批量任务弱项是对环境变化没有弹性一旦运行期子问题边界发生变化整套分配方案就要重做。传统 DAI 里的多专家系统、分布式专家系统、群体决策支持系统走的基本都是这条路线。2.2 PAI细粒度并行与符号主义-联结主义的交汇PAI 这里容易被当成“并行加速”的工程问题但它其实是一个体系结构问题。讲义里的定义说得很清楚系统由多个紧密耦合的问题求解器组成每个求解器是一个细粒度的知识体研究观点与方法结合了符号主义和联结主义神经元计算机也被划入这个范畴。和 DPS 相比PAI 的耦合更紧密不是任务级分解而是把知识本身分布到多个处理器上让推理过程并行发生。这类结构对应的是传统 AI 的一个长期痛点符号推理的状态空间搜索是串行瓶颈专家系统的知识库越大单机推理延迟越长。PAI 的思路是让多个小求解器同时推进各自的知识匹配再通过共享内存或高速互联同步中间结果。神经元计算机与 PAI 的关系可以理解为联结主义路线的硬件化把大量细粒度知识体做成神经元形态用并行脉冲计算替代符号匹配。我一般会建议把 PAI 当作理解“从符号 AI 到计算智能”过渡的关键节点它和现在大模型的张量并行训练不是一回事但在“细粒度、紧耦合、并行求解”这三个特征上二者的结构逻辑一脉相承。2.3 MAS自治个体与无全局控制的协作模型如果说 DPS 是“总指挥加执行者”MAS 就是“一群没有统一领导的自组织个体”。MAS 里的每个 Agent 是自主的生命周期不全被其他 Agent 掌握它们可以有共同目标也可以各怀目的之间可能协作也可能对抗。协作形式更是直接落到真实社会规则上——命令/服从式、投票式、磋商式全部都能出现需要系统去协调这些自治行为。讲义特别强调了一个组合约束Agent 在空间上分布、时间上并行、逻辑上依赖三者叠加让 MAS 的求解过程比 DPS 复杂得多。三个分支的边界其实并不严格互有交叉所以实践中判断一个系统落在哪条线上我常用三个问题来测个体能不能拒绝任务拒绝之后系统怎么处理有没有全局事实源能拒绝、有冲突、无全局控制就往 MAS 上靠。三个分支的横向对比可以看这张表维度DPSPAIMAS个体粒度大粒度任务单元细粒度知识体自治 Agent耦合方式松散任务级紧密耦合依赖关系动态变化控制方式集中/命令式结构化并行无全局控制协作是否预知预知不协商结构固定动态协商/竞争典型场景分布式专家系统神经元计算机、并行推理多智能体协作系统3. 从 BDI 到反应式再到分层混合Agent 的三条构建路径Agent 的定义是出了名的难。Hewitt 说定义 Agent 和定义智能一样困难而讲义给出的线索其实已经够用弱定义强调自治性、社会性、感知环境并作出反应强定义在弱定义之上再加入信念、愿望、意图这类心智状态。定义之争并不是书斋问题而是直接决定你用什么架构去写代码——只有感知-反应需求就上反应式需要目标推理就上 BDI既要快又要稳就上混合架构。3.1 思考型 Agent 与 BDI 模型的实现骨架思考型 Agent 本质是一个符号 AI 系统。它把 Agent 当作一个有意识态度的智能代理用信念Belief、愿望Desire、意图Intention三个模态算子刻画推理过程这是 Rao 和 Georgeff 对 BDI 模型的核心贡献。在这套框架里信念对应 Agent 对当前环境与世界状态的判断愿望是它想达到的目标集合意图则是经过承诺之后真正准备执行的行动方案。BDI 循环的代码骨架可以写得非常简洁class SimpleBDIAgent: def __init__(self, beliefs: dict, desires: list[dict]): self.beliefs beliefs # 信念对环境的判断形如 {cpu_load: high} self.desires desires # 愿望候选目标含前提条件与计划 self.intentions [] # 意图承诺执行的计划 def perceive(self, env): # 感知环境并用新观测更新信念 self.beliefs.update(env) def deliberate(self): # 从愿望中筛选出信念可支持的计划写入意图 for desire in self.desires: if self._holds(desire[precondition]): self.intentions.append(desire[plan]) def _holds(self, conditions: dict) - bool: # 检查前置条件是否全部满足 return all(self.beliefs.get(k) v for k, v in conditions.items())perceive负责信念更新deliberate完成从愿望到意图的筛选_holds是前置条件的统一校验入口。这三个方法分别对应 BDI 中的信念修正、选项生成和意图形成。真实的 BDI 框架比如 Jason、Jadex在循环里还会加入意图的挂起、恢复与放弃策略但核心永远是这个感知—思考—行动的闭环。这里要注意beliefs的写入不能无脑覆盖感知数据必须先做可信度评估否则一次误判会让整个意图链崩塌。讲义里提到的理性平衡简单说就是不要让 Agent 不断切换意图、导致什么事都收不了尾这也是引入“承诺”的原因。3.2 反应型 Agent没有知识只有映射思考型 Agent 的复杂度劝退了不少人行为主义心理学的回应更激进Agent 根本不需要知识。反应型 Agent 不做符号表示和推理它的全部行为就是感知环境变化然后触发对应动作。讲义说得非常直白——反应型 Agent 对环境变化有很高的响应速度但智能程度低、缺乏灵活性。反应型的实现本质是一组条件-动作规则或者更工程化一点是一张状态到动作的映射表。比如一个避障 Agent传感器读到前方距离小于阈值就直接输出“转向”中间没有任何推理环节。它的缺陷在于没有长期目标也没有对未来的预期规则覆盖不到的场景直接就失效。所以现实中很少看到纯反应式系统更多是把它用在低层控制里把“快”交给规则把“聪明”交给上层。3.3 混合型 Agent反应层保底线认知层做决策混合型 Agent 是当前研究的主流也是工程上最常用的折中。讲义里的结构描述很关键底层是反应层不做符号表示和推理可快速响应并处理外部环境的突发变化通常具有较高优先级高层采用传统 AI 方法进行规划、推理和决策。两层配合的典型场景是机器人导航——反应层处理突发障碍物避让认知层规划全局路径遇到计划外障碍时反应层先动作再让认知层重新规划。能力维度思考型反应型混合型响应速度慢快反应层快认知层慢是否需要知识库是符号化否上层需要环境变化适应依赖重新推理依赖规则覆盖双层协同工程复杂度高低最高适用场景规划、博弈、决策实时控制、应急响应机器人、多 Agent 系统设计混合型 Agent 时一个容易被忽略的技术点是优先级仲裁。反应层的高优先级不能简单地理解为“反应层先跑”而是要明确当反应层动作与认知层计划冲突时以反应层指令为准同时通知认知层撤销或修正当前意图。否则两层各跑各的在真实系统里就会表现出抖动和目标丢失。4. 多 Agent 协作的关键机制组织形成与协商协议MAS 的前提是“没有全局控制”那协作怎么发生答案是通过组织形成和协商这两个机制。组织形成解决“谁和谁一起干活、各自承担什么角色”的问题协商解决“在干活过程中想法和利益冲突时怎么办”的问题。讲义把组织形成归纳成三条路线联盟形成、交互形成和面向结构的方法而协商则从对策论走向了基于劝说的新范式。4.1 组织形成的三条路线联盟形成方法源于对策论中的多人合作博弈代表工作是 Sheory 等人的研究。它的执行路径非常标准第一步形成联盟结构第二步求解联盟值第三步把联盟值在成员之间分配。三步反复迭代直到得到稳定解才停。注意这里的“稳定”不是说所有 Agent 都满意而是没有任何子集能通过脱离当前联盟获得更高收益。交互形成方法则相反它不预设组织结构让 Agent 在交互中自然长出来。讲义点出了四种做法基于协商的合同网协议、基于依赖关系的社会推理Agent 找出与其目标有依赖关系的其他 Agent通过协商与其形成合作组织、基于价格调控的市场方法通过市场价格调节达到供求平衡、以及组织自设计Agent 组织可以根据情况排斥或合并 Agent。另外还有面向结构的方法它和人类社会组织的产生机制更接近先有组织结构再往里填角色。Agent 能承担某个角色需要能力匹配有利可图时Agent 会主动期望承担该角色当角色还没被承担时组织欢迎合适的 Agent 加入。方法组织结构来源代表机制适用前提联盟形成迭代博弈形成多人合作博弈、联盟值求解成员目标可量化、可比较交互形成动态涌现合同网、社会推理、市场价格无预设结构允许试错面向结构先有组织后填角色角色分配与调整领域角色清晰、职责稳定4.2 合同网协议一个可以照抄的协作流程合同网是交互形成方法里工程落地最成熟的一个。它的核心思想是模拟现实中的招标-投标-中标过程特别适合任务分配问题。流程可以拆成四步招标阶段任务发起方将任务描述广播给所有可用 Agent附上能力要求、期限、报酬等约束投标阶段收到招标信息的 Agent 根据自身状态决定是否投标投出的标书包含自身能力评估、预估代价和完成时间评标阶段发起方按评估函数比较所有投标选出最优者发中标通知最后是签约与执行中标 Agent 接受通知后建立合同进入任务执行未中标的收到落标消息。可以写一个非常简易的评标逻辑来感受合同网的节奏def contract_net_tender(task: dict, agents: dict, bid_fn) - str: 简化版合同网广播任务 - 收取标书 - 评标 - 返回中标者 task: {id: t1, difficulty: 7, deadline: 10} agents: {agent_a: {capability: 8, cost: 5}, ...} bid_fn: 由 agent 自评能否承接返回报价或 None bids {} for name, profile in agents.items(): offer bid_fn(name, profile, task) # 每个 Agent 独立决策 if offer is not None: bids[name] offer # 决定投标才进入评标 if not bids: return None # 无人投标任务需要再分解或放宽条件 winner min(bids, keylambda a: bids[a]) # 评标策略最小成本优先 return winnerbid_fn是每个 Agent 自评估的接口封装了“我能不能干、值不值得干”的判断bids用字典收集报价min(bids, key...)就是最简单的评标函数。实际系统中评标策略要复杂得多必须把时间、质量、成本、信任度一起带进效用函数但流程骨架就是这个。任务无人投标时不要硬派退回重新分解任务或放宽截止期才是合同网的正确用法。提示合同网在任务粒度上要控制好——任务拆得越细招标次数越多通信开销按指数抬升任务太粗又会出现单个 Agent 能力覆盖不了的情况。一般以“单个 Agent 在单个周期内能完成”为粒度下限。4.3 协商机制与通信协议给 Agent 一套说话的方式任务分配不总是顺利的Agent 之间利益冲突、资源竞争、目标不一致时就要协商。讲义把协商分成两个流派基于对策论的协商以 Zotkin 和 Rosenschein 的工作为代表把协商建模成博弈理论上漂亮但没考虑人类社会协商中的劝说特点计算量大、效率较低基于劝说的协商由 Parsons 和 Jennings 最早提出核心是“提出建议时必须附上原因让对方看到你的推理过程”对方在更完全的信息基础上做出更好的反应从而加快协商进程。协商的前提是双方说话互相能听懂这就需要协商协议。协议的内容包括 Agent 通信语言ACL的定义、表示、处理和语义解释。ACL 的表示方法有三种BNF 表示、有限状态自动机表示和纯语义表示。讲义认为 BNF 简洁明了、研究者熟悉因此成为最广为使用的表示方法这个判断在实际工程里也成立——一张典型的 FIPA 风格 ACL 消息用 BNF 描述大概是这个样子message :: performative :sender( agent-id ) :receiver( agent-id ) :content( expression ) performative :: request | inform | propose | accept-proposal | reject-proposal agent-id :: letter { letter | digit } expression:: symbol { symbol }performative 只有五个常用值却已经覆盖“请求动作、通知事实、提出建议、接受/拒绝建议”这些协商基本动作。BNF 定义完语法之后语义解释要单独写文档这也是多 Agent 系统最容易出 bug 的地方——两个 Agent 对同一个词有不同解释画布上写的是“continue”A 理解成继续执行B 理解成继续等待如果没有语义对齐系统就悄悄分裂了。5. 验证把固定分配与合同网放到同一批任务下对比讲义里讲了大量机制但只有把 DPS 的固定分配和 MAS 的合同网放到同一批动态任务上对比才能直观理解“协作是否可预知”意味着什么。我一般会写一个很小的模拟器生成 10 个任务每个任务带难度值和到达时间然后跑两种模式。基线模式fixed模拟 DPS任务按编号均分给 4 个 workerworker 只能处理分配到位的任务不做任何协商。合同网模式contract_net模拟 MAS任务到达后广播Agent 根据自身当前负载决定是否投标标价综合考虑技能匹配度和剩余容量中标者执行。命令行入口大致是python mas_demo.py --mode fixed --tasks 10 --agents 4 python mas_demo.py --mode contract_net --tasks 10 --agents 4对比时重点看三个指标任务完成率、平均周转时间、以及加入故障后的完成数。关键是要在实验里加一个--fail_rate参数让某个 Agent 在工作途中直接宕机。在 fixed 模式下宕机 worker 手里的任务会直接丢失因为 DPS 的分配是预知且不可协商的而 contract_net 模式下其他 Agent 会通过重新招标接管失败任务这就是讲义里“Agent 生命周期不全为其他 Agent 所知”的直观证据。实际操作时把fail_rate从 0 调到 0.5分别记录两种模式的完成率差值差值越大的场景越应该用 MAS 而不是 DPS。还有一个值得做的实验把合同网的评标函数从“最小成本优先”改成“成本加信任度的加权评分”观察恶意 Agent总是低价中标但经常失败进入系统后两种评标策略的完成率曲线。这个实验能顺手验证讲义里“Agent 间可能对抗”的论断也会让你明白为什么工业级多 Agent 系统里信任度和声誉机制跟协商协议本身一样重要。本文还有配套的精品资源点击获取 从分布式人工智能到多Agent协作：DAI三分支与Agent架构全解析
简介分布式人工智能与智能体是人工智能的重要方向这份PPT直击大型智能问题的并行性、分布性与开放性系统梳理了分布式人工智能的三大分支分布式问题求解强调大粒度协作群体将待求解问题分解为子问题并综合部分解多智能体系统关注自治个体的协作、对抗与开放生命周期并行人工智能聚焦基于符号主义与联结主义的并行计算体系。同时详细阐述了智能体的强弱定义、思考型、反应型与混合型的分类特点以及多智能体系统的组织形成、协商与任务分配机制。资源包仅含1个pptx文件共295KB内容结构完整、逻辑清晰适合高校学生、科研人员及人工智能从业者作为课程教学、自学入门或技术汇报的参考。目前已有112人学习可帮助快速搭建分布式智能与多智能体系统的知识框架深入理解智能体的心智状态与理性行为建模。1. 从 DAI 到 AI Agent为什么 2025 年还要回来翻这份课件从 1980 年 MIT 那场 DAI 国际会议算起分布式人工智能已经走了四十多年但直到今天几乎所有认真做 Agent 开发的人最后都要回来补这节课。原因很简单单机单模型的智能已经打到天花板多 Agent 协作、多机调度、联邦式推理这些真实场景面对的正是 DAI 当年概括出的三个问题——并行性、分布性、开放性。这份讲义的含金量在于它没有停留在概念罗列而是把 DAI 从 DPS、PAI 到 MAS 的演进脉络以及 Agent 从 BDI 到反应式再到分层混合的建构路径完整串了一遍。对想转 AI Agent 开发的工程师或正在设计多智能体系统的架构师来说这份材料可以直接当入门骨架照着它的框架去补框架选型和协议设计基本不会跑偏。2. DAI 的三个分支DPS、PAI 与 MAS 的边界和分工DAI 一词在 1980 年 MIT 的 “The Workshop on Distributed Artificial Intelligence” 上被正式推到台前Avouris N.M 后来从个体的自治性和粒度出发把 DAI 的研究切成了三块分布式问题求解DPS、多 Agent 系统MAS和并行人工智能PAI。这三者的分界线经常被搞混尤其是 DPS 和 MAS——二者表面都在做“多个计算体协作求解”但在协作是否可预知、控制是否集中这两点上存在着本质区别。2.1 DPS自顶向下“分解—求解—综合”的老牌方案DPS 的研究目标很朴素创建一个粒度较大的协作群体把待求解问题拆成互不重叠的子问题分配给群体里的个体去算每个个体输出局部解最后按事先定好的规则把局部解综合成全局解。关键约束在于这种协作是可预知的个体之间不需要协商本质是一种“命令/服从式”的调度关系环境条件已知算法专用整体设计自顶向下展开。用一个典型的并行分治示意就能看清 DPS 的骨架import concurrent.futures def solve_subtask(sub_id: int, data: list) - float: # 子问题局部求解每个 worker 独立处理一段数据 return sum(x * sub_id for x in data) / (len(data) 1) def dps_orchestrator(tasks: list[list], workers: int 4) - list[float]: # 求解器的角色负责任务分解与结果综合 with concurrent.futures.ThreadPoolExecutor(max_workersworkers) as pool: futures [ pool.submit(solve_subtask, i, task) for i, task in enumerate(tasks) # 分解按索引指派子任务 ] partial [f.result() for f in futures] # 收集部分解 # 综合所有子解按固定策略合并为全局解 return partial if __name__ __main__: tasks [[1, 2, 3], [4, 5, 6], [7, 8, 9], [10, 11, 12]] print(dps_orchestrator(tasks, workers4))solve_subtask对应 DPS 中的部分求解器dps_orchestrator用线程池做任务分发模式是“分解 → 并行求解 → 综合”个体间没有协商环节也没有动态的角色调整。workers参数决定并行度但 DPS 的并行度通常在设计期就定死这也是它和 MAS 拉开差距的地方——DPS 的“智能”在编排者手里不在个体手里。这个模式的强项是算法确定、结果可复现适合场景固定的批量任务弱项是对环境变化没有弹性一旦运行期子问题边界发生变化整套分配方案就要重做。传统 DAI 里的多专家系统、分布式专家系统、群体决策支持系统走的基本都是这条路线。2.2 PAI细粒度并行与符号主义-联结主义的交汇PAI 这里容易被当成“并行加速”的工程问题但它其实是一个体系结构问题。讲义里的定义说得很清楚系统由多个紧密耦合的问题求解器组成每个求解器是一个细粒度的知识体研究观点与方法结合了符号主义和联结主义神经元计算机也被划入这个范畴。和 DPS 相比PAI 的耦合更紧密不是任务级分解而是把知识本身分布到多个处理器上让推理过程并行发生。这类结构对应的是传统 AI 的一个长期痛点符号推理的状态空间搜索是串行瓶颈专家系统的知识库越大单机推理延迟越长。PAI 的思路是让多个小求解器同时推进各自的知识匹配再通过共享内存或高速互联同步中间结果。神经元计算机与 PAI 的关系可以理解为联结主义路线的硬件化把大量细粒度知识体做成神经元形态用并行脉冲计算替代符号匹配。我一般会建议把 PAI 当作理解“从符号 AI 到计算智能”过渡的关键节点它和现在大模型的张量并行训练不是一回事但在“细粒度、紧耦合、并行求解”这三个特征上二者的结构逻辑一脉相承。2.3 MAS自治个体与无全局控制的协作模型如果说 DPS 是“总指挥加执行者”MAS 就是“一群没有统一领导的自组织个体”。MAS 里的每个 Agent 是自主的生命周期不全被其他 Agent 掌握它们可以有共同目标也可以各怀目的之间可能协作也可能对抗。协作形式更是直接落到真实社会规则上——命令/服从式、投票式、磋商式全部都能出现需要系统去协调这些自治行为。讲义特别强调了一个组合约束Agent 在空间上分布、时间上并行、逻辑上依赖三者叠加让 MAS 的求解过程比 DPS 复杂得多。三个分支的边界其实并不严格互有交叉所以实践中判断一个系统落在哪条线上我常用三个问题来测个体能不能拒绝任务拒绝之后系统怎么处理有没有全局事实源能拒绝、有冲突、无全局控制就往 MAS 上靠。三个分支的横向对比可以看这张表维度DPSPAIMAS个体粒度大粒度任务单元细粒度知识体自治 Agent耦合方式松散任务级紧密耦合依赖关系动态变化控制方式集中/命令式结构化并行无全局控制协作是否预知预知不协商结构固定动态协商/竞争典型场景分布式专家系统神经元计算机、并行推理多智能体协作系统3. 从 BDI 到反应式再到分层混合Agent 的三条构建路径Agent 的定义是出了名的难。Hewitt 说定义 Agent 和定义智能一样困难而讲义给出的线索其实已经够用弱定义强调自治性、社会性、感知环境并作出反应强定义在弱定义之上再加入信念、愿望、意图这类心智状态。定义之争并不是书斋问题而是直接决定你用什么架构去写代码——只有感知-反应需求就上反应式需要目标推理就上 BDI既要快又要稳就上混合架构。3.1 思考型 Agent 与 BDI 模型的实现骨架思考型 Agent 本质是一个符号 AI 系统。它把 Agent 当作一个有意识态度的智能代理用信念Belief、愿望Desire、意图Intention三个模态算子刻画推理过程这是 Rao 和 Georgeff 对 BDI 模型的核心贡献。在这套框架里信念对应 Agent 对当前环境与世界状态的判断愿望是它想达到的目标集合意图则是经过承诺之后真正准备执行的行动方案。BDI 循环的代码骨架可以写得非常简洁class SimpleBDIAgent: def __init__(self, beliefs: dict, desires: list[dict]): self.beliefs beliefs # 信念对环境的判断形如 {cpu_load: high} self.desires desires # 愿望候选目标含前提条件与计划 self.intentions [] # 意图承诺执行的计划 def perceive(self, env): # 感知环境并用新观测更新信念 self.beliefs.update(env) def deliberate(self): # 从愿望中筛选出信念可支持的计划写入意图 for desire in self.desires: if self._holds(desire[precondition]): self.intentions.append(desire[plan]) def _holds(self, conditions: dict) - bool: # 检查前置条件是否全部满足 return all(self.beliefs.get(k) v for k, v in conditions.items())perceive负责信念更新deliberate完成从愿望到意图的筛选_holds是前置条件的统一校验入口。这三个方法分别对应 BDI 中的信念修正、选项生成和意图形成。真实的 BDI 框架比如 Jason、Jadex在循环里还会加入意图的挂起、恢复与放弃策略但核心永远是这个感知—思考—行动的闭环。这里要注意beliefs的写入不能无脑覆盖感知数据必须先做可信度评估否则一次误判会让整个意图链崩塌。讲义里提到的理性平衡简单说就是不要让 Agent 不断切换意图、导致什么事都收不了尾这也是引入“承诺”的原因。3.2 反应型 Agent没有知识只有映射思考型 Agent 的复杂度劝退了不少人行为主义心理学的回应更激进Agent 根本不需要知识。反应型 Agent 不做符号表示和推理它的全部行为就是感知环境变化然后触发对应动作。讲义说得非常直白——反应型 Agent 对环境变化有很高的响应速度但智能程度低、缺乏灵活性。反应型的实现本质是一组条件-动作规则或者更工程化一点是一张状态到动作的映射表。比如一个避障 Agent传感器读到前方距离小于阈值就直接输出“转向”中间没有任何推理环节。它的缺陷在于没有长期目标也没有对未来的预期规则覆盖不到的场景直接就失效。所以现实中很少看到纯反应式系统更多是把它用在低层控制里把“快”交给规则把“聪明”交给上层。3.3 混合型 Agent反应层保底线认知层做决策混合型 Agent 是当前研究的主流也是工程上最常用的折中。讲义里的结构描述很关键底层是反应层不做符号表示和推理可快速响应并处理外部环境的突发变化通常具有较高优先级高层采用传统 AI 方法进行规划、推理和决策。两层配合的典型场景是机器人导航——反应层处理突发障碍物避让认知层规划全局路径遇到计划外障碍时反应层先动作再让认知层重新规划。能力维度思考型反应型混合型响应速度慢快反应层快认知层慢是否需要知识库是符号化否上层需要环境变化适应依赖重新推理依赖规则覆盖双层协同工程复杂度高低最高适用场景规划、博弈、决策实时控制、应急响应机器人、多 Agent 系统设计混合型 Agent 时一个容易被忽略的技术点是优先级仲裁。反应层的高优先级不能简单地理解为“反应层先跑”而是要明确当反应层动作与认知层计划冲突时以反应层指令为准同时通知认知层撤销或修正当前意图。否则两层各跑各的在真实系统里就会表现出抖动和目标丢失。4. 多 Agent 协作的关键机制组织形成与协商协议MAS 的前提是“没有全局控制”那协作怎么发生答案是通过组织形成和协商这两个机制。组织形成解决“谁和谁一起干活、各自承担什么角色”的问题协商解决“在干活过程中想法和利益冲突时怎么办”的问题。讲义把组织形成归纳成三条路线联盟形成、交互形成和面向结构的方法而协商则从对策论走向了基于劝说的新范式。4.1 组织形成的三条路线联盟形成方法源于对策论中的多人合作博弈代表工作是 Sheory 等人的研究。它的执行路径非常标准第一步形成联盟结构第二步求解联盟值第三步把联盟值在成员之间分配。三步反复迭代直到得到稳定解才停。注意这里的“稳定”不是说所有 Agent 都满意而是没有任何子集能通过脱离当前联盟获得更高收益。交互形成方法则相反它不预设组织结构让 Agent 在交互中自然长出来。讲义点出了四种做法基于协商的合同网协议、基于依赖关系的社会推理Agent 找出与其目标有依赖关系的其他 Agent通过协商与其形成合作组织、基于价格调控的市场方法通过市场价格调节达到供求平衡、以及组织自设计Agent 组织可以根据情况排斥或合并 Agent。另外还有面向结构的方法它和人类社会组织的产生机制更接近先有组织结构再往里填角色。Agent 能承担某个角色需要能力匹配有利可图时Agent 会主动期望承担该角色当角色还没被承担时组织欢迎合适的 Agent 加入。方法组织结构来源代表机制适用前提联盟形成迭代博弈形成多人合作博弈、联盟值求解成员目标可量化、可比较交互形成动态涌现合同网、社会推理、市场价格无预设结构允许试错面向结构先有组织后填角色角色分配与调整领域角色清晰、职责稳定4.2 合同网协议一个可以照抄的协作流程合同网是交互形成方法里工程落地最成熟的一个。它的核心思想是模拟现实中的招标-投标-中标过程特别适合任务分配问题。流程可以拆成四步招标阶段任务发起方将任务描述广播给所有可用 Agent附上能力要求、期限、报酬等约束投标阶段收到招标信息的 Agent 根据自身状态决定是否投标投出的标书包含自身能力评估、预估代价和完成时间评标阶段发起方按评估函数比较所有投标选出最优者发中标通知最后是签约与执行中标 Agent 接受通知后建立合同进入任务执行未中标的收到落标消息。可以写一个非常简易的评标逻辑来感受合同网的节奏def contract_net_tender(task: dict, agents: dict, bid_fn) - str: 简化版合同网广播任务 - 收取标书 - 评标 - 返回中标者 task: {id: t1, difficulty: 7, deadline: 10} agents: {agent_a: {capability: 8, cost: 5}, ...} bid_fn: 由 agent 自评能否承接返回报价或 None bids {} for name, profile in agents.items(): offer bid_fn(name, profile, task) # 每个 Agent 独立决策 if offer is not None: bids[name] offer # 决定投标才进入评标 if not bids: return None # 无人投标任务需要再分解或放宽条件 winner min(bids, keylambda a: bids[a]) # 评标策略最小成本优先 return winnerbid_fn是每个 Agent 自评估的接口封装了“我能不能干、值不值得干”的判断bids用字典收集报价min(bids, key...)就是最简单的评标函数。实际系统中评标策略要复杂得多必须把时间、质量、成本、信任度一起带进效用函数但流程骨架就是这个。任务无人投标时不要硬派退回重新分解任务或放宽截止期才是合同网的正确用法。提示合同网在任务粒度上要控制好——任务拆得越细招标次数越多通信开销按指数抬升任务太粗又会出现单个 Agent 能力覆盖不了的情况。一般以“单个 Agent 在单个周期内能完成”为粒度下限。4.3 协商机制与通信协议给 Agent 一套说话的方式任务分配不总是顺利的Agent 之间利益冲突、资源竞争、目标不一致时就要协商。讲义把协商分成两个流派基于对策论的协商以 Zotkin 和 Rosenschein 的工作为代表把协商建模成博弈理论上漂亮但没考虑人类社会协商中的劝说特点计算量大、效率较低基于劝说的协商由 Parsons 和 Jennings 最早提出核心是“提出建议时必须附上原因让对方看到你的推理过程”对方在更完全的信息基础上做出更好的反应从而加快协商进程。协商的前提是双方说话互相能听懂这就需要协商协议。协议的内容包括 Agent 通信语言ACL的定义、表示、处理和语义解释。ACL 的表示方法有三种BNF 表示、有限状态自动机表示和纯语义表示。讲义认为 BNF 简洁明了、研究者熟悉因此成为最广为使用的表示方法这个判断在实际工程里也成立——一张典型的 FIPA 风格 ACL 消息用 BNF 描述大概是这个样子message :: performative :sender( agent-id ) :receiver( agent-id ) :content( expression ) performative :: request | inform | propose | accept-proposal | reject-proposal agent-id :: letter { letter | digit } expression:: symbol { symbol }performative 只有五个常用值却已经覆盖“请求动作、通知事实、提出建议、接受/拒绝建议”这些协商基本动作。BNF 定义完语法之后语义解释要单独写文档这也是多 Agent 系统最容易出 bug 的地方——两个 Agent 对同一个词有不同解释画布上写的是“continue”A 理解成继续执行B 理解成继续等待如果没有语义对齐系统就悄悄分裂了。5. 验证把固定分配与合同网放到同一批任务下对比讲义里讲了大量机制但只有把 DPS 的固定分配和 MAS 的合同网放到同一批动态任务上对比才能直观理解“协作是否可预知”意味着什么。我一般会写一个很小的模拟器生成 10 个任务每个任务带难度值和到达时间然后跑两种模式。基线模式fixed模拟 DPS任务按编号均分给 4 个 workerworker 只能处理分配到位的任务不做任何协商。合同网模式contract_net模拟 MAS任务到达后广播Agent 根据自身当前负载决定是否投标标价综合考虑技能匹配度和剩余容量中标者执行。命令行入口大致是python mas_demo.py --mode fixed --tasks 10 --agents 4 python mas_demo.py --mode contract_net --tasks 10 --agents 4对比时重点看三个指标任务完成率、平均周转时间、以及加入故障后的完成数。关键是要在实验里加一个--fail_rate参数让某个 Agent 在工作途中直接宕机。在 fixed 模式下宕机 worker 手里的任务会直接丢失因为 DPS 的分配是预知且不可协商的而 contract_net 模式下其他 Agent 会通过重新招标接管失败任务这就是讲义里“Agent 生命周期不全为其他 Agent 所知”的直观证据。实际操作时把fail_rate从 0 调到 0.5分别记录两种模式的完成率差值差值越大的场景越应该用 MAS 而不是 DPS。还有一个值得做的实验把合同网的评标函数从“最小成本优先”改成“成本加信任度的加权评分”观察恶意 Agent总是低价中标但经常失败进入系统后两种评标策略的完成率曲线。这个实验能顺手验证讲义里“Agent 间可能对抗”的论断也会让你明白为什么工业级多 Agent 系统里信任度和声誉机制跟协商协议本身一样重要。本文还有配套的精品资源点击获取