假设一家公司给采购部门部署了一个AI智能体。它可以理解采购需求、查询供应商、比较报价，再把确定的采购任务交给另一个智能体完成下单。供应商也有自己的销售智能体，可以自动报价、确认库存和接受订单。交易继续往后走，付款智能体执行付款，物流智能体安排交付。

单独看其中任何一个智能体，我们已经有一套相对熟悉的治理问题：它可以访问哪些数据，可以调用什么工具，权限有多大，什么时候需要人工确认，发生问题以后能不能追溯。等这些智能体开始彼此交互，特别是代表不同主体相互行动以后，原来的问题会迅速扩展。供应商智能体发来的authorised，究竟表示交易已经批准，还是只允许继续准备？采购智能体把任务交给付款智能体时，原来的授权范围有没有一起传过去？一家公司的智能体作出承诺，对方已经据此发货以后，这项行为还能不能单方面撤回？如果事故跨越两个组织发生，两边各自保留了一套日志，又怎样还原完整的行为链？

2026年8月10日，澳大利亚工业、科学与资源部发布了由Gradient Institute编写的《多智能体系统的风险与控制》（Risks and Controls for Multi-Agent Systems）。报告共119页，以三个治理层级分析多智能体系统中的风险因素、失效模式、控制措施，以及不同治理主体能够采取控制的位置。随着智能体逐渐越过内部部署边界，原来集中在单一组织内部的治理能力会不断分散，需要由共同规则、共享基础设施和更广泛的治理机制来补足。

这份报告真正值得关注的地方，是它把治理对象向前推进了一步。过去企业通常以一个AI系统为单位建立治理框架；当智能体开始代表不同主体彼此行动以后，只把每一个智能体单独管好已经不能覆盖完整风险，智能体之间形成的关系开始需要被单独识别和治理。

这里讨论的是一类特定的AI系统

报告讨论的是当前的基于大语言模型的智能体。按照其定义，这类智能体由大语言模型及其周围的运行框架和功能支架组成，并具有持续的智能体循环：规划下一步，调用工具对环境采取行动，观察结果，再根据新状态继续调整。缺少这一循环的普通提示词或者线性大语言模型工作流，不在报告的智能体定义范围内。

研究对象进一步限定在两个以上智能体相互作用产生的失效模式。单智能体风险主要作为背景出现；至少有一方智能体被假定处于组织治理之下；智能体与人的一般互动也没有被作为主要对象；完全发生在个人智能体之间、没有组织治理方参与的场景同样没有直接展开。报告列出的风险因素、失效模式和控制措施也明确采用选择性分析，并不试图穷尽所有多智能体风险。

还需要注意，这是一套分析框架，不是具有约束力的监管规则。报告不提出具体政策建议，所列控制措施也只是非穷尽的备选组合，应由部署组织结合后果严重程度、实施成本和具体场景作出选择。

因此，本文所说的“AI治理开始从系统治理进入关系治理”，主要针对具有智能体循环、并存在智能体之间交互的组织部署场景。把这一判断直接扩展到所有AI系统，会超过原报告的适用范围。

从现实部署看，这类系统目前也没有成为企业AI的普遍形态。报告对2026年产业实践的观察显示，企业更常见的仍是内部生产力智能体，以及权限和场景受到较强约束的外部服务智能体。多个智能体按照明确协议跨业务职能、跨组织自主协作，还处在相对早期。

不过，企业并不一定能够等到这种部署模式成熟以后再处理相关问题。报告在讨论部分提到一个很值得注意的变化：“交互对方是人”的假设正在逐渐失效。 很多面向客户的系统是在“接口另一端是一个人”的前提下设计、测试和监测的。消费者开始使用自己的智能体，供应商也逐渐部署智能体以后，一个原本面向人的界面可能在企业没有主动改造的情况下变成智能体之间的接口，对方还未必主动披露自己的智能体身份。

因此，一家公司没有主动部署第二个智能体，并不意味着它现有的智能体不会遇到其他智能体。变化完全可能先从交易和服务链的另一端发生。

真正增加的治理对象，是智能体之间的连接关系

