JetBrains Air 入门：在 IDE 中管理编程智能体

让几个 coding agent 同时干活并不难，难的是随时知道谁做到哪了、改了什么、还有什么需要你处理。JetBrains Air 想解决的就是这层协作问题：把 agent 会话、变更审查和测试放回开发者已经熟悉的 IDE。

这篇入门文章展示了一条从派任务到验收代码的工作流。它的价值在于说明如何管理委派出去的开发工作，但演示能证明流程可用，还不足以证明多开几个 agent 就能提高团队产出。

Air 接进 IDE，究竟帮你省了哪一步

Air 把不同 agent 的会话集中在一个工作区里。你可以查看进度，打开修改过的文件，检查 diff，再进入项目运行和测试代码。对于已经使用 JetBrains IDE 的开发者，这能减少在会话窗口、代码编辑器和测试工具之间寻找上下文的操作。

Air 的核心价值，是把任务执行和人工验收接到同一条工作流上。

文章中，Developer Advocate Kristel Cocoli 从一个已有项目出发，让 agent 扩展功能，再审查修改并测试结果。它展示的是委派开发的完整路径，没有给出任务耗时、缺陷率或人工修改量的对照。

安装方面，Air 可以从 JetBrains Marketplace 获取，也已内置于 JetBrains IDEs 的 2026.3 EAP。EAP 是早期访问版本，文章没有交代稳定版的具体安排。

如果通过 AI Assistant 的通知安装 Air，AI Assistant 会被关闭，避免两者并行运行。想切回去，可以连按两次 Shift，选择 Actions，搜索 Open AI Assistant；也可以在 Agent Sessions 工具窗口的 Options 中选择同名入口，无须禁用 Air。

选哪个 agent，和把代码交给谁，是两件相关的事

Air 可以检测本机已经安装的兼容 agent。打开 Manage Agents，可以从注册表安装，或连接自定义 agent，再为每项任务选择执行者。

原文列出的支持对象包括 Codex、Gemini、GitHub Copilot、Claude Agent 和 Junie，也支持通过 Agent Client Protocol（ACP）连接的其他 agent。这里可以把 ACP 理解成接入协议，让不同 agent 能在同一个环境里使用；它不代表这些 agent 的能力和行为完全一致。

订阅规则需要单独看。原文称，JetBrains AI 订阅支持上述 agent，并特别说明：Claude Agent 在 Chat 视图中需要 JetBrains AI 订阅，在终端界面则可以使用自己的 Claude 订阅。文章没有逐一解释其他 agent 的独立订阅接入条件，不能据此推断所有组合都可直接使用。

安装 Air 本身不会安装或激活 agent，也不会因此把项目代码发送给 AI 提供方。连接并使用哪些 agent，由用户决定。第三方 agent 的数据直接发送给对应提供方，适用用户已有的协议；使用 JetBrains AI 时，则适用 JetBrains AI 的服务条款。

因此，统一入口并没有统一所有数据处理关系。选 agent 时，除了看任务适配程度，还得确认实际使用的账号和服务方。

多会话的关键，是让每项工作都能被检查

选择 agent 后，macOS 使用 Cmd+2，Windows/Linux 使用 Alt+2，启动新会话。接着描述任务，也可以附加文件或选中相关代码，缩小 agent 需要理解的范围。

作者建议给出聚焦的请求，例如探索项目的一部分、调查一个 bug，或实现一项功能。原因很直接：起点越明确，后续越容易判断 agent 有没有完成要求。

Air 允许一个 agent 探索陌生模块，另一个实现变更，也允许同一个 agent 开多个会话。会话以编辑器标签页呈现，修改文件和 diff 可以从会话访问。兼容 agent 可使用聊天或终端界面，其中终端作为全屏标签页打开；语音输入则取决于相应功能是否可用。

此外，Air 提供会话级费用估算，便于观察 agent 和模型选择如何影响用量。原文没有说明估算的计算口径，也没有承诺它等于最终账单。

真正决定结果能否接受的，还是审查环节：从会话进入项目，检查 diff，跳转关联代码，运行测试；发现问题后，再把针对 diff 的反馈交给 agent。

文章还给了一个试用入口：登录 JetBrains Account，可以在没有付费订阅的情况下尝试 Junie Lite mode，但没有列出具体额度和限制。worktrees、代码备注和提交信息生成被留到下一篇，本篇没有展开操作方法。

我的判断

我认可它把重点放在验收上。agent 写完代码，只是任务进入了待审查状态。把 diff、关联代码和测试留在同一个开发环境里，确实有利于开发者检查结果。

但多会话能否提高效率，取决于任务是否适合拆分，以及人有没有足够的审查能力。两个 agent 同时修改相互依赖的代码，仍然可能产生冲突；文章没有展示如何处理这些情况。与在独立终端运行 agent 相比，Air 展示出的优势主要是管理和审查入口更集中，不能据此认定代码质量更高。

原文末尾还混有其他文章的预告。其中提到，JetBrains IDE intelligence 在另一组测试中通常带来 20–30% 的效率提升，最佳约 65%；另一系列列出 caveman skill 宣传减少 65%、实测减少 8.5%，rtk 宣传减少 60–90%、实测增加 7.6%，以及后续的 80 组配对任务。这些数字缺少本篇内的实验细节，也不构成 Air 多会话工作流的直接证据。

这篇适合作为上手指南，效率收益仍需要在自己的任务上验证。

能拿来做什么

• 在现有项目里选一个边界清楚的 bug 或小功能，附上相关文件，并写明预期行为，再走完派任务、看 diff、运行测试的全过程。
• 尝试多会话时，先让一个 agent 做只读探索，另一个执行范围明确的修改，观察自己能否跟上进度和审查节奏。
• 把针对具体 diff 的问题反馈给 agent，并重新检查修改结果，避免只凭会话中的完成说明接受代码。
• 如果准备日常使用，先核对 agent、交互界面和订阅的对应关系，再结合会话费用估算判断使用成本。