JetBrains Air 接入 GitHub Copilot：本地可选，云任务有组织门槛

JetBrains Air 现在可以把 GitHub Copilot 选作编码 agent。 11 月 3 日的官方接入公告说的是 Copilot 加入 Air 的任务工作流，不是宣布这一天首次发布一款新 IDE：本地可通过 Air 插件连接账户，云端任务则需要 Air Teams 企业组织、Copilot 订阅和管理员开启。两条路径都叫「在 Air 里用 Copilot」，准入条件却不能混为一谈。

在这次集成里，可以把 Air 理解为选择 agent、管理任务并审阅改动的入口，它不是既有 Copilot IDE 插件的改名。对于习惯在 IDE 里与助手对话的人，值得看的并非又多了一个聊天框，而是任务交给谁、在哪儿运行，以及改动回到哪里审阅。官方称这项集成使用 Agent Client Protocol（ACP），可在 Air 的 agent picker 里选 Copilot，委派编码工作、引导执行并检查结果。下面只讨论公告能证实的工作方式和限制；我们没有登录账户或亲自运行任务。

Air 的 agent picker 多了 Copilot，不等于替代原有 IDE 插件

设想你同时处理一个小修复和一项重构：分别交给两个 agent 会话，回来时还得知道哪次改动属于哪个任务。Air 在这次公告中强调的正是并行跟踪多个会话、利用项目上下文及 IDE 工具，并在代码旁审阅修改。这描述的是任务组织与审阅位置，不是模型效果或修复成功率的测试结论。公告没有提供可以拿来宣称「比原有插件更快」的比较数据。

原有的 GitHub Copilot JetBrains 插件也没有被公告宣布淘汰；官方明确说两者可以并用，由使用者选择工作流。区别可以简单理解为：一个是在 Air 的 agent picker 里安排任务、看会话和改动；另一个是既有 IDE 插件入口。具体哪种方式适合某个项目，仍需按自己的代码审阅和协作习惯判断，而不是看到「接入」二字就以为所有旧入口都迁移了。

本地能选，云端还要 Air Teams 与管理员许可

在公告的本地任务说明里，路径是给 JetBrains IDE 安装 Air 插件、选择 Copilot，再连接自己的 Copilot 账户。这里说的「本地」是任务工作环境；不是说 Copilot 的所有计算都离线进行，也不能由此推断不需要订阅或网络。公告只明确已有 Copilot 订阅可用于集成任务，没有给出额外价目表。

云端是另一道门。官方列出的条件是：JetBrains 账户属于已启用 Air Teams 的企业组织、拥有 GitHub Copilot 订阅，且 Air 管理员已启用 Copilot。满足这些条件后，云任务可从浏览器里的 Air 或 IDE 内 Air 插件发起；浏览器路径要连接 GitHub、选仓库和远端分支，再选 agent。云任务消耗的是 Copilot plan，不是 JetBrains AI credits。因此，「已有个人 Copilot 就能直接在任意 Air 工作区开云任务」不是公告的承诺；组织资格与管理员开关同样是门槛。

云端不改本机，但用量不能只看 Air 的控制台

官方对云环境的描述相当具体：每次任务在新虚拟机的 Docker 容器里运行，流量经过代理，任务之间不保留状态；agent 可以构建、测试和安装依赖，不修改本地环境。这是运行隔离的说明，不等于任务天然安全、代码审查可以省掉，或它会替你解决仓库权限与依赖的所有问题。团队仍要把远端任务的输出作为待审代码，而非自动合并的交付物。

更容易影响组织采用的是云任务注意事项。官方说，连接账户时并不请求 Copilot 权限；连接成功不代表云任务已经通过订阅和额度检查，相关权益可能到云环境启动才核验，不可用时任务失败并在会话里报错。这里讨论的是 Copilot 云任务的权益检查，不改变前述「不使用 JetBrains AI credits」的说明，也不据此推断具体授权范围或额度计费规则。单个任务不能手选使用个人还是组织 Copilot plan。Air 自身的治理和分析也不包含 Copilot 用量；Air 管理员可以通过治理策略关闭这一集成，却不能在 Air 内为 Copilot 设置支出上限。

这几句话放在一起，给管理者的结论比「支持云端 agent」更有用：开放入口之前，先在 Copilot 侧核实实际关联账户、权益及计费归属，明确由谁核查用量、如何处理失败任务；不要假定能在 Air 内逐任务切换个人或组织计划。这里提出的是基于官方限制的管理建议，不是我们实测过账单归属或后台统计。

这次更新适合谁先看

已经使用 Copilot、想在 JetBrains IDE 里把任务和审阅集中处理的开发者，可以先关注本地 Air 工作流；团队若希望把任务交给远端环境，则先核对 Air Teams 组织资格、管理员策略及 Copilot 权益，再谈推广。两者最大的差异并不在 agent 的名字，而在运行位置和组织是否能看清用量。

截至这份公告，能确定的是接入方式、云任务环境和列明的边界；不能从中推出「11 月新 IDE 首发」、所有账户都能开云端任务，或集成后写代码一定更好。这仍是一条值得留意的开发工具动态，但是否改变你的日常工作，需要实际任务与组织权限一起验证。