JetBrains 发布 Air：IDE 不再只是写代码的地方，而要成为 Agent 的总控台

Air 是什么：三层架构，一次整合

9 月 22 日，JetBrains CEO Kirill Skrygan 在公司官方博客上宣布了 JetBrains Air，用他自己的话说，这是公司 26 年历史上"最重要的一步之一"。Air 不是一个新 IDE，也不是又一个 coding agent，而是一套"为 agent 时代的软件开发准备的产品系统"（a system of products for agentic software development），覆盖开发者个人、团队、组织三个层面。

这套系统由三个产品组成。Air in JetBrains IDEs 是 IDE 内的 agent 编排与验证体验：开发者可以在熟悉的 IDE 里指挥多个 agent 会话、审查它们产生的改动，JetBrains 的代码智能（符号理解、项目结构感知）成为"验货"的工具。值得注意的是，它不绑定自家模型：Claude Agent、Codex 和自家的 Junie 都可以直接接入，开发者可以用已有的订阅；JetBrains 还推出了免费的 Junie Lite 配置，鼓励用户"拿一个真实任务试试手感"。Early Access Program 已经启动。

Air Teams（9 月 28 日官方博客进一步详解）解决的是"agent 工作流只活在某个人笔记本上"的问题：配置一次，全团队复用。任务在共享的云环境（Docker 容器）中运行，可以由仓库事件触发（比如给 issue 打个标签就启动一个 agent 去修 bug 并提 PR），也可以按定时计划执行（依赖更新、PR 打开时自动 review）。成本上可以选择项目 AI credit 或个人 credit。Air Teams 已经向 JetBrains 的商业客户开放。

Air Governance 则是原 JetBrains Central 的更名与升级：组织的策略管理、可见性、审计、AI 成本管控和问责机制。Skrygan 在公告里写了一句很值得咀嚼的话："工作可以被委派，但责任不能"（while the work can be delegated, accountability cannot）。

这次发布不是从零开始。Air 的个人版工作区在今年 3 月进入公开预览，Central 也在 3 月发布，随后半年里 JetBrains 陆续推出了 Central CLI、共享上下文、云端 agent、自动化流程和团队成本控制。9 月的动作，是把这半年的实验收拢到同一个品牌和同一套架构之下。Skrygan 的原话是："26 年来，我们主要专注于个人的开发者工作台。现在，我们要为 agent 工作被发起、执行、协调、评审和治理的整个系统而构建。"

最值得玩味的赌注：不强制 Junie，把"验证"做成产品

JetBrains 本可以走一条最省力的路：把 Junie 设为必选项，用 IDE 的装机量把用户锁进自家全家桶。但它没有。Air 明确支持外部 agent 通过 Agent Client Protocol 接入，Claude Agent 和 Codex 在发布时就被点名。Skrygan 的赌注是反直觉的：模型会换代，agent 会过时，但"上下文、评审流程和治理机器"是长青的。只要 JetBrains 的产品在"理解你的代码"和"帮你为 AI 的产出负责"这两件事上不可替代，用户用谁的 agent 都无所谓。

这个判断背后是一个残酷的成本真相，JetBrains 在公告里说得很直白：AI 可以飞快地生成代码，但工程组织为此付出的代价并没有消失，只是转移了——转移到了 review、返工、安全事故、基础设施和线上故障上。"看似合理的代码带着一个错误的假设"比"直接报错的代码"难查得多，也贵得多。所以 JetBrains 把"验证"从"生成之后的清理工作"提升为核心功能：用 IDE 对符号和项目结构的理解来检查 diff，逐行评论，把改动打回给 agent。这是在把 26 年积累的"代码智能"护城河，重新包装成 agent 时代的"验货能力"。

对比一下同行的路线选择，会发现 2026 年下半年的 agent 战争已经分出了三条战线：Cursor 在 9 月推出了 Projects（协调者 agent 调度数千个子 agent）和 Rollouts（部署监控、自动回滚 PR），赌的是"agent 编排平台"；GitHub 在 9 月 24 日宣布 Copilot 企业功能的"默认启用"策略（10 月 22 日生效），赌的是"平台默认权"；而 JetBrains 赌的是"验证与治理层"。三家都没有在"谁的模型写代码最好"上纠缠——因为大家都默认，模型会越来越强、越来越便宜，真正的稀缺品是别的东西。

还有一个细节值得注意：Air Governance 的前身 Central，以及 Air Teams 的云端执行环境，都指向同一个方向——agent 的工作负载正在从"个人笔记本"迁移到"组织基础设施"。当 agent 开始 7×24 小时在云端跑定时任务、自动修 bug、自动 review PR 时，"谁在为什么买单、谁对结果负责"就成了必须回答的问题。JetBrains 抢先把"成本管理"和"问责"写进产品矩阵，是嗅到了企业采购清单的变化：明年 CIO 们买的不会是"AI 编程工具"，而是"agent 治理方案"。

对 vibe coder 意味着什么：IDE 战争进入下半场

先说直接影响：如果你是 JetBrains IDE 的重度用户，Air in IDEs 的 EAP 值得一试，尤其是免费的 Junie Lite——在一个你熟悉的、带完整代码智能的环境里指挥多个 agent（包括 Claude 和 Codex），这种"总控台"体验是目前纯终端 agent 给不了的。JetBrains 的 diff 审查、符号跳转、重构工具，本来就是为"理解代码"而生的，把它们用在"审查 AI 生成的代码"上，是顺理成章的降维打击。

