JetBrains Air 深度解析：当 IDE 围绕 AI Agent 重建，多智能体并发开发究竟意味着什么

2026 年 3 月 9 日，JetBrains 悄悄上线了一个叫 Air 的工具，没有发布会，只有一篇博客。但它提出的问题，却让很多开发者停下来认真思考：我们现在用的 AI 编程工具，是不是方向就错了？

Cursor 在 VS Code 里加 Agent，GitHub Copilot 在编辑器里加对话框，JetBrains 自己也在 IntelliJ 里塞进了 AI 助手。大家的思路都是一样的：把 AI 嵌进 IDE。

Air 的答案截然不同：把 IDE 建在 AI Agent 周围。

背景：一场正在发生的范式转变

AI 编程工具的第一代：嵌入式助手

2021 年 GitHub Copilot 发布，开启了"AI 辅助编程"的第一个时代。这一代工具的核心逻辑是：开发者还是主体，AI 是助手。你在编辑器里写代码，AI 在旁边提示、补全、回答问题。

这个范式运行得很好，但它有一个根本性的约束：AI 的能力被限制在"补全"这个动作上。即便后来的 Cursor Composer、Claude Code、Copilot Agent 开始支持多文件编辑和自动执行命令，它们的 UI 框架仍然是以代码编辑器为中心的——AI 在一个对话框里工作，开发者在旁边看着。

第二代的核心问题：Agent 需要一个不同的工作流

当 AI Agent 能够自主执行长时间、多步骤的任务时，原来的工作流开始出现裂缝：

1. 上下文太粗糙：对话框只能输入文本，你没法精确告诉 Agent "去改第 142 行的那个函数"，只能粘贴一大段代码
2. 并发没有支撑：Agent 跑任务时你只能等，或者开多个窗口手动管理，混乱不堪
3. 审查工具缺失：Agent 改了 20 个文件，你只有一个 diff，没法在整个项目上下文里理解这些变更是否正确
4. 多 Agent 孤岛：Claude Agent、Codex、Gemini CLI 各自独立，每个用不同工具、不同设置，切换成本极高

JetBrains Air 就是针对这四个问题从零设计的。

Fleet 的"遗产"

值得一提的是，Air 构建在 JetBrains 2024 年底关闭的 Fleet IDE 代码库之上。Fleet 当年定位是"下一代轻量级 IDE"，但最终因为与 IntelliJ 生态重叠太多而被放弃。不过它的现代化架构——脱离了 25 年历史的 IntelliJ 平台——恰好成为 Air 实现任务级隔离和多进程并发的技术基础。一个"失败"的产品，以这种方式找到了它的使命。

JetBrains Air 是什么

官方定义是：Agentic Development Environment（ADE，智能体开发环境）。

这个名字里没有"IDE"，这不是笔误。JetBrains 非常明确地表示：Air 不是传统 IDE，它的定位是 IDE 的补充，而不是替代品。

"Air handles the agent-powered development; your IDE handles the rest." ——JetBrains Air 官方文档

具体来说，Air 做的事情是：让你把一批编码任务分发给多个 AI Agent，让它们并发地在隔离环境里执行，然后提供工具帮你审查、合并结果。

你依然需要一个传统 IDE 来做日常的代码阅读、调试、重构；Air 负责那些"我不想亲自敲键盘，让 Agent 去做"的任务。

核心能力详解

能力一：多 Agent 并发执行

Air 当前内置支持四个 Agent：

这四个 Agent 可以同时运行在不同任务上。你可以让 Claude Agent 处理一个复杂的业务逻辑重构，同时让 Codex 在另一个任务里补充单元测试，互不干扰。

在 Agent 切换方面，Air 支持 Agent Client Protocol（ACP）——一个由 JetBrains 和 Zed 共同主导的开放标准，作用类似 LSP（语言服务器协议），但针对 AI Agent。目前 ACP Registry 里已有 Cursor、Gemini CLI、GitHub Copilot、Mistral Vibe 等多个 Agent。这意味着未来你可以在 Air 里一键切换任何支持 ACP 的 Agent，不被任何单一厂商锁定。

能力二：精确上下文传递

这是 Air 区别于"在对话框粘贴代码"的核心差异。