报告把多智能体系统定义为两个以上彼此连接的智能体，它们的行为相互依赖，并可能出现任何单个智能体设计都无法完整预测的系统行为。智能体通过连接关系发生影响，一次API调用、一段消息、一个共享文件都可能构成连接；这些交互又运行在更大的交互底层之上，例如网络、协议、文件系统、市场平台或者注册表。

系统结构变化以后，传统治理能力也会随之承压。一个智能体独立执行任务时，授权主要解决它能不能采取某项行动；多智能体环境还需要处理任务委托：它能不能调用或者创建另一个智能体，新智能体获得什么权限，这些权限是否受到上游智能体权限约束，任务结束以后如何回收。错误定位也会变得复杂，一个异常结果可能已经经过数个智能体、不同工具和多个任务状态，需要重新拼接消息、调用和决策链条才能理解发生了什么。

报告因此重点讨论归因、授权、监督和评测四项治理能力。它们共同指向一个变化：企业逐渐需要从“管理有哪些智能体”，进一步走向“管理这些智能体怎样连接”。

过去一张AI系统清单可能长这样：

进入多智能体环境以后，还需要看到它们之间的关系：

很多新增风险发生在连接线上：信息怎样交接，权限怎样传递，双方怎样理解同一个状态，数据有没有跨越授权主体边界，出现问题以后两端日志能不能重新拼起来。

报告提出的单一治理、联合治理和开放环境三个层级，也可以从这种关系变化来理解。区分三个层级的核心，是发生交互的智能体之间最低能够假定存在多少共同治理基础。

单一治理

联合治理

开放环境

联合治理里的“组织”需要稍微解释一下。报告在这一部分把它扩展为任何独立的治理权限单元，既可以是一家公司，也可能是公司内部相对独立的业务单元或者团队。共同框架既可能由参与者共同协商，也可能由平台或者其他中介方统一制定。参与各方的目标可能高度一致，也可能存在相互独立甚至冲突的利益。

所以，下面虽然仍然会用“公司A—公司B”作为最直观的例子，联合治理真正识别的是治理权限边界。同一集团不同业务单元、共同项目参与方，或者受同一平台规则约束的商家和用户，都可能存在类似结构。

沿着这个思路落到企业实践，一个更实用的方法，是对每一条重要智能体连接判断治理环境。同一个智能体把任务交给自己团队内部的另一个智能体，可能属于单一治理；调用另一个业务单元独立治理的智能体，可能进入联合治理；连接已经签约的供应商智能体同样属于联合治理；再按照任务动态访问此前未知的外部智能体或者工具，治理条件又进入开放环境。

这样看，企业未来需要维护的基础资产除了智能体清单，还会包括一张 智能体关系图。

第一批治理问题，已经出现在智能体之间的交接处

很多多智能体工作流已经设置了多个智能角色，但智能体之间真正传递任务的方式仍然非常接近人与人交谈：

智能体B需要自己理解“确认”的对象、范围和后果。哪个客户，确认了哪个版本，价格有没有确认，付款是否已经授权，这项确认在多长时间内有效，下一步究竟可以准备材料还是正式下单，都可能没有结构化表达。

报告把自然语言交接列为重要风险因素，并把结构化交接列为一项重要控制措施。关键任务按照预先约定的数据结构交接，必要字段可以程序化验证，缺失信息明确保留为空，由系统触发补充，而不是让下一个智能体根据上下文自行填补。这样的交接点还可以同时承担日志记录和评测功能。

于是：

以下字段是本文按照报告控制逻辑整理的示意，并非报告提供的标准格式。自然语言可以逐渐转化为：

这里对法律和合规人员很有价值的一点，是审核对象向任务过程内部移动了。过去我们更多检查智能体最终输出是否正确；多智能体环境还需要检查一个智能体到底把什么事实、状态和权力传给了下一个智能体。

增加智能体数量也不会自然产生更可靠的独立复核。如果多个智能体共享相同基础模型、相似训练来源和提示词，它们可能拥有共同的判断盲区；多智能体讨论还可能出现从众偏差，最终形成虚假共识。报告因此讨论了模型和提示词多样化、盲投等控制方法。

