JetBrains Air：面向代理式软件开发的开放产品体系

AI可以生成代码，但组织依然需要产出软件。代理式开发正在改变软件的生产方式，却并未改变出错的成本。

六个月前，我们开始公开试验代理式开发环境。几乎与此同时，我们推出了喷气大脑中心——一套面向代理驱动开发的开放控制与执行系统。

随后，我们又逐步发布了JetBrains Central CLI、共享上下文、云端代理、自动化工具、治理框架，以及面向团队和组织的AI成本管控功能。

今天，我们将这些工作整合为JetBrains Air：一个面向开发者、团队和组织的开放、连贯的产品体系，不仅涵盖JetBrains IDE，更超越其边界。

它具备多界面、多服务的特性；每个产品解决特定问题，但各产品协同运作时效果更佳。

JetBrains Air标志着JetBrains业务重心的重大扩展。过去26年，我们主要聚焦于个人开发者的工作台；如今，我们正构建一个更广泛的系统，用于发起、执行、协调、审查并治理代理式工作流程。

IDE在JetBrains的未来中仍具重要地位。然而，将整个软件开发系统浓缩于单一窗口的时代正在终结。作为持续投入的一部分，我们现在将基础的代理式体验引入JetBrains IDE，为专业开发者提供一个既能高效使用代理，又能理解、修改并验证生成代码的环境。

JetBrains Air则连接起围绕它的更大开发体系。

这一体系基于一个核心信念：代理式开发的未来将是多供应商共存的格局。没有哪一种模型、代理或服务能够适用于所有开发者、团队或任务。

从单一产品到开放的产品体系

这一战略转变带来了一个实际结果：JetBrains Air不能仅仅是又一个代理或开发环境。它必须连接用于个人工作、团队协作、组织管控、上下文管理及流程自动化的各类产品，并且对开发者选择的工具与代理保持开放，包括那些并非由JetBrains开发的工具与代理。

JetBrains Air包含现已可用的产品，以及随着体系发展而陆续推出的其他产品：

• Air in JetBrains IDEs——在JetBrains IDE内指挥、编排代理并验证其成果的完整代理式开发体验。
• Air Teams——一种全新的方式，用于协调和自动化涉及开发者与自主代理的软件交付流程。
• Air Governance（原JetBrains Central）——面向AI辅助与代理驱动开发的组织级策略、可见性、可审计性、成本管理与责任机制。

Junie是JetBrains专为专业软件开发打造的编码代理，将在Air的所有界面中得到支持。

Air in JetBrains IDEs为开发者提供了利用JetBrains的代码智能来指挥代理并验证其输出的环境；Air Teams则将个体代理活动转化为协调一致的团队流程；Air Governance使这些活动在整个组织范围内变得可见、可控并可追溯责任。

然而，一个开放的体系不能仅限于JetBrains自有的产品。代理客户端协议（ACP）标准化了IDE与代理完整运行环境之间的连接，包括其规划、逻辑、工具集、模型路由及可观测性。

通过ACP注册中心，开发者可以在继续使用JetBrains IDE的同时，发现并运行越来越多兼容的代理。

Air Governance旨在将可见性和成本管控延伸至不同提供商及代理式工作所经的各类工具之间。这意味着开发者可以选择最适合当前任务的代理、模型或服务，而无需让组织牺牲上下文、可见性或控制力。

这些Air产品共同作用，使工作能够在开发者、代理、工具与环境之间流转，同时不丢失其背后的上下文与管控机制。

个人采用速度远超组织基础设施建设

自三月以来，我们的产品取得了显著进展，但我们对代理式开发需求的理解也在不断深化。

开发者采用代理的速度远远快于组织搭建配套基础设施的速度。代理的能力不断提升，不同的模型与代理在不同任务中各有其用武之地。

然而，围绕它们的上下文、协调、治理与成本管理却未能同步跟上。

对许多开发者而言，代理已经带来了切实的价值。但在组织层面，经济性却难以证明。成本往往体现在其他环节——审查、返工、安全、基础设施与支出等方面。

哪些代理可以访问公司代码？数据会流向何处？哪些输出需要人工复审？代理远程工作期间发生了什么？最终变更由谁批准，又是如何验证的？

这种层级上的割裂不仅令人困扰，更使得软件开发在更多工作被委派出去之际，变得更加难以理解、度量与治理。

瓶颈随工作重心转移

显而易见的错误代码很快会被发现，这部分体系仍在运转。更棘手的问题是那些看似合理、能通过表面检查，却暗藏不良假设或架构不一致的代码——这些问题往往要付出高昂代价才会暴露出来。

随着代理承担更多执行工作，瓶颈正从“产生变更”转向“理解、验证并承担责任”。代码的生成成本降低了，但验证成本却上升了；代理活动更容易启动，却更难协调、审计与解释。

工作可以被委派，但责任却无法转移。当系统出现问题时，凌晨三点不会有人打电话给代理。交付的责任仍然归属于交付者——人与组织。

这也正是为什么随着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的业务从开发者工作台扩展至连接开发者、代理、团队与组织的产品体系。

我们的目标不是生成更多代码，而是让开发者、团队与组织都能理解、验证并为其负责的软件。

探索JetBrains Air