在 Air 中，你可以通过 @ 符号引用：

• 具体的代码文件或目录
• 特定 Git 提交（git commit）
• 特定 Git 分支
• 代码中的类、方法、函数等符号（Symbol）
• 终端输出
• 本地未提交的变更

这意味着你可以写出这样的任务描述：

参考 @commit:a3f2c1b 里引入的接口规范，重构 @UserService.processPayment() 方法，使其符合新的错误处理模式，参考 @src/utils/errors.ts

Agent 拿到的不是一段文字，而是真实的、有结构的代码上下文。这对任务质量的影响是本质性的。

能力三：三种隔离模式

这是 Air 在并发安全方面的关键设计。

Local Workspace：直接在你的当前工作目录运行。启动最快，但 Agent 的所有修改都直接作用在项目文件上，不适合并发。

Git Worktree：为每个任务创建一个独立的 Git 工作树（一个仓库的多个并发检出）。文件系统级别的隔离，不同任务在不同分支上工作，互不影响。任务完成后 Air 会帮你把变更合并回主工作区。这是最推荐的并发模式。

Docker Container：在完全隔离的容器里运行 Agent，包括代码、命令和依赖都在容器内。这是隔离级别最高的方式，适合那些需要安装特定依赖、或者有破坏性操作风险的任务。需要本地安装 Docker Desktop。

能力四：代码审查工作流

任务完成后，Air 提供了一套专门为 Agent 输出设计的审查工具：

• Diff 面板：支持 Unified（单页对比）和 Side-by-side（双栏对比）两种视图
• Inline Comment：类似 GitHub 的代码审查，可以在 diff 的任意行添加注释，这些注释会自动进入下一轮任务的上下文，Agent 据此继续迭代
• 全局预览：不只是看代码 diff，还可以在完整项目上下文里查看变更的影响
• 内置 Web Preview：对于前端项目，Air 可以直接预览运行结果，不需要切换到浏览器

这个设计解决了一个实际痛点：Agent 改了很多文件，你不知道该相信还是不相信，也不知道怎么给反馈。现在有了专门的工具。

能力五：MCP 服务器支持

Air 支持连接 MCP（Model Context Protocol）服务器，为 Agent 提供额外的工具能力。比如连接数据库、调用外部 API、访问文档系统等。配置方式是在设置里以 JSON 格式添加 MCP 服务器：

{
  "mcpServers": {
    "your-service": {
      "command": "uvx",
      "args": ["your-mcp-server", "YOUR_API_KEY"]
    }
  }
}

使用场景

场景一：并行处理多个独立功能

最典型的使用场景。项目里有三个相对独立的 Issue，传统做法是按顺序处理，或者手动开三个终端窗口各自运行 Claude Code。

在 Air 里，你可以为三个 Issue 各建一个任务，分别在不同的 Git Worktree 里并发运行。你坐下来喝咖啡，Air 会在某个任务需要你介入时发出通知。

场景二：探索性开发

你对某个技术方案不确定，想同时试两种实现。可以让 Claude Agent 做方案 A，Codex 做方案 B，在两个独立的容器里并行跑，最后对比结果再做决定。

场景三：快速学习新技术栈

JetBrains AI 总监曾分享过一个案例：他用一个晚上，用从未接触过的 Go 语言写出了一个功能完整的 CLI 工具。做法是给 Agent 足够详细的任务描述和参考资料，然后通过不断在 diff 面板提反馈来迭代，就像和一个 Go 专家结对编程。

场景四：测试补全

在已有业务代码的基础上，让一个 Agent 专门负责补充单元测试和集成测试。任务描述可以这样写：

为 @src/services/ 目录下的所有服务类补充单元测试，参考 @src/tests/UserService.test.ts 的风格和覆盖率标准，使用 Git Worktree 隔离，不要修改任何非测试文件

场景五：遗留代码现代化

对一个老项目的某个模块做重构——比如把回调地狱改成 async/await，或者把 CommonJS 迁移到 ESM。这类任务范围明确、规则清晰，非常适合交给 Agent。用 Docker 隔离可以避免影响主工作区。

如何使用

第一步：下载安装

