JetBrains Air 进入 IDE 开启 EAP，但真正的押注在于编排

JetBrains 已向早期用户开放 JetBrains Air in IDEs，将五款受支持的编程智能体引入一个面向并行任务构建的工作区。此举与其说是新增一个聊天机器人，不如说是在决定开发者将在哪里监督 AI 生成的代码。

Air 原生支持 Codex、Gemini、GitHub Copilot、Claude Agent，以及 JetBrains 自家的 Junie。它还可通过 Agent Client Protocol（ACP）连接其他兼容工具；ACP 是编程智能体与开发环境之间的通用接口。

这使 JetBrains 站到了以模型为中心的软件开发观的对立面。在这种模式下，开发者会追随当前产出效果最佳的智能体。JetBrains 押注于，更具持久价值的产品是能够提供上下文、跟踪并发工作，并帮助人类审查每一项变更的环境。

早期报道的重点是 EAP 覆盖五款 IDE。JetBrains 当前文档则表示，该插件支持其 IDE 产品线中的所有产品，Android Studio 除外，最终范围因此比最初的表述更广。更重要的数字仍然是五款智能体，因为 Air 将它们视为同一控制界面中的可互换工作者。

JetBrains 并不要求开发者放弃 Codex、Claude、Gemini、Copilot 或 Cursor。它希望这些系统能在 JetBrains 产品内部运行。这一区别让 JetBrains Air EAP 成为一次检验：当智能体承担更多实现工作时，IDE 能否继续作为软件开发的中心。

JetBrains Air in IDEs 将工作区与模型分离

JetBrains Air in IDEs 是一层编排层，而非新模型，也不是 AI Assistant 的替代名称。

JetBrains 于 10 月初通过 Marketplace 及其 IDE 的 2026.3 EAP 构建版本推出 EAP。该公司的 Air EAP 公告称，该插件在未安装智能体的情况下即可部署，且并不充当 AI 提供商。

这一设计之所以重要，是因为它将用户常常作为一体化体验接触到的三类产品区分开来。模型负责生成或理解文本。编程智能体负责规划任务、操作工具、编辑文件并运行命令。Air 则在 IDE 内部组织这些智能体及其工作。

开发者可以连接自己已在使用的智能体，但须遵守各提供商的身份验证规则。仅为运行兼容的第三方智能体，他们不需要订阅 JetBrains AI。Air 能检测本地已安装的智能体、通过注册表提供智能体，并复用受支持的授权方式。

五款智能体获得了明确的一级支持：Codex、Gemini、GitHub Copilot、Claude Agent 和 Junie。Cursor 及其他工具则可通过 ACP 兼容性接入，尽管不同智能体的具体接口与授权路径可能有所不同。

该产品围绕会话组织工作，而不是围绕一段持续不断的单一聊天。每个会话代表一项任务、其智能体、上下文、进度，以及产出的变更。开发者可以查看跨项目的活跃工作、识别等待输入的会话，并打开已完成的变更进行审查。

Air 还支持预设。预设可保存智能体、模型选择、推理强度、访问级别及其他启动设置。这使团队能够为日常修复、大规模重构、审查或实验创建不同配置。

这种结构将 IDE 变成一个调度器。开发者可以把失败的测试交给 Codex，将文档修改分配给 Gemini，并让 Junie 检查性能问题。Air 并未宣称这些智能体会作为一种集体智能协同工作。它只是为每项任务提供可见位置，并将其输出保留在审查流程中。

这一区别避免了人们对“运行五个 AI 智能体”这一说法产生重要误解。Air 原生支持五款具名智能体，但并不要求五者同时运行。它也无法保证并发运行的智能体会产出彼此兼容的代码。

JetBrains 当前的 Air 文档 表示，本地智能体在开发者的机器上运行。Air 通过 ACP 与兼容智能体通信，而命令行智能体则可以在 IDE 内保留其终端界面。

该插件可安装在 2026.2 版本中，并随 2026.3 EAP 构建版本一同提供。JetBrains 现已记录其对除 Android Studio 之外各款 IDE 的支持。实际可用性、智能体授权与云端执行仍可能取决于用户的产品版本及组织设置。

这些细节表明，这不只是一次分发更新。JetBrains 正围绕委派式工作重组其 AI 界面，同时让已有的编辑器、调试器、检查、导航与版本控制工具紧贴产出结果。