“三个智能体都认为没有风险”表面上很像三重复核，实际和三位具有独立知识背景和独立判断过程的专家分别得出相同结论，并没有相同的证据价值。

任何一方都看不完整个系统

联合治理是整份报告里最值得法律和合规人员仔细看的部分。采购智能体与供应商智能体是最容易理解的例子，报告涉及的场景还包括跨业务单元的内部智能体、共同代码库中的多方智能体，以及通过平台规则或共同项目框架发生交互的智能体。它们有一个共同特征：各参与方都能够治理自己的一部分，没有任何一方能够单独控制完整系统。

公司A可以管理自己的智能体，却无法直接看到公司B生产环境中的模型、系统提示、权限状态和完整运行记录；即使两个部门属于同一个法人，只要真正的数据、权限和决策机制由不同治理单元掌握，也会出现相似的跨边界问题。

报告因此为联合治理增加了两层共同框架。规则协议层规定参与主体承担哪些义务、智能体应满足哪些配置要求、允许怎样的行为以及如何处理争议；交互底层与基础设施层解决这些关系怎样进入机器运行，包括通信协议、消息结构、身份体系、共享日志和监测机制。

这两层放在一起，对法律工作很有启发。过去一项系统合作中，合同和技术接口经常由不同团队分别推进，法务关注权利义务，研发关注API。智能体开始直接代表不同授权主体行动以后，两套机制需要在更细的层面发生连接。

报告讨论的语义分歧就是一个典型例子。双方即使采用完全相同的数据结构，authorised在A的业务规则里可能表示“可以继续准备”，在B的系统里却表示“已经可以正式执行”。数据格式完全兼容，两个智能体也分别按照各自规则正确处理了输入，最终交易仍然可能发生实质偏差。

报告将“共同的业务与范围词汇”列为规则协议层的一项预防控制。参与方可以共同定义delivery、place order、authorise payment等会真正影响业务后果的概念，再通过消息结构和基础设施把这些语义带进机器交互。报告也把语义分歧直接放进跨组织未授权交易的风险链条中。

一部分合同规则，会越来越靠近机器执行的接口

传统合同可能写：

人类通常可以结合背景理解“授权”的含义。智能体直接执行这项规则以后，这个概念还要继续被拆解：谁可以授权，针对哪一笔交易，最高金额是多少，持续多久，交互对方能否变化，权限能不能继续委托，授权撤销以后多久才能真正阻止系统执行。

以下字段同样是本文根据报告形成的示意，并非澳方发布的标准结构。一个法律概念可能开始对应一组可以被机器验证的状态：

报告没有讨论用代码取代合同，它建立的是规则协议层与交互底层及基础设施层之间的治理连接。沿着这套框架继续看，部分关键业务语义、授权边界和行为限制，确实越来越需要在自然语言合同之外形成能够被系统识别、验证并留存证据的结构化表达。

一项智能体交易以后可能同时依赖几套相互连接的载体：合同确定双方的权利义务，数据结构规定关键业务状态如何表达，身份与访问管理系统判断某项行为由谁授权，运行日志记录最后究竟发生了什么。

报告对联合审计基础设施的讨论已经体现了这种方向。跨组织审计需要通过共享身份层连接参与各方自己的日志片段，再通过参与方签名等机制提高记录的防篡改可信度，使跨边界行为在事后仍然能够被重建。

对法务来说，一项智能体合作需要关注的内容也会随之扩大。责任限制、知识产权和数据保护仍然存在，同时还要关心智能体代表谁、关键业务语义是否一致、授权怎样表达和撤销、双方怎样对接日志、共同测试如何进行、异常时谁有权暂停系统，以及争议发生后怎样证明机器当时获得了什么权限。

智能体背后是谁，仍然是法律分析的起点

讨论“智能体谈判”“智能体竞争”“智能体合谋”时，很容易逐渐把智能体想象成一个新的自主法律主体。报告对此处理得相当克制。全文使用“规划”“谈判”“竞争”“合谋”等拟人化词汇，只是为了描述可以观察到的行为模式及其效果，并不意味着这些系统具有与人相同的理解、意图或者道德主体性。

