Multi-Agent系统权限管理细粒度控制智能体的操作范围二、 摘要/引言2.1 引人入胜的Hook场景当AI协作失控时的代价想象一个企业级Agent协作平台部署在金融科技公司内部的场景平台里有12个分工明确的智能体——包括负责用户历史数据分析的「洞察Agent」、负责生成基金产品推荐话术的「文案Agent」、负责从CRM系统中提取客户隐私信息手机号、风险等级、资产规模的「CRM接口Agent」、负责在邮件营销系统中一键触发批量发送的「营销触发Agent」、以及由这四个基础Agent组成的「财富管理营销Pipeline Agent组」。某个周三的深夜Pipeline组里的洞察Agent被一个恶意第三方通过弱口令入侵该Agent原本只被分配了“访问脱敏数据湖API只读权限”但营销触发Agent的权限配置写反了“可触发者”的角色所有基础Agent都能调用它。入侵者用洞察Agent冒充系统巡检员让CRM接口Agent临时暴露了真实数据接口的访问密钥随后通过营销触发Agent向平台上所有20万中高风险偏好客户发送了伪造的「监管要求紧急赎回资金」诈骗邮件。短短48小时内该公司收到了372起客户投诉监管机构启动了专项调查市值蒸发了12%团队里负责Agent运维和权限配置的3名工程师被停职——这一切仅仅是因为Multi-Agent系统的权限管理做得太粗粒度甚至存在低级的配置失误。再看另一个更贴近开源社区的场景你搭建了一个基于LangGraph的「论文阅读代码复现实验报告生成」的个人Multi-Agent系统系统里有负责从arxiv.org爬取论文PDF的「爬虫Agent」、负责解析PDF并提取关键代码框架的「解析Agent」、负责在本地Python环境中安装依赖包并运行代码的「执行Agent」、负责把运行结果整理成Markdown报告的「报告Agent」。某天你在测试一篇开源自动驾驶论文的代码时没注意到「执行Agent」被默认分配了本地系统的root权限——解析Agent从论文PDF附录里提取的恶意Shell脚本伪装成依赖安装命令pip install -r requirements.txt rm -rf ~/Documents/*被执行Agent直接运行你3年来积累的所有学术论文、实验数据、个人笔记全部永久丢失没有任何备份。2.2 问题陈述Multi-Agent系统面临的三类核心权限挑战上面两个场景绝非危言耸听——根据Gartner 2025年前瞻预测报告的数据到2026年全球75%以上的企业级AI应用都会采用Multi-Agent架构而其中90%的安全事件将直接或间接由Agent权限管理缺陷导致平均每次事件的损失将超过200万美元。为什么Multi-Agent系统的权限管理会这么难因为它和传统的「用户-角色-资源」User-Role-ResourceURR模型的单用户/角色应用权限管理、甚至和普通的API网关权限管理仅控制外部调用方对系统API的访问完全不同——Multi-Agent系统的权限管理需要同时应对三类全新的核心挑战2.2.1 第一类挑战主体多样化且交互复杂传统应用的权限主体是「人」或「单个静态程序」交互链通常是人→角色→单资源/API链交互是单向的、可控的而Multi-Agent系统的权限主体是多个动态智能体交互链可能是Agent1→Agent2→Agent3→外部API/本地资源→Agent4→用户甚至是Agent1↔Agent2↔Agent3↔…↔AgentN这种闭环交互——主体之间不仅会单向调用还会双向协作、委托任务、共享数据、传递令牌每一步交互都可能引入新的权限风险。2.2.2 第二类挑战权限需求动态化传统应用的权限需求是静态的、预先定义的——一个员工入职成为理财顾问系统管理员预先给他分配“查看客户基础信息、生成普通推荐邮件、不能修改产品参数”的权限除非他离职或升职否则权限不会变化而Multi-Agent系统的权限需求是动态的、上下文敏感的——比如同样是「CRM接口Agent」当Pipeline组处于“正常工作日上班时间9:00-18:00、执行的是经过审核的「每日固定理财周报生成」任务时CRM接口Agent只能访问CRM系统中客户的「脱敏基础信息」和「上周交易记录不含金额的脱敏数据」当Pipeline组处于“正常工作日上班时间、执行的是经过高级理财经理审批的「个性化定制基金方案」任务时CRM接口Agent可以访问客户的「完整手机号仅前3后4、完整风险等级、最近3个月的交易金额区间显示」当Pipeline组处于“非正常工作日、执行的是临时的「监管紧急数据统计」任务时CRM接口Agent必须同时持有高级数据分析师的审批令牌、监管机构的临时访问密钥才能访问客户的「完整手机号、完整资产规模仅统计用生成报表后立即删除、最近1年的完整交易记录仅统计用生成报表后立即删除」当Pipeline组处于“非正常工作日、执行的是未认证的任务时CRM接口Agent完全不能访问CRM系统。2.2.3 第三类挑战资源边界模糊化传统应用的资源边界是清晰的——要么是系统内部的数据库表、文件系统目录要么是外部的第三方API接口资源的所有者、访问者、访问方式都是明确的而Multi-Agent系统的资源边界是模糊的——除了内部数据库、外部API之外还包括其他智能体的能力/API接口比如洞察Agent的“生成用户画像标签”能力就是文案Agent的“核心资源”智能体的上下文记忆/状态比如洞察Agent在分析过程中生成的“客户A属于激进型风险偏好、资产规模在1000万以上”的临时记忆就是CRM接口Agent、营销触发Agent都可能需要访问的“敏感资源”智能体的计算资源/存储资源比如执行Agent在本地Python环境中占用的CPU、内存、磁盘空间就是整个平台的“公共资源”——如果某个恶意Agent故意占用100%的CPU其他所有Agent都会无法正常工作。2.3 核心价值读完这篇文章你能学到什么既然Multi-Agent系统的权限管理这么重要又这么难那这篇文章能为你解决什么问题呢作为一位在AI安全领域深耕了8年、曾主导过3个大型金融科技公司Multi-Agent平台权限体系建设的资深软件工程师我会用通俗易懂、循序渐进、理论实践的方式带你从0到1搭建一套完整的、细粒度的、动态的、可扩展的Multi-Agent系统权限管理体系。具体来说读完这篇文章你将理解Multi-Agent系统权限管理的核心概念、边界与外延——搞清楚它和传统权限管理的本质区别不再把它当成“API网关权限的简单延伸”掌握Multi-Agent系统权限管理的核心数学模型与算法——学会用形式化的方法描述和验证权限规则用高效的算法处理动态的、上下文敏感的权限请求掌握Multi-Agent系统权限管理的核心架构设计与技术选型——了解主流的Multi-Agent权限框架比如LangChain的LangSmith Permissions、OpenAI的Assistants API的Thread-Level Permissions、微软的Semantic Kernel的Function Calling Filters、以及开源的AuthZ for Agents/AZ4A的优缺点学会根据自己的业务需求选择合适的技术栈从0到1实现一个基于LangGraph AZ4A OPAOpen Policy Agent的细粒度Multi-Agent权限管理系统——包括环境安装、系统功能设计、系统架构设计、系统接口设计、系统核心实现源代码还有完整的测试用例掌握Multi-Agent系统权限管理的最佳实践与常见陷阱——学会避免“权限配置过松/过紧”“闭环交互中的权限泄露”“上下文记忆中的敏感数据泄露”等常见问题了解Multi-Agent系统权限管理的行业发展历史与未来趋势——搞清楚权限模型从“RBAC”到“ABAC”再到“OBACIBACPBAC”的演变过程以及未来的发展方向比如“基于大语言模型的智能权限审计”“基于联邦学习的跨平台权限管理”“基于区块链的不可篡改权限记录”。2.4 文章概述这篇文章会讲哪些内容为了让你更好地理解和掌握Multi-Agent系统权限管理的知识我把这篇文章分成了9个核心章节每个章节都有明确的学习目标、核心概念、实践案例以及大于10000字的详细内容对你没看错——为了让你彻底搞懂每个知识点我会把每个细节都讲透不会有任何省略章节三Multi-Agent系统权限管理的核心概念、边界与外延这一章是整篇文章的基础我会从“什么是Multi-Agent系统”开始讲起逐步引入“Multi-Agent系统的权限”“细粒度权限控制”等核心概念然后通过大量的类比比如把Multi-Agent系统比作一个公司把智能体比作公司的员工把资源比作公司的资产把权限规则比作公司的规章制度让你彻底搞懂这些概念的含义最后明确Multi-Agent系统权限管理的边界哪些是我们需要管的哪些是我们不需要管的和外延权限管理和其他AI安全领域的关系比如Agent身份认证、Agent行为审计、Agent数据隐私保护。章节四Multi-Agent系统权限管理的核心概念结构与要素组成这一章我会深入剖析Multi-Agent系统权限管理的核心概念结构——包括“权限主体Subject”“权限客体Object”“权限动作Action”“权限规则Rule”“权限约束Constraint”“权限上下文Context”“权限令牌Token”“权限委托Delegation”“权限撤销Revocation”等9个核心要素然后用ER实体关系图Entity-Relationship Diagram展示这些要素之间的联系用交互关系图展示这些要素在权限请求-验证-执行-撤销整个流程中的作用最后用Markdown表格对比这些要素在传统权限管理和Multi-Agent系统权限管理中的核心属性比如主体的动态性、客体的多样性、约束的上下文敏感性等。章节五Multi-Agent系统权限管理的核心数学模型与算法这一章是整篇文章的理论核心我会从“传统权限管理的数学模型”开始讲起比如RBAC模型的形式化描述、ABAC模型的形式化描述然后逐步引入适合Multi-Agent系统的数学模型——包括“基于角色-上下文-属性的混合模型Role-Context-Attribute Based Access ControlRCABAC”“基于本体的权限模型Ontology-Based Access ControlOBAC”“基于意图的权限模型Intent-Based Access ControlIBAC”“基于隐私预算的权限模型Privacy-Budget Based Access ControlPBAC”然后用LaTeX公式详细描述这些模型的数学定义接着用Mermaid流程图展示这些模型对应的权限验证算法最后用Python源代码实现这些算法并对比它们的性能比如响应时间、内存占用、可扩展性等。章节六Multi-Agent系统权限管理的主流框架与技术选型这一章是整篇文章的技术选型指南我会详细介绍5个主流的Multi-Agent系统权限管理框架——包括LangChain的LangSmith Permissions、OpenAI的Assistants API的Thread-Level Permissions、微软的Semantic Kernel的Function Calling Filters、开源的AuthZ for Agents/AZ4A、以及开源的OPAOpen Policy Agent然后用Markdown表格对比这些框架的核心属性比如是否开源、是否支持细粒度控制、是否支持动态权限、是否支持权限委托、是否支持权限审计、是否支持跨平台部署、学习曲线、社区活跃度等最后根据不同的业务场景比如个人项目、小型企业项目、大型金融科技企业项目、跨企业协作项目给出明确的技术选型建议。章节七从0到1实现一个基于LangGraph AZ4A OPA的细粒度Multi-Agent权限管理系统这一章是整篇文章的实践核心我会带你从0到1搭建一个完整的、细粒度的、动态的、可扩展的Multi-Agent权限管理系统——这个系统的业务场景是我们在引言中提到的「财富管理营销Pipeline」我会按照软件工程的标准流程来实现环境安装包括Python环境的安装、LangGraph的安装、AZ4A的安装、OPA的安装、以及相关依赖包的安装系统功能设计包括身份认证功能、权限规则定义功能、权限请求验证功能、权限委托功能、权限撤销功能、权限审计功能系统架构设计包括前端架构可选简单的命令行界面即可、后端架构分为Agent层、权限代理层、权限验证层、权限存储层、审计层、数据存储架构关系型数据库存储Agent身份信息、权限规则信息、权限审计信息非关系型数据库存储Agent上下文记忆信息系统接口设计包括身份认证接口、权限规则CRUD接口、权限请求验证接口、权限委托接口、权限撤销接口、权限审计查询接口系统核心实现源代码包括LangGraph的Pipeline Agent组的实现、AZ4A的权限代理层的实现、OPA的权限验证层的实现、权限存储层的实现、审计层的实现系统测试用例包括正常场景的测试用例、异常场景的测试用例、动态场景的测试用例、权限委托场景的测试用例、权限撤销场景的测试用例。章节八Multi-Agent系统权限管理的最佳实践与常见陷阱这一章是整篇文章的经验总结我会分享我在8年的AI安全领域工作中积累的20条Multi-Agent系统权限管理的最佳实践比如“遵循最小权限原则Principle of Least PrivilegePoLP”“遵循职责分离原则Principle of Separation of DutiesSoD”“遵循默认拒绝原则Principle of Deny by Default”“为每个Agent分配唯一的身份标识”“为每个权限请求生成唯一的审计日志”“定期审计权限规则和Agent的权限使用情况”“限制Agent的上下文记忆的大小和存储时间”“限制Agent的计算资源和存储资源的使用”“避免在Agent之间传递敏感数据的明文”“使用加密的权限令牌”等然后分享我见过的10个最常见的Multi-Agent系统权限管理陷阱比如“权限配置过松给Agent分配了root权限”“权限配置过紧导致Agent无法正常完成任务”“闭环交互中的权限泄露比如Agent1把自己的权限令牌传递给Agent2Agent2又传递给Agent3最后Agent3用Agent1的权限访问了敏感资源”“上下文记忆中的敏感数据泄露比如Agent1在分析过程中生成的敏感临时记忆没有被及时删除”“弱口令入侵比如没有为Agent的身份认证设置强密码”“权限委托没有设置约束比如Agent1可以把自己的所有权限永久委托给任何Agent”“权限撤销不及时比如某个Agent被入侵后没有立即撤销它的所有权限”“没有权限审计功能无法追溯权限事件的发生过程”“没有权限验证的熔断机制比如某个Agent的权限请求失败次数过多没有禁止它继续发起请求”“跨平台协作中的权限管理缺失比如没有为跨企业的Agent协作设置统一的权限规则”等每个最佳实践和陷阱都会配具体的例子和解决方案。章节九Multi-Agent系统权限管理的行业发展历史与未来趋势这一章是整篇文章的展望部分我会用Markdown表格展示Multi-Agent系统权限管理的发展历史——从1960年代的“传统单用户权限管理”DACDiscretionary Access Control到1990年代的“基于角色的权限管理”RBAC到2000年代的“基于属性的权限管理”ABAC到2010年代的“API网关权限管理”到2020年代的“单Agent权限管理”再到2023年以后的“细粒度Multi-Agent权限管理”每个阶段都会有明确的时间节点、核心技术、代表公司/项目、解决的核心问题然后我会详细介绍Multi-Agent系统权限管理的5个未来发展趋势比如“基于大语言模型的智能权限审计和规则生成”——大语言模型可以自动分析Agent的行为日志发现潜在的权限风险自动生成合适的权限规则“基于联邦学习的跨平台权限管理”——多个企业可以在不共享敏感数据的情况下共同训练一个统一的权限验证模型“基于区块链的不可篡改权限记录和委托管理”——所有的权限事件比如身份认证、权限请求、权限委托、权限撤销都会被记录在区块链上无法篡改和删除“基于隐私计算的细粒度数据访问控制”——比如用差分隐私Differential Privacy技术限制Agent访问敏感数据的次数和精度用同态加密Homomorphic Encryption技术让Agent在加密数据上进行计算无需解密“基于意图的全自动权限管理”——用户只需要用自然语言告诉系统“我想让Agent组完成一个个性化定制基金方案的任务”系统就会自动分析任务的意图自动为每个Agent分配合适的、动态的权限无需人工配置每个趋势都会有明确的技术原理、代表公司/项目、应用场景、面临的挑战。章节三Multi-Agent系统权限管理的核心概念、边界与外延3.1 学习目标在开始学习这一章之前我希望你能先明确自己的学习目标——通过这一章的学习你将彻底搞懂什么是Multi-Agent系统——包括它的定义、分类、核心特征彻底搞懂什么是Multi-Agent系统的权限——包括它的定义、本质、作用彻底搞懂什么是细粒度权限控制——包括它的定义、和粗粒度权限控制的区别、为什么Multi-Agent系统需要细粒度权限控制明确Multi-Agent系统权限管理的边界——搞清楚哪些是我们需要管的哪些是我们不需要管的明确Multi-Agent系统权限管理的外延——搞清楚权限管理和其他AI安全领域的关系比如Agent身份认证、Agent行为审计、Agent数据隐私保护、Agent行为监控。3.2 什么是Multi-Agent系统在讲解Multi-Agent系统的权限管理之前我们必须先搞懂什么是Multi-Agent系统——因为只有搞懂了主体我们才能搞懂主体的权限。3.2.1 Multi-Agent系统的定义Multi-Agent系统Multi-Agent SystemMAS是人工智能AI和分布式系统Distributed System的交叉领域它的定义有很多种其中最权威、最被广泛接受的是美国斯坦福大学计算机科学系的Michael Wooldridge教授和Nicholas R. Jennings教授在1995年发表的论文《Intelligent Agents: Theory and Practice》中给出的定义Multi-Agent系统MAS是由多个自主的、交互的智能体Agent组成的系统这些智能体在一个共同的环境中工作通过协作、竞争或协商的方式完成单个智能体无法完成的复杂任务。为了让你更好地理解这个定义我会把它拆解成5个核心关键词并用大量的类比来解释每个关键词的含义3.2.1.1 核心关键词1智能体Agent什么是智能体Michael Wooldridge教授和Nicholas R. Jennings教授在同一篇论文中也给出了定义智能体Agent是一个位于某个环境中的计算机系统它能够自主地感知环境、做出决策、采取行动以实现其预设的目标。同样我会把这个定义拆解成4个核心特征并用类比把智能体比作公司的员工来解释3.2.1.1.1 核心特征1自主性Autonomy自主性是智能体的最核心特征——它意味着智能体不需要外部的直接干预比如不需要用户的每一步操作、不需要系统管理员的每一步指令就能自主地感知环境、做出决策、采取行动。用公司员工的类比来说自主性就像公司的员工不需要老板的每一步指令就能自主地完成自己的工作——比如一个理财顾问他不需要老板告诉他“今天9:00到10:00要查看客户的上周交易记录10:00到11:00要生成理财周报11:00到12:00要给客户发送邮件”他只需要老板告诉他“每周三中午12:00之前要给所有中高风险偏好客户发送上周的理财周报”他就能自主地安排自己的时间完成这个任务。而传统的计算机程序比如一个单线程的计算器、一个单功能的文件压缩工具是没有自主性的——它需要用户的每一步操作才能工作比如你打开计算器输入“11”按下“”它才会输出“2”你不操作它就不会做任何事情。3.2.1.1.2 核心特征2感知能力Sensory Capability感知能力意味着智能体能够通过某种方式比如传感器、API接口、文本输入感知其所处的环境——获取环境的状态信息、其他智能体的状态信息、用户的输入信息等。用公司员工的类比来说感知能力就像公司的员工能够通过眼睛、耳朵、嘴巴等感官感知公司的环境——比如一个理财顾问他能够通过CRM系统的API接口感知客户的状态信息能够通过邮件感知客户的反馈信息能够通过会议室的投影感知老板的指令信息。而传统的计算机程序的感知能力是非常有限的——它只能通过特定的输入方式比如键盘、鼠标、文件感知特定的信息比如一个单线程的计算器只能感知你输入的数字和运算符不能感知其他任何信息。3.2.1.1.3 核心特征3决策能力Decision-Making Capability决策能力意味着智能体能够根据其感知到的环境信息、预设的目标、以及内部的状态比如上下文记忆做出合理的决策——选择下一步要采取的行动。用公司员工的类比来说决策能力就像公司的员工能够根据自己的经验、老板的指令、客户的需求做出合理的决策——比如一个理财顾问他感知到客户A的上周交易记录显示客户A频繁买卖高风险股票预设的目标是“为客户A提供合适的基金产品推荐”内部的记忆是“客户A属于激进型风险偏好、资产规模在1000万以上”他就会做出“推荐2-3只高风险高收益的股票型基金”的决策。而传统的计算机程序的决策能力是完全预设的——它只能根据程序员预先写好的if-else语句或switch-case语句做出决策不能根据环境的变化或内部的状态做出灵活的决策比如一个单线程的计算器只能根据你输入的运算符执行对应的运算不能做任何其他的决策。3.2.1.1.4 核心特征4行动能力Actuation Capability行动能力意味着智能体能够通过某种方式比如执行器、API接口、文本输出对其所处的环境产生影响——改变环境的状态、改变其他智能体的状态、向用户输出信息等。用公司员工的类比来说行动能力就像公司的员工能够通过手、嘴巴、电脑等工具对公司的环境产生影响——比如一个理财顾问他能够通过CRM系统的API接口修改客户的标签信息能够通过邮件向客户发送基金产品推荐信息能够通过会议室的发言改变其他同事的想法。而传统的计算机程序的行动能力是非常有限的——它只能通过特定的输出方式比如屏幕、打印机、文件输出特定的信息不能对环境产生太大的影响比如一个单线程的计算器只能在屏幕上输出运算结果不能做任何其他的事情。3.2.1.2 核心关键词2多个Multiple“多个”意味着Multi-Agent系统中必须有至少2个智能体——如果只有1个智能体那就是单Agent系统不是Multi-Agent系统。用公司员工的类比来说多个就像公司里必须有至少2个员工——如果只有1个员工那就是个体户不是公司。3.2.1.3 核心关键词3共同的环境Shared Environment“共同的环境”意味着Multi-Agent系统中的所有智能体都位于同一个环境中——这个环境可以是物理环境比如一个机器人足球场上的所有机器人都位于同一个足球场也可以是虚拟环境比如一个财富管理营销Pipeline中的所有智能体都位于同一个虚拟的“公司内部网络环境”。用公司员工的类比来说共同的环境就像公司里的所有员工都位于同一个办公楼里——虽然他们可能在不同的办公室但都属于同一个公司的办公楼环境。3.2.1.4 核心关键词4交互的Interacting“交互的”意味着Multi-Agent系统中的智能体之间不是孤立的——它们会通过某种方式比如消息传递、共享内存、API调用进行交互交互的方式包括协作Cooperation、竞争Competition、协商Negotiation三种3.2.1.4.1 交互方式1协作Cooperation协作意味着智能体之间为了完成一个共同的目标而一起工作——它们会互相帮助、互相配合、共享信息。用公司员工的类比来说协作就像公司里的理财顾问、文案编辑、营销专员一起工作完成一个财富管理营销活动的目标——理财顾问负责生成基金产品推荐方案文案编辑负责生成推荐话术营销专员负责触发批量发送邮件。3.2.1.4.2 交互方式2竞争Competition竞争意味着智能体之间为了完成各自的、相互冲突的目标而争夺资源——它们会互相竞争、互相排斥。用公司员工的类比来说竞争就像公司里的两个销售团队为了争夺“年度最佳销售团队”的称号而争夺客户资源——它们会互相竞争客户互相排斥对方的推荐方案。3.2.1.4.3 交互方式3协商Negotiation协商意味着智能体之间为了达成一个双方都能接受的协议而进行沟通和妥协——它们会互相提出条件、互相让步。用公司员工的类比来说协商就像公司里的采购部门和供应商为了达成一个双方都能接受的采购合同而进行沟通和妥协——采购部门提出“价格要降低10%”供应商提出“价格只能降低5%但可以延长付款期限30天”最后双方协商达成“价格降低7%付款期限延长20天”的协议。3.2.1.5 核心关键词5单个智能体无法完成的复杂任务Complex Tasks That a Single Agent Cannot Complete“单个智能体无法完成的复杂任务”意味着Multi-Agent系统的存在价值——如果一个任务可以由单个智能体轻松完成那我们就不需要用Multi-Agent系统用单Agent系统甚至传统的计算机程序就可以了。用公司员工的类比来说单个智能体无法完成的复杂任务就像公司里的“年度财富管理营销活动”——这个任务需要生成基金产品推荐方案、生成推荐话术、设计营销海报、触发批量发送邮件、跟踪客户反馈、调整推荐方案单个员工无法轻松完成需要多个员工一起工作。3.2.2 Multi-Agent系统的分类Multi-Agent系统可以根据不同的维度进行分类我会介绍5种最常用的分类方式3.2.2.1 分类方式1根据智能体的自主性和智能程度分类根据智能体的自主性和智能程度Multi-Agent系统可以分为三类3.2.2.1.1 反应式Multi-Agent系统Reactive MAS反应式Multi-Agent系统中的智能体是反应式智能体Reactive Agent——它们没有内部的状态没有上下文记忆只能根据当前感知到的环境信息做出决策和采取行动决策规则是完全预设的if-else语句或规则引擎。反应式智能体的例子包括扫地机器人、恒温器、简单的聊天机器人比如只能回答固定问题的客服机器人。反应式Multi-Agent系统的例子包括机器人足球赛中的简单机器人团队、仓库中的自动化分拣机器人团队。反应式Multi-Agent系统的优点是简单、高效、响应速度快缺点是没有学习能力、不能处理复杂的、动态的环境。3.2.2.1.2 慎思式Multi-Agent系统Deliberative MAS慎思式Multi-Agent系统中的智能体是慎思式智能体Deliberative Agent——它们有内部的状态有上下文记忆有一个内部的世界模型Internal World Model能够根据感知到的环境信息更新世界模型然后根据世界模型、预设的目标、以及规划算法比如A*算法、蒙特卡洛树搜索算法做出决策和采取行动。慎思式智能体的例子包括自动驾驶汽车、国际象棋AI、复杂的聊天机器人比如GPT-4o、Claude 3.5 Sonnet。慎思式Multi-Agent系统的例子包括自动驾驶车队、企业级财富管理营销Pipeline、科研论文阅读代码复现实验报告生成的个人系统。慎思式Multi-Agent系统的优点是有学习能力、能处理复杂的、动态的环境、能完成复杂的任务缺点是复杂、低效、响应速度慢。3.2.2.1.3 混合式Multi-Agent系统Hybrid MAS混合式Multi-Agent系统中的智能体是混合式智能体Hybrid Agent——它们同时具有反应式智能体和慎思式智能体的特征对于简单的、紧急的任务它们会用反应式的方式处理响应速度快对于复杂的、不紧急的任务它们会用慎思式的方式处理能完成复杂的任务。混合式智能体的例子包括高级的扫地机器人比如科沃斯的T20 Pro——它有反应式的避障能力也有慎思式的路径规划能力和记忆能力、高级的客服机器人比如阿里巴巴的小蜜——它有反应式的固定问题回答能力也有慎思式的复杂问题处理能力和学习能力。混合式Multi-Agent系统是目前最常用、最实用的Multi-Agent系统——它结合了反应式Multi-Agent系统和慎思式Multi-Agent系统的优点避免了它们的缺点。3.2.2.2 分类方式2根据智能体的交互方式分类根据智能体的交互方式Multi-Agent系统可以分为两类3.2.2.2.1 协作式Multi-Agent系统Cooperative MAS协作式Multi-Agent系统中的智能体之间的交互方式主要是协作——它们为了完成一个共同的目标而一起工作。协作式Multi-Agent系统的例子包括企业级财富管理营销Pipeline、科研论文阅读代码复现实验报告生成的个人系统、自动驾驶车队、仓库中的自动化分拣机器人团队。协作式Multi-Agent系统是目前最常用的Multi-Agent系统之一——因为大部分复杂的任务都需要多个智能体协作完成。3.2.2.2.2 竞争式Multi-Agent系统Competitive MAS竞争式Multi-Agent系统中的智能体之间的交互方式主要是竞争——它们为了完成各自的、相互冲突的目标而争夺资源。竞争式Multi-Agent系统的例子包括机器人足球赛中的机器人团队、电子游戏中的AI对手、股票交易市场中的AI交易员团队。3.2.2.3 分类方式3根据智能体的架构分类根据智能体的架构Multi-Agent系统可以分为三类3.2.2.3.1 分层式Multi-Agent系统Hierarchical MAS分层式Multi-Agent系统中的智能体之间是分层的、上下级的关系——有一个或多个“上级智能体Supervisor Agent”负责协调和管理多个“下级智能体Worker Agent”下级智能体只能和上级智能体交互不能和其他下级智能体直接交互或者只能通过上级智能体间接交互。用公司员工的类比来说分层式Multi-Agent系统就像公司的层级架构——有CEO上级智能体负责协调和管理多个部门经理中级上级智能体部门经理负责协调和管理多个员工下级智能体员工只能和部门经理交互不能和其他部门的员工直接交互。分层式Multi-Agent系统的例子包括OpenAI的Assistants API的Thread架构一个Thread Supervisor Agent协调和管理多个Assistant Worker Agent、微软的Semantic Kernel的Planner架构一个Planner Supervisor Agent协调和管理多个Plugin Worker Agent、企业级的项目管理Multi-Agent系统。分层式Multi-Agent系统的优点是结构清晰、易于管理、易于扩展缺点是灵活性差、上级智能体可能成为系统的瓶颈单点故障。3.2.2.3.2 分布式Multi-Agent系统Distributed MAS分布式Multi-Agent系统中的智能体之间是平等的、没有上下级的关系——所有智能体都可以直接和其他任何智能体交互没有中央协调者或者中央协调者只是一个可选的组件不是必须的。用公司员工的类比来说分布式Multi-Agent系统就像一个扁平化的公司——没有CEO没有部门经理所有员工都是平等的都可以直接和其他任何员工交互。分布式Multi-Agent系统的例子包括比特币网络中的节点每个节点都是一个智能体平等地交互、P2P文件共享网络中的节点、机器人足球赛中的高级机器人团队没有中央队长所有机器人平等地交互。分布式Multi-Agent系统的优点是灵活性好、没有单点故障、可扩展性强缺点是结构不清晰、难以管理、协调成本高。3.2.2.3.3 混合式Multi-Agent系统Hybrid MAS混合式Multi-Agent系统中的智能体之间是分层和平等相结合的关系——有一个或多个“上级智能体”负责协调和管理多个“小组”每个小组内部是平等的、分布式的关系小组之间可以通过上级智能体间接交互也可以直接交互。用公司员工的类比来说混合式Multi-Agent系统就像一个矩阵式的公司——有CEO负责协调和管理多个项目组每个项目组内部是平等的、扁平化的关系项目组之间可以通过CEO间接交互也可以直接交互。混合式Multi-Agent系统是目前最常用、最实用的Multi-Agent系统架构之一——它结合了分层式Multi-Agent系统和分布式Multi-Agent系统的优点避免了它们的缺点。3.2.2.4 分类方式4根据智能体的应用场景分类根据智能体的应用场景Multi-Agent系统可以分为很多类我会介绍6种最常用的3.2.2.4.1 企业级业务流程自动化Multi-Agent系统这类系统的应用场景是企业级业务流程自动化——比如财富管理营销Pipeline、客户服务Pipeline、财务报销Pipeline、供应链管理Pipeline等。这类系统的例子包括基于LangGraph的企业级财富管理营销Pipeline、基于微软Semantic Kernel的客户服务Pipeline、基于UiPath的财务报销Pipeline虽然UiPath主要是RPA但也可以结合AI Agent组成Multi-Agent系统。3.2.2.4.2 科研辅助Multi-Agent系统这类系统的应用场景是科研辅助——比如论文阅读代码复现实验报告生成、文献综述生成、实验设计优化等。这类系统的例子包括基于LangChain的科研论文阅读代码复现实验报告生成的个人系统、基于GPT-4o的文献综述生成系统、基于AlphaFold的蛋白质结构预测Multi-Agent系统虽然AlphaFold主要是单Agent但也可以结合其他Agent组成Multi-Agent系统。3.2.2.4.3 自动驾驶Multi-Agent系统这类系统的应用场景是自动驾驶——比如自动驾驶汽车内部的Multi-Agent系统感知Agent、决策Agent、控制Agent、自动驾驶车队的Multi-Agent系统协调Agent、多个自动驾驶汽车Agent等。这类系统的例子包括特斯拉的Autopilot内部的Multi-Agent系统、Waymo的自动驾驶车队的Multi-Agent系统、百度的Apollo内部的Multi-Agent系统。3.2.2.4.4 机器人Multi-Agent系统这类系统的应用场景是机器人——比如机器人足球赛中的机器人团队、仓库中的自动化分拣机器人团队、医院中的护理机器人团队、家庭中的服务机器人团队等。这类系统的例子包括RoboCup机器人足球赛中的机器人团队、亚马逊的Kiva自动化分拣机器人团队、波士顿动力的Spot机器人团队虽然Spot主要是单Agent但也可以结合其他Spot组成Multi-Agent系统。3.2.2.4.5 游戏Multi-Agent系统这类系统的应用场景是游戏——比如电子游戏中的AI对手团队、电子游戏中的NPCNon-Player Character非玩家角色团队等。这类系统的例子包括《英雄联盟》中的AI对手团队、《赛博朋克2077》中的NPC团队、《 Minecraft》中的村民团队。3.2.2.4.6 金融Multi-Agent系统这类系统的应用场景是金融——比如股票交易市场中的AI交易员团队、风险评估Multi-Agent系统、欺诈检测Multi-Agent系统等。这类系统的例子包括文艺复兴科技公司的Medallion基金中的AI交易员团队虽然文艺复兴科技公司没有公开技术细节但据推测是Multi-Agent系统、基于LangChain的风险评估Multi-Agent系统、基于微软Semantic Kernel的欺诈检测Multi-Agent系统。3.2.2.5 分类方式5根据智能体的是否跨平台分类根据智能体的是否跨平台Multi-Agent系统可以分为两类3.2.2.5.1 单平台Multi-Agent系统Single-Platform MAS单平台Multi-Agent系统中的所有智能体都位于同一个平台上——比如都位于同一个服务器上、都位于同一个云平台上、都位于同一个移动设备上。单平台Multi-Agent系统的例子包括基于LangGraph的个人科研辅助系统所有智能体都位于同一个个人电脑上、基于OpenAI Assistants API的企业级客户服务系统所有智能体都位于OpenAI的云平台上。单平台Multi-Agent系统的优点是部署简单、管理简单、协调成本低、性能好缺点是可扩展性有限受限于单个平台的资源、灵活性差只能在单个平台上运行。3.2.2.5.2 跨平台Multi-Agent系统Cross-Platform MAS跨平台Multi-Agent系统中的智能体位于不同的平台上——比如有的智能体位于企业内部的服务器上有的智能体位于公共云平台上有的智能体位于移动设备上。跨平台Multi-Agent系统的例子包括基于联邦学习的跨企业风险评估Multi-Agent系统有的智能体位于企业A的内部服务器上有的智能体位于企业B的内部服务器上有的智能体位于联邦学习的协调平台上、基于区块链的跨企业供应链管理Multi-Agent系统有的智能体位于供应商的内部服务器上有的智能体位于制造商的内部服务器上有的智能体位于零售商的内部服务器上有的智能体位于区块链节点上。跨平台Multi-Agent系统的优点是可扩展性强可以利用多个平台的资源、灵活性好可以在不同的平台上运行、可以实现跨企业协作缺点是部署复杂、管理复杂、协调成本高、性能受限于网络延迟。3.2.3 Multi-Agent系统的核心特征除了我们在定义中拆解的5个核心关键词之外Multi-Agent系统还有5个核心特征这些特征是Multi-Agent系统和传统的分布式系统的本质区别3.2.3.1 核心特征1智能性Intelligence智能性是Multi-Agent系统的最核心特征之一——它意味着Multi-Agent系统中的智能体具有一定的智能程度能够自主地感知环境、做出决策、采取行动甚至能够学习和进化。而传统的分布式系统中的节点是没有智能性的——它们只能根据程序员预先写好的代码执行固定的任务不能自主地做出决策不能学习和进化。3.2.3.2 核心特征2动态性Dynamics动态性意味着Multi-Agent系统中的环境是动态变化的——环境的状态可能会随时变化智能体的数量可能会随时变化有的智能体会加入系统有的智能体会离开系统智能体之间的交互关系可能会随时变化。而传统的分布式系统中的环境通常是静态的——环境的状态变化很慢节点的数量通常是固定的节点之间的交互关系通常是固定的。3.2.3.3 核心特征3开放性Openness开放性意味着Multi-Agent系统是开放的——任何符合一定标准的智能体都可以加入系统任何智能体都可以随时离开系统不需要系统管理员的预先批准或者只需要简单的身份认证。而传统的分布式系统通常是封闭的——只有预先配置好的节点才能加入系统节点不能随时离开系统需要系统管理员的预先批准。3.2.3.4 核心特征4不确定性Uncertainty不确定性意味着Multi-Agent系统中存在大量的不确定性——智能体感知到的环境信息可能是不准确的、不完整的智能体的行动可能会产生不确定的结果智能体之间的交互可能会产生不确定的后果。而传统的分布式系统中通常没有太多的不确定性——节点感知到的环境信息通常是准确的、完整的节点的行动通常会产生确定的结果节点之间的交互通常会产生确定的后果。3.2.3.5 核心特征5自适应性Adaptability自适应性意味着Multi-Agent系统能够根据环境的变化自动调整自己的行为——智能体能够根据感知到的环境信息的变化更新自己的世界模型、调整自己的决策规则、甚至学习新的知识整个系统能够根据智能体的数量变化、交互关系变化自动调整自己的结构和协调方式。而传统的分布式系统通常没有自适应性——节点不能根据环境的变化自动调整自己的行为整个系统不能根据节点的数量变化、交互关系变化自动调整自己的结构和协调方式需要系统管理员的人工干预。3.3