从 air.dev 下载 macOS 版本（目前仅支持 macOS，Windows/Linux 版本计划 2026 年推出）。

第二步：连接 AI Provider

首次启动会引导你连接 AI Provider。支持以下方式：

• JetBrains AI 订阅：如果你有 JetBrains AI Pro 或 AI Ultimate 订阅，登录 JetBrains 账号后所有内置 Agent 均可用
• BYOK（自带 API Key）：分别连接 Anthropic、OpenAI、Google AI Studio 账号。适合已有相应订阅的用户
• ChatGPT/Google 个人账号：直接用现有的 Plus/Pro/Workspace 账号登录，不需要单独的 API 计费

设置路径：⌘+, → Account → AI Providers

第三步：打开项目

点击 Open 选择本地项目，或点击 Clone from Git 输入仓库地址。首次打开需要点击 Trust 以允许 Air 执行项目代码（如运行脚本、git 命令等）。

第四步：定义任务

新建任务快捷键：⌘+\

任务定义是 Air 使用体验的核心。建议遵循以下原则：

1. 明确目标：说清楚要做什么，不要模糊
2. 提供上下文：用 @ 引用相关文件、函数、提交，而不是粘贴代码
3. 说明约束：比如"不要修改 API 接口"、"保持现有的错误处理风格"
4. 可以先用 Plan 模式：在正式运行前，先让 Agent 制定执行计划，你确认后再开始

示例任务描述：

基于 @UserService.ts 里的现有结构，为用户注册流程增加手机验证码校验。
参考 @src/validators/ 里的现有验证器风格。
需要新增：
1. 发送短信验证码的接口（参考 @config/sms.ts 里的配置）
2. 校验验证码的中间件
3. 注册接口里加入校验逻辑

不要修改现有的密码验证逻辑。

第五步：选择执行环境和权限模式

权限模式决定 Agent 在执行过程中是否需要你授权：

• Ask Permission：每次使用新工具前询问
• Auto-Edit：自动接受文件编辑，命令执行仍需授权
• Full Access：跳过所有授权提示（适合信任度高的任务）
• Plan：只分析，不执行任何修改

第六步：审查和提交

任务完成后在 Changes 标签页审查变更：

1. 查看 diff，理解 Agent 做了什么
2. 对不满意的地方，在 diff 行上点击图标添加 Inline Comment
3. 这些 Comment 会成为下一轮任务的输入，Agent 继续迭代
4. 满意后选择文件 → 填写 commit message → Commit → Push

最佳实践

实践一：任务粒度要适中

太小的任务（改一行）不值得为它建一个 Agent 任务；太大的任务（重构整个系统）Agent 很难一次做好。

经验法则：一个任务对应一个 Pull Request。如果这个任务做完后需要一个 PR，那它的粒度就是合适的。

实践二：优先使用 Git Worktree

除非任务极其简单，否则永远使用 Git Worktree 模式。它能保证：

• 并发安全：多个 Agent 不会互相踩脚
• 主分支干净：你随时可以在主工作区工作，不受 Agent 进行中的变更影响
• 轻松回滚：不满意直接丢弃整个 worktree

实践三：把 Agent 当初级工程师，不是魔法

Agent 会犯错，会误解需求，会做多余的事情。在任务描述里明确写出"不要做什么"，往往比写"要做什么"更重要。

同时，用 Plan 模式先让 Agent 展示它的执行计划，确认方向正确再让它真正动手，可以避免大量的无效返工。

实践四：在 diff 面板做精准反馈，不要重新开始

任务没做好，不要直接取消任务重来，而是在 diff 面板的具体代码行上添加注释，告诉 Agent 哪里有问题、应该怎么改。这样 Agent 有完整的上下文，修改质量会好很多。

实践五：让 Air 和你的 IDE 分工明确

Air 不适合：

• 实时代码补全
• 调试和断点
• 复杂重构（提取方法、重命名等）
• 阅读和理解代码

这些事情继续在 IntelliJ / VS Code / Cursor 里做。Air 只做"可以委托给 Agent 异步执行"的任务。

实践六：用 MCP 扩展 Agent 的能力边界

