9 月 22 日，JetBrains 在官网上宣布了 Air。消息当天就冲上了 Hacker News 首页，但如果你是第一次听到这个词，容易产生一个误会——以为 JetBrains 又发了一个新的 AI 编程工具。
不是。Air 是一个体系的名字，把 JetBrains 过去六个月做的智能体相关产品全收进去了。CEO Kirill Skrygan 在 LinkedIn 上的说法是”JetBrains 26 年历史中最重大的步骤之一”。这家公司做了 26 年 IDE，现在承认了一件事：整个软件开发流程，已经装不进一个窗口里了。
Air 到底是什么：三块拼图，覆盖三层人
官方博客里把 Air 拆成三个产品，对应三种不同的使用者。它们解决的问题各不相同，但要一起用才有意义。
Air in JetBrains IDEs——给开发者的那一层。 你可以在 IntelliJ IDEA、PyCharm、WebStorm 这些 IDE 里同时开几个 agent 会话，每个项目、每个会话独立，能跨窗口看到未读更新、改动的文件和待推送的提交。Agent 跑完的 diff 直接打开，你可以在具体某一行上留评论让 agent 去改。隔离方式有三种：本地、Git worktree、Docker。它还会自动发现机器上已经装好的兼容 agent，一键连上。
Air Teams——给团队的那一层。 目前是早期访问。核心是把 agent 的工作从”某个人自己的电脑”搬到共享的云端环境里：团队成员在专用云环境里协作跑 agent 任务，可以配定时自动化，把代码审查、发布说明、缺陷修复这类重复活儿直接派给 agent，还能按项目控制 VM 规格、外网访问权限和密钥。MCP 服务器只需要配一次，团队和团队成员的所有 agent 共享。
Air Governance——给组织的那一层。 这是原来的 JetBrains Central 改名而来。管的是另外一类问题：哪些模型和 agent 允许用、权限怎么分、AI 花销上限设多少、用量怎么统计。支持把 Amazon Bedrock、OpenAI、Anthropic 等自家密钥带进来，也支持按团队甚至按人设定不同策略。同样在早期访问阶段。
另外还有两块连接件值得单独点名。Air Context 用语义索引加速执行，官方称能降低在大规模生产级仓库里的操作成本；Air Gateway 是命令行入口，专门负责把 Claude Code、Codex 这类终端 agent 接进 Air 体系。JetBrains 也提到了移动端规划，让开发者离开电脑时还能查看和推进 agent 的任务，目前标注即将推出。
ACP 才是这盘棋的关键
三个产品里最有战略价值的，其实是那个不起眼的协议。
Agent Client Protocol（ACP） 由 JetBrains 和 Zed 一起开发，走 JSON-RPC 2.0，干的事情是标准化 IDE 和 agent 之间那条连线——不只是接个模型，而是接管整个 harness：规划、逻辑、工具调用、模型路由、可观测性。官方 ACP 页面列出的兼容 agent 已经包括 Junie、Gemini CLI、GitHub Copilot、Codex、Cursor、Mistral Vibe、OpenCode、Kimi CLI、Qwen Code、Factory Droid、Cline、Kiro CLI；客户端一侧有 JetBrains 全家桶、Zed，以及通过插件接入的 Neovim。配了 ACP Registry，在 IDE 里就能发现并直接拉起这些 agent。
熟悉编辑器历史的人看到这个结构会有点眼熟。2016 年 LSP 干掉了”每个编辑器给每种语言写一遍插件”的重复劳动，ACP 想做的是同一件事，只不过对象从语言服务器换成了编程 agent。JetBrains 官方把多厂商当成 Air 的基础设计原则，理由写得很直白：模型各有擅长、榜单每几个月就翻一次、同一家公司里不同团队的选择本来就不一样——今天绑死一家，等于签了一份好几年、但市场下季度就变了的合同。
JetBrains 自己也承认现在”开放”的代价：上下文在工具之间传不过去、花销归不到人头上、每接一个新服务策略就得重建一遍。现有技术栈里没有一个东西是设计来站在多个厂商之上的。Air 想当那一层。
这个判断不是空话。国内读者最熟悉的场景能对上：企业里 A 团队用 Claude Code、B 团队用 Cursor、公司统一买了 Copilot，三套东西各记各的账，谁也说不清这个月 AI 花了多少、哪些改动是人审过的。Air 想卖的正是这把总账。想做多 agent 编排的还可以对照站内《Cursor 发布自托管机器》，那条路是把执行层搬进企业内网；JetBrains 这条路是做治理层，两者其实可以叠着用。
上手：个人开发者四步就能跑起来
如果你只是想先试试 IDE 里的那层，门槛比想象中低：
- 装插件。 在 JetBrains IDE 里安装 Air 插件（云执行环境目前对部分客户开放，后续逐步铺开）。
- 接 agent。 打开 Air 面板，它会自动扫描本机已安装的兼容 agent。已经装过 Claude Code 或 Codex 的话，通常一键就能连上；没装的可以从 ACP Registry 里补。
- 配模型来源。 用自己的订阅或 API Key 都行，也可以用 JetBrains AI 的额度（按公开 API 价计费），会话中途也能切。
- 控权限、然后审。 Agent 请求改文件时，点文件名就能打开完整的改动预览，而不是只看聊天窗口里的一小段。看完再放行。
团队侧要等 Air Teams 的早期访问；治理侧要上 Air Governance。想在自己机器上完全离线跑的话，JetBrains 从 7 月起已经支持通过 Ollama 或 LM Studio 接本地模型，macOS 用户还能开一个”agent 干活时别让电脑睡着”的开关。本地部署这条路站内《Ollama vs LM Studio 深度对比》讲得比较细，可以一起看。
优缺点：它想解决的问题，和它现在的问题
先说 JetBrains 判断对的部分。它博客里对行业瓶颈的描述可以抄下来当结论用：明显写错的代码很快会被抓住，难的是看起来对的代码——能过一遍表面检查，但藏着一个错误假设或架构不一致，等你发现时已经很贵了。随着 agent 承担更多执行，写代码越来越便宜，理解、验证和担责越来越贵。活动更容易发起，却更难协调、审计和解释。而且责任无法外包：半夜出事被叫醒的还是人，模型再强也不会凭空产生组织政策、保留出处、提供成本可见性，或者决定谁来背这个改动。
这段判断和站内这几篇是一脉相承的——9 月 16 日写的《给 AI 编程 Agent 收权限》讲单个工具怎么把 Bash 权限收窄、9 月 12 日的 Cursor Projects 讲多智能体怎么协调、9 月 20 日的 AWS AgentCore Runtime 讲执行层怎么省钱。Air 是把”权限 + 协调 + 账本”三件事摆到一个产品体系里。
再说短板，这部分 JetBrains 自己也没否认，但值得翻译成人话：
- 一半还在早期访问。 Air Teams 和 Air Governance 都不是今天就能买来用；云执行环境也只对部分客户开放，剩下的要等几个月。
- “开放”目前还不是真的中立。 ACP 确实是开放的，但 Air Governance 能治理多少东西、能不能真的覆盖非 JetBrains 的第三方工具链，取决于第三方配合到什么程度。它现在更像是开放协议的发起方，不是已经跑通的中立层。
- 多 agent 编排本身有成本。 一个 agent 能解决的活儿，开三个只会多出协调开销和审核负担——多出来的这些审核，恰好就是 JetBrains 自己说”越来越贵”的那部分。别为了编排而编排。
- 移动端、Windows 相关的部分还在路上。 移动端标注即将推出；桌面版 Air 目前覆盖 macOS、Windows、Linux，浏览器版面向组织。
适合谁用，不适合谁用
适合： 团队里同时跑两种以上 AI 编程工具、说不清这个月 AI 花销的人；公司有合规或数据边界要求、agent 必须在受控环境里跑的团队；重度 JetBrains 用户——对 Java、Kotlin 项目来说，Air 能直接用 IntelliJ 的代码引擎做跳转、用法查找和符号搜索，改动后的错误警告也能在放行前看到，这个优势其他编辑器暂时给不了。单个 IDE 项目多但会话杂乱的独立开发者，也能靠它把几个 agent 的活儿摆到一张桌面上看。
不太适合： 一个人一个项目、已经在 Cursor 或 Claude Code 里跑得顺的开发者——加一层编排系统只会增加摩擦；Windows 主力机、又不想等的人；只想找免费 agent 的人——Air 本身的价值在编排和治理，不在模型。
替代方案怎么选： 想要执行层自主可控，看 Cursor 的自托管机器那条路；想要便宜的开源 CLI 加沙箱，9 月 19 日的 MiniMax Code CLI 值得试；只想让 agent 在终端里干活、不需要 IDE 图形编排，Claude Code 和 Codex 本身也够用。
老达点评
第一，JetBrains 这次卖的不是功能，是位置。 论单个 agent 的能力，它自家的 Junie 未必打得过 Claude Code。但 ACP 如果真成了 IDE 和 agent 之间的通用接线标准，那无论最后哪家模型领先，JetBrains 都握着那个路口。官方明说了”我们不要求用户用自家的 agent，策略也不取决于谁排第一”——这句话听起来像大度，其实是算过账的：做标准比做模型更稳。
第二，这波真正被承认的是”验证比生成贵”。 过去两年 AI 编程的叙事都在讲生成能力，JetBrains 作为 IDE 厂商反而把瓶颈说成理解和验证。这个观察对个人开发者最实用：与其纠结用哪个模型写代码，不如先把自己的验收流程设计好——改动能不能一眼看完、出事能不能查到是谁批的。Air 的产品设计就是把这件事做成了默认动作（改动预览、逐行评论、成本可见）。
第三，别被”开放”这个词带跑。 ACP 是真开放，但 Air Governance 的治理能力覆盖范围，现在还是画在纸上的目标。想上这条船的团队，建议先只做一件事：把 IDE 里那层用起来，把自己真实的 AI 花销和审查记录摸清楚，等 Air Teams / Air Governance 正式可用了，再决定要不要把治理权力交给一家 IDE 厂商。这也符合我们一贯的建议——先在能拿到数据的地方做实验，再谈制度。
