Anthropic 如何为 Claude 构建安全边界：一篇被忽视的工程实践指南

起因：为什么现在需要聊“如何约束 AI”？

当 AI Agent 从聊天框走向代码执行、文件操作和系统调用时，“安全”就从一个哲学问题变成了迫在眉睫的工程挑战。我们都在谈论“对齐”和“安全”，但具体怎么做？Anthropic 这篇技术概述之所以重要，正是因为它填补了这个空白——它不是谈论理念，而是首次系统性地公开了“我们如何在实际产品中给 Claude 画圈圈”。对于正在构建或集成 AI 应用的开发者来说，这是一份难得的、来自一线的“安全施工图”。

拆解：他们到底用了哪些“笼子”？

Anthropic 的方法核心是“纵深防御”，为不同场景打造不同强度的隔离层。这就像为不同活动修建不同安全级别的场地：

1. Claude.ai（网页版）：使用 gVisor。你可以把它理解为一个“用户态操作系统”，它拦截并模拟程序发出的系统调用，而不是直接交给真正的 Linux 内核。这好比给 Claude 一个高度仿真的“玩具房间”，它在里面可以活动，但所有动作都被翻译和审查，无法触及房间外的真实系统。
2. Claude Code（本地运行）：在 macOS 上使用 Seatbelt，在 Linux 上使用 Bubblewrap。这是更轻量级的“进程级沙箱”。它们直接限制单个进程能访问的文件、网络和系统资源。想象一下，给运行代码的进程戴上“手铐”和“脚镣”，严格规定它只能去特定的地方、做特定的事。
3. Claude Cowork（协作环境）：使用完整的虚拟机（VM）。在 macOS 上用苹果的 Virtualization framework，在 Windows 上用 HCS。这是最高级别的隔离，相当于给 Claude 一个完全独立的“虚拟电脑”。即使这个虚拟电脑被完全攻破，也很难影响到宿主机器和其他用户环境。

这种分层策略非常务实：根据风险等级和性能开销，选择最合适的工具，而不是“一把锤子敲所有钉子”。

趋势洞察：AI 安全的“工程化”和“透明化”

这篇文章揭示了一个更深层的趋势：AI 安全正在从抽象的“RLHF”和“宪法 AI”原则，下沉到具体的、可审计的系统架构和工程实践。当 Agent 能力越强，其破坏潜力就越大，因此“约束”必须内置于其运行的基础设施中，成为默认属性，而非事后补救。

更值得注意的是 “透明化”。Anthropic 主动公开了自己安全架构的细节，甚至包括曾经犯过的错误（如文件 API 渗漏漏洞）。这传递了一个强烈信号：在 AI 安全领域，建立信任不能靠黑箱，而需要通过可验证的工程实践。这可能会推动行业形成新的标准——就像云计算时代的安全合规认证一样，未来的 AI 服务可能需要证明其“沙箱”是可信的。

实用价值：开发者能从中获得什么？

对于 AI 应用开发者，这篇概述提供了直接的行动指南：

• 重新评估你的 Agent 架构：你的 Agent 是否在“裸奔”？是否考虑了代码执行、文件访问时的隔离？Anthropic 的方案是现成的参考架构。
• 理解安全权衡：没有完美的方案。gVisor 有性能开销，VM 隔离最强但也最重。你需要根据你的应用场景（是仅聊天，还是执行代码？）选择合适的隔离级别。
• 关注开源工具：文章末尾提到的 srt (Anthropic Sandbox Runtime) 是一个开源工具，它很可能封装了上述部分沙箱能力。对于想在自有环境中安全运行 Agent 的团队，这是一个值得评估的选项。

反常识/意外：安全是一个持续的过程

最让人意外的或许不是他们用了多高级的技术，而是他们坦然承认“我们曾遗漏风险”。例如，攻击者可能通过诱导模型访问 api.anthropic.com/v1/files 这样的端点，将沙箱内的数据渗漏出去。这说明，即使有强大的沙箱，安全仍然是一个需要持续对抗和迭代的“猫鼠游戏”。它打破了“部署一个沙箱就一劳永逸”的幻想，强调了安全监控和漏洞响应机制的重要性。

总而言之，Anthropic 的这篇分享，标志着顶级 AI 公司的安全实践进入了一个新阶段：从隐藏走向开放，从原则走向工程。对于所有身处 AI 浪潮中的从业者，这都是一份不容错过的“内功心法”。

原文地址: How we contain Claude across products