JetBrains Air 多AI编码评测：同时运行Agent写代码效果

一、Air 是什么

简单来说，它是一个 Agentic Development Environment，也就是一个专为 AI Agent 而生的开发环境。它不是给 IDE 再加一个聊天框，而是围绕 AI Agent 重新构建了整个开发底座。

1.1 什么是AI Agent的开发环境？

跟传统 IDE 一对比，它的不同就非常清晰了：

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 的解法

Air 的思路很直接：不在旧架构上打补丁，而是从零设计一个「Agent-first」的开发环境。多个 Agent 可以并行工作，每个 Agent 都拥有独立的任务卡片和执行状态。

三、核心卖点：五大能力

功能1：多 Agent 并发执行

你可以同时启动 Junie、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：精准代码上下文

这背后，是 IntelliJ 平台 26 年积累的代码索引能力在支撑：AST 解析、类型推导、依赖图、调用链分析。

这些信息会被以结构化的方式注入给 Agent，让它能“真正理解”你的项目——而不是简单地把文本塞进上下文窗口。

对比现在的其他方案，差距一目了然：

功能4：Agent 自由切换

Air 支持 BYOK（Bring Your Own Key）。同一个任务执行到一半，如果你觉得当前的 Agent 产出不满意，可以热切换到另一个模型继续，并且会话上下文不会丢失。

这个功能在实际操作中非常实用：

• Junie 擅长 Kotlin 代码风格，但遇到复杂算法不如 Claude
• Claude 产出质量高但速度慢，简单任务可以切到 Codex 提速
• 不同 Agent 对不同语言/框架的适配度不同

功能5：变更审查与编排

所有 Agent 的产出都以 Diff 形式呈现在一个审查面板中。

你可以：

• 逐文件查看修改内容
• 一键 Accept 或 Reject 单个文件 / 整个任务
• 看到冲突提示（如果两个 Agent 修改了同一区域）
• 在合入主分支前进行最终审查

开发者始终保有代码主权——AI 不会直接修改你的主分支。

四、与现有方案对比

核心差异在哪里呢？

• Cursor 和 Windsurf 本质上是编辑器：它们在优化“人+AI”在同一个文件上协作的体验。
• 而 Air 优化的是**“多个 AI 并行工作”的调度和管理体验**。

二者不一定互斥。你大可以用 Cursor 做日常编辑，用 Air 来做大型重构、多模块并行开发。

五、实战上手

5.1 安装

1. 前往 air.dev 下载 macOS 客户端（要求 Apple Silicon）
2. 安装后登录 JetBrains 账号
3. 配置 Agent API Key：
   • Junie：内置，无需额外配置
   • Claude：填入 Anthropic API Key
   • Codex：填入 OpenAI API Key

5.2 打开项目

Air 的项目打开方式跟 IntelliJ 很像——选择项目根目录即可。Air 会自动：

• 扫描项目结构
• 建立代码索引
• 检测构建系统（Gradle / Ma ven / 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/Ja va 代码层面。以下场景的 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 运行环境，有两个几乎是“天赋”的优势：

1. 代码理解深度：26 年 IDE 开发积累的 AST 解析、类型推导、依赖分析能力，这是 Cursor 这类新玩家短期内很难复制的
2. 开发者信任：全球超过 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。