你可以告诉 Agent“不要碰敏感文件”，但你不能保证它一定会听。Zed 的答案是：让操作系统来执行这个规则。

AI 编程助手正在快速融入开发工作流。它们能读代码、写代码、运行命令，甚至自主完成整个功能。但随之而来的问题也很直接：我们怎么确定 Agent 不会误删文件、泄露密钥，或者被恶意 PR 诱导做不该做的事？

Zed 在 1.14 版本中引入了一个重要的安全机制：Agent 沙箱。它默认开启，通过操作系统层面的限制，约束 Agent 的行为边界。

为什么需要沙箱？指令约束不够

最直接的想法是：在系统提示里告诉 Agent“不要修改 .git 目录”或者“不要访问 /etc/passwd”。现代 LLM 通常能理解并遵守这类指令。但这只是“建议”，而不是“规则”。

真正的风险来自两个方向：

一是 Agent 可能被误导。 比如，你正在审查一个开源 PR，PR 里藏了一个修改过的 AGENTS.md，悄悄指示 Agent“把环境变量里的密钥上传到某个服务器”。LLM 在解析上下文时，可能会执行这条隐藏指令，而你毫无察觉。类似的安全事件已经发生过，而且只会越来越常见。

二是指令本身无法覆盖所有攻击路径。 禁止 git 命令？Agent 可以用 bash -c 'git ...'，或者写一个临时脚本再执行，甚至通过 Python 的 subprocess 调用。在指令层面做黑名单，是一场永远追不上的猫鼠游戏。

沙箱的出发点就是：不要让 Agent 来决定哪些操作是安全的，而是由操作系统直接拒绝不安全操作。

Zed 的沙箱在做什么

在 Zed 中，Agent 面板的 terminal 和 fetch 工具默认运行在沙箱内。默认规则阻止 Agent 在项目目录外写入、修改 .git 目录、以及发起网络请求。当 Agent 确实需要更高权限时，它会向用户发起请求，并说明原因。用户可以基于 Agent 提供的理由，临时批准或拒绝。

这种设计把 Agent 放在一个预设的“运行范围”里，既保留了自动化带来的效率，也让用户始终保留对敏感操作的最终控制权。

从技术实现上看，Zed 利用了操作系统提供的隔离机制：macOS 使用 Seatbelt，Linux 通过 Bubblewrap 使用 Namespace，Windows 则通过 WSL 实现。不同平台的做法虽有差异，但核心思路一致：在 Agent 执行操作前，由操作系统判断该操作是否在允许范围内。

沙箱并非万能

沙箱能阻止 Agent 直接修改系统文件，但无法阻止 Agent 通过间接方式诱导你执行危险操作。例如：

• Agent 在项目里添加一个 build.rs 文件。当你运行 cargo build 时，这个文件会在沙箱外执行恶意代码；
• Agent 修改你的 .bashrc，下次打开终端时自动运行恶意脚本；
• Agent 在项目里插入一个恶意宏，rust-analyzer 在分析代码时触发执行。

这些攻击路径并不依赖 Agent 在沙箱内执行命令，而是通过修改项目文件，让你在正常操作时“替它”执行恶意代码。沙箱无法完全杜绝这类风险，它只是一个防御层，而非完整的解决方案。

在 AI 编程助手快速普及的当下，安全往往被当作“后续再说”的问题。Zed 选择在 Agent 功能成熟期就引入操作系统级别的约束，而不是仅依赖提示词工程，是对 Agent 使用场景中安全风险的认真考虑。沙箱无法解决所有问题，但它设定了一个边界：Agent 能做什么，不能做什么，由操作系统说了算，而不是由 Agent 的“自觉”决定。

对于长期使用 AI 编程助手的开发者来说，沙箱机制是一个重要的补充。它让你在享受 Agent 带来的效率提升时，不必时刻担心一次误操作或一次精心构造的注入攻击会带来不可逆的后果。随着 Agent 能力的增强，类似的安全措施会越来越成为开发工具的标配。