JetBrains上线团队AI权限与费用管理
JetBrains Air Governance正式可用,前身为JetBrains Central,是Air智能体开发体系的组织管理层。团队可集中管理Agent、模型和服务商的使用权限,设置支出上限并查看使用成本与成效。
AI 深度解读
团队同时用上 Claude Agent、Codex、Gemini CLI,麻烦很快就会从「选哪个工具」变成「谁能用、花多少、值不值」。JetBrains 推出正式可用的 Air Governance,想把这些分散在不同厂商后台的问题,收进一个组织级控制台。
它的价值是统一管理 Agent 的准入、供应商账号、预算和用量。对程序员来说,这关系到工具选择能保留多少自由;对负责人来说,则关系到 AI 账单能否管住,以及投入产出该怎么解释。
为什么多用几个 Agent,就需要统一管理
Air Governance 原名 JetBrains Central,是 JetBrains Air 产品体系中的组织管理层。原文称,它支持 Claude Agent、Codex、Gemini CLI、Junie,以及其他兼容 ACP 的 Agent,覆盖 IDE、CLI、浏览器和移动端等开发入口。
这里要解决的是管理碎片化:开发者按任务切换工具,公司却要分别处理合同、后台和权限。每个平台都能展示自己的用量,但跨平台汇总往往得另做一遍。
JetBrains 给出的内部经历很具体:2026 年上半年,他们的 AI 支出增长了约十倍,第一次跨供应商用量报告靠人工整理,花了四天。目前,Air Governance 每月帮助管理 JetBrains 内部约 2,300 人的 Agent 使用。
这些数据解释了需求从哪里来,但还不能证明产品上线后省了多少钱。原文没有提供报告耗时的前后对照,也没有给出成本下降比例。
作者主张,新增 Agent 或模型时,可以把它加入已有策略,不必再建立一套独立管理配置。这个方向适合多工具并行的团队,但实际接入仍要看兼容范围。
管住预算,靠的是限制能真正生效
Air Governance 把管理对象分成几层:供应商、模型、Agent,以及不同用户组。管理员可以把它们组合成 AI 策略,让不同团队获得不同的工具范围和额度。
预算可以分配到个人、团队和服务账号。原文强调,这些 AI credit 限制会被执行,而不只是事后出现在报表里。对团队负责人来说,区别很直接:看见超支和阻止继续消耗,是两种能力。
供应商接入支持 JetBrains AI,也支持集中式 BYOK,即接入组织自己的 OpenAI、Anthropic、Amazon Bedrock 或 Google Vertex AI 账号。

但这里有个边界:集中接入 BYOK 已经提供,BYOK 模型的额度限制和自定义定价仍在开发中。 不能把通用预算功能直接理解成对所有自带账号都已完整生效。
管理员还可以指定获准使用的 Agent,并在公司级配置 MCP servers,让团队使用统一批准的外部工具。

不过,把这些 MCP 配置传播到第三方 CLI,仍属于后续计划。统一配置入口已经存在,不代表每个终端 Agent 现在都能收到相同配置。
账单能汇总,产出却不能只看代码量
Air Governance 提供按用户、Agent、模型和供应商拆分成本的能力。负责人可以查看某个开发者消耗多少预算,也可以比较 Junie、Claude Agent、Codex、Gemini CLI 等工具的支出。
这能回答「钱花在哪里」,但还没有回答「钱花得值不值」。
原文列出的产出指标,包括人工编写与 AI 生成代码的占比,以及 AI 生成、AI 修改代码的数量。它们能帮助观察 AI 参与开发的程度。

AI 参与了多少代码,不等于团队交付得更快、更稳。 生成的代码可能减少工作,也可能增加审查和返工。原文提到了指标计算文档,但没有展开统计口径,也没有给出交付周期或缺陷率的对照数据。
接入范围同样需要区分当前能力与路线图。通过第三方 CLI 连接器 Air Gateway 支持 GitHub Copilot、连接云端 Agent,以及高级 AI 分析、跨团队 skills 管理,都在开发计划中。
费用则有两部分:Business 方案按每位获得 AI 访问权限的开发者收取 USD 20/月,组织还要另外购买共享 AI credits。开发者无需分别购买个人 AI 许可证,但这笔月费并不包含全部模型消耗。
原文开头说同时提供免费和付费方案,后面重点介绍 Business,却没有说明免费方案的功能边界。选型时需要进一步核实。文中另列有 November 18、4:00–5:00 PM CET 的产品演示活动,这也不能代替实际接入验证。
我的判断
我认同它把工具选择和组织管理放在同一套体系里。团队不必先强行统一到某一个 Agent,才有机会统一权限和成本。相比逐个后台人工汇总,这种管理方式也更适合持续增加工具的团队。
但价值有前提:团队确实有多供应商、多用户和预算分配需求,常用工具也能进入它的管理范围。对于只使用一种工具的小团队,现有厂商后台可能已经够用,新增平台反而多一层配置和按人费用。
最需要保留判断的是投入产出。JetBrains 的内部使用规模说明它承接了真实需求,不能据此推导其他团队一定能降本。原文没有对照实验,也没有效率提升数据;目前更适合把它看成权限与成本管理工具,代码指标用于辅助观察。
能拿来做什么
- 如果前端或全栈团队已经混用多个 Agent,先整理人员、工具、供应商账号和支出归属,再核对 Air Governance 的实际支持范围,判断是否值得集中接入。
- 如果准备给自动化任务使用服务账号,先确认对应供应商和模型的预算限制能否生效,尤其要单独核实 BYOK,避免把路线图功能算进上线方案。
- 如果要向负责人解释 AI 投入,把按人、按 Agent、按模型的费用与已有交付记录一起看;AI 代码占比可以展示使用情况,不宜单独作为绩效依据。
- 如果准备采购,按有 AI 访问权限的人数计算 USD 20/月的平台费用,再估算另购共享 AI credits 的开销,并确认免费方案能覆盖哪些需求。