如果你的任务涉及外部服务（比如查数据库、读 API 文档、访问设计稿），通过 MCP 服务器把这些能力接入 Air，Agent 就可以真正端到端地完成任务，而不是在没有信息的情况下瞎猜。

真实案例

案例一：微服务并行开发

一个后端团队在开发 Kotlin 微服务时，需要同时处理：

• 服务 A 的性能优化
• 服务 B 的新功能开发
• 全局的单元测试补全

他们用 Air 为三个任务各建了一个 Git Worktree，分配给不同的 Agent 并发运行。整个过程里，开发者只需要在关键节点做决策——确认执行计划、审查关键变更——而不是亲自敲每一行代码。

案例二：一晚上搞定陌生语言

JetBrains AI 团队负责人分享了一个亲身经历：他需要用 Go 语言编写一个 CLI 工具，但自己没有写过 Go。他把需求拆解成多个任务，通过 Air 的交互式任务模式，不断在 diff 面板提反馈——"这里的错误处理应该更明确"、"这个函数命名不符合 Go 惯例"——最终在一个晚上完成了这个工具。

他的评价是：这就像和一个 Go 专家结对编程，但这个专家不会累。

案例三：V2EX 开发者的早期体验

在 V2EX 关于 JetBrains Air 的讨论中，有开发者反馈："简单用了下体感不错"，认为 Air 的多 Agent 管理思路是有价值的方向。不过也有人指出当前的限制：暂不支持 Ollama 等本地模型，对于有隐私需求或成本敏感的开发者是一个障碍。

局限性与注意事项

当前限制

平台限制：目前仅支持 macOS。Windows 和 Linux 版本 JetBrains 承诺会在 2026 年推出，但尚无确切日期。

本地模型不支持：BYOK 模式仅支持 Anthropic、OpenAI、Google 的云端 API，不支持 Ollama、LM Studio 等本地部署方案。对于有数据隐私要求或希望控制成本的开发者，这是一个重要限制。

依赖成本：使用 Air 需要 AI Provider 的订阅或 API 费用。多 Agent 并发意味着 Token 消耗也是并发的，成本要比单 Agent 模式高。

不替代 IDE：Air 没有代码补全、没有调试器、没有语法高亮。它只是一个任务编排和审查平台，你仍然需要一个传统 IDE 作为主力工具。

复杂代码库的局限：JetBrains 自己承认："Complex codebases aren't yet ready for pure agentic coding."（复杂代码库还没准备好纯粹的 Agent 化编程。）对于架构复杂、上下文依赖深的大型项目，Agent 的自主能力仍然有限。

选型建议

如果你：

• 是 macOS 用户 ✓
• 有 JetBrains AI 订阅或已有 Anthropic/OpenAI/Google 账号 ✓
• 日常工作有大量可以"委托出去"的编码任务 ✓
• 需要同时推进多个功能或 Issue ✓

那么 Air 值得认真试用。

如果你：

• 主力在 Windows 或 Linux 上开发 ✗
• 对数据隐私要求严格，必须用本地模型 ✗
• 日常工作以代码阅读和理解为主，而不是编写 ✗

那么目前可以继续观望。

总结

JetBrains Air 代表的不是一个新工具，而是一个新的工作方式假设：在 AI Agent 能力足够强的时候，开发者的核心工作会从"写代码"变成"定义任务、审查结果、做决策"。

它现在还很早期——只有 macOS，不支持本地模型，很多边缘能力还没完善。但它提出的架构思路：多 Agent 并发、精确上下文、任务级隔离、专用审查工具，是当前所有 AI 编程工具里最系统性的一次设计。

更有意思的是，它选择不打败 IntelliJ，而是说"你继续用你的 IDE，我来处理你不想亲自动手的那部分"。这种清醒的产品定位，在 AI 工具普遍夸大宣传的今天，本身就值得关注。

对于开发者来说，现在不是 Air 全面取代现有工具的时候，但这绝对是值得花一个下午认真体验的方向。毕竟，理解下一个范式是什么样的，比等它成熟了再追赶，要划算得多。

参考资料：

• JetBrains Air 官方博客
• JetBrains Air 官方文档
• Agent Client Protocol (ACP)
• ACP Agent Registry 发布公告