JetBrains Air接入Copilot任务委派

GitHub Copilot 接入了 JetBrains Air：开发者可以在 Air 里分派编码任务、引导执行，并在代码旁审查结果。它通过 Agent Client Protocol（ACP）集成，既支持本地任务，也支持云端任务，使用已有的 Copilot 订阅。

这次更新值得关注的，是任务执行和审查流程多了一个入口。但云端使用有组织与管理员门槛，订阅检查、套餐归属和用量管理也存在限制，不能只看见「接入成功」就默认整套管理能力已经打通。

接入 Air 后，编码流程有什么变化

在 Air 的 agent 选择器中选中 GitHub Copilot，就能把编码任务交给它执行。ACP 是这次集成使用的协议，可以理解为 Air 与编码 agent 对接的通信方式；原文没有展开具体协议实现。

Air 支持同时跟踪多个 agent 会话，结合项目上下文和 IDE 工具工作，并在代码旁查看修改。对开发者来说，重点是能在同一个工作界面里分派任务、跟进过程和检查结果。

原文明确说，Copilot in Air 可以与 GitHub Copilot plugin 搭配使用，按需要选择工作流。不过，这份公告没有提供二者的详细能力对照，也没有给出效率测试。不能据此认定 Air 已经覆盖插件的全部用途。

本地任务的接入步骤很直接：在 JetBrains IDE 中安装 Air，选择 GitHub Copilot，再连接自己的 GitHub Copilot 账号。

云端任务隔离了环境，却没有打通全部管理能力

云端任务通过 Air Teams 运行，消耗 Copilot 套餐，而非 JetBrains AI credits。使用前需要同时满足三个条件：拥有属于已启用 Air Teams 的企业组织的 JetBrains 账号、拥有 GitHub Copilot 订阅，并且 Air 管理员已启用 Copilot。

入口有两个：

• 在浏览器打开 Air，通过 Settings > VCS Providers 连接 GitHub；创建任务后选择仓库、远程分支和 GitHub Copilot，再发送提示词。
• 在 JetBrains IDE 中使用 Air plugin，并在环境选择器中选择 Cloud。

执行时，Copilot 会进入一台全新虚拟机上的 Docker 容器。所有流量经过代理，任务之间不保留状态。它可以构建、测试和安装软件包，不会修改本地环境。

任务环境相互隔离，但任务之间也不会继承状态。

这让云端任务适合需要安装依赖、构建和测试的工作。不过，原文没有说明依赖缓存、环境启动耗时，以及项目所需服务如何配置，暂时无法判断具体项目的准备成本。

计费和治理还有几个容易忽略的边界。连接 Copilot 时，Air 不会请求 GitHub Copilot 权限；订阅或额度是否可用，可能要等云端环境启动时才检查。若不可用，任务会失败，并在会话中显示错误。

单个任务也不能自行选择使用个人套餐还是组织套餐。Air 的治理与分析功能不包含 Copilot 用量；管理员可以通过治理策略禁用 Copilot，但不能在 Air 内设置 Copilot 支出上限。

能控制是否启用，不等于能在 Air 里控制花费。

我的判断

这次接入的价值是明确的：已有 Copilot 订阅的 JetBrains 用户，多了一条在 Air 中分派任务和审查代码的路径；需要云端执行时，也有隔离于本机的环境。

但它是一份功能公告，没有任务成功率、完成耗时或成本对照数据。多会话管理是否能提高团队产出，仍取决于任务能否独立拆分，以及开发者能否及时审查结果，不能把「支持并行」直接当成效率提升的证据。

和继续使用 GitHub Copilot plugin 相比，Air 值得评估的地方是任务组织、执行跟踪和上下文内审查。具体哪个更适合日常工作，原文信息还不足以下定论。

对团队采购和管理来说，限制更实际：Air 中看不到 Copilot 用量，也设不了其支出上限。已有组织预算制度的团队，需要先确认用量核算与管理由哪里承接。

能拿来做什么

• 已有 Copilot 订阅的 JetBrains 用户，可以先接入本地任务，用一项范围明确的代码修改检查分派、执行和审查流程是否顺手。
• 对需要安装依赖、构建和测试的前端或 Node 项目，可以评估云端环境，同时检查任务是否依赖本机配置或上一次任务留下的状态。
• 准备启用云端任务的团队，应先核实 Air Teams 组织资格、Copilot 订阅和管理员开关，避免等环境启动后才发现任务无法执行。
• 有费用管理要求的团队，应先确认套餐归属和用量核算方式，再扩大使用范围，因为 Air 内无法为单个任务选择套餐，也无法设置 Copilot 支出上限。