JetBrains 为何超越 AI 聊天面板

推动 JetBrains 的压力来自开发者行为的变化，而不只是语言模型变得更强。

第一代基于 IDE 的 AI 功能主要围绕自动补全和聊天展开。开发者选择代码、提出问题、获得答案，然后决定粘贴或应用哪些内容。这种交互很自然地适合放在侧边栏中。

编程智能体带来了不同的管理问题。它们可以读取多个文件、形成计划、执行命令、修改代码库，并在交还控制权前运行测试。开发者也可以在第一个智能体仍处于活跃状态时启动另一项任务。

JetBrains 表示，它曾尝试在现有 AI Assistant 聊天界面中容纳更多智能体。该公司得出的结论是：监督并发任务需要围绕工作状态而非对话历史组织的产品。

这一结论解释了为何在 EAP 期间，Air 与 AI Assistant 仍保持分离。AI Assistant 将继续在既有 IDE 体验中提供聊天、补全、代码洞察、下一步编辑建议及智能体访问。Air 则将智能体和会话视为核心工作单元。

JetBrains 预计 Air 最终会成为其主要的智能体式界面，但尚未宣布移除 AI Assistant。用户可以继续安装 AI Assistant，不过若通过 AI Assistant 通知安装 Air，旧插件会被禁用，以防两个界面同时运行。用户可通过插件设置重新启用它。

更深层的竞争问题是开发者注意力的归属。智能体优先的编辑器和命令行工具可能将工作从传统 IDE 中拉走。如果开发者大部分时间都在别处发出提示并审查补丁，IDE 就有可能沦为仅用于棘手调试的次要场所。

Air 试图扭转这一流程。它不强迫开发者在 JetBrains 与外部智能体之间二选一，而是邀请外部智能体进入 JetBrains 环境。智能体负责规划与生成，IDE 则提供代码库上下文和验证工具。

这种做法也应对了模型迭代更替。领先的编程模型变化速度可能快于组织更换开发环境的速度。一家公司可能更愿意使用某个智能体进行 Java 迁移、另一个用于界面工作，并为包含受限代码的代码库使用内部智能体。

如果 Air 仍是管理这些系统的场所，JetBrains 就不需要让 Junie 在每一次比较中获胜。该公司能够从第三方智能体的增强中获益，因为这些智能体会让共享工作区更有价值。

这正是 ACP 居于核心位置的原因。ACP 合约 定义了客户端（如 IDE）与智能体之间的通用连接。智能体保留自身的模型选择、工具、身份验证和规划行为。

JetBrains 将这一边界类比为 Language Server Protocol 所扮演的角色。编辑器无需为每一个兼容的语言服务器提供单独的私有集成。ACP 旨在减少每个智能体与每个开发环境之间都需要定制插件的需求。

这一类比也有局限。编程智能体可以执行命令并修改代码库的大部分内容，因此其权限和副作用带来的风险更大。尽管如此，通用连接层仍能减少集成工作，并降低切换智能体的干扰。

对 JetBrains 而言，这创造了一个战略切口。Cursor、Codex、Claude、Copilot 和 Gemini 无须在模型层面被击败。它们可以成为 JetBrains 多智能体 IDE 中的选项。

IDE 成为智能体工作的控制平面

Air 的核心押注是：随着代码生成变得更容易，验证的价值将变得更高。

生成补丁只是软件开发的一部分。仍需有人判断补丁是否符合需求、是否保留架构、是否通过测试、是否遵守安全边界，以及在真实条件下能否正确运行。

JetBrains 已拥有完成这类工作所需的许多工具。其 IDE 能理解符号、类型、引用、项目结构、测试运行器、版本控制、数据库、调试器和性能分析配置文件。Air 将智能体活动连接到这些既有界面。

智能体可以接收文件、提交记录、截图和可复用指令作为上下文。开发者可以检查已变更文件、比较差异、导航至相关代码，并在无需将结果转移到其他应用的情况下运行项目。

这种连接可以减少重复探索。编程智能体经常要耗费 token 来列出目录、打开配置文件并定位相关符号。IDE 提供的上下文能让它更早地指向正确代码，尽管节省程度会因智能体和任务而异。

