组合问题：为何安全属性不会自动叠加

当工程师评估多智能体流水线的安全性时，他们通常着眼于单个智能体：这个智能体的权限范围是否正确、凭证是否短期有效、是否经过硬件证明。他们较少思考的，是流水线本身作为一个独立的信任界面。潜在的假设是：治理良好的组件能组合成治理良好的整体。这一假设是错误的。

组合引入了任何单个智能体都不会出现的失效模式。一条由单独限定范围的智能体组成的链路，可能产生没有任何单个智能体被授予的涌现权限。一条由单独可审计步骤组成的流水线，可能产生没有任何单条日志记录所能描述的结果。当组合流水线造成伤害时，"谁该对此结果负责"这一问责问题，会以一种无法令人满意、也无法真正解决的方式分散到各个组件中。这三种失效模式并非实现上的缺陷，而是组合本身的结构性属性。

涌现权限

权限范围被分配给智能体，而非流水线。一个被允许读取患者记录的协调智能体，将子任务委托给一个被允许向消息系统写入的第二智能体。没有任何一个智能体被授权根据医疗记录内容向患者发送消息——但组合后的流水线可以做到这一点。执行这一组合动作的权限从未被授予任何人，而是从两个单独合理的授权的交集中涌现出来。

这并非病态配置，而是当两个具有互补权限范围的智能体在未对其交集进行显式推理的情况下被串联时所发生的事情。问题在于，现有权限模型是以智能体为中心的。它们回答的是"这个智能体被允许做什么"，而非"这条流水线被允许产生什么"。这是两个不同的问题，而只有第二个问题才真正约束实际结果。

不可见的副作用链

流水线中的每个智能体处理其输入并产生输出，输出成为下一个智能体的输入。在正确隔离的系统中，没有单个智能体能够观察其输出的下游后果——它已完成任务并继续前进。但下游后果恰恰是流水线实际效果所在之处。一个格式化临床建议的智能体，对第二个智能体将如何解读该格式，或第三个智能体将如何依据第二个智能体的解读采取行动，没有任何可见性。

在硬件部署中，这种链式结构意味着局部无害的输出可能成为危险的输入。一个传感器读数智能体输出的数值在正常参数范围内，但第二个智能体——基于略有不同的运营基准训练——可能将其分类为需要处理的异常。由此产生的执行器指令，是两个单独正确但未共享参考框架的推理的产物。没有任何单条日志记录了驱动这一结果的跨智能体解读差距。

在照护场景中，同样的动态适用于临床推理链。分诊智能体的输出传递给照护协调智能体后，可能产生两个智能体单独均不会生成的照护路径建议，且没有任何临床医生对其整体进行过审查。每个单独步骤都是合适的，组合后的输出却并非如此。

问责扩散

当组合流水线产生有害结果时，因果链是真实存在的，却是分散的。协调智能体调用了子智能体；子智能体依据协调智能体的指令行动；指令是对任务描述的合理解释；任务描述经过运营方授权；伤害产生于所有这些步骤的交汇处，而每一个步骤单独来看都没有错误。

现有问责框架并非为这种结构而设计。它们将责任分配给智能体或部署它们的运营方，而不分配给流水线配置本身——即将这些智能体以这种顺序、这种信息流连接在一起的组合决策。在组合被视为一项需要明确授权的行为之前，流水线层面的问责缺口将持续存在于结构层面。

设计应对

解决组合问题，需要将流水线作为独立的授权界面来对待。组合流水线应携带明确的组合契约：声明其接受什么输入、产生什么输出、这些输出代表什么组合权限，以及谁授权了这一组合。该契约应在部署时由组装流水线的权威机构签名，而非由各组件智能体单独签名。

硬件根植的证明在这里以特定方式发挥作用。如果流水线中的每个智能体都必须提供经证明的身份，则组合可以被追溯：每个步骤都有签名的溯源记录，证明哪个智能体产生了哪个输出。流水线运行的端到端追踪因此成为一条签名记录链，而非一组独立日志。重建所发生的事情成为可能，不是因为任何单个智能体记录得足够仔细，而是因为组合协议在每次交接时强制执行了可追溯性。

这一洞察令人不安，但至关重要：安全性在默认情况下不具有组合性。单个智能体可以被正确限定范围、经过证明并受到治理，但它们的组合仍可能是不安全的。将组合视为一项授权行为——要求明确的契约、端到端的追踪和流水线级的范围审查——是弥合这一缺口的架构步骤。而在实践中，这也是大多数多智能体部署尚未采取的步骤。