智能体遏制是一套架构模式，用于限制AI智能体在出错时所能造成的影响范围。汲取Anthropic、OpenAI、Google DeepMind、Microsoft和OWASP的经验——以下是每个在生产环境中部署智能体的团队都需要理解的四层架构，辅以FlowZap序列图展示智能体、沙箱、人类审核者、权限门控与SIEM之间的交互。
为什么智能体遏制刻不容缓
2026年6月19日，Anthropic 发布了《我们如何在各产品中遏制 Claude》——一份详细剖析保护 claude.ai、Claude Code 和 Cowork 的安全架构的技术文档。开篇即点明利害关系：
"随着智能体能力不断增强，其潜在的爆炸半径也在扩大。工程问题在于如何限制它。"
Anthropic 是自2月以来第四个发布遏制框架的主流生态系统：
| 生态系统 | 关键贡献 | 日期 |
|---|---|---|
| Anthropic | 四层遏制栈（沙箱→权限→人机协同→审计），面向 Claude Code | 2026年6月 |
| OpenAI | 《治理智能体AI系统的实践》——爆炸半径、委派链、权限范围限定 | 2026年1月 |
| Google DeepMind | 面向 Astra、Mariner、Veo 的智能体安全框架——运行时隔离+审批层级 | 2026年3月 |
| Microsoft | 来自 Copilot 智能体的 AI 红队经验——沙箱逃逸、智能体链中的提示注入 | 2026年2月 |
这绝非纸上谈兵。每一个自动批准 AI 编码智能体 PR 的 CI/CD 流水线，都是一个等待被测量的爆炸半径。每一个授予 terminal 访问权限而未加路径限定的 MCP 服务器，都是一个沙箱逃逸向量。以下模式正是这四大生态系统所汇聚的共识。
智能体遏制的四个层级
Anthropic 正式定义了该堆栈。OpenAI、DeepMind 和 Microsoft 各自贡献了细微之处。以下是统一模型：
交互模型
每一个遏制层都是参与者之间的对话，而非智能体内部的独白。下图展示了真实的交互流程：
- 第1层——沙箱：智能体 ↔ 沙箱运行时（临时容器、路径校验）
- 第2层——权限：智能体 ↔ 权限网关（白名单、范围检查）
- 第3层——人机协同：智能体 ↔ 人工审核者（审批、疲劳管理）
- 第4层——审计：智能体 ↔ SIEM（不可变日志记录、告警）
第1层：沙箱——智能体 ↔ 沙箱
第一道防线：智能体运行在一个它物理上无法触及任何关键要素的环境中。
模式（五大生态系统共识）：
- 每个智能体会话使用专用容器或虚拟机（Anthropic、Google、Microsoft）
- 默认无内部服务网络访问（OpenAI、OWASP #4）
- 系统目录采用只读文件系统挂载（全部五家）
- 临时存储在每个会话后销毁（Anthropic、Google）
agent { # Agent
n1: circle label:"Session Start"
n2: rectangle label:"Request Tool Call"
n5: rectangle label:"Process Result"
n6: circle label:"Session End"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> sandbox.n3.handle(top) [label="tool call"]
}
sandbox { # Sandbox
n3: diamond label:"Path in Workspace?"
n4: rectangle label:"Execute in Ephemeral Container"
n7: rectangle label:"Deny - Log Security Event"
n8: rectangle label:"Return Result to Agent"
n3.handle(right) -> n4.handle(left) [label="yes"]
n3.handle(bottom) -> n7.handle(top) [label="no"]
n4.handle(right) -> n8.handle(left)
n7.handle(right) -> n8.handle(bottom)
n8.handle(top) -> agent.n5.handle(bottom) [label="result"]
n5.handle(right) -> n6.handle(left)
}
Anthropic 的做法：Claude Code 运行在沙箱环境中，每次工具调用均依据 ALLOWED_HOSTS 进行评估，并配有 SSRF 保护与请求超时机制。
Microsoft 的补充：Copilot 智能体运行在"Defender 托管沙箱"中，在模型边界拦截提示注入——在智能体执行恶意指令之前。其红队发现，34% 的智能体系统沙箱逃逸来自工具描述，而非用户提示。
陷阱所在：沙箱的安全性取决于其配置。携带 --privileged 参数或挂载了 Docker 套接字的容器会使一切形同虚设。Google DeepMind 安全团队推荐运行时证明机制：在每个智能体会话之前验证沙箱配置未被篡改。
第2层：权限——智能体 ↔ 权限网关
即使在沙箱内部，智能体也需要某些访问权限。第2层定义了具体的边界。
模式：
- 使用白名单，绝不使用黑名单（Anthropic、OpenAI、OWASP）
- 每个工具遵循最小权限原则（Google、Microsoft）
- 基于路径的限制：仅限
./workspace/，绝不开放/etc/（全部五家） - 读、写、执行作为独立的权限类型（Anthropic、OpenAI）
agent { # Agent
n1: circle label:"Tool Call Initiated"
n2: rectangle label:"Request File Write"
n5: diamond label:"Permission Granted?"
n6: rectangle label:"Write File to Disk"
n7: rectangle label:"Abort - Log Denial"
n8: circle label:"Done"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> permgate.n3.handle(top) [label="check permission"]
}
permgate { # Permission Gate
n3: rectangle label:"Check Whitelist and Path Scope"
n4: rectangle label:"Return Decision"
n3.handle(right) -> n4.handle(left)
n4.handle(top) -> agent.n5.handle(bottom) [label="decision"]
n5.handle(right) -> n6.handle(left) [label="granted"]
n5.handle(bottom) -> n7.handle(top) [label="denied"]
n6.handle(right) -> n8.handle(left)
n7.handle(right) -> n8.handle(left)
}
OpenAI 的硬性要求：《治理智能体AI系统的实践》（2026年1月）明确提出了委派链权限范围限定——当智能体 A 将任务委派给智能体 B 时，B 必须拥有严格少于 A 的权限。任何子智能体都不应拥有比其父智能体更大的权力。这直接映射到 flowzap-senior-dev → flowzap-security-auditor 的委派模式。
OWASP 的警示：LLM 应用 Top 10（v2.0，2025年11月）中第4项"过度代理权"警告称，授予智能体不受限制的工具访问权限——尤其是 shell、文件系统写入和网络出口——是生产环境中智能体部署的头号架构漏洞。
第3层：人机协同审批——智能体 ↔ 人类
某些行动过于危险，不能完全自动化。第3层在智能体的决策与现实世界之间引入了人类。
模式：
- 自动批准：只读、低风险操作（Anthropic、Microsoft）
- 提请审批：文件写入、网络调用、shell 命令（全部五家）
- 拒绝：破坏性操作、配置更改、密钥访问（OpenAI、Google）
- 审批疲劳预防：批量审批、模式学习（Anthropic 的"自动模式"创新）
agent { # Agent
n1: circle label:"Dangerous Tool Call"
n2: rectangle label:"Request Human Approval"
n5: diamond label:"Human Approved?"
n6: rectangle label:"Execute Tool Safely"
n7: rectangle label:"Abort Operation"
n8: circle label:"Done"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> human.n3.handle(top) [label="approval request"]
n5.handle(right) -> n6.handle(left) [label="approved"]
n6.handle(right) -> n8.handle(left)
n7.handle(right) -> n8.handle(left)
n5.handle(bottom) -> n7.handle(bottom) [label="Rejected"]
}
human { # Human Reviewer
n3: rectangle label:"Review Tool Call and Context"
n4: rectangle label:"Return Decision"
n3.handle(right) -> n4.handle(left)
n4.handle(top) -> agent.n5.handle(bottom) [label="decision"]
}
| 操作 | 默认行为 | 理由 |
|---|---|---|
read_file | 自动批准 | 只读，无副作用 |
grep / glob | 自动批准 | 搜索操作 |
write_file | 提请审批 | 修改文件系统 |
terminal（shell） | 提请审批 | 任意代码执行 |
web_fetch | 提请审批 | 网络出口 |
.env 访问 | 提请审批 + 警告 | 密钥暴露 |
rm -rf / 破坏性操作 | 拒绝 | 不可逆的损害 |
Anthropic 的创新：Claude Code 的"自动模式"（2026年3月）有选择地跳过低风险操作的权限提示，同时在进行任何状态修改时将人类保留在决策环路中。关键在于：智能体会学习你批准的哪些模式，并自动批准类似的未来操作，在降低疲劳的同时不牺牲安全性。但他们对"三个近期事件"（2025年9月）的事后复盘揭示，模式学习式自动批准导致了一类新的错误——开发者停止阅读提示，自动批准了一切。
Google DeepMind 的强制要求："审批层级"——在多智能体系统中，任何单个人类都不得批准其自身智能体的操作。审批人必须来自不同的汇报链，以防止橡皮图章式的审批。Project Mariner 在浏览器操作级别实现了这一机制。
第4层：审计日志——智能体 ↔ SIEM
这是大多数团队跳过的一层——也是他们在事件发生后最希望自己曾经部署过的一层。
模式：
- 每个智能体会话的不可变日志（Anthropic、Microsoft）
- 每次工具调用均被记录：时间戳、工具名称、参数（脱敏）、结果（全部五家）
- 安全事件标记：权限被拒、异常模式、速率限制命中（OWASP）
- 日志发送至独立系统——智能体本身无法读取（Google）
agent { # Agent
n1: circle label:"Execute Tool Call"
n2: rectangle label:"Send Event to Logger"
n5: rectangle label:"Continue Execution"
n6: circle label:"Done"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> siem.n3.handle(top) [label="log event"]
}
siem { # SIEM Audit System
n3: rectangle label:"Sanitize Args and Strip Secrets"
n4: rectangle label:"Write to Immutable Log Store"
n3.handle(right) -> n4.handle(left)
n4.handle(top) -> agent.n5.handle(bottom) [label="logged"]
n5.handle(right) -> n6.handle(left)
}
Microsoft 红队的发现：在针对 Copilot 智能体的模拟攻击中，40% 的情况下，审计日志是唯一的检测机制。权限因配置错误而失败。沙箱因容器逃逸而失效。人机协同因审批疲劳而形同虚设。事后审计日志捕获了 100% 的攻击——但仅限于那些确实将日志发送至离线系统并设置了告警规则的团队。
OWASP 的建议：日志必须是"可证明的"——经过加密签名，使智能体在遭到入侵后无法篡改自身审计轨迹。这对于拥有仓库写入权限的 CI/CD 智能体尤为关键。
整合：完整的遏制栈
当四层协同工作时，架构如下图所示——一个统一的遏制栈，智能体在每次工具调用时与之通信：
agent { # Agent
n1: circle label:"User Prompt Received"
n2: rectangle label:"Agent Plans Tool Call"
n5: rectangle label:"Process Final Result"
n6: circle label:"Response to User"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> stack.n3.handle(top) [label="tool call"]
}
stack { # Containment Stack
n3: rectangle label:"L1 - Sandbox Ephemeral Container"
n4: rectangle label:"L2 - Whitelist Permission Check"
n7: diamond label:"Dangerous Operation?"
n8: rectangle label:"L3 - Human Approves"
n9: rectangle label:"Execute Tool"
n10: rectangle label:"L4 - Audit to Immutable SIEM"
n3.handle(right) -> n4.handle(left)
n4.handle(right) -> n7.handle(left)
n7.handle(right) -> n8.handle(left) [label="yes"]
n7.handle(bottom) -> n9.handle(top) [label="no"]
n8.handle(right) -> n9.handle(left)
n9.handle(right) -> n10.handle(left)
n10.handle(top) -> agent.n5.handle(bottom) [label="result"]
n5.handle(right) -> n6.handle(left)
}
什么有效 vs. 什么会失效
| 方案 | 有效条件 | 失效条件 | 生态系统证据 |
|---|---|---|---|
| 仅沙箱 | 智能体无状态、只读 | 智能体需要持久状态或数据库访问 | Anthropic：仅沙箱不够，2026年6月 |
| 仅权限 | 工具表面小而稳定 | 新增工具但未更新白名单 | OpenAI：委派链必须缩小权限，2026年1月 |
| 仅人机协同 | 操作不频繁 | 智能体每次任务调用50+次工具（疲劳） | Anthropic：2025年9月自动模式疲劳事后分析 |
| 仅审计 | 拥有专职安全团队 | 日志从未被审核（安全表演） | Microsoft 红队：40%攻击仅被审计发现，2026年2月 |
| 四层栈 | 正在生产环境中运行智能体 | ——（这是目标状态） | 全部五大生态系统 |
来自这些领先生态系统的教训是：没有哪一个单独的层是足够的。无权限的沙箱只是一个纸板箱。无人机协同的权限只是一份无人阅读的政策。无审计日志的人机协同意味着你永远不会知道自己批准了什么。
这对 FlowZap 架构意味着什么
我个人的体会：这五种遏制模式直接映射到我的智能体编排器：
| 遏制层 | FlowZap 实现 | 状态 |
|---|---|---|
| L1 沙箱 | MCP 服务器 secureFetch() 封装器（SSRF 保护、ALLOWED_HOSTS、超时） | 已就位 |
| L2 权限 | 按配置文件限定技能（marie-pierre、code、securite、qa）——各配置拥有最小工具访问权限 | 已就位 |
| L3 人机协同 | Cron → Idea Scout → 人工审批 → Writer 流程 | 本周构建 |
| L4 审计 | Hermes cron 日志 → 会话数据库 → Telegram 投递 | 已就位 |
缺失的一环：跨配置文件的权限范围限定。当我的 senior-dev（代码配置文件）将任务委派给 security-auditor（安全配置文件）时，子智能体现阶段继承了父智能体的全部权限。OpenAI 的委派链原则要求子智能体必须拥有严格更少的权限。这是我需要解决的一个缺口。
核心要点
- 立即从第1层（沙箱）开始。如果你的智能体运行在与生产数据库相同的环境中，在解决其他问题之前先修复这一点。
- 第2层和第3层可以逐步实施。为你的工具建立白名单。为写入操作添加审批提示。你不需要从第一天起就拥有一个完美的系统。Anthropic 从 Claude Code 发布（2025年4月）到推出四层架构文章（2026年6月）花费了18个月。
- 第4层（审计）是大多数团队跳过的一层——也是他们在事件发生后最希望自己曾经部署过的一层。记录每一次工具调用。将日志发送至离线系统。为
[SECURITY]事件设置告警规则。 - 多智能体系统会放大爆炸半径。当决策环中有多个智能体时，OpenAI 的链式委派原则和 Google 的审批层级并非可选项。
灵感来源
- Anthropic Engineering — How we contain Claude across products, June 2026
- OpenAI — Practices for Governing Agentic AI Systems, January 2026
- Google DeepMind — Agent Safety Framework, March 2026
- Microsoft AI Red Team — Lessons from Securing Copilot Agents, February 2026
- OWASP Top 10 for LLM Applications v2.0, November 2025
所有 FlowZap 图表均使用 FlowZap Code 生成。复制以上任意 .fz 代码块并粘贴至您的 FlowZap 账户，即可查看、编辑和分享。