JetBrains开放Air把IDE改成智能体调度台,编码竞争转向编排与验收

首页 / AI资讯 / AI智能体

0:00
0:00
1x
定时

10月1日起,JetBrains在2026.3抢先体验构建中向IntelliJ IDEA、PyCharm、WebStorm、GoLand等主流IDE开放了Air:一个用来同时托管多个编码智能体的插件层。官方博客把这次更新称为公司二十六年历史上最重要的几步之一,这种罕见的措辞背后是一个清晰的判断:当智能体替人写代码成为常态,开发工具的价值高地正从辅助生成转移到编排与验收。

Air到底是什么,不是什么

先说它不是什么。Air不做模型,也不训练智能体,JetBrains明确表示它不内置任何智能体,也不会在用户登录前向任何地方发送数据。它做的是一件更基础的事:检测开发者机器上已经装好的各家智能体,把它们拉进同一个面板统一管理。Codex、Claude智能体、GitHub Copilot、自家Junie,乃至任何兼容开放协议的第三方智能体,都可以在Air里并排开多个会话,每个会话的进度、未读更新、已改动文件和累计花费一目了然。

这个设计的价值在于把碎片化的智能体使用体验收敛成一张控制台。过去开发者同时用两三家智能体,需要在不同的窗口、不同的订阅体系之间来回切换,改了哪几个文件、谁在跑什么任务全靠脑子记。Air把任务状态、代码变更和成本数据放在同一个视图里,等于给智能体时代配了一个塔台调度屏。官方还提供了一个顺手的细节:在IDE任意位置连按两次Ctrl,就能带着当前文件上下文开一个子任务,让主任务拆解子工作变得零摩擦。

定价策略同样体现了编排者的自我定位。自家的Junie Lite登录账号即可免费使用,接入Claude、Codex或Gemini则直接填用户已有的API密钥,不强制购买JetBrains的AI订阅。企业侧另有Air Teams版本提供云端执行环境。这种自带钥匙的模式意味着,开发者不需要为同一份智能体能力向工具厂商重复付费,工具层与模型层的账目被切得干干净净。

并行会话如何不互相踩脚

多个智能体同时改同一个代码库,最直接的风险是互相覆盖。Air给出的答案是隔离执行:每个智能体会话可以运行在独立的Git工作树或者Docker容器里,各自在互不可见的分支副本上干活,完成后由开发者统一审查差异、决定合并或丢弃。配合仓库根目录的配置文件,团队可以为不同智能体预置各自的隔离策略,让并行真正落在工程流程里而不是停留在演示视频。

协议层面的开放是另一块基石。Air采用与Zed共同推进的智能体客户端协议,任何实现该协议的智能体都能接入,包括GitHub Copilot命令行、OpenCode、Cline,甚至本地运行的Ollama模型。这种供应商中立的姿态,让Air有机会成为多智能体工作流的公共底座:团队可以先在同一个仓库里横向对比不同智能体的产出,再决定标准化采购哪家,试错成本被降到最低。

支持的智能体还能调用IDE内置的技能与工具,包括调试器、性能剖析、数据库探索和语义代码搜索。JetBrains的解释很务实:让智能体用上这些工具,能在部分任务上产出更好的结果,某些场景还能减少词元消耗。逻辑不难理解,与其让智能体把整个文件读进上下文,不如让它直接调用一次精确的语义搜索,既省时间又省钱。

写代码不再是瓶颈,评审才是

JetBrains对行业趋势的判断写在官方博客里:随着智能体承担越来越多的工作,验证并拥有结果成为最困难的部分,而这正是IDE的用武之地。公司还透露了产品思路的一次转弯:最初曾尝试把智能体塞进AI助手的聊天面板,随着工作流演进发现行不通,因为编排多个并发任务与进行一段对话在本质上是两种活动,对话面板永远只能盯住一个线程,而调度者需要同时看清所有任务的状态。

这个判断与同期的行业动向形成了呼应。同周内,多家编码工具厂商不约而同把资源投向评审环节:有工具上线了专门的评审机器人,也有团队围绕代码审查重构了产品主线。当生成环节的成本被智能体压到趋近于零,人的时间约束就转移到了审查与合并上,谁能把评审做得更快更可靠,谁就卡住了工程效率的新咽喉。IDE厂商在这件事上有天然优势:差异对比、代码导航、静态检查这些评审基础设施,本来就是它们的看家本领。

当然,短板也要说清楚。多智能体并行改动相关代码时,合并冲突依然会出现;编排层本身会引入延迟,小任务上的并行收益可能被抵消;作为抢先体验版本,语言支持和智能体兼容性还不完整。社区讨论还指出了一个更深层的问题:并行会话共享代码库,却不共享各自积累的发现,一个会话里摸清的数据库连接池问题,不会传递给下一个从零开始的会话。执行可以编排,知识还没有编排,这个缺口随着项目变长只会越拉越大。

对开发团队的务实建议

对已经在用JetBrains生态的团队,这是一次接近零摩擦的试水:不换IDE,不换智能体订阅,装个插件就能把不同厂商的智能体拉到同一条流水线上做对比和分工。适合的场景也很明确:跨模块的大型重构、批量补测试、并行搭建新服务这类任务,多智能体分工的优势最明显;而单文件的精细调试、安全敏感的核心模块,单一模型全上下文介入仍然更稳。

对整个编码工具市场,Air的开放姿态提出了一个尖锐的问题:当编排层成为公共设施,模型厂商的绑定优势还剩多少?工具厂商的护城河正在从我的模型更好,转向我的调度更聪明、我的验收更可信。对中国开发者而言,这类多智能体编排思路同样可以直接借鉴到自研工具链中,把隔离执行、成本可视和统一评审这三件事做扎实,比堆砌生成能力更接近企业客户的真实痛点。编码工具的下半场,裁判员的位置比运动员更值钱。

素材来源:JetBrains官方博客、daily.dev、CSDN开发者日报、byteiota 发布时间:2026-10-06