JetBrains Air，代理开发来了

JetBrains Air 正式亮相，开发环境开始围绕 Agent 重构

JetBrains 今天发布 JetBrains Air，一套面向 Agentic 软件开发的产品体系。Air 的核心不是再做一个带聊天框的 IDE，而是把 AI Agent 放到开发流程的中心，让开发者像管理一个并行工作的工程团队一样，拆分任务、分配代理、检查改动并决定最终合并什么。

Agentic 软件开发是指开发者通过 AI Agent 承担代码编写、调试、测试和重构等连续任务，并由人负责目标设定、过程监督与最终验收。 与传统的代码补全不同，Agent 不只生成几行代码，而是可以理解任务、修改多个文件、运行命令、执行测试，并根据结果继续迭代。

JetBrains 对 Air 的定位也很明确：它不是 IntelliJ IDEA 的简单升级版，也不是 VS Code 的直接替代品，而是建立在现有 IDE 之上的一层 Agent 编排环境。IDE 继续承担代码理解、导航、调试和精细编辑，Air 则负责把复杂的软件任务交给一个或多个代理执行。

从“写代码”转向“调度代理”

Air 最值得关注的变化，是它把开发者与 AI 的交互单位从单次问答，提升到了完整任务。

在传统 AI 编程工具中，开发者通常需要打开一个编辑器，输入一段指令，然后等待模型修改当前代码。任务一旦变复杂，就会出现几个问题：上下文不完整、不同代理之间无法共享工作状态、多个任务不能同时推进，开发者还需要在终端、编辑器和聊天窗口之间不断切换。

JetBrains Air 是一个以 Agent 为中心的开发环境，开发者可以在其中向多个 AI Agent 分派任务，并让它们并行运行。 这意味着一个真实的软件需求可以被拆成多个相互独立的工作流，例如：

• 让一个 Agent 分析现有代码并提出重构方案；
• 让另一个 Agent 编写单元测试；
• 让第三个 Agent 调查某个线上报错的可能原因；
• 让第四个 Agent 更新文档或补充类型定义。

这些任务不必排队执行。开发者可以同时启动多个代理，让它们分别在独立工作区中修改代码，最后再对比不同结果。

这套模式更像是把 AI 从“副驾驶”变成了一个可以被调度的工程团队。开发者不再需要亲自完成每一次编辑，而是要做任务拆解、上下文准备、结果评估和风险控制。

不绑定单一模型，Agent 可以自由切换

Air 的第二个关键设计是 Agent-agnostic，也就是不绑定单一模型或单一代理供应商。

Agent-agnostic 是指开发环境不把开发者锁定在某一个 AI Agent 上，用户可以根据任务类型自由切换、组合和比较多个代理。 这点对真实开发尤其重要，因为不同模型在代码生成、长上下文理解、终端操作、测试修复和前端实现上的表现并不一样。

根据 JetBrains 的介绍，Air 可以接入多种主流 AI Agent，包括 Claude、Codex、Gemini 以及 JetBrains 自家的 Junie 等。开发者可以针对同一个任务运行多个代理，然后比较它们的实现路径、改动范围和测试结果。

| 对比维度 | 传统单 Agent 工作流 | JetBrains Air 的多 Agent 工作流 | |---|---|---| | 任务执行 | 通常按顺序处理 | 多个任务可以并行运行 | | 模型选择 | 常绑定单一工具或模型 | 可以在不同 Agent 之间切换 | | 结果评估 | 主要依赖一次输出 | 支持并排比较多份结果 | | 工作区 | 多数情况下共享当前目录 | 可使用独立工作区隔离改动 | | 人的角色 | 频繁编辑和纠错 | 任务拆解、监督和验收 | | 适合场景 | 小范围补全、局部修改 | 重构、测试、调研和多文件任务 |

这个设计的价值并不只是“可以同时打开更多聊天窗口”。真正的差异在于，Air 试图把不同 Agent 的执行过程放进同一个任务管理框架里，让开发者能看到每个代理正在做什么、修改了什么，以及它们之间的结果差异。

对于大型代码库来说，这种可比较性比单纯追求某个模型的最高基准分更重要。一个代理可能给出更短的实现，另一个代理可能更重视测试覆盖率，还有一个代理可能更擅长识别历史代码中的隐含约束。Air 的意义，是让这些方案可以被放在同一张工作台上评估，而不是被分散在不同工具里。

