GitHub Copilot 现已登陆 JetBrains Air

你现在可以在 JetBrains Air 中使用 GitHub Copilot 委派编码任务、引导执行并审查结果。该集成使用 Agent Client Protocol（ACP），并支持在你的 JetBrains IDE 中或云端执行任务。你可以在 Air 中配合 GitHub Copilot 插件使用 Copilot，并选择最适合你的工作流。有关对比与常见问题，请参阅 GitHub Copilot in JetBrains Air。

Air 中的 GitHub Copilot 智能体选择器：选择 GitHub Copilot，并使用你现有的 Copilot 订阅执行编码任务。并行工作与上下文内审查：跟踪多个智能体会话，使用项目上下文和 IDE 工具，并在代码旁审查更改。基于你的 GitHub Copilot 订阅的云端任务：通过 Air Teams，从你的 IDE 或浏览器在隔离的云环境中运行 Copilot。任务使用你的 Copilot 套餐，而不是 JetBrains AI 额度。

对于本地任务，在你的 JetBrains IDE 中安装 Air，选择 GitHub Copilot，并连接你的 GitHub Copilot 账户。对于云端任务，你需要一个位于已启用 Air Teams 的企业组织中的 JetBrains 账户、一个 GitHub Copilot 订阅，以及由你的 Air 管理员启用的 Copilot。

运行云端任务有两种方式：浏览器：在浏览器中打开 Air，在 Settings > VCS Providers 下连接 GitHub，并创建任务。选择你的仓库和远程分支，选择 GitHub Copilot，然后发送你的提示。IDE：在你的 JetBrains IDE 中使用 Air 插件，并在环境选择器中选择 Cloud。

当你通过 JetBrains Air 运行 GitHub Copilot 云端任务时，Copilot 会在全新虚拟机上的 Docker 容器中工作。所有流量都经过代理，任务之间不会保留任何状态。Copilot 可以构建、测试和安装软件包，而不会修改你的本地环境。更多信息，请参阅 Cloud agent sandboxing in Air。

订阅检查：将 GitHub Copilot 连接到 Air 不会请求 GitHub Copilot 权限。Air 可能仅在云环境启动时验证订阅或额度可用性。如果你的订阅或额度不可用，任务将失败，并在会话中显示错误。套餐选择：你无法选择单个任务是使用你的个人 GitHub Copilot 套餐还是你所在组织的套餐。

GitHub Copilot 通过 Agent Client Protocol 接入 JetBrains Air，支持在 JetBrains IDE 内或云端沙箱中委派编码任务、引导执行并审查结果；云端任务消耗 Copilot 订阅而非 JetBrains AI 额度，但需要企业组织与管理员开通。

• GitHub Copilot 通过 Agent Client Protocol 接入 JetBrains Air，支持在 JetBrains IDE 内或云端沙箱中委派编码任务、引导执行并审查结果；云端任务消耗 Copilot 订阅而非 JetBrains AI 额度，但需要企业组织与管理员开通。
• 原贴提到：You can now delegate coding tasks, guide execution, and review results w
• 来源：github.blog

这是什么信号

GitHub Copilot 以 Agent Client Protocol（ACP）的方式接入了 JetBrains 的 Air，这意味着 Copilot 不再只是“IDE 里的补全插件”，而是作为一个可被外部智能体编排层调用的执行体存在。ACP 是关键：它把“哪个模型/智能体来干活”变成可插拔选项，Air 负责会话管理、上下文投喂、环境调度和结果审查，Copilot 负责执行。对用户来说，操作路径变成：在 Air 的 agent picker 里选 GitHub Copilot，用已有的 Copilot 订阅跑任务，本地在 JetBrains IDE 里跑，云端则由 Air 在隔离环境中跑。

另一个值得注意的细节是计费口径：云端任务消耗的是 Copilot 套餐，而不是 JetBrains AI 额度。这把“用哪个智能体”从技术选择直接变成了采购与预算选择。

为什么重要

过去开发者在 IDE 插件、云端 agent 平台、模型订阅之间做的是互斥选择：选了 JetBrains 生态就用它的额度，选了 Copilot 就留在它的插件里。ACP 让这两层解耦——IDE 平台做编排与审查界面，Copilot 做执行引擎与账号体系。对已经在 Copilot 上付费的团队，这相当于把既有订阅的“可执行算力”扩展到 JetBrains 的智能体会话界面里，避免重复付费。

同时，云端任务的沙箱设计（Docker 容器、全新虚拟机、全流量走代理、任务间不保留状态）说明这是按“不可信代码执行”来设计的：Copilot 可以在隔离环境里构建、测试、装包，不碰本地机器。这是把 agent 真正放进 CI 式流水线的前提条件。

对谁有价值

• 已在付费使用 GitHub Copilot、同时主力 IDE 是 JetBrains 系（IntelliJ、PyCharm、GoLand 等）的开发者：可以把订阅复用为 Air 中的执行智能体。
• 需要并行跑多个 agent 会话的技术负责人：Air 支持跟踪多个会话、使用项目上下文、在代码旁审查改动，适合批量任务派发与结果验收。
• 有平台治理诉求的工程组织：Air Teams 提供组织级开通、管理员启用 Copilot、云环境下的订阅/额度校验，便于统一管控。
• 想在本地之外跑构建与测试、又不想污染开发机的团队。

可以怎么行动

• 本地先试：在 JetBrains IDE 中安装 Air，在智能体选择器里选 GitHub Copilot，连接 Copilot 账号，用一个小重构或测试补全任务验证闭环。
• 云端再评估：确认企业组织是否已启用 Air Teams、管理员是否已开启 Copilot；然后在浏览器中打开 Air，在 Settings > VCS Providers 连接 GitHub，选定仓库与远程分支后创建任务。
• 把并行会话纳入日常工作流：把可以独立拆分的任务（补测试、修 lint、依赖升级验证）作为并行会话派发，自己专注在审查环节。
• 提前做预算口径对齐：与财务/采购确认云端任务走 Copilot 套餐后的成本归属，避免出现“以为在花 JetBrains 额度”的账目错配。

风险与限制

• 云端任务门槛不低：需要 Air Teams 已启用的企业组织内 JetBrains 账户、Copilot 订阅，以及管理员开启 Copilot，个人用户基本只能先用本地路径。
• 套餐不可按任务切换：无法指定单个任务走个人 Copilot 套餐还是组织套餐，这在个人账号与公司账号并存时会造成归属不清。
• 订阅校验发生在云环境启动时，一旦订阅或额度不可用，任务直接失败并在会话中报错，属于“启动即失败”而非降级运行。
• 任务间不保留状态、全流量走代理，意味着需要外部网络访问的构建或私有源拉取可能受限，长周期任务的上下文需要每次重建。
• 接入时不请求 GitHub Copilot 权限，权限校验被推迟到运行时，团队需要自行明确谁有权发起云端任务。

这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。

如果把《GitHub Copilot 现已登陆 JetBrains Air》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。

• Allison 原帖