让多个AI Agent并行写代码？JetBrains 新工具 Air 来了
前言
最近，JetBrains 正式发布了 Air 的公开预览版（Public Preview）：让多个 AI Agent 并行写代码的全新工具。
一、Air 是什么
一个 Agentic Development Environment，不是给 IDE 加个 AI 聊天框，而是围绕 AI Agent 重新构建的开发环境。
1.1 什么是AI Agent的开发环境？
对比传统的IDE 你就会很清晰：
| 传统 IDE | Air |
|---|---|
| 人类写代码，AI 辅助 | AI 写代码，人类审查 |
| AI 是「副驾驶」 | AI 是「团队成员」 |
| 一次一个 Agent | 同时多个 Agent 并行 |
| Agent 直接改主分支 | Agent 在沙箱中工作 |
1.2 Air 主界面总览
- 左侧任务列表，右侧 Agent 工作区
- 整体设计围绕「任务管理」而非「文件编辑」
- 每个 Agent 拥有独立的任务卡片和执行状态
二、解决了什么问题？
在深入Air的特性之前，我们需要先理解：为什么需要一个专门的 Agent 运行环境？
2.1 当前 AI 辅助编程的真实痛点
对于GitHub Copilot、Cursor 再到各种 Agent 工具，你一定遇到过这些问题：
痛点一：Agent 碎片化
你可能同时在用 Cursor 写业务代码、用 Claude 做架构设计、用 ChatGPT 查问题。每个 Agent 都是独立的「信息孤岛」，它们之间无法共享项目上下文。你需要反复复制粘贴代码片段、手动描述项目结构。
痛点二：只能串行，不能并行
当你有一个需求需要同时改网络层、UI 层和测试层时——即使 AI 30 秒就能写完一个文件——你也只能一个接一个地排队等。这就像有一支 10 人团队，但只允许一个人干活。
痛点三：上下文窗口的「断崖」
大模型有 token 限制。当项目复杂到一定程度，Agent 对项目的理解就不可避免地「降级」。传统方案要么全量塞进去（超了），要么只塞当前文件（不够）。
痛点四：代码安全失控
现有工具中，Agent 的修改直接落在你的工作目录里。一旦改错了，你需要手动 git stash 或者 Ctrl+Z 多次回退。如果同时跑两个 Agent，产出的代码可能互相冲突覆盖。
痛点五：审查成本高
Agent 生成了 200 行代码，你需要逐行阅读来判断质量。但你无法快速看到「它到底改了什么」，没有 Diff 视图、没有冲突提示、没有一键回退。
2.2 传统 IDE 的「插件式 AI」为什么不够用
IntelliJ IDEA 加了 AI Assistant，VS Code 有 Copilot 插件——但本质上，这些方案都是在已有 IDE 架构上「叠加」AI 能力。
问题在于：传统 IDE 的架构是为人类单线程操作设计的——一个编辑器、一个终端、一条主分支。当你想让多个 Agent 同时工作时，这套架构就成了瓶颈：
- 文件系统只有一份，多个 Agent 会写入冲突
- 构建系统是单线程的，无法为每个 Agent 隔离编译环境
- 上下文管理没有为多并发设计
2.3 Air 的解法
不在旧架构上打补丁，而是从零设计一个「Agent-first」的开发环境：多Agent并行，每个 Agent 拥有独立的任务卡片和执行状态
三、核心卖点：五大能力
功能1：多 Agent 并发执行
你可以同时启动 Junie（JetBrains 自研 Agent）、Claude Code、OpenAI Codex 等多个 Agent，让它们各自处理不同的子任务。
实际场景：
需求：为 App 新增「收藏」功能Air 拆解为 3 个子任务：
Task A → Junie：写 Room 数据库 DAO + Repository
Task B → Claude：写 Compose UI + ViewModel
Task C → Codex：写单元测试 + 集成测试三个 Agent 同时开工，互不干扰。
传统方式下你需要等 A 完成才能开始 B（因为它们在同一个文件系统里操作），但在 Air 中，总耗时从「A+B+C」降为「max(A, B, C)」。
功能2：沙箱隔离环境
每个 Agent 工作在独立的 Git Worktree 中：相当于每个 Agent 有自己的分支和文件副本。
再配合 Docker 容器，Agent 可以自由执行命令（跑测试、启动服务、编译代码），不会影响你的主工作区。
这意味着：
- Agent A 正在重构某个文件时，Agent B 可以同时修改另一个文件
- Agent 执行
gradle build不会阻塞你的本地构建 - 任何时候都可以一键丢弃某个 Agent 的全部产出
功能3： 精准代码上下文
Air 继承了 IntelliJ 平台 26 年积累的代码索引能力：AST 解析、类型推导、依赖图、调用链分析。
这些信息以结构化的方式注入给 Agent，让它「真正理解」你的项目——而不是简单地把文本塞进上下文窗口。
对比现在的Agent方案：
| 方案 | 上下文策略 | 效果 |
|---|---|---|
| Copilot Chat | 当前文件 + 手动 @file | 简单场景够用，复杂项目不够 |
| Cursor | 全局 embedding 索引 | 能找到相关文件，但缺乏语义 |
| Air | AST + 类型 + 依赖图 + 编译信息 | Agent 理解项目结构如同 IDE 本身 |
功能4：Agent 自由切换
Air 支持 BYOK（Bring Your Own Key）。同一个任务执行到一半，如果你觉得当前 Agent 产出不满意，可以热切换到另一个模型继续，同时会话上下文不丢失。
这在实践中非常有用：
- Junie 擅长 Kotlin 代码风格，但遇到复杂算法不如 Claude
- Claude 产出质量高但速度慢，简单任务可以切到 Codex 提速
- 不同 Agent 对不同语言/框架的适配度不同
功能5：变更审查与编排
所有 Agent 的产出都以 Diff 形式呈现在审查面板中。
你可以：
- 逐文件查看修改内容
- 一键 Accept 或 Reject 单个文件 / 整个任务
- 看到冲突提示（如果两个 Agent 修改了同一区域）
- 在合入主分支前进行最终审查
开发者始终保有代码主权——AI 不会直接修改你的主分支。
四、与现有方案对比
| 维度 | Cursor | Windsurf | 多终端方案 | Air |
|---|---|---|---|---|
| 定位 | AI-native 编辑器 | AI 编辑器 | 手动组合 | Agent 运行环境 |
| Agent 数量 | 1 | 1 | N（手动） | N（统一管理） |
| 隔离方式 | 无 | 无 | 手动 stash/branch | Git Worktree + Docker |
| 上下文来源 | Embedding 索引 | 文件索引 | 手动复制 | AST + 编译信息 |
| 审查方式 | Inline Diff | Apply | 手动比对 | 统一审查面板 |
| Agent 切换 | 切换模型需重新对话 | 固定模型 | N/A | 热切换，上下文保持 |
| 平台支持 | 全平台 | 全平台 | 全平台 | 仅 macOS（当前） |
| 价格 | $20-40/月 | $15-50/月 | 各 Agent 费用之和 | Public Preview 免费 |
核心差异：
- Cursor 和 Windsurf 本质上是编辑器：它们优化的是「人+AI」在同一个文件上协作的体验。
- 而 Air 优化的是**「多个 AI 并行工作」的调度和管理体验**。
两者不一定互斥。你完全可以用 Cursor 做日常编辑，用 Air 做大型重构、多模块并行开发。
五、实战上手
下面来看下该如何实际使用Air
5.1 安装
- 前往 air.dev 下载 macOS 客户端（要求 Apple Silicon）
- 安装后登录 JetBrains 账号
- 配置 Agent API Key：
- Junie：内置，无需额外配置
- Claude：填入 Anthropic API Key
- Codex：填入 OpenAI API Key
5.2 打开项目
Air 的项目打开方式与 IntelliJ 类似——选择项目根目录即可。Air 会自动：
- 扫描项目结构
- 建立代码索引
- 检测构建系统（Gradle / Maven / npm 等）
5.3 启动多 Agent 并行任务
在 Air 的 Task 面板中：
1. 点击 "New Task"
2. 描述你的需求（自然语言）
3. Air 自动拆解为子任务（你可手动调整）
4. 为每个子任务分配 Agent
5. 点击 "Run All" → 并行启动
5.4 审查与合并
任务完成后，进入 Review 面板：
- 查看每个 Agent 的产出 Diff
- 运行自动化测试验证
- Accept → 合入主分支
- 或 Reject → 丢弃该 Agent 的全部修改
整个流程对 Git 操作者来说非常直觉：每个 Agent 的产出就像一个 Pull Request。
六、Air的局限
Air 仍处于 Public Preview 阶段，使用前需要了解以下限制：
6.1 平台限制
目前仅支持 macOS（Apple Silicon）。Windows 和 Linux 支持还在开发中。对于以 Windows 为主力开发机的团队，暂时无法使用。
6.2 Fleet 遗产的稳定性隐忧
Air 基于 Fleet 技术栈构建。Fleet 在公测期间以「性能不稳定」「功能缺失」著称，最终被砍。虽然 Air 团队声称已大幅重构底层，但 Fleet 的技术债是否完全清理干净，仍需时间验证。
6.3 Android 项目支持深度
目前 Air 对 Android 项目的支持集中在 Kotlin/Java 代码层面。以下场景的 Agent 效果仍待验证：
- Compose Preview 的实时渲染
- Gradle Build Variants 的正确切换
- Resource 文件（XML layout、strings）的智能修改
- ProGuard / R8 规则的感知
6.4 企业级功能空白
- 没有 Team 协作功能
- 没有审计日志
- 没有 SSO / SAML 集成
- 没有 on-premise 部署选项
对于有合规要求的企业，目前不适合在生产流程中引入 Air。
七、如何看待Air的发布？
7.1 为什么 JetBrains 做这件事说得通
JetBrains 做 Agent 运行环境有两个独一无二的优势：
- 代码理解深度：26 年 IDE 开发积累的 AST 解析、类型推导、依赖分析能力，这是 Cursor / Windsurf 等新玩家短期内无法复制的
- 开发者信任：全球超过 1200 万付费 IDE 用户，品牌信任已建立
Air 的逻辑是：如果 AI Agent 是未来的「劳动力」，那么 JetBrains 要做的不是被 Agent 替代，而是成为 Agent 的「工作平台」。
7.2 对 Android 开发者的影响
短期来看（6-12 个月）
- 试水阶段：在个人项目或 Side Project 中体验多 Agent 并行的开发节奏
- 能力储备：学会如何拆解需求为可并行的子任务——这本身是一种新的「架构能力」
- 关注集成：等待 Air 与 Android 工具链（Gradle、AGP、Compose）的深度集成
长期来看（1-3 年）
- 工作流变革：从「自己写代码」到「指挥 Agent 写代码、自己做架构决策和审查」
- 技能重心转移：代码实现能力的溢价降低，系统设计、需求拆解、质量审查的溢价上升
- 团队结构变化：一个人 + N 个 Agent 的生产力可能等于过去一个小团队
八、总结
Air 押注的方向是对的：AI Agent 需要一个比「聊天框」更好的运行环境。
但当前版本离「好用」还有距离。建议先关注、体验、储备认知，不必急于在生产项目中 all-in。
参考链接
- Air 官网：air.dev
- Air 官方博客：blog.jetbrains.com/air/2026/03…