报告定义的授权主体，是智能体依据其授权行动、且智能体行为最终归属于该主体的个人或者组织。归因和授权也围绕这条链条展开：系统需要识别哪个智能体实施了某项行为，同时还应继续追溯到它背后可被问责的主体。

智能体法律人格被放在报告主要范围以外的相邻议题中处理。报告提到，当智能体根本没有可以问责的授权主体，例如系统被设计为以自己的名义持续行动，或者与原来的人类授权主体失去持续关系时，智能体法律人格的问题会更加突出。这部分已经超出报告的主要分析范围。

现有合同、代理、责任和监管原则怎样适用于由智能体介入的行为，哪些场景可能需要新的法律机制，报告也没有给出答案。它提供的是技术和治理层面的风险结构，让法律研究和监管能够进一步判断哪些制度缺口需要处理。

对现在的企业而言，讨论智能体是否成为新的法律主体还比较遥远。更现实的任务，是确保一条行为链始终能够回答：这个智能体代表谁，它依据什么授权行动，最终由谁承担相应责任。

联合治理还要面对真实的利益分歧

跨治理边界的风险并不只来自接口和业务语义不一致。多个治理单元之间可能存在共同目标，也可能在具体利益上发生分歧。采购智能体和销售智能体都希望完成交易，但会分别为自己的授权主体争取更优条件；多个智能体可能竞争同一有限资源，也可能在长期互动中形成对市场产生影响的策略。

因此报告进一步讨论了欺骗性谈判、算法合谋、共享资源管理失效，以及大规模相关决策可能带来的不稳定动态。这里的“合谋”依然只是行为层面的描述，并不预设智能体具有人类意义上的主观合谋意图。

这些风险使规则协议层承担的任务更复杂。参与方除了需要共同定义authorised是什么意思，还要考虑智能体在目标不一致时允许采取哪些策略，什么行为越过可接受的行为边界，高价值交易怎样确认，异常交易如何争议和撤销，以及双方怎样进行联合评测。

人与企业之间本来就存在利益不完全一致的合作关系，合同一直承担着为这种关系建立行为边界的功能。智能体开始高速、持续地代表不同主体行动以后，同样的问题进入了机器交互环境。未来智能体合作协议需要处理的内容，自然会超过技术接口是否兼容。

人工介入可以找到更准确的位置

企业谈智能体治理时，经常会写“高风险事项需要人工审核”。这个要求本身没有问题，困难在于“高风险”很难直接转化成系统设计。所有动作都要求人工确认会显著削弱智能体效率；完全让智能体自己判断什么时候应该停下来，又会让关键控制依赖被控制对象自己的判断。

报告在联合治理里提供了一个更容易落地的维度：跨边界不可逆性。

智能体在内部生成了一份错误文件，通常还可以修改；内部工作流状态出错，也可能回滚。一旦智能体代表某个主体向另一个治理主体作出承诺，对方可能已经发货、预留库存或者启动自己的分包商，原组织很难再通过修改内部系统单方面恢复到原来的状态。机器执行速度还可能让授权主体在意识到问题以前就错过干预窗口。

报告列出的控制选项包括：对可能产生重大后果的行为设置人工审核停止点，在真正形成跨边界承诺前重新确认授权，并在部分场景下通过冷静期保留一定的纠错空间。

这个思路可以把人工介入放到更明确的位置：优先寻找智能体即将把法律、经济或者数据后果带出本治理主体单方面控制范围的节点。付款、正式下单、接受重大商业条件、向外部主体发送受保护数据，都可以按照这一逻辑判断。

数据问题尤其能说明这种变化。报告把“数据义务失效”放在上下文泄漏越过组织边界以后分析；这些数据还可能附带客户同意、合同保密、商业敏感性或者特定法域的合规义务。数据一旦离开原治理主体，其后续使用已经无法再通过原主体自己的系统单方面控制。对于数据合规来说，这比单纯把任务标成“敏感”更接近实际风险形成过程。

智能体变成网络以后，评测需要同时看能力和行为倾向

报告对评测还有一组很有价值的区分：能力和行为倾向。

能力关心智能体是否具备实施某种行为的能力，行为倾向关心它在具体部署条件下有多大倾向实际实施这种行为。多智能体环境越开放，第二个问题越难回答。