Air 还让受支持的智能体能够访问 IDE 技能，用于调试、性能分析、数据库探索和语义代码搜索等活动。JetBrains 表示，这些工具能够改善某些任务的结果，但这一说法仍需在不同代码库和语言中进行广泛测试。

智能体会话成为这一工作流的容器。它会记录所选智能体、对话、活动、变更文件、提交记录及报告成本。会话可以在多个项目间保持可见，帮助开发者发现已经完成或需要介入的工作。

这一模式不同于打开五个聊天标签页。聊天标签页主要保存一段对话。Air 会话则将对话与代码库状态及审查操作关联起来。

设想一位负责某项服务、且面临集成测试失败的开发者。一个会话可以调查失败原因。第二个可以在隔离分支中更新相关依赖。第三个可以检查受变更影响的文档。

当这些会话推进时，开发者仍可在主检出目录中继续工作。当某个会话完成后，IDE 就成为审查差异、运行检查、核验测试，并决定结果是否应进入目标分支的场所。

这一过程契合工程工作更广泛的转变。开发者越来越多地协调生成的变更，而非亲自逐行输入所有实现。他们的责任并未消失，而是转向指定任务、提供上下文、审查证据和解决冲突。

JetBrains 正将 IDE 定位为承担这些责任的控制平面。这个术语指的是协调工作者和状态、但不亲自充当工作者的界面。如果 Air 能让多个智能体更易于监督，即使它不生成最好的补丁，也能体现价值。

模型同样保留用户选择权。开发者可在提供商允许的情况下连接现有订阅、选择 JetBrains AI，或使用本地配置的 ACP agent。Air 本身并不提供专有模型。

这种灵活性具有重要战略意义。与单一模型绑定的封闭工作区，会继承该模型的弱点和商业策略变化。多 agent 工作区则能让开发者替换 agent，同时保留项目习惯和审查工具。

已经在构建可搜索工程上下文的团队，可能会注意到相同的模式。真正持久的资产并不是某一个答案，而是连接代码、决策、文档和审查的结构。一个技术知识库可以补充 agent 会话，保留那些应当超越单次编码任务而持续存在的信息。

Air 本身无法解决这一更广泛的知识问题。一次会话包含有价值的工作上下文，但团队仍需要保存架构决策、事故和需求的长期记录。IDE 可以协调实现工作，而共享知识系统则保留实现存在的原因。

并行 Agent 带来合并与注意力问题

只有当开发者能够审查、协调并信任其输出时，运行更多 agent 才会提升吞吐量。

Air 允许开发者从某个分支启动会话，并将工作置于临时 Git worktree 中。worktree 是一份独立的工作副本，与同一仓库历史关联。它让 agent 的编辑操作与开发者当前检出的内容分离。

这种隔离对于并行工作至关重要。在同一工作区中编辑相同文件的两个 agent，可能会覆盖彼此的假设，或产生各自能通过、组合后却会失败的改动。独立 worktree 可减少直接干扰。

Air 可以展示结果，并让开发者将选定提交转移回活动项目。其文档中的会话工作流支持在将改动 cherry-pick 到目标分支前进行审查。

隔离并不能消除集成工作。如果五个 agent 修改了相互关联的区域，开发者可能要面对五个分支、重复编辑、不一致的抽象以及合并冲突。每个 agent 都可能给出看似合理的局部结果，但组合后的系统却会变得缺乏一致性。

此时，瓶颈会从代码产出转向人的注意力。开发者必须理解每个 agent 改了什么、为什么改。他们还必须判断哪些测试能提供有意义的证据，而非接受由编写代码的同一系统生成的绿色摘要。

Air 的会话列表有助于呈现这类工作负担。它可以显示活跃会话、未读更新、修改文件、待推送提交以及等待输入的任务。这种可见性很有价值，但它无法判断底层决策是否正确。

这正是 JetBrains Air EAP 背后的核心权衡。并行化可以缩短等待时间，但也可能成倍增加审查义务。一个团队若启动 agent 的速度快于验证其工作的能力，只会创建更长的不确定补丁队列。

预设还带来了另一项治理问题。它们使配置可以重复使用，但团队必须决定每类任务应使用哪些模型、权限和投入级别。适合一次性测试仓库的高权限 agent，可能完全不适合生产基础设施。

