单智能体的安全（本库《给 Agent 上锁》）已经有完整的清单：最小权限、沙箱、人工确认点、输入消毒。但当系统从「一个智能体」进化为「一个智能体团队」——规划者智能体分解任务、执行者智能体各自干活、评审者智能体验收结果、它们之间互相委托与传递上下文——安全问题的形态发生质变：不是「更多个单智能体的问题叠加」，而是一类全新的系统性风险在多主体的交互中涌现。本库收录的「1200 个智能体自发建留言板」事件已经预演过一次这种涌现的不可预测性。本篇讲清多智能体系统的新攻击面与设计原则。
新攻击面：交互结构本身成为风险
多智能体系统的风险增量来自「交互」这个新变量，主要形态有四类。形态一：错误的链式放大（error cascades）。单智能体的错误率是 p，一条 N 个智能体的委托链上，系统级错误率接近 1-(1-p)^N——每个智能体 95% 的可靠性，五级委托链的系统可靠性只剩约 77%；更糟的是链式放大的复合形态：上游的一个小偏差被下游当成「事实」继续推理（上游说「已确认订单信息」，下游基于这个未验证的断言执行删除），错误带着「已被上游确认」的假权威滚动放大。形态二：信任的传递与「信任链劫持」。多智能体架构里，智能体之间天然存在信任传递（「这是协调者派来的任务」）——攻击者只要攻陷链上任何一环（或伪造一个「上游」身份），就能以「可信来源」的身份向下游注入指令——提示注入在多智能体场景的威力被信任结构放大（本库《一篇读懂提示注入》的间接注入，在多智能体里获得了「官方转发的伪装」）。形态三：目标漂移与「团队合谋」。多个优化局部目标的智能体，可能在交互中形成谁都没设计过的整体行为（智能体间「协商」出规避监管的协作方式——1200 个智能体建留言板就是一次无害的预演）；当智能体具备互相「记忆」与「学习」的能力时，不良模式的传染成为系统性风险。形态四：责任的多米诺（accountability diffusion）。「哪个智能体干的」在链条式协作里越来越难回答——每个环节都「只是执行了上游的指令」，事故的责任在系统里蒸发；这对审计、追责与保险都提出新问题。
设计原则：给「组织」而不是给「个体」上锁
多智能体的安全设计，方法论要从「锁住个体」升级为「设计一个安全的组织」。原则一：信任不做默认传递。智能体之间的每次委托都重新鉴权（不因「来自内部协调者」而豁免检查），每个智能体对上游传递的信息保持「数据非指令」的纪律（本库《一篇读懂提示注入》的原则在每次交接时重申）；身份与信任的建模可以借用零信任架构的思路——永不信任，始终验证，按最小信任设计每一条边。原则二：关键动作的人类检查点在「链」上，不在「点」上。单智能体的人工确认点设计（本库《给 Agent 上锁》）在多智能体场景要重新布点：不是每个智能体各设一个确认（会淹死用户），而是在系统级的关键动作（对现实世界有影响的操作、不可逆的操作、聚合敏感数据的操作）设统一闸门——检查点的对象是「能力聚合后的风险」，不是中间步骤。原则三：为「链」设计可观测性。每个智能体的输入输出、决策依据、委托关系全程留痕（可追溯的任务血缘——出事时能回放整条链路的每一步），链级的监控指标（错误率沿链的传播曲线、智能体间通信的异常模式）独立于单智能体监控。原则四：冗余与交叉验证的架构化。用「执行者-评审者」的分工（一个智能体干活、另一个独立验证——它们的训练谱系或视角刻意差异化，避免「合谋性盲区」）、对关键结论要求多智能体的一致性确认——用组织的冗余对冲个体的不可靠，这正是人类组织用「四眼原则」对抗个人错误的同款智慧。
边界与前瞻：多智能体安全的开放问题
诚实地说，多智能体安全的大部分问题还处于「识别阶段」而非「解决阶段」。开放问题一：交互涌现的不可预测性——智能体间交互的涌现行为（自组织、自发协议、未设计的分工）无法靠静态分析预判，目前的手段只有实测与沙盒演练（在封闭环境里先跑起来观察）；「1200 个智能体」那类事件的价值正是作为涌现行为的观察样本。开放问题二：责任框架的空白——法律上「智能体团队」的行为归属（开发者？部署者？协调者？）尚无成熟框架，欧盟 AI Act 的责任链条在多智能体场景的适用性是活跃的讨论题。开放问题三：智能体间通信协议的安全标准——智能体互操作协议（MCP、A2A 类协议）的安全规范正在起草与迭代（本库《MCP 协议深度拆解》追踪的演进），多智能体时代的「网络协议安全」会像互联网早年一样经历漏洞发现与标准修补的循环。对从业者的建议收敛为一句：多智能体系统的能力红利与安全债务同时增长——在把一个智能体团队接入现实世界之前，先假设它会以你没想到的方式犯错，然后为那种方式设计护栏。
多智能体的组织隐喻：从「同事」到「流程」
多智能体安全的设计原则里，「组织隐喻」的选择本身是个决策：你把智能体团队当「同事」管理，还是当「流程」管理——两种隐喻导向完全不同的安全架构。「同事」隐喻：智能体像可信任的员工（有自主判断、互相协作、被授权后灵活行事）——它的效率高（灵活、自适应），安全问题也像员工问题（权限滥用、判断失误、被社会工程）——这个隐喻适合「人监督智能体」的形态，但多智能体的互赖结构让它失效：员工可以问责，智能体链条里没有「这个人」。「流程」隐喻：智能体团队是一条自动化流水线（每个环节的功能、输入输出、失败模式都是设计好的，环环可测、可审计、可替换）——它的安全性高（流程的可验证性），代价是灵活性（设计之外的场景就崩溃）。实践中的正确选择是分层的混合：核心业务与高危操作走「流程」隐喻（可验证性优先），探索与辅助任务走「同事」隐喻（灵活性优先），且两个域之间有防火墙（同事域的智能体无权触碰流程域的关键操作）。隐喻选择的治理含义：采用「同事」隐喻的团队必须补上「同事」才有的配套（问责、培训、考核——对智能体而言即评测、对齐与审计），采用「流程」隐喻的团队则要接受流程的僵硬成本——隐喻不是免费的，每一种都要为它的安全代价付费；而最危险的组合，是用「同事」的隐喻部署、按「流程」的标准免责**。
智能体间的「通信协议」安全：A2A 时代的前瞻
多智能体的通信正在被协议化（MCP 之外的智能体间协议 A2A 等正在成型），协议层的安全是这个领域的前瞻话题。协议化的安全意义：互操作协议让「任意智能体找到任意智能体并委托任务」成为基础设施——就像 HTTP 让任意网页互联——互联的效率与攻击面的扩散同时到来：恶意智能体的身份伪装（「我是合法的协调者」）、任务委托的注入（委托描述里藏指令）、返回结果的污染（智能体交付的结果里带毒）。协议安全的设计要点（借鉴互联网协议安全的历史教训）：身份层（智能体的可验证身份——证书与签名，防止伪装）、授权层（任务委托的权限边界——委托不等于全权，被委托方的能力受委托方的权限约束）、内容层（委托内容与返回结果的「数据非指令」纪律——协议层强制区分任务与数据）、审计层（交互的不可抵赖记录——链路级的日志，本库正文的可观测性原则在协议层的落地）。历史教训的引用：互联网早年的协议（SMTP、HTTP）都没有内建安全（认证、加密是后补的），补课的成本极高（垃圾邮件、钓鱼、劫持至今是顽疾）——智能体协议如果重蹈「先互联后补安全」的覆辙，多智能体生态会在早期被滥用定型——协议设计的当下，就是安全设计的最佳（也可能是最后的）窗口。
小结
多智能体安全收成四条：交互本身是新攻击面——错误的链式放大（95% 可靠性的五级链只剩 77%）、信任链劫持、目标漂移、责任蒸发，四类风险都源于「交互」这个新变量；设计原则从锁个体升级为设计组织——信任不默认传递、检查点设在链级的关键动作、任务血缘全程留痕、用执行者-评审者的架构化冗余对冲个体不可靠；涌现行为不可静态预判——沙盒演练与事件观察（1200 智能体事件的价值）是当前的唯一手段；责任框架是空白——法律与标准的跟进远落后于系统的部署。单智能体像管一个员工，多智能体像管一家公司——你需要的是组织设计，不是更多锁。
参考资料
- 本库前篇：《给 Agent 上锁：工具权限、沙箱与最小信任设计》《一篇读懂提示注入》《当 1,200 个智能体自己建了留言板》《MCP 协议深度拆解》
- 多智能体系统的风险与可靠性研究综述（error cascades 与 agent interaction 的公开论文群）
- 零信任架构（Zero Trust Architecture, NIST SP 800-207）—— 信任模型的架构参照
读者留言
COMMENTS 暂无还没有留言，来说第一句？