JetBrains Air 接上 Copilot：云任务先查这 4 个限制

2026 年 11 月 3 日，GitHub 宣布 GitHub Copilot 正式接入 JetBrains Air。现在，用户可以在 Air 中委派编码任务、引导执行过程并检查结果，既能调用 JetBrains IDE 内的项目上下文，也能把任务交给云端运行。

这次更新值得马上关注，不只是因为 Air 多了一个智能体入口，而是 Copilot 云任务开始使用用户已有的 GitHub Copilot 订阅，而不是消耗 JetBrains AI credits。不过，它并不等于 Copilot 被完整纳入 Air 的管理体系：订阅检查、套餐归属、用量可见性和管理员控制仍有限制。

下文凡涉及官方明确说明的内容，均来自 GitHub 或 JetBrains 原文；涉及兼容性、适用范围和管理成本的内容，会明确标为分析或推算。

Air 增加了什么，不只是多一个模型入口

GitHub 与 JetBrains 公布的集成采用 Agent Client Protocol，也就是 ACP：一种让智能体客户端连接编码代理的统一通信协议。对普通用户来说，最实际的变化是 Copilot 可以进入 Air 的工作流，使用 IDE 工具、项目上下文，并支持同时跟踪多个智能体会话。

这张表揭示了更新后的核心变化：同一个 Air 界面可以管理本地任务和云任务，但两类任务所在环境完全不同。云端任务不会直接改动本机环境；本地任务则能结合当前 IDE 中的项目内容和工具。

JetBrains 在 2026 年 7 月公布的 Air 更新中已经提到 Copilot、OpenCode、Pi、Cline 等 ACP 兼容智能体。GitHub 这次公告带来的增量，是 Copilot 在 Air 中不仅能承担本地代理工作，还通过 Air Teams 支持云端任务，并明确采用 Copilot 套餐而非 JetBrains AI credits。

因此，如果团队已经统一使用 GitHub Copilot，Air 可以继续作为并行代理与结果审查界面；如果团队本来就依赖 JetBrains AI 额度，也不能因为出现了 Copilot 选项，就假设所有任务都会自动改用 Copilot。

云任务的隔离方式，改变了代码修改的边界

根据 GitHub 的说明，Copilot 云任务在全新虚拟机中的 Docker 容器里运行。全部流量经过代理，任务之间不保留状态。Copilot 可以在隔离环境中构建代码、运行测试和安装软件包，而不会修改开发者的本地环境。

这带来两个直接好处。第一，依赖安装和构建过程不会把本机环境搅乱；第二，多个任务之间不共享运行状态，可以并行探索不同方案。对于大型仓库、依赖较多或需要反复跑测试的项目，这种隔离方式比让代理直接在本地目录中自由操作更容易控制风险。

但“不会修改本地环境”不等于“结果会自动安全地回到本地”。任务产物仍需经过检查、比较和接受流程。GitHub 的公告提到 Air 支持并行工作与上下文内审查，却没有承诺自动合并、自动提交或自动创建拉取请求。因此，以下 YAML 可以作为个人或团队的任务验收清单：

task_acceptance:
  environment: isolated_cloud
  review_required:
    - generated_code
    - dependency_changes
    - test_results
  apply_to_local:
    - inspect_diff
    - run_local_tests
    - approve_changes
  automatic_merge: false

这里的 automatic_merge: false 是根据官方功能描述作出的保守配置建议，并非 JetBrains 或 GitHub 提供的官方设置项。隔离环境解决的是执行污染问题，不能代替代码审查，也不能证明云端生成的修改适合直接进入生产分支。

本地与云端任务怎么选

本地任务需要先在 JetBrains IDE 中安装 Air，然后选择 GitHub Copilot，再连接已有的 GitHub Copilot 账户。云端任务的门槛更高：用户需要加入启用了 Air Teams 的 JetBrains 企业组织、拥有 GitHub Copilot 订阅，并且管理员已为 Air 启用 Copilot。