认证机制同样仍不均衡。JetBrains 支持多种途径，包括提供商托管登录、第三方凭据和 JetBrains AI。不过，一个订阅即使可在某个界面中使用，也未必能在另一种界面中授权同一个 agent。

Claude 正说明了这种复杂性。JetBrains 表示，Claude 订阅可通过终端界面使用，而结构化聊天中的 Claude Agent 则需要 JetBrains AI，或配备 API 计费的 Anthropic API key。开发者在将 Air 视为通用订阅中心之前，应先核查当前授权规则。

云端执行增加了更多边界。本地会话在开发者机器上运行，但符合条件的组织可以将某些任务发送至 JetBrains 基础设施。云端运行可在 IDE 关闭后继续，但其可用性取决于组织设置、仓库托管方式以及 JetBrains AI 订阅。

因此，数据处理取决于所选路径。JetBrains 表示，使用第三方订阅时，第三方 agent 数据会依据用户与该提供商现有的协议直接发送给该提供商。JetBrains AI 和云端功能则适用各自相关条款。

EAP 协议也明确指出了成熟度水平。早期访问软件可能包含错误、出现意外行为，并在开发过程中发生变化。当 agent 能够编辑文件和执行命令时，团队不应将 EAP 标签视作普通标识。

谨慎的推广应从非关键仓库和有限权限开始。团队应要求人工审查、保留可恢复的分支，并在合并前运行独立测试。敏感代码在任何 agent 获得上下文前，都需要明确的提供商和数据路由决策。

这些控制措施并非反对在 IDE 中使用 JetBrains Air 的理由。它们是其并行模式得以发挥价值的前提条件。只有当编排让责任更加可见，而不是将其隐藏在活动仪表板之后时，才能形成真正的杠杆。

JetBrains 正将竞争对手变为可替换组件

Air 通过吸纳 agent-first 编辑器的 agent，同时保留 JetBrains 开发环境，向 agent-first 编辑器发起挑战。

最重要的对手并不是某一家公司，而是“编码 agent 应拥有整个开发者工作区”这一理念。

agent-first 编辑器可以围绕一个集成系统优化每一次交互。这会带来专注的体验，但也可能使开发者的工作流依赖于该产品的模型路由、界面决策和发布节奏。

JetBrains 采取了相反的立场。IDE 保持稳定，而 agent 则在其中竞争任务。开发者可以保留熟悉的导航、重构、调试和检查工具，同时更换生成代码的系统。

ACP 让这一主张更具可信度。没有共享协议，支持大量 agent 将需要不断增长的私有集成集合。每次提供商更新都可能破坏连接器，或使不同产品间的功能表现不一致。

有了 ACP，可替换的单元不止是模型。一个 agent 还携带其规划逻辑、工具、权限、模型路由和界面行为。Air 通过共同的客户端边界连接这一完整组件。

这让 JetBrains 能够从外部创新中获益。如果 Codex 更擅长仓库级改动，Air 用户可以选择它。如果 Gemini 更适合另一类工作负载，工作区本身无需改变。内部 ACP agent 可用于受限制的任务。

因此，五个具名 agent 是首发阵容，而非固定上限。Codex、Gemini、GitHub Copilot、Claude Agent 和 Junie 为 EAP 提供了易于识别的选择。注册表和自定义配置则扩展了可能的范围。

Cursor 是一个很有启发性的例子。它作为面向 AI 的编码环境争夺开发者注意力，但其 agent 也可以通过 ACP 连接到 JetBrains 产品。JetBrains 可以将一个通常与切换编辑器相关联的产品，变成其自有 IDE 中可用的工作者。

这并不保证用户会留下来。原生的 agent-first 产品仍可能提供更一致的界面、更快的功能交付，或与其偏好模型更紧密的集成。协议兼容性很少能让所有客户端体验完全相同。

Air 也必须证明“选择的复杂性”是合理的。五个拥有不同权限、订阅、模式和优势的 agent，可能比一个熟悉的工具更难管理。工作区需要清晰的状态、可预测的配置和可信的审查信息。

JetBrains 自身的产品线还带来另一项风险。用户已经会接触到 AI Assistant、Junie、Air、ACP agents、提供商账户和 JetBrains AI。Air 带来了更清晰的概念划分，但过渡期仍可能令人感到割裂。

