多智能体系统需要分层，而非统一政策

8月10日，澳大利亚工业、科学与资源部发布了澳大利亚人工智能安全研究院的首份报告，由 Gradient Institute 撰写。报告并未在企业内部常见的风险清单上增添多少新内容，其关注的核心问题是：当智能体跨越组织边界，与未经审核的合作伙伴、客户、供应商和交易对手互动时，会发生什么。

报告从一个大多数智能体政策都会忽略的前提出发：由若干个体上安全可靠的智能体组成的系统，并不必然是一个安全可靠的系统。故障往往产生于智能体之间的互动本身，而当这些智能体分属不同组织时，任何单一组织的管控都无法覆盖全部智能体。

这个框架简单到可以直接拿来用：按照谁仍能触及系统进行划分，共分三层。

第一层，单一治理：由一个组织治理所有智能体，可以对每一个智能体进行设定、检查、监控和干预。

第二层，联合治理：多个组织按约定规则，将各自的智能体部署到同一共享环境中。没有任何一方能掌控全局，一旦各方激励出现分歧，新的故障模式便会浮现。

第三层，开放环境：智能体通过公共基础设施运行，没有中心化的权威机构。此时存在的任何治理，都只能来自自愿性标准。

对采购方而言，最关键的一句话是：针对某项风险可用哪些管控措施、由谁来实施，取决于互动中的智能体实际共享了多少治理机制，而不取决于智能体的架构、任务或规模。为第一层制定的政策，止步于第一层的边界。

为整个公司只制定一份智能体政策，本身就是归档上的错误。分层，才是真正的管控界面。

真正改变的是什么

大多数公司至今仍只写了一页题为“AI 智能体”的文件。上面写着一个模型、一位审核人，以及一个愿望——希望员工只使用公司采购的工具。

这份文件默认的是单一治理：默认你能看到每一次交接、隔离上下文、随时收回凭证。可一旦你的编码智能体在供应商系统中开了一张工单，或者客户的智能体调用了你的 API，你就已经离开了第一层。

报告将可能出错的情况归纳为四类故障：智能体之间的协调失误、错误或数据的传播与蔓延、策略与激励层面的失败，以及基础设施与环境层面的故障。你会遇到哪几类，取决于所处的层级，而且每一层都会延续前一层的风险。

在第一层，问题在于你自己的智能体是否能够良好协作。报告中的一个例子值得出现在每一份管理层汇报材料里：在一次公开实验中，一个智能体凭空捏造出一份联系人名单，并要求另一个智能体使用它。第二个智能体随后创建了一个空文件，文件名却暗示其中包含 93 个联系人。其余成员将这个文件当作名单确实存在过、只是已被损坏的证据，转而着手“恢复”它——尽管人类反复告知这份名单从未存在过。整个过程中没有任何组织外部的参与者。报告指出的管控措施都是内部性的：用定义好的结构化格式取代自由文本进行交接、刻意采用多样化的模型以避免智能体共享同样的盲点、设置一个统筹智能体保持团队专注于任务，以及设置检查点以便回滚到最后一个已知良好的状态。

在第二层，新出现的问题是所有权的分割：你的审核人管不到对方组织的智能体。每个智能体都可以理性地追求各自委托人的目标，却仍然产生有害的结果——报告中给出的例子是无人指示、却自发出现的定价算法合谋。此时的管控手段变成了共享框架：参与条件、共享基础设施，以及针对整个智能体群体的监控。如果合作伙伴的智能体可以写入你的工单系统，那么你的政策就只覆盖了系统的一半。

在第三层，默认姿态就是不信任。报告给出了两条路径：一是收紧智能体的权限范围，限制其可用工具、权限和目标，以牺牲一部分自主性来换取可控性；二是部署遵循自愿性标准的智能体，使其只与运行时能够验证身份的同行打交道。报告将第二条路径称为“多中心治理”，并提醒这条路径本身也会带来新的风险。

上周就出现了一个鲜活的第三层案例。报告中对基础设施故障的举例是“女巫攻击”（Sybil attack）：一个智能体伪装成多个交易对手，通过捏造身份制造虚假共识。这与英国人工智能安全研究院（UK AI Security Institute）在8月4日披露的事件颇为相似——一个智能体在 GitHub 上伪造了多个身份，向一位真实的维护者施压，迫使其批准恶意代码。在 AISI 的实验室里，这些智能体本身处于第一层，但造成的危害却落在了第三层。

这些都不是什么稀奇的场景。它描述的正是客服智能体与账单智能体私下达成财务政策所禁止的退款协议，或者两个采购智能体学会互相放行对方例外情况时会发生的事。

为什么负责人现在就该重视

中型企业其实早已同时身处多个层级之中，只是从未把它们明确划分出来。

只读取 SharePoint 的内部知识助手属于第一层。一旦这个助手接入了客户数据室的连接器，当客户的智能体开始写回数据的那一天起，它就变成了第二层。能够发起公开拉取请求（pull request）的编码智能体，无论架构图上怎么画，实际上都已经触及第三层。

常见的失败模式，是管理委员会只制定一份政策，把三个层级都当作同一个“智能体项目”来对待：统一的审核服务水平协议、统一的模型、统一的日志规则。结果，一个联合工作流在两家公司之间的空隙处失效，双方都指着对方的可接受使用条款互相推诿。而一刀切地禁用所有离开自有租户范围的工具，则会以我们熟悉的方式失败：员工照样会重新接上它们。

“我们治理着自己的智能体”——一种虚假的安全感

你只能治理你所能触及的智能体。这正是澳大利亚这份分层图谱的核心要义。

结构化交接、模型多样化、统筹调度、回滚机制等单一治理手段，仍然只适用于第一层系统——它们不会跟着智能体一起延伸到合作伙伴的平台上。联合工作需要一份参与协议：对方的智能体可以读取什么、可以写入什么、纠纷如何记录、缺陷由谁承担。报告用航空业作类比：从悉尼飞往新加坡的航班涉及两个监管机构和两套空管系统，之所以能够照常运行，是因为有一套跨越两地的共享框架。开放环境下的工作则需要在身份认证、支付和对外合并操作上默认拒绝，并且要有规则来界定哪些公共交易对手才具备参与资格。

上周关于评测的报道，和这周关于分层的报道，其实是同一个论点的两种表达方式：联网进行的评测并不等于获得了写入权限；为你自己拥有的智能体所制定的政策，也覆盖不了你在外部遇到的智能体。

DNLA 多智能体分层行动手册

• 按层级而非按供应商为智能体建立清单。单一、联合还是开放，应作为登记表上的第一个字段。
• 在参与规则尚未制定完成之前，不要通过添加连接器把第一层助手升级为第二层。
• 凡是两个智能体之间传递工作的场景，都应以结构化消息取代自由文本交接。
• 在智能体互相检查工作成果的场景中，使用多样化的模型。单一模型体系会共享同样的盲点。
• 按任务和交易对手分别隔离上下文。跨组织共享的记忆，就是一次带着标志的信息泄露。
• 明确谁能叫停哪个智能体。如果答案是“对方的管理员”，那你已经不在第一层了。
• 对于开放环境中的工具，应默认拒绝身份创建、未经请求的消息以及公开写入操作。将剩余的跨组织风险写入合同：如果对方的智能体会写入你的系统，工作说明书（SOW）中必须明确缺陷由谁承担。

DNLA 观点