并行不等于无脑自动化

JetBrains 并没有把 Air 包装成“完全自动驾驶”的开发工具。恰恰相反，官方对复杂代码库的判断相对克制：当前的软件项目还没有准备好完全交给 Agent 独立完成。

Air 的目标不是取消人的参与，而是把人的参与从逐行写代码转移到更高层的任务编排和代码审查。 这也是它与部分强调端到端自动编码产品的区别。

复杂代码库通常存在大量模型难以直接观察的约束：

1. 某些接口虽然没有写在文档里，却被多个服务依赖；
2. 一个看似简单的重构，可能影响构建系统、部署脚本和监控配置；
3. 测试全部通过，并不代表行为符合产品需求；
4. 代码风格、性能预算和安全边界往往需要结合团队经验判断。

因此，Air 更像是给开发团队增加了一层并行执行能力，而不是让 Agent 直接接管整个仓库。开发者仍然需要决定任务边界，检查代理生成的计划，审阅代码差异，并通过测试和人工验证确认结果。

这也是 JetBrains 强调“Air 负责 Agent 驱动的开发，现有 IDE 负责其余工作”的原因。Air 的价值，不在于把所有开发环节都塞进一个窗口，而在于把不同工具之间原本割裂的 Agent 工作流组织起来。

Local、Git Worktree 和 Docker：隔离是关键能力

多 Agent 并行运行的前提，是每个代理不能随意覆盖其他代理的工作。Air 因此提供了多种运行和隔离方式，包括本地环境、Git Worktree 以及 Docker 等方案。

Git Worktree 是 Git 提供的多工作目录机制，可以让同一个仓库在不同目录中同时检出多个分支。 对 Agent 工作流而言，它的作用是让多个代理分别在独立分支或目录中工作，避免一个 Agent 的实验性修改污染另一个 Agent 的任务。

三种方式各有取舍：

| 运行方式 | 主要特点 | 适合场景 | 潜在问题 | |---|---|---|---| | Local | 直接使用本机开发环境，启动成本最低 | 快速修改、熟悉项目、轻量任务 | 环境污染和文件冲突风险较高 | | Git Worktree | 为不同任务提供独立工作目录和分支 | 并行开发、方案比较、重构实验 | 需要理解分支、合并和依赖状态 | | Docker | 通过容器隔离运行环境和依赖 | 高风险任务、环境复杂项目、可复现执行 | 启动和配置成本更高，权限管理更复杂 |

隔离机制看起来不像模型能力那样吸引眼球，但它可能是 Agent 开发工具能否进入真实团队的关键。只要多个代理共用同一个工作目录，所谓并行开发很快就会变成文件冲突、依赖覆盖和无法追责的混乱。

从这个角度看，Air 的产品重点并不只是“接入更多模型”，而是补齐了多代理协作需要的工程基础设施。谁修改了哪个文件、哪个任务基于什么状态开始、不同方案如何比较，都是企业开发环境必须解决的问题。

它与 IntelliJ IDEA、Cursor、Claude Code 有什么不同

JetBrains Air 进入的是一个已经高度拥挤的 AI 编程工具市场。Cursor、Windsurf、Claude Code、Codex、Gemini CLI 和 Junie 等产品，都在争夺开发者的工作流入口。Air 能否突围，取决于它是否解决了这些工具尚未解决的问题。

| 产品或工具 | 核心定位 | 多 Agent 并行 | IDE 能力 | 主要优势 | |---|---|---:|---:|---| | JetBrains Air | Agentic Development Environment | 是 | 与 JetBrains IDE 工作流协同 | 任务编排、代理切换、结果比较 | | IntelliJ IDEA | 传统专业 IDE | 不是核心能力 | 强 | 代码理解、调试、重构和工程支持 | | Cursor | AI 原生代码编辑器 | 部分支持 | 中到强 | 编辑器内的模型交互和代码修改 | | Claude Code | 终端型编码 Agent | 通常单任务为主 | 依赖外部 IDE | 终端操作、仓库级任务执行 | | GitHub Copilot | AI 编程助手体系 | 取决于具体产品 | 依赖宿主环境 | 生态覆盖广、集成范围大 | | Junie | JetBrains Agent | 由 JetBrains 定义 | 与 JetBrains 生态结合 | JetBrains 项目理解和开发流程 |

