JetBrains推出Air：构建面向智能体软件开发的产品体系
AI 能生成代码，但组织仍需交付软件。智能体开发正在改变软件的构建方式，却没有改变出错的代价。
六个月前，我们开始公开实验智能体开发环境。大约在同一时间，我们推出了 JetBrains Central，作为面向智能体驱动开发的开放控制与执行系统。随后，我们开始为团队和组织推出 JetBrains Central CLI、共享上下文、云端智能体、自动化、治理以及 AI 成本控制。
今天，我们将这些工作整合为 JetBrains Air：一个开放、连贯的产品体系，面向开发者、团队和组织，覆盖 JetBrains IDE 内外。它横跨多个界面和多种服务。每个产品解决一个不同的问题，但产品协同工作时效果更好。
JetBrains Air 标志着 JetBrains 构建目标的重大扩展。26 年来，我们主要专注于个人开发者工作台。如今，我们正在为更广泛的系统而构建，智能体工作正是通过这一系统被发起、执行、协调、审查和治理。
IDE 对 JetBrains 的未来仍然重要。整个软件开发系统都能被容纳在一个窗口中的时代正在结束。作为持续投入的一部分，我们现在将基础智能体体验引入 JetBrains IDE，为专业开发者提供一个能够与智能体高效协作，同时理解、修改并验证所生成代码的环境。JetBrains Air 连接着围绕它发展起来的更广泛系统。
这一系统基于一个核心理念：智能体开发的未来将是多厂商的。没有单一模型、智能体或服务能适合每一位开发者、每个团队或每项任务。
从一个产品到开放的产品体系
这一战略转变带来一个实际结果：JetBrains Air 不能只是又一个智能体或开发环境。它必须连接面向个人工作、团队协调、组织控制、上下文和流程自动化的产品——并对开发者所选择的工具和智能体保持开放，包括并非由 JetBrains 构建的那些。
JetBrains Air 既包含今天已可用的产品，也包含将随系统发展而推出的产品：
- JetBrains IDE 中的 Air —— 一套完整的智能体开发体验，用于在 JetBrains IDE 内指挥和编排智能体，并验证其工作。
- Air Teams —— 协调和自动化涉及开发者与自主智能体的软件交付工作流的新方式。
- Air Governance（原 JetBrains Central）—— 面向 AI 辅助和智能体驱动开发的组织策略、可见性、可审计性、成本管理与问责机制。
[LOADING...]
Junie 是 JetBrains 面向专业软件开发的编码智能体。它将在所有 Air 界面中得到支持。
JetBrains IDE 中的 Air 为开发者提供环境，让他们使用 JetBrains 的代码智能来指挥智能体并验证其输出。Air Teams 将单个智能体活动转化为协调的团队工作流。Air Governance 让这些活动在整个组织范围内可见、可治理、可问责。
但一个开放系统不能止步于 JetBrains 自家产品。Agent Client Protocol（ACP）标准化了 IDE 与智能体完整运行框架之间的连接，包括其规划、逻辑、工具、模型路由和可观测性。通过 ACP Registry，开发者可以发现并运行越来越多兼容的智能体，同时继续在 JetBrains IDE 内工作。
Air Governance 旨在将可见性和成本治理扩展到不同提供商以及智能体工作所经由的各种工具。这意味着开发者可以选择适合任务的智能体、模型或服务，而不会迫使组织放弃上下文、可见性或控制权。
Air 产品共同让工作能够在开发者、智能体、工具和环境之间流转，同时不丢失围绕它的上下文与控制。
个人采用速度已超过组织基础设施建设
自 3 月以来，我们的产品取得了显著进展，同时我们对智能体开发所需条件的理解也大为加深。
开发者采用智能体的速度，快于组织围绕其构建基础设施的速度。智能体能力不断进步，不同模型和智能体已被证明适用于不同任务。然而，围绕它们的上下文、协调、治理和成本管理并未跟上。
对许多开发者而言，智能体已经在交付实际价值。在组织层面，其经济性要难证明得多。成本会出现在别处——审查、返工、安全、基础设施和支出。
哪些智能体可以访问公司代码？数据可以去往哪里？哪些输出需要人工审查？智能体远程工作期间发生了什么？谁批准了最终变更，又是如何验证的？
这一层面的碎片化不仅令人恼火。恰在更多工作被委派出去之时，它让软件开发更难理解、衡量和治理。
瓶颈正随工作方式转移
明显错误的代码会很快被发现。系统的这部分仍然有效。更难的问题是那些几乎正确的代码：看似合理、能通过表面检查，却悄悄携带着错误假设或架构不一致，直到代价高昂时才暴露出来。
随着智能体承担更多执行工作，瓶颈从产生变更转向理解、验证并对其负责。代码生成变得更便宜，但验证变得更昂贵。智能体活动更容易启动，却更难协调、审计和解释。
工作可以委派，责任却不能。凌晨 3 点出故障时，智能体不会接到电话。交付内容的最终责任，仍属于交付它的个人和组织。
这就是为什么随着 AI 进步，控制变得更难，而非更容易。能力更强的模型可能产生更好的输出。它不会制定组织策略、保留来源信息、提供成本可见性，也不会决定由谁对最终变更承担责任。
未来属于多厂商
多厂商支持是 JetBrains Air 的基础设计原则，从一开始就塑造着系统的构建方式。
我们认为这个市场不会很快整合。模型各有擅长，排名每隔几个月就会变化。同一家公司内部的团队已经做出不同选择，而且他们往往是正确的。今天标准化于一家 AI 厂商，意味着在一个下季度就将面目全非的市场中做出多年承诺。
保持选择开放是合理的。问题在于当前开放所付出的代价。组织每增加一个新模型、智能体或服务，就会对自己开发工作的可见性再少一分。上下文无法在工具之间延续。支出无法归因。策略必须为每项服务重建。
组织不应被迫在使用最佳可用工具与了解自身工程内部正在发生什么之间做选择。这种取舍之所以存在，是因为当前技术栈中没有任何东西被设计为同时位于多家厂商之上。
这正是 JetBrains 承担的工作。我们构建自己的智能体，并致力于让它出类拔萃。但 JetBrains Air 不要求客户使用我们的智能体，我们的战略也不取决于本季度哪家模型提供商排名第一。我们没有理由让生态变得比现在更小。
我们所能提供的，是一个统一的地方，让开发者、团队和组织能够跨每一种模型、智能体和服务来运行、查看、治理和核算智能体开发。
支持多个模型和智能体只是下限，而非上限。真正重要的是位于它们之上的部分：共享上下文、一套策略、单一成本视图，以及无论变更来自哪家厂商都能记录发生了什么。
为什么是 JetBrains？
多厂商选择只能解决部分问题。智能体还需要可靠的软件智能。
JetBrains 将 26 年的工程智能带入这一问题，帮助开发者理解复杂软件的结构与行为，而不只是生成更多代码。这种确定性的代码智能为让智能体工作在不同模型和智能体之间更可靠、更高效、更易理解提供了基础。我们已看到让 AI 智能体访问确定性代码智能所带来的可喜成果。
这既是技术优势，也是经济优势。智能体会花费时间和金钱重新发现代码库中已经包含的信息。能够检索这些知识的智能体，比必须重建知识的智能体更便宜、更准确。由于智能并不属于某一个模型，这种收益可以扩展到受支持的智能体和服务。
我们也正在经历与我们服务的组织相同的转型：在内部采用智能体、重新设计工作流，并了解个人生产力提升在何处转化为更好的软件交付，在何处只是把工作转移到别处。
接下来会发生什么
JetBrains Air 将通过一系列滚动发布逐步发展。我们会明确说明客户现在可以使用什么、什么正在进入预览，以及什么仍属于我们的长期方向。
随着时间推移，JetBrains Air 将进一步扩展到移动和远程体验，让人们能够在智能体工作于不同环境之间流转时发起、监控、审查并继续这些工作。目标不是在每个界面上复刻 IDE。我们是在需要做出决策的地方提供正确的上下文和控制。
我们还将把 JetBrains 的智能带入更多智能体工作流。这包括从代码、架构、仓库、运行时行为和组织知识中提取的更丰富上下文，以及在开发者、模型、智能体和服务之间更好地路由工作。
更多工作将由仓库事件、计划和交付流程触发，而不是由开发者打开编辑器并发出提示词触发。JetBrains Air 将跨界面和服务，为这些工作流提供所需的智能、监督和人工控制。
在范围和可用性得到确认之前，我们不会公布未来产品的名称。每次发布，我们都会说明哪些功能可用、如何连接，以及哪些仍在进行中。
JetBrains Air 将走向何方
成功采用 AI 的公司未必是生成代码最多或部署智能体最多的公司，而是那些能够在扩大试验的同时不失去质量、上下文、成本纪律或人类理解的公司。
JetBrains Air 是我们为这一现实而构建的承诺。它将 JetBrains 从开发者工作台扩展为一个连接开发者、智能体、团队和组织的产品体系。
目标不是更多代码，而是开发者、团队和组织能够理解、验证并为之负责的软件。