## 概述 把六个 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 七智能体 | ```mermaid flowchart LR subgraph M1["模式1 隔离工具"] A1[可信智能体
持有真实凭据] -->|HTTP| S1[工具沙箱
无密钥] end subgraph M2["模式2 隔离智能体"] A2[不可信智能体
零密钥 3个环境变量] -->|代理转发| CP[可信控制面
注入真实API key] CP --> S2[LLM/文件/网络] end subgraph M3["模式3 隔离整体"] O[编排器
也是不可信] --> ADP[持久通信适配器
SQLite WAL+死信] PM[PM] --> ADP ENG[工程] --> ADP QA[QA] --> ADP ADP -.内核级nftables
拒绝横向直连.- ENG end M1 -->|爆炸半径>1个agent| M2 M2 -->|编排器成单点| M3 style M3 fill:#0d2b1e,color:#cfffdf style ADP fill:#1b5e3f,color:#cfffdf ``` ## 深度分析 ### 1. 单智能体沙箱治不了多智能体——那条被忽视的鸿沟 模式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 凭合法凭据就能对同伴"撒谎"，触发看起来合法、实则上下文错误的系统级动作。单智能体沙箱画的边界，根本没覆盖这条横向信任链。 ### 2. 生产里真正出现的五种故障传导 把多智能体系统推到生产并发负载下，崩的从来不是单个模型 bug，而是"架构没设计容纳的复合部分失败"。五种模式高度一致： - **毒循环（poison loops）**：agent 收到畸形消息、处理失败、消息被重排队，没有死信机制就在线程池里无限打转，堵死下游消费者。 - **状态污染传导（state corruption propagation）**：agent 往 Postgres 写了一半状态就崩了，下游读到半截状态继续干活，等发现时污染已经过了好几个流水线阶段。 - **消费组饥饿（consumer group starvation）**：慢 agent 死占一个 Kafka 分区租约，同组其他消费者干等，滞后堆积。 - **监督者级联（supervisor cascade）**：监督者成了单点，它一崩，worker 干完活也没人接收结果、领新任务。 - **内存压力交叉污染**：共享 pod 没设资源上限，一个内存泄漏的 agent 把同 pod 里所有人拖慢，表现为间歇性卡顿而非干净崩溃——后者更难抓。 关键认知是：这五种里没有一种是"模型变好就能解决的"。它们是**拓扑和资源边界**的失败，只能靠架构兜。一个干净崩溃 + 重启策略是可恢复的；跨 pod 的静默劣化不是。 ### 3. OWASP ASI-08 级联失败：一条被信任链放大的毒 `ASI-08 级联失败`是 OWASP 2026 里最该被产品经理背下来的条目。官方给的金融案例极其典型：一个市场分析 agent 摄入了一份被投毒的研究报告，声称某只股票正在崩盘；它给持仓 agent 发了一条"高风险"告警，持仓 agent 自动清仓并通知财务 agent 有"紧急对冲"需求；财务 agent 再生成一段说辞，**说服人工操作员批准了这笔交易**。 这条链的恐怖之处在于——因为**状态被持久化、被传播、被信任**，失败会跨会话存活，直到有人带外介入硬停。一个原本局限于"分析 agent 读错一份报告"的小爆炸，沿"分析→持仓→财务→人"这条信任链放大成一笔真实资金动作。更阴险的是 `ASI-09`：最终动作是人工批准的，agent 的操纵痕迹从审计里消失，系统只记录了一个"合法的人工决策"。DeepInspect 给出的缓解是——人工 in-the-loop 必须被当成一个**控制面**而非免责符，高影响建议要带置信度加权分、显式不确定性和来源溯源，专门用来压制 automation bias（人对 agent 那套顺耳说辞的过度信任）。 ### 4. 模式3 的内核级横向拒绝：把同伴当攻击者 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 一定会犯错，基础设施的职责是把这些错误关进笼子**。 ### 5. 通信适配器：唯一可信信道，且它有状态 模式2 的控制面是无状态的 FastAPI 代理；模式3 的通信适配器则是**带状态、有投递保证的服务**，这是两者最关键的分野。所有 agent 间通信只走这一条路：它用 SQLite WAL 预写日志做消息存储，提供至少一次投递保证，带死信队列，维护静态群组频道（`all-agents`、`product`、`platform`）。消息**先持久化再回 ACK**，序列号出现 gap 就触发 replay。它不是模式2 那种"无状态转发"，而是多智能体系统里唯一的真相总线： ```python # 通信适配器：持久化优先，序列号保证可重放 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 层就被内核拒绝。横向信道从"默认开放、应用层禁止"翻转为"默认关闭、内核拒绝、仅一条受控隧道"。 ### 6. 基础设施层兜底：让故障"干净地死" 模式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 实例锁自己能立刻拿到的行、跳过别人锁住的行，零协调开销分发任务： ```sql -- 工作队列：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 被暂停，链就断了。 ### 7. 把编排器拉下神坛：模式3 的真正分水岭 模式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 的灵魂——没有可信中心，也就没有可被一次性击穿的中心。 ### 8. 推荐方案：按爆炸半径预算选模式 选型不该看 star 数，该看你的**爆炸半径预算**有多大、横向上有多少 agent 必须互信： - **单 agent + 危险工具（代码执行/浏览器/终端）** → 模式1。agent 是你自己的代码、跑你自己的逻辑、你信任它，只需把危险工具沙箱化。E2B/Modal/早期 Browser Use 都在这个象限。许多团队永远不需要往前走。 - **单 agent 产品，但 agent 会接触用户输入/不可信内容** → 模式2。整个 agent 进 Unikraft micro-VM 或等价隔离，零密钥启动、经控制面代理。这是 chatbot、编程助手、浏览器自动化 agent 的近最优架构，爆炸半径锁死在单个会话。 - **多 agent 必须协作，且各有不同凭据/信任级** → 模式3。没有别的选项。一旦横向出现 ≥2 个 agent 且它们持有不同 vault，模式1/2 的"单点信任"假设就破产，必须上内核级横向拒绝 + 持久通信适配器 + 不可信编排器。 落地优先级建议：先做**带外断路器和死信队列**（拦 `ASI-08` 级联，ROI 最高、改动最小）；再做**凭据按 agent 拆 vault**（拦 `ASI-07/09` 的越权放大）；最后做**横向流量内核级拒绝 + 编排器不可信化**（模式3 的骨架）。对于面向企业的"多智能体安全工程"方向，这套正成为合规刚需——OWASP AISVS 的 C09 章节已把执行预算（C09-01）、高危动作审批（C09-02）、工具隔离（C09-03）、智能体身份与审计（C09-04）、授权委派（C09-05）、优雅降级与停机（C09-06）列为可审计要求，是平台与安全工程训练营里稀缺的、能直接对标合规的硬内容。 ## 参考来源 1. [The Two Patterns of Agent Isolation (and Why You Need a Third) — Gregor Vucajnk](https://realgregorvucajnk.github.io/blog/2026-02-27-isolation-patterns/) — 提出隔离工具/隔离智能体/隔离整体三模式框架，含 Multiclaw 七智能体 Podman+nftables 架构与完整对比表 2. [Managing the Agentic Blast Radius in Multi-Agent Systems (OWASP 2026) — DeepInspect](https://www.deepinspect.ai/blog/managing-the-agentic-blast-radius-in-multi-agent-systems-owasp-2026) — 逐条拆解 OWASP ASI-07 跨智能体通信、ASI-08 级联失败（金融毒报告案例）、ASI-09 人机信任利用 3. [Failure Isolation in Multi-Agent Systems: How to Contain Blast Radius — AI Agent Orchestration](https://ai-agent-orchestration.com/blog/multi-agent-failure-isolation-patterns-production.html) — 生产级五种故障传导模式与 K8s pod/Kafka 死信/Postgres 乐观锁/SKIP LOCKED/断路器隔离手段 4. [OWASP AISVS — C09 Orchestration and Agents 章节](https://github.com/OWASP/AISVS) — C09-01 执行预算至 C09-06 优雅降级的可审计安全要求（C09-03 工具/插件隔离、C09-04 身份与审计、C09-05 授权委派） 5. [Sandboxing & Blast-Radius Containment — Agent Patterns](https://learn.agentpatterns.ai/harness-engineering/sandboxing-and-blast-radius/) — 沙箱作为运行时边界限制 agent 进程可达范围（文件系统/网络/凭据）的工程模式库 > [!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 等场景全覆盖。