Air 最直接的竞争对象并不是传统 IDE，而是“如何管理多个编码 Agent”这一层工具。它的差异化也不在于单次代码生成质量一定超过所有竞争对手，而在于是否能让不同 Agent 在同一个开发任务中协作和竞争。

这是一条更偏平台化的路线。JetBrains 不需要押注某一个模型永远领先，而是把自己放在模型之上，成为开发者组织 AI 工作的入口。如果模型能力继续快速变化，这种策略理论上更有弹性。

但它也带来新的问题：当 Agent 越来越多，开发者是否真的有能力管理它们？如果每个任务都需要人工比较四五份实现，审查成本可能反而上升。Air 能否提供可靠的任务状态、差异摘要、测试证据和风险提示，将决定它最终是提高生产力，还是把开发者变成一个更忙的 AI 项目经理。

公开预览意味着什么

JetBrains Air 目前以 Public Preview 形式面向开发者开放。此前，JetBrains 已经在 2026 年 3 月发布 Air 的公开预览版本，如今的产品体系进一步明确了它在 JetBrains AI 工具矩阵中的位置。

公开预览阶段的 Air，重点不是证明所有任务都能自动完成，而是验证一种新的开发交互：开发者是否愿意把任务拆给多个 Agent，是否愿意在不同实现之间进行选择，以及现有 IDE 和 Agent 编排环境之间应该如何分工。

根据目前披露的信息，开发者可以通过 JetBrains AI 订阅，或使用已拥有的相关 Agent 服务订阅来体验 Air。具体可用 Agent、地区、权限和计费方式可能随预览阶段持续调整，团队在正式导入前仍需要确认当前版本的访问条件。

对于个人开发者，Air 更适合尝试这些场景：

• 对同一个重构任务生成两到三种实现并进行比较；
• 把测试补全、文档更新和代码实现拆成并行任务；
• 让一个 Agent 负责定位问题，另一个 Agent 负责提出修复方案；
• 在不影响主分支的情况下，让 Agent 处理探索性修改；
• 用不同模型验证同一份需求是否存在理解偏差。

对于团队，真正值得评估的是以下几个指标：

• Agent 修改后的测试通过率；
• 每个任务需要人工返工的代码比例；
• 多工作区管理是否增加了合并成本；
• Agent 是否能稳定遵守项目级规范和权限边界；
• 运行多个代理后，模型成本和开发收益是否匹配。

OpenAI Hub 判断：JetBrains 押注的是“Agent 操作系统”

JetBrains Air 的发布，说明 AI 编程工具的竞争正在从“谁的模型更聪明”转向“谁能更好地组织模型完成软件工程”。

Agent 编排是指对多个 AI Agent 的任务分派、运行隔离、上下文管理、结果比较和最终合并进行统一控制。 在模型能力逐渐趋同之后，这一层会越来越重要。软件开发不是一次性生成代码，而是由需求分析、设计、实现、测试、评审和发布组成的长流程。谁能把这些环节连接起来，谁就更接近真正的开发平台。

JetBrains 的优势在于拥有 26 年 IDE 产品经验，理解大型代码库、语言服务、重构工具和开发者工作流；它的短板则是 Air 仍处在早期阶段，需要证明复杂项目中的稳定性，也需要让开发者相信多 Agent 不会带来更多噪声和管理负担。

我们的判断是：Air 目前更像一个值得关注的开发基础设施，而不是可以立刻替代现有 IDE 的完整产品。它最有价值的场景，是把原本需要几个小时甚至几天的并行探索工作交给多个 Agent 同时推进；它最需要警惕的地方，则是代理数量增加后，审查和合并成本可能吞掉自动化收益。

如果 JetBrains 能进一步打通代码索引、测试结果、Git 历史、任务追踪和 Agent 记忆，Air 有机会成为 JetBrains 生态中连接 IDE 与 AI Agent 的关键入口。反过来，如果它只是把多个现有 Agent 放在同一个窗口里，缺少对任务状态和工程上下文的深度理解，那么它最终可能只是一个更漂亮的 Agent 管理器。

无论结果如何，JetBrains 今天的发布都释放出一个清晰信号：下一代开发环境的核心界面，可能不再是文件树和代码编辑器，而是一个由人负责决策、由多个 Agent 负责执行的任务系统。