在单一治理中，部署方知道系统内其他智能体的设计，能够较真实地构造交互对方和运行条件，所以除了能力测试，还可以相对有效地评估某种失效模式在实际系统里的发生倾向。

进入联合治理以后，对方智能体变得不透明。企业自己模拟一个供应商智能体，并不能证明它和对方生产环境里的真实智能体行为一致。联合评测和共享测试环境因此变得重要，一些风险只有把不同授权主体、不同目标的真实系统放在一起以后才有机会被观察到。

进入开放环境后，行为倾向评测更加困难。潜在交互对方没有明确边界，运行环境持续变化，同一种行为发生的倾向会跟着部署条件变化。历史基准会逐渐失效，部署方越不了解真实环境，评测越需要回到能力层面，测试系统在最坏条件下究竟能够做到什么。

可以把三层治理环境中的评测概括成：

单一治理

联合治理

开放环境

从测试方法的演进看，路径也比较清楚：

评测方法的演进路径

多智能体时代的基准测试因此很难只靠“多加几个案例”完成升级。测试对象、测试环境以及最终能够证明什么，都在发生变化。

进入开放环境以前，企业先要做一道架构选择

开放环境面对未知交互对方，部署方无法假定双方利益一致，也不能确定对方有没有被攻陷，很多时候甚至不知道对方究竟代表哪个主体。报告认为，最可靠的部署姿态是把未知交互对方视为可能具有对抗性、可能利用系统弱点的对象。

不过，企业在采取具体控制以前，还有一道更基础的架构选择：业务究竟需不需要让智能体进入开放环境。

如果业务不需要开放自治，系统完全可以继续留在单一治理或者联合治理框架里。确实需要进入开放环境时，报告提出的两种设计方向差异很大。

一种方向是锁定运行范围。企业把智能体的目标、工具、权限和行动空间限制在很窄的范围，让它即使面对未知交互对方，也缺少造成严重后果的行动能力。这会牺牲一部分通用自主能力，但很适合客服、文档处理、理赔材料处理等能够划定明确任务边界的场景。

另一种方向是保留更广泛的通用自主能力。这时，企业自身的身份与访问管理、内部政策和日志只能解决本地问题，系统还需要通过多中心治理寻找更广泛的信任基础，包括共同身份机制、密码学证明、信任标准和公共基础设施。报告认为，这两种方向会导向几乎相反的智能体设计。

企业面对的实际决策可以整理成：

这样理解以后，开放智能体公共基础设施就不会变成所有企业都需要提前建设的统一前置条件。它更多是企业选择让智能体在未知环境中保持较广泛自治以后，需要承担的治理成本。

走到开放环境，身份开始成为公共基础设施问题

如果智能体只和已知主体交互，企业还可以通过内部身份与访问管理或者共同协议验证对方。开放环境里，大量智能体持续存在，系统需要进一步判断另一个智能体究竟是谁、代表谁、过去做过什么，以及它展示出来的声誉是否可信。

报告因此把去中心化身份、防女巫攻击和群体监测等问题逐步推向公共基础设施和集体行动层面。去中心化标识符（DID）、可验证凭证等技术组件已经存在，真正缺少的是被广泛接受、能够让智能体凭证产生现实意义的可信基础设施。报告用Let’s Encrypt作类比，正是为了说明标准和密码学本身并不足够，身份体系还需要一个能够被大量参与者共同接受的运行机制。

从单一治理走到开放环境，信任基础也在变化：

信任基础的变化

随着这条路径继续延伸，AI基础设施的内涵也会扩大。模型、数据和算力解决系统能否运行；身份、授权、协议、日志、评测和可信交互机制，则越来越多地决定智能体能否进入真实商业和社会关系。

控制措施之间也存在真实的取舍

如果只看前面的控制措施，很容易得到一种过于乐观的印象：自然语言交接有问题，就改成结构化字段；身份有问题，就增加凭证；追溯困难，就增加日志；开放环境复杂，就进一步加强验证。报告在讨论部分专门提醒，很多治理目标之间存在取舍，控制设计本身也会改变系统能力。