云端任务可以从浏览器中的 Air 发起，也可以在 IDE 的 Air 插件里把环境选为 Cloud。浏览器路径要求在 Settings > VCS Providers 中连接 GitHub，然后选择仓库和远程分支，再指定 GitHub Copilot 并发送任务。

这是我根据官方入口条件做出的边界推导：个人拥有 Copilot 订阅，不等于个人已经具备 Air 云任务资格。Air Teams 企业组织和管理员开关是两个额外条件，而浏览器、IDE 两种入口最终使用同一种 Copilot 云任务能力。

上线前必须确认的 4 个管理限制

GitHub 在公告中集中列出了四项限制。第一，连接 Copilot 时不会立即请求 GitHub Copilot 权限；Air 只有在云环境启动时才检查订阅或额度可用性。若订阅或额度不可用，任务会失败，并在会话中显示错误。这意味着“账号已经连上”不能证明“下一次云任务一定能启动”。

第二，用户不能为单个任务选择使用个人 Copilot 套餐还是组织套餐。Air 会使用 Copilot 套餐，而不是 JetBrains AI credits，但个人与组织之间如何选择，官方明确表示无法由单个任务决定。

第三，Air 的治理和分析功能不包含 Copilot 使用量。因此，即使管理员可以在 Air 中看到 Air 自身的活动，也不能假定 Air 会提供完整的 Copilot 用量分析。第四，Air 管理员能够通过治理策略禁用 GitHub Copilot，却不能在 Air 内设置 Copilot 消费上限。

这四项限制意味着 Air 更像 Copilot 的任务执行界面，而不是完整的 Copilot 治理后台。团队若准备大规模启用，最该先解决的不是“每个人会不会安装插件”，而是订阅归属、额度监控和禁用策略由谁维护。

这次集成适合谁，落地前还要确认什么

对于已经统一使用 GitHub Copilot 的团队，这次更新最有价值的地方，是可以把 IDE 上下文、多个并行代理和云端隔离执行放进同一套 JetBrains 工作流。个人开发者也能借此减少直接让代理在本地目录中构建、安装依赖的场景。

不过，Air Teams 的组织要求是明确的采用门槛。云端路径不应被描述成“安装 Air 后人人立即可用”；它至少依赖企业组织、Copilot 订阅和管理员启用三项目件。若企业尚未使用 Air Teams，现阶段应先验证本地任务，不要把云端并行执行写进近期交付承诺。

这也带来一个反方判断：Copilot 能进入 Air，并不意味着 JetBrains AI credits 失去价值。Air 仍提供自己的本地模型、Java 与 Kotlin 代码智能，以及其他 ACP 兼容智能体。企业真正需要决定的不是“Copilot 是否取代 Air”，而是哪些任务交给已获批准的 Copilot，哪些任务继续由本地模型或其他代理完成。

如果准备试用，可先选一个依赖清楚、测试命令稳定的仓库，通过浏览器或 IDE 各创建一次云任务，观察订阅检查、代理执行和结果审查的完整路径。随后在本地重跑测试，并比较生成改动，而不是直接接受代理结果。若最终要启用，还要到 GitHub 一侧确认套餐与消费控制，因为 Air 本身既不展示完整 Copilot 用量，也不能设置其消费上限。

参考来源

• GitHub Copilot is now available in JetBrains Air – GitHub Changelog

• GitHub Copilot is now available in JetBrains Air：GitHub 于 2026 年 11 月 3 日发布的功能说明，包含本地与云端任务入口、执行环境、订阅及管理限制。

• What’s new: Air gets more agents, local models, and Java/Kotlin code intelligence：JetBrains 对 ACP 智能体支持、Copilot CLI 连接方式及 Air 能力的介绍。

• The Air Blog：Agentic AI：JetBrains Air 智能体相关更新的官方汇总。

• GitHub Copilot IntelliJ 插件反馈仓库：GitHub 提供的 Copilot IntelliJ 插件反馈渠道。