北京
最近，我们发布了 JetBrains Air 云端代理的预览版。云端代理让你在 JetBrains 托管的云环境中远程运行 AI 代理，为它们提供一个隔离的工作场所，而不依赖你的本地机器。
以下是实际效果。在这个视频中，我在 IntelliJ IDEA 中启动一个任务，从浏览器和手机上跟进它，并在任务完成后审查代理所做的更改。
云端代理目前通过 IDE 中的 Air 和浏览器中的 Air Teams 向组织用户开放，面向个人用户的更广泛发布计划在之后。但它们也属于一个更大的问题：当 AI 代理能读文件、执行代码、使用工具、与外部服务交互时，如何安全地运行它们。
在本文中，我将解释代理沙箱的含义、为什么重要、目前有哪些执行选项，以及云端执行如何融入更广泛的沙箱图景。
为什么 AI 代理需要沙箱
给 AI 代理做沙箱，是指在隔离且严格控制的环境中运行代理，限制它能访问哪些资源、允许执行哪些动作。沙箱不是授予对主机系统、网络或敏感数据的无限制访问权，而是在文件、API 和外部服务周围强制执行预定义的边界，同时施加最小权限、资源限制、审计机制和追踪。
这种做法很重要，因为现代 AI 代理能执行代码、使用工具、自主行动，如果代理行为异常或被攻破，会带来非预期的系统改动、数据泄露和漏洞利用等风险。通过将代理限制在明确的安全边界内，沙箱能限制故障或攻击的影响，为在开发、企业和生产环境中部署 AI 代理提供更安全可靠的基础。
运行 AI 代理的五种方式及其安全代价
我们可以识别出启动代理的五种主要场景，可归为两大类：本地和远程。
本地方案共用你的机器。远程方案把代理挪到别处，默认就做了隔离。
本地场景下，代理默认很容易跑出当前工作目录，可能是无意的，也可能是提示注入导致的。它们的文件系统和网络访问可以通过操作系统级沙箱工具来限制（Linux 上的 landrun、macOS 上的 sandbox-exec、Windows 上的 Sandboxie）。但接下来就得靠客户端（也就是用户用来跟代理或 Claude Code、Codex 这类命令行工具交互的程序）去包装启动的代理并执行所需策略。
远程执行默认提供更好的保障：代理环境跟开发者的是隔离的。代理对资源的访问可以通过文件系统和网络控制来限制，影响范围被框住。
这些方式的主要差别在于需要多少手动配置。SSH 主机需要用户自己提供机器，手动配置。Docker 可以由客户端或组织管理员配置。Docker Sandboxes 更进一步，每个代理跑在自己的微型虚拟机里。云方案则应该根据团队或组织管理员定义的设置，自动处理环境配置。
Air 里的云端代理沙箱如何运作
驱动 Air 云端代理的代理核心，走的是 Docker Sandboxes 那套思路。每个任务在云端启动一台虚拟机（微型虚拟机即将支持），代理跑在这台虚拟机里的 Docker 容器中。这台虚拟机被视为不可信：任务之间不复用，只允许访问有限的内部资源。虚拟机里设了一个代理服务器，代理容器的所有连接都经过它路由。
默认情况下，这个代理服务器只允许连接到预设的可信源代码管理和包注册域名列表，比如 npm。你可以为自己的工具链、包管理器或内部服务添加域名，也可以允许所有域名，或者完全关闭互联网访问。
密钥加密存储，以环境变量的形式暴露给任务。队友可以共用一个密钥而看不到它的值，个人密钥保持私密。每个任务还在开发者自己的仓库权限范围内行动，所以它永远看不到开发者本来就访问不了的仓库。
代理在哪跑，和它能干什么一样重要
代理沙箱正在成为安全使用 AI 代理的重要一环。随着代理能力更强、更自主，问题不再只是它们能做什么，还包括它们在哪跑、能访问什么、出事时能造成多大影响。
云端执行是一种默认提供更强隔离、减少本地配置需求的方式，也让组织对网络访问、环境配置和任务执行策略有更多控制权。
在组织里工作的开发者，已经可以在 JetBrains IDE 的 Air 和浏览器里的 Air Teams 中试用云端代理。
有问题或反馈？在 X 上 @getsome_air 联系我们——Dennis 和 Air 团队会阅读并回复提及。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