其中一组是可理解性与能力之间的取舍。不少监督方法依赖人类能够理解智能体之间的通信或者推理记录，但智能体为了提高协作效率，可能使用更压缩、更高效、同时更难直接理解的表示方式。系统能力提升以后，人类监督的可读性未必同步提高。

另一组是协调与上下文隐私之间的取舍。多智能体要完成复杂协作，需要共享足够上下文，而通信通道本身又是上下文泄漏的重要来源。更麻烦的是，隐私泄露可能来自多轮互动产生的累积推断。某一条消息本身没有泄露秘密，对方仍然可能从多轮拒绝、让步及其组合模式中逐渐还原隐藏信息，所以单纯在消息出口设置过滤器无法覆盖全部问题。

这对数据合规有一个很实际的提示：多智能体环境中的“最小必要”不能只按照显式字段数量判断。一系列单次看来合理、必要的交互，组合以后也可能向另一个智能体暴露本不应获得的上下文。

因此，多智能体治理很难形成一套可以机械套用的“最佳控制组合”。企业需要理解具体关系中可能出现的失效模式，再判断为了降低这些风险，愿意牺牲多少效率、可读性、上下文和自主性。

企业真正应该先画的，是智能体关系图

如果把报告的三级结构转化为企业实践，我更建议从每一条重要智能体连接开始盘点，而不是直接建设一套庞大的多智能体治理框架。

一条关系至少需要回答这些问题：

每一条重要连接至少需要回答：

再根据双方的共同治理基础判断：

按每条连接分类，是我在报告三级框架基础上进一步形成的企业盘点方法。报告主要按照部署层级分析，而层级本身就是根据发生交互的智能体之间最低共同治理水平确定的，因此关系图很适合作为实际治理入口。需要注意，逐条连接分类适合企业盘点；如果这些连接共同构成一个连通的部署，系统整体仍应按照其中最低的共同治理基础判断，并承接更开放层级的累积风险。

最后，用一张矩阵检查每一条智能体关系

报告采用“风险因素→作用机制→失效模式→后果”的分析链，并在不同位置配置预防、恢复、基础性控制和验证活动。不同场景可能产生完全不同的后果，因此报告也没有要求组织机械采用全部控制措施。

如果把119页内容进一步压缩成一张企业可以实际使用的关系风险矩阵，可以这样处理：

授权主体

身份

交接

授权

利益关系

数据

追溯

不可逆动作

监督

评测

开放环境策略

控制权衡

核心问题

这张矩阵不是报告提供的官方检查表，而是按照它的治理层级、风险因素、失效模式和控制措施重新组织形成的企业使用工具。它更适合帮助企业识别一条智能体关系改变了哪些治理条件，而不是直接据此建设一套独立的多智能体合规体系。

过去做AI治理，我们通常登记一个系统，分析它的模型、数据、用途、权限和风险，再围绕这个系统设置控制。多智能体开始出现以后，这套方法还需要增加一层：智能体受谁授权，它正在和谁发生关系，双方有没有共同治理基础，事实和权限怎样跨过连接传递，各自授权主体的利益是否一致，一个行为越过治理边界以后还能不能撤回，事故发生以后完整证据链是否能够重新拼起来。

这些问题很大一部分都发生在智能体之间。报告的三级治理结构也正是沿着这个方向展开：共同治理基础减少以后，会出现新的失效模式，相应的控制能力也从单一组织逐渐转向多个参与方，再延伸到公共基础设施和集体行动。

这里仍然需要保持报告本身的克制。今天很多跨组织、开放多智能体形态仍处在早期，现有法律如何适用于由智能体介入的行为，还有大量没有完成的分析；身份、评测和群体层面治理也存在明显的研究和基础设施缺口。

因此，现阶段企业未必需要提前构造一整套关于“智能体法律身份”的新制度。更现实的工作，是先把每一条重要关系看清楚：智能体代表哪个授权主体，连接了什么对象，双方的信任建立在什么基础上，企业自己的控制能力能够延伸到哪里，越过这条边界以后又依赖什么机制继续治理。

当越来越多智能体开始替个人和组织行动以后，这些问题会逐渐和模型准确率、智能体能力本身一样，成为AI治理中的基础问题。这也是我理解这份119页报告真正向前推进的地方。