该公司正试图通过将 Air 定位为 agentic 工作流的专用环境，同时保留 AI Assistant 用于聊天和行内辅助，来解决这一问题。用户是否理解并偏好这种划分，将成为 EAP 的关键结果。

JetBrains 最初将独立的 Air 环境描述为一个围绕 agent 构建的场所，而不是附加 AI 的编辑器。其 3 月的公开预览将并发委派确立为产品的核心理念。

将这一体验引入成熟 IDE 改变了主张。开发者不再需要采用独立应用程序来测试这一工作流。JetBrains 可以通过已经嵌入工程团队的产品分发 Air。

这种分发优势意义重大，但采用与否取决于日常实用性。开发者不会仅仅因为一个工具窗口能识别多个 agent，就一直保留它。Air 必须让并发工作比独立终端或提供商应用更易理解、审查和合并。

JetBrains Air EAP 后续值得关注什么

下一项考验不是 Air 列出了多少 agent，而是团队能否以更少的上下文切换和可控的审查成本完成真实工作。

第一个信号是其在普通仓库中的采用情况。JetBrains 需要证明，在并行启动会话的新鲜感消退后，开发者仍会持续使用 Air。在调试、维护、测试和重构中反复使用，将支持其编排论点。

有价值的指标不是提示词数量。团队应考察完成任务数、被接受的改动、审查时间、重新打开的缺陷，以及 agent 完成后所需的人工修复量。高会话量可能掩盖低质量输出。

第二个信号是基于 worktree 的集成可靠性。Air 应让分支状态、未提交改动、冲突和转移目标一目了然。一个为并行 agent 设计的系统，必须防止开发者丢失工作，或将正确补丁应用到错误分支。

JetBrains 记录了保障措施和审查控制机制，但 EAP 将揭示它们在日常压力下的表现。大型仓库、生成文件、单体仓库和重叠重构，将提供比孤立演示更严苛的测试。

第三个信号是 agent 提供商和竞争编辑器的回应。更广泛的 ACP 采用将强化 JetBrains 的开放工作区战略，因为开发者可在支持的客户端之间迁移 agent。提供商也可能转而偏好仅在自家应用中效果最佳的专有功能。

对通用能力的支持将与 agent 数量同样重要。权限、工具调用、上下文附件、成本报告、会话恢复和差异归属需要一致的行为。若某项协议连接了许多 agent，却只暴露它们最低层的共同功能，将限制 Air 的优势。

组织还应关注管理控制。JetBrains 表示，公司可通过托管 AI 访问权限禁用 Air，但其文档指出 IDE Services 管理尚未完善。企业采用需要针对提供商、凭据、云端运行、数据路由和可审计性制定清晰政策。

Air 与 AI Assistant 之间的关系是另一个具体信号。JetBrains 表示，AI Assistant 将继续获得支持，而 Air 将成为首选的智能体体验。未来的版本将揭示这种分工会变得更清晰，还是会产生重叠的界面。

成功的过渡将为开发者留下一个清晰的位置来处理委派任务，以及另一个位置来获得轻量级的行内帮助。混乱的过渡则会迫使用户弄清楚每个智能体、订阅或聊天模式归属于哪个插件。

这五个受支持的智能体也将验证专业化是否带来实际价值。开发者需要有可观察到的理由，针对某项任务选择 Codex，而针对另一项任务选择 Junie 或 Gemini。否则，这个选择器就会变成一项管理选择，而非生产力功能。

JetBrains Air 在 IDE 中最终建立在一个站得住脚的前提之上：生成式代码提升了上下文和审查的价值。尚未解决的问题是，一个 IDE 能否组织足够多的智能体，同时不把开发者变成全职队列管理员。

不妨在一个可恢复的分支上试用 EAP，并交给它一项跨越多个文件、测试和审查步骤的任务。然后将完整工作流程与你当前的智能体配置进行比较。Air 是否减少了上下文切换，让变更更容易检查，并保留了你对仓库的控制权？还是它只是把五套界面集中到了一个窗口中？这个答案在真实团队中反复得到验证后，将决定 JetBrains Air 会成为智能体开发的操作层，还是仅仅停留在一个有趣的实验。