JetBrains 为旗下每一款 IDE 内置了 Agent 编排器
JetBrains 于 10 月 1 日在其各款 IDE 中开放了 Air 的早期访问。它既可以作为插件在 JetBrains Marketplace 上获取，也已内置在 IntelliJ、PyCharm、WebStorm、Rider 及全家桶其余产品的 2026.3 EAP 构建版本中，并且从 2026.2 版本起即可使用。该插件免费。
有意思的地方在于它的定位。Air 本身不是模型，也不是 Agent。它出厂时没有预装任何 Agent。JetBrains 将其描述为一个通道，用来接入开发者已经付费的 Agent 和订阅服务，它会像 IDE 检测终端那样，自动检测机器上已有的内容。
以会话取代聊天
JetBrains 认为，同时编排多个任务与和模型对话是两种不同的活动，把两者塞进同一个界面一直是个错误。经典的 IDE AI 以聊天为中心，而 Air 以会话为中心。
每个会话就是一个正在执行任务的 Agent，界面会把它们集中呈现：活动状态、未读更新、变更文件、待推送提交以及每个会话的成本，都在同一个视图中。会话可以跨项目运行，可以显示为编辑器标签页，也可以根据任务类型停留在终端或图形化聊天界面中。在 IDE 任意位置双击 Ctrl，即可打开一个附带当前上下文的提示词窗口。
隔离通过临时的 Git worktree 来实现。会话可以从任意分支启动，可以在新分支上或以 detached 状态运行，结果再通过 cherry-pick 回到主项目。JetBrains 表示，Agent 的输出会以可审查的 diff 形式出现在 IDE 内，使用的是开发者审查 pull request 时所用的同一套工具，并且变更不会被自动应用。
协议这步棋才是战略关键
Air 连接的是支持 Agent Client Protocol 的 Agent，这是 JetBrains 与 Zed 共同构建、以 Apache 许可证发布的开放标准。ACP 通过 stdin 和 stdout 使用 JSON-RPC 2.0，目前已有 JetBrains、Zed、Google、GitHub 以及 25 个以上的 Agent 采用它。两家公司还推出了 ACP Registry——一个内置于 IDE 中、可发现兼容 Agent 的目录。
最容易的类比是 Language Server Protocol。LSP 让任意编辑器都能通过一个共享标准支持任意语言，而不必为每种组合单独定制集成。ACP 想在 Agent 领域做同样的事。
JetBrains 争夺的不是模型质量，而是 Agent 被启动、被监管、被审查的那一层；而共同制定规范 Agent 与编辑器通信方式的协议，正是让自己成为基础设施而非一个功能的方式。该公司自己的说法更直白：当 Agent 化开发成为常态，一个把 Agent 拒之门外的 IDE 将举步维艰。
支持的 Agent 包括 Codex、Claude Agent、GitHub Copilot、Gemini、OpenCode 以及 JetBrains 自家的 Junie，此外还有其他兼容 ACP 的工具。已经拥有 Anthropic、OpenAI 或 Google 密钥的用户无需向 JetBrains 支付任何费用。对于没有 Agent 订阅的用户，JetBrains 提供免费的 Junie Lite 使用额度，只需用 JetBrains 账号登录即可。如需使用该公司自有的托管模型访问，JetBrains AI 点数的起售价为每月十美元。
Cursor 没有的功能
JetBrains 主打的差异化在于，接入 Air 的 Agent 可以把 IDE 工具当作技能来调用。Agent 可以触发调试运行来排查失败的测试，可以运行性能分析器，也可以在具备完整多文件上下文的情况下使用重构引擎。Agent 还能通过 MCP 访问 IDE 工具，处理结构化上下文，而不是粘贴的文本。
JetBrains 称这在某些任务上能带来更好的结果，在某些情况下还能减少 token 消耗。关于 token 的说法来自该公司，目前尚无独立测试结果公布。
背后的论点在于 Agent 能看到什么。一个只能读写文件的 Agent，只能基于文本工作。一个能对慢函数做性能分析并检查调用栈的 Agent，拥有资深开发者在诊断同类问题时所具备的上下文。JetBrains 花了 26 年打造这套工具链，而 Air 是 Agent 第一次能够用上它。
为什么这个时机说得通
JetBrains 推出它的时机，正值审查环节已成为公认的瓶颈。对许多团队来说，写代码不再是制约因素，检查写了什么才是。
这一判断同时出现在整个工具市场上。Qodo 在同一周发布了 3.0 版本，以审查为核心卖点；Cursor 则为其 Agent 工作流加入了一个审查机器人。三家厂商得出相同结论，说明制约因素已经永久性地转移了：当 Agent 产出代码的速度超过人类阅读的速度，价值就会转向任何能降低阅读成本的东西。
Air 的设计反映了这一点。该产品把并行的 Agent 会话当作待审查的工作队列，而不是需要引导的对话，并把每个会话的成本与变更文件放在同一个视图中。对于需要决定同时运行多少个 Agent 的工程经理来说，那行成本数字就是实际的界限。
按会话显示成本是个小功能，却对行为有着超乎比例的影响。看不到长时运行 Agent 花销的团队，往往会谨慎地只跑一个 Agent。能看到每个会话数字的团队则更愿意同时跑好几个，因为决策变成了资源分配，而不是一场赌博。这与云支出仪表盘带来的转变如出一辙，它会改变人们组织工作的方式。
Air 还试图解决一个协调问题。一个团队用 Claude 做一项任务、用 Codex 做另一项、用 Copilot 做第三项，结果就是三个彼此独立的界面，且没有任何共享记录说明各自改动了什么。把它们整合进一个本就掌管 diff、检查和版本控制的 IDE，比采用一款新工具的改动更小；而对于在 Java、Kotlin 或 Python 上已标准化使用 JetBrains 的团队来说，这也避免了仅仅为了用上 Agent 就把所有人推到另一款编辑器上。
尚未确定的事
Air 是早期访问版本。JetBrains 表示要做好遇到粗糙之处的准备，界面和行为都可能变化，更新频率大约是每周一次。它尚未给出正式发布（GA）日期。针对长时运行任务的云端执行仅限拥有 AI 席位的组织使用，JetBrains 尚未公布其定价。
在隐私方面，该公司表示，在未登录任何 Agent 的情况下，不会有任何数据离开本机；在使用第三方订阅时，数据会依据现有协议直接发送给该服务商，而不经过 JetBrains。禁用该插件不会改变其他任何东西，独立的 AI Assistant 仍继续获得支持。
真正值得在团队自己的代码仓库中检验的，是关于审查的那项说法。Air 让同时运行多个 Agent 变得更容易。这究竟会带来更多被合并的工作，还是更多没人看的 diff，是一个实证问题，答案会在使用的第一个月里揭晓，而不是在发布文章里。