再说间接影响：JetBrains 的转向是一个信号，说明agent 工具的竞争重心正在从"生成"转向"治理"。对独立开发者和小团队来说，这意味着选型标准要变了：不要只问"哪个 agent 写代码最强"，要问"哪个工作流让我对结果最有把握、成本最可控"。Air Teams 的"配置一次、全团队复用"就是一个很好的试金石——你的 agent 工作流是每次都要从头调教的"手艺活"，还是可以沉淀为团队资产的"工程"？

最后说一个判断：JetBrains 这次发布最聪明的地方，是承认了"IDE 不再是宇宙中心"。Skrygan 明确说，Air 未来会延伸到移动端和远程体验，agent 的工作可以在不同环境之间流转。IDE 的角色从"写代码的地方"收缩为"验货的地方"——但"验货"恰恰是 AI 时代最值钱的一环。当生成变得廉价，判断就变得昂贵。JetBrains 用 26 年时间学会了如何帮助开发者"理解代码"，现在它想把这门手艺卖给 agent 时代。下半场 IDE 战争的胜负手，不是谁帮你写得更快，而是谁让你敢为 AI 写的东西签字。

一家 26 年老店的转身：为什么是 JetBrains 先喊出"治理"

JetBrains 喊"治理"是有资格的。在所有 IDE 厂商里，它是唯一一个把"理解代码"做成核心资产的公司：IntelliJ 的索引、重构、符号解析，二十多年的积累。当 Cursor 用"AI 优先"颠覆编辑器时，JetBrains 的第一反应其实是迟缓的——Junie 的推出比 Cursor 晚了一大截，Air 的个人预览版今年 3 月才来。但迟缓有迟缓的好处：它看清了第一波 agent 工具都没解决的问题——生成很容易，规模化治理很难。

Skrygan 的履历也值得一提：2010 年加入 JetBrains，做过 ReSharper，带过 Rider，后来负责整个 IntelliJ 部门，2024 年 2 月接任 CEO。他是一个"工具人"出身的 CEO，对"开发者真正为什么买单"有体感。他在公告里没有谈参数、没有谈榜单，谈的是"责任不能被委派"——这是一个做过企业级工具的人才会抓住的痛点。个人开发者为"爽"买单，企业为"可控"买单。Air 的三层架构，本质上是把"爽"（IDE 内的 agent 体验）和"可控"（Teams 的复用、Governance 的审计）分开卖，各赚各的钱。

对中国开发者来说，Air 的发布还有一层特殊意义。JetBrains 系 IDE 在中国有极高的渗透率（尤其是 Java/Kotlin 后端和 Python 开发者），而 Junie、Cursor 这类 agent 工具在中国的可用性一直受网络和支付的困扰。如果 Air in IDEs 能通过 JetBrains 现有的中国渠道顺畅落地，它可能是很多中国团队接触"多 agent 编排"的第一站。EAP 阶段值得关注的一个问题是：Air Teams 的云端执行环境在哪里？数据合规怎么做？这些细节决定了它在中国企业的落地速度，也决定了它是"真香"还是"看看就好"。

当然，质疑的声音也不会少。最直接的质疑是：Air 现在"有些组件可用，有些还在路上"，发布会开完了，产品矩阵还是半成品。JetBrains 的回应是"滚动发布"，但市场会用脚投票——Cursor 的 Projects 已经能用了，GitHub 的默认策略 10 月 22 日就生效，留给 JetBrains 把饼画圆的时间并不多。第二个质疑是开放策略的可持续性：今天说支持 Claude Agent 和 Codex，明天如果 Junie 的商业化需要"差异化"，开放承诺会不会打折？Skrygan 需要用行动回答，而不仅仅是博客文章。

但无论如何，JetBrains 做了一件对的事：它把"验证"从后台提到了前台。在 agent 生成代码的成本趋近于零的时代，唯一稀缺的是"敢签字的人"和"帮人敢签字的工具"。Air 赌的就是后者。这个赌注能不能赢，要看未来一年企业采购清单的变化。但方向是对的——当所有人都在比谁生成得更快时，有人开始比谁让你更放心，这本身就是一种成熟。

给想尝鲜的读者三条实操建议。第一，从 Air in IDEs 的 EAP 入手，别一上来就折腾 Air Teams——个人体验的验证成本最低，先用免费的 Junie Lite 跑一个你熟悉的小任务，感受"多 agent 会话 + IDE 级 diff 审查"的工作流，和你现在用的终端 agent 有什么本质不同。第二，重点体验"打回"这个动作（逐行评论、把改动退回给 agent）：JetBrains 认为这是它的杀手锏，你要亲自验证它是不是真的比"在终端里复制粘贴报错信息"更高效。第三，如果你是团队负责人，可以开始盘点你们现在的 agent 工作流里，哪些是"每次都要重新调教的手艺活"——这些就是未来 Air Teams 要吃掉的场景，提前把它们文档化。无论最后用不用 JetBrains 的产品，这份盘点本身就已经赚到了。

补充一个容易被忽略的视角：JetBrains 这次其实是在"重新定义 IDE 的计费单位"。过去 IDE 按"座位"卖 license，未来 Air 很可能按"agent 工作量 + 治理 seat"来收费——Air Teams 的"项目 AI credit 或个人 credit"已经露出了端倪。对用户来说，这意味着选型时要算两笔账：agent 本身的 token 成本，和"编排与治理"这层中间件的成本。中间件从来都不是免费的，只是账单换了个名字。