GitHub Copilot 正式接入 JetBrains Air，代码任务直接在独立的 Docker 容器里运行，完全不修改本地环境。
这超越了传统 IDE 插件的范畴，直接实现了 Agent 执行环境的物理隔离。对于企业级代码安全管控，云端沙盒意味着数据不落地，直接改变了 AI 编程工具在强合规行业的部署逻辑。
核心看点
- 基于 Agent Client Protocol (ACP)，支持在 JetBrains IDE 或云端并行处理任务。
- 云端任务在隔离的 Docker 容器中运行，流量经代理且无状态保留。
- 直接复用现有 GitHub Copilot 订阅，不消耗 JetBrains AI 积分。
▎云端沙盒的物理隔离机制
当你在浏览器或 IDE 中发起云端任务时，Copilot 会在全新的虚拟机上启动 Docker 容器。所有网络流量强制经过代理服务器，且任务结束后不保留任何状态。开发者可以放心让 AI 构建项目、运行测试、安装各种依赖包，因为这一切都发生在隔离环境中。这种设计允许 Air Teams 成员在云端执行重负载任务，而无需担心污染本地的开发环境。
这种物理隔离机制的适用边界非常明确。对于需要频繁安装依赖、测试不同环境配置的探索性任务，沙盒是完美的，因为搞坏了也不影响本地。但对于需要长期保持上下文、依赖本地庞大数据库或私有硬件驱动的任务，这种“无状态保留”和“隔离”就是灾难。产品经理在评估 AI 编程工具时，必须把任务类型分为“环境敏感型”和“环境无关型”，前者继续用本地插件，后者才推向云端沙盒。
▎企业级管控的盲区与妥协
在企业管理层面，这次集成展现出明显的妥协。连接 GitHub Copilot 到 Air 不会请求额外的 Copilot 权限，系统仅在云环境启动时验证订阅或积分。更关键的是，你无法选择单个任务使用个人计划还是组织计划。Air 的治理和分析功能中，完全不包含 Copilot 的使用数据。管理员可以通过治理策略禁用 Copilot，但无法在 Air 内部设置支出限制。
推导这里的财务与合规风险。企业 CTO 最关心的成本可见性和细粒度控制，在这里是缺失的。Air 看不到 Copilot 的具体使用量，也无法在 Air 内部设置 Copilot 的支出上限。这意味着如果开发者滥用云端任务，比如跑极其消耗算力的死循环测试，企业只能承担超额账单，而无法在 Air 侧进行熔断。财务和 IT 部门在采购前，必须要求 GitHub 提供独立的计费看板，或者在组织层面直接锁死 Copilot 的总预算，绝不能依赖 Air 的治理策略来做成本兜底。
▎落地配置与资源获取
本地任务配置相对简单，只需在 JetBrains IDE 安装 Air 插件，选择 GitHub Copilot 并连接账户即可。云端任务则需要更多前置条件：你需要一个启用了 Air Teams 的商业组织 JetBrains 账户、有效的 GitHub Copilot 订阅，并且需要 Air 管理员在后台启用 Copilot。配置完成后，可以通过浏览器直接访问云端环境，或者在 IDE 的环境选择器中切换到 Cloud 模式。
JetBrains Air 主页：
Agent Client Protocol (ACP) 协议：
GitHub Copilot 插件：
Copilot in JetBrains Air 指南：
Air Alpha 插件下载：
Air 浏览器端入口：
云端沙盒机制说明：
问题反馈仓库：
官方调查问卷：
Agent Client Protocol (ACP) 的推出，说明 AI 编程正在从单点辅助走向分布式执行。JetBrains 和 GitHub 的这次联手，把 IDE 变成了调度器，把云端变成了执行器。对于创业者来说，不要再去卷单纯的代码补全模型，去卷 Agent 的调度协议和沙盒安全机制，这才是下一个企业级市场的入场券。
点个赞再走？
AI 编程工具把本地环境搞崩溃，你遇到过这种事吗？
往期推荐
- ·
- ·82%企业环境存在未知AI Agent，年底渗透率将飙升至40%
- ·百万 Token 长对话，首字生成时间骤降 35%
点击公众号头像 → 历史消息，可翻阅以上文章
