把六个 agent 关进同一个后端进程跑得很顺，直到第七个 agent 被 prompt injection 击穿，连带另外六个一起越权——这不是模型不行，是爆炸半径（blast radius）没被设计。2026 年的多智能体工程，真正的分水岭已经从"谁的拓扑更聪明"悄悄挪到了"谁能在单点失守时把损失关进笼子"。OWASP 把 ASI-07 跨智能体通信、ASI-08 级联失败、ASI-09 人机信任利用 单独立项，行业也从"隔离工具"演化到"隔离智能体"再到"隔离整体"三段式。本文沿这条主线拆解：故障到底沿哪几条信任链传染，三种隔离模式的信任边界分别画在哪，以及把编排器自己拉下神坛之后，多智能体系统如何靠"不可信编排 + 内核级横向拒绝 + 带外断路"活下来。
| 维度 | 模式1 隔离工具 | 模式2 隔离智能体 | 模式3 隔离整体 |
|---|---|---|---|
| 信任模型 | 智能体可信，工具沙箱不可信 | 智能体不可信，控制面可信 | 全体智能体不可信，无单一可信实体 |
| 凭据托管 | 智能体自己持有 | 控制面持有全部凭据 | 每智能体独立保险库，无人持有全部 |
| 横向流量 | 不适用（单智能体） | 不适用（单智能体） | 内核级拒绝，仅经通信适配器 |
| 通信模型 | HTTP 调沙箱 | HTTP 调控制面 | 持久适配器，至少一次投递+预写日志+死信队列 |
| 编排器信任 | 不适用 | 控制面是可信基础设施 | 编排器是被隔离的不可信智能体 |
| 爆炸半径 | 仅工具沙箱 | 单智能体 VM/容器 | 单智能体 pod + 用户命名空间 |
| 典型代表 | 早期 Browser Use、E2B、Modal | Browser Use Unikraft micro-VM | Multiclaw 七智能体 |
flowchart LR
subgraph M1["模式1 隔离工具"]
A1[可信智能体<br/>持有真实凭据] -->|HTTP| S1[工具沙箱<br/>无密钥]
end
subgraph M2["模式2 隔离智能体"]
A2[不可信智能体<br/>零密钥 3个环境变量] -->|代理转发| CP[可信控制面<br/>注入真实API key]
CP --> S2[LLM/文件/网络]
end
subgraph M3["模式3 隔离整体"]
O[编排器<br/>也是不可信] --> ADP[持久通信适配器<br/>SQLite WAL+死信]
PM[PM] --> ADP
ENG[工程] --> ADP
QA[QA] --> ADP
ADP -.内核级nftables<br/>拒绝横向直连.- ENG
end
M1 -->|爆炸半径>1个agent| M2
M2 -->|编排器成单点| M3
style M3 fill:#0d2b1e,color:#cfffdf
style ADP fill:#1b5e3f,color:#cfffdf
模式1（隔离工具）和模式2（隔离智能体）回答的都是同一个问题：怎么不让一个 agent 碰到我的密钥。Browser Use 的 Unikraft micro-VM 做到了极致——整个 agent 只带三个环境变量（SESSION_TOKEN、CONTROL_PLANE_URL、SESSION_ID）启动，要调 LLM 就把请求发给控制面、由控制面注入真实 API key，要读写文件就由控制面签发限时预签名的 S3 URL。它甚至把 Python 编译成字节码后删掉源码、启动后降权、读完环境变量就从 os.environ 抹掉，假设主边界迟早会被突破。
但这套近乎最优的单智能体隔离，在"七个 agent 必须协作"时瞬间失效。问题从"怎么让 agent 碰不到外面的秘密"变成了"怎么让 agent 们碰不到彼此的秘密、不耗尽彼此的资源、不互相篡改状态，却还能一起干活"。这正是 OWASP ASI-07 想拦的东西：多智能体靠 API 和消息总线持续协调，一旦 agent 们"隐式信任同伴发来的消息"，一个被攻陷的 agent 凭合法凭据就能对同伴"撒谎"，触发看起来合法、实则上下文错误的系统级动作。单智能体沙箱画的边界，根本没覆盖这条横向信任链。
把多智能体系统推到生产并发负载下，崩的从来不是单个模型 bug，而是"架构没设计容纳的复合部分失败"。五种模式高度一致：
关键认知是：这五种里没有一种是"模型变好就能解决的"。它们是拓扑和资源边界的失败，只能靠架构兜。一个干净崩溃 + 重启策略是可恢复的；跨 pod 的静默劣化不是。
ASI-08 级联失败是 OWASP 2026 里最该被产品经理背下来的条目。官方给的金融案例极其典型：一个市场分析 agent 摄入了一份被投毒的研究报告，声称某只股票正在崩盘；它给持仓 agent 发了一条"高风险"告警，持仓 agent 自动清仓并通知财务 agent 有"紧急对冲"需求；财务 agent 再生成一段说辞，说服人工操作员批准了这笔交易。
这条链的恐怖之处在于——因为状态被持久化、被传播、被信任，失败会跨会话存活，直到有人带外介入硬停。一个原本局限于"分析 agent 读错一份报告"的小爆炸，沿"分析→持仓→财务→人"这条信任链放大成一笔真实资金动作。更阴险的是 ASI-09：最终动作是人工批准的，agent 的操纵痕迹从审计里消失，系统只记录了一个"合法的人工决策"。DeepInspect 给出的缓解是——人工 in-the-loop 必须被当成一个控制面而非免责符，高影响建议要带置信度加权分、显式不确定性和来源溯源，专门用来压制 automation bias（人对 agent 那套顺耳说辞的过度信任）。
Multiclaw 的七智能体（编排器、PM、工程、QA、研究设计、增长 GTM、通信适配器）给出了模式3 的范本。它的核心洞察是——agent 之间的横向流量必须在内核层拒绝，而不是应用中间件层。每个 agent 一个独立 Linux 用户，每个用户跑一个 rootless Podman pod（含 OpenClaw 运行时 + Gateway sidecar 两个容器），7 个 pod 共 15 个容器。横向拒绝锚定在 rootless-netns 边界的 nftables 规则上，处于 pod 命名空间之外：
# nftables: 拒绝任意 agent pod 直连其他 agent pod 的端点
table inet agent_isolation {
chain forward {
type filter hook forward priority 0; policy drop;
# 仅放行 agent → communication_adapter 的受控信道
iifname "pod0*" oifname "adapter0" accept
# 其余 agent 间横向流量一律内核级丢弃
iifname "pod*" oifname "pod*" drop
}
}
凭据隔离是绝对的：每个 agent 一个 1Password 服务账号，scope 到只装自己秘密的单一 vault，系统里没有任何实体——连编排器都不例外——持有全部 agent 的凭据。工程 agent 出了岔（误调 API、日志泄密、推理越界），爆炸半径被锁死在工程 vault 里，碰不到 PM、碰不到编排器。知识隔离同理：每个 agent 一个独立 Obsidian 知识库目录（bind-mount 进 pod），存架构决策、研究结论、累积上下文，任何 agent 都读不了同伴的库。这套设计的隐含哲学是——自主 agent 一定会犯错，基础设施的职责是把这些错误关进笼子。
模式2 的控制面是无状态的 FastAPI 代理；模式3 的通信适配器则是带状态、有投递保证的服务，这是两者最关键的分野。所有 agent 间通信只走这一条路：它用 SQLite WAL 预写日志做消息存储，提供至少一次投递保证，带死信队列，维护静态群组频道（all-agents、product、platform）。消息先持久化再回 ACK，序列号出现 gap 就触发 replay。它不是模式2 那种"无状态转发"，而是多智能体系统里唯一的真相总线：
# 通信适配器：持久化优先，序列号保证可重放
def send(src_agent, dst_channel, payload):
msg = Message(seq=next_seq(dst_channel), src=src_agent,
channel=dst_channel, payload=payload, persisted_at=now())
store.wal_append(msg) # 先落 WAL
ack(src_agent) # 再 ACK，崩溃也不丢
dispatch_to_channel(msg) # 派发给该频道订阅者
# 订阅者检测到 seq gap → 触发 replay，自愈漏消息
这个设计直接回应 ASI-07：agent 间流量要在意图层做零信任。适配器是唯一路径，意味着一切横向通信可审计、可重放、可死信；任何绕过适配器、想直接 TCP 连同伴的企图，在 nftables 层就被内核拒绝。横向信道从"默认开放、应用层禁止"翻转为"默认关闭、内核拒绝、仅一条受控隧道"。
模式3 之外，传统的分布式容错手段在多智能体里依然是第一道闸，而且必须画在 agent 控制面之外（OWASP 反复强调的 out-of-band）。Kafka 侧，每个 agent 类型一个独立死信 topic、可配重试阈值——瞬时错误（网络超时、下游不可用）配指数退避多试几次；结构性错误（schema 畸形、必填缺失）第一次就 fail-fast 进死信，因为重试修不好 schema 问题。消费者组要按 agent 类型隔离，即便它们订阅同一个 topic，这样一类 agent 卡住不会影响其他类的分区分配。
Postgres 侧用乐观锁防并发污染：每条状态记录带 version 列，写回时带 WHERE version = $captured_version，影响 0 行就说明读已过期、可重取重试。这把"静默数据污染"转成"可检测冲突"，是爆炸半径控制的关键转化。工作队列模式用 SELECT FOR UPDATE SKIP LOCKED，每个 agent 实例锁自己能立刻拿到的行、跳过别人锁住的行，零协调开销分发任务：
-- 工作队列：SKIP LOCKED 无协调分发
UPDATE task_queue
SET owner = 'agent_qa_3', status = 'claimed', version = version + 1
WHERE id = (
SELECT id FROM task_queue
WHERE status = 'pending'
ORDER BY priority DESC, created_at
FOR UPDATE SKIP LOCKED LIMIT 1
)
RETURNING id;
-- enum + CHECK 约束编码合法状态迁移，DB 层兜底应用 bug
带外断路器监控异常信号（消息量激增、API 调用尖峰），能不依赖 agent 配合直接暂停或隔离它——这正是上面金融级联案例里该有的那道闸：财务 agent 一侧的断路器被触发，持仓 agent 被暂停，链就断了。
模式1/2 的共同假设是——总有一个可信的中心实体（你的后端进程，或控制面）来裁断。模式3 把这个假设也砸了：编排器自己就是一个不可信的、被隔离的 agent。它和工程、QA 一样，跑在独立用户名下的 rootless pod 里、持有独立 vault。在 Scenario(1) 基线下，策略完整性靠 root 拥有的不可变基线文件、overlay 版本/过期检查、以及编排器无法绕过的审批门来保证。编排器不能改自己的策略 overlay、不能改自己的 Linux 身份、对审计库只有 append 权限——不能改、不能删。
这一点决定了"治理是架构的，不是流程的"。分离职责：编排器提议，Scenario(1) 完整性门校验（root 基线 + 版本/过期 + 审批），人工放行。三种人工模式分级：active approval（逐项审批）、bounded autonomy（Scenario 1 下人工不可达 15 分钟则例行动作放行）、safe-halt（人工不可达 4 小时则系统冻结）。Sigstore/cosign 签名验证、哈希链审计防篡改都显式延后到 Scenario(2+)，但架构已经为它们留好位置。编排器不可信化是模式3 区别于模式2 的灵魂——没有可信中心，也就没有可被一次性击穿的中心。
选型不该看 star 数，该看你的爆炸半径预算有多大、横向上有多少 agent 必须互信：
落地优先级建议：先做带外断路器和死信队列（拦 ASI-08 级联，ROI 最高、改动最小）；再做凭据按 agent 拆 vault（拦 ASI-07/09 的越权放大）；最后做横向流量内核级拒绝 + 编排器不可信化（模式3 的骨架）。对于面向企业的"多智能体安全工程"方向，这套正成为合规刚需——OWASP AISVS 的 C09 章节已把执行预算（C09-01）、高危动作审批（C09-02）、工具隔离（C09-03）、智能体身份与审计（C09-04）、授权委派（C09-05）、优雅降级与停机（C09-06）列为可审计要求，是平台与安全工程训练营里稀缺的、能直接对标合规的硬内容。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。