JetBrains宣布推出JetBrains Air，这是一个旨在统筹开发者、团队和企业环境中的代理式软件开发的产品生态，而不是将代理的使用局限在单一集成开发环境窗口内。该生态将代理运行、工作协调、政策与成本监控结合起来，同时继续为来自多个供应商的模型、服务和代理保留开放空间。
该公司表示，Air的发布整合了大约六个月前公开启动的工作。当时，公司开始试验代理式开发环境，并推出JetBrains Central，作为一个开放的控制与执行系统。后续发展包括Central CLI界面、共享上下文、云代理、任务自动化、治理以及人工智能成本控制。
生态组成
JetBrains Air由目前已经提供的产品和将逐步推出的产品组成。其中包括Air in JetBrains IDEs，这是一种用于在JetBrains环境内引导代理、组织其工作并验证其输出的体验，并利用该公司理解代码的工具。Air Teams则侧重于协调和自动化由开发者与独立代理共同参与的软件交付流程。
Air Governance沿用了此前JetBrains Central的名称，重点关注企业政策、可见性与审计、成本管理，以及人工智能辅助开发中的问责。Junie也将继续得到支持。Junie是JetBrains面向专业编程的代理，并将通过Air的所有界面提供支持。
该生态还支持Agent Client Protocol (ACP)，其目标是统一开发环境与完整代理生态之间的通信，包括规划、推理、工具、模型路由和监控。通过ACP Registry，开发者可以发现兼容的代理，并在JetBrains环境内运行这些代理。
为什么这一公告很重要？
其核心观点是，代理的采用速度快于管理代理所需的企业基础设施建设速度。即使代理能够生成软件变更，仍然存在一系列问题：谁可以访问代码、数据将流向何处、人工审查的范围是什么、远程工作期间发生了什么、谁批准了变更，以及如何对其进行验证。
JetBrains认为，随着代理的作用从生成变更扩展到理解、验证变更并为其承担责任，问题也会随之转移。看似正确但包含错误假设或与架构相冲突的代码，即使生成成本降低，也可能在审查、返工、安全和基础设施方面带来更高成本。
多供应商开放性与当前限制
JetBrains推出Air的基础是：代理式开发的未来将由多个供应商共同构成，因为不同模型和代理对不同任务的适配性各异，同一企业内部的团队也可能选择不同工具。该公司表示，支持多个模型和代理并不是最终目标；更重要的是，无论由哪种工具生成变更，都能提供共享上下文、统一政策、统一的成本视图，以及对发生过程的记录。
不过，这一公告在一定程度上仍是一份路线图。JetBrains已说明，Air将通过后续版本不断发展，并区分哪些功能已经提供、哪些进入预览阶段，以及哪些仍属于长期方向。未来计划包括扩大移动端和远程体验，增加来自代码、架构、代码库、运行时行为和企业知识的上下文，同时根据代码库事件、时间表和交付流程运行更多任务。
从实际情况看，仅凭这一公告还无法证明这些控制措施能够解决所有治理问题，也无法证明不同代理之间的集成在所有情况下都能达到同样的深度。但公告明确显示，JetBrains正从主要关注单个开发者工作站，转向构建连接开发者、代理、团队和企业的层，同时将可理解性、可验证性和问责纳入代理式开发体系。