我们控制AI支出的初步行动

在过去的六个月里，JetBrains 的 AI 开发支出增长了大约 10 倍。当成本开始上升时，我们当然注意到了——并意识到我们根本不知道如何系统地控制它们。

我们不知道，是因为我们的开发人员不仅仅使用我们自己构建的 AI 工具。他们会自行决定哪些工具最能帮助他们完成工作。

他们中的大多数人在一个月内会使用三到五种 AI 工具。他们对 IDE 的使用频率和以往一样高——只是现在他们在工具组合中加入了更多的 CLI 智能体、智能体开发环境（用于并行运行多个 AI 智能体）以及 IDE 集成的 AI 工具。

解决成本急剧膨胀问题的一个方法，是限制我们的开发人员可以使用的 AI 工具数量。在与来自其他公司的人交流时，我们经常听到他们决定只使用一两个选项。这可能会减少混乱，并限制管理一切的开销。

然而，以这种方式限制自己，很可能会让我们错过任何特定时间的最佳选择。本周最佳配置是在 Opus 模型上运行 Claude Code，明天可能是 Codex，下周可能是 Claude Code 搭配 GLM 和 Opus 的混合模型。

理想情况下，应该在开发人员自由与“工具动物园”管理之间取得平衡，涵盖成本、效率、预算、合规性和安全性。以下是我们试图实现这种平衡的方式。

最初的痛点

成本飞涨。 从 2026 年 1 月开始，我们看到 AI 工具的采用率急剧上升，token 消耗量也随之增加。我们将这一激增归因于 Claude Opus 4.5 和 4.6 模型的发布，这些模型显著提升了智能体性能。JetBrains 的开发人员开始在多个地方使用这些模型，比如 Claude Code CLI、JetBrains IDE 中的 AI 聊天以及 Junie。

此后，使用量几乎每月翻一番。很快，我们就达到了 150 个 Claude Code 席位，并升级到了基于 API 使用量计费的企业版计划。就在这时，成本真正开始飙升。

[LOADING...]

我们的 AI 支出在 2026 年上半年增长了大约 10 倍。

管理员头疼。 每个开发人员的平均消耗量在上升。想要访问不同工具的开发人员数量也在增加——例如，为了比较 Claude Code 和 Codex，或者尝试第三方智能体。每个请求都需要多人审批。管理员的工单堆积如山，等待时间拖慢了开发人员的进度。

通过实验找到解决方案

手动处理电子表格 → 不可持续

我们的“工具动物园”已经壮大，包含了通过 JetBrains IDE 中 AI 聊天可用的各种智能体，以及 Junie CLI、Claude Code 和 Codex 的 CLI 与桌面版本、Cursor、GitHub Copilot，以及其他大量长尾工具。为了开始预测和管理这种增长及其成本，我们手动打开了不同的控制台，下载数据，并按部门和业务单元在多个维度上进行分组。

这一次性工作花了四天时间。在设定组织使用量或进行持续管理方面，我们得到的只是一份情况快照，仅此而已。这是一个合理的开端，但很明显，这种时间投入使得它无法作为未来的可持续方法。

内部仪表盘 → 持续支出只读

大多数 AI 工具，包括 JetBrains 的工具，都有集中式 API，允许你拉取每个用户的使用数据。我们临时拼凑了几个解决方案来实现这一点（也尝试了一些更成熟的第三方方案），并将结果合并到映射到我们组织结构的仪表盘中。这让我们能够深入了解持续支出，但仍然无法方便地设置或强制执行支出限额。

内部控制台和 CLI 包装器 → 最终胜出的原型

对于我们自己的人工智能工具，我们已经有一个管理控制台，内置了消耗和效率分析。只是它不涵盖第三方工具——而这恰恰是我们大部分增长发生的地方。

我们的一位开发人员悄悄构建了一个仅供自己使用的 CLI 包装器：用于验证他的 JetBrains 账户，通过我们的 AI 流量路由层发送请求，并在开发过程中调试本地第三方智能体。这是一个个人工具，而不是治理工具，但事实证明它正是我们缺失的那一块拼图。

从原型到产品

2026 年 4 月初，我们着手将这个被重新利用的个人调试工具变成一个每个 JetBrains 开发人员都能并且愿意实际使用的产品。这意味着它必须：

• 处理身份验证，消除登录麻烦。
• 自动检测已安装的智能体，这样就不再浪费时间在配置上。
• 通过我们的流量路由层发送所有请求，使我们能够以 AI 积分的形式将 token 预算规则应用于第三方工具（以及我们自己的工具）。
• 保持符合我们的安全、加密和访问隔离要求。

其中一些我们已经具备了。JetBrains AI Platform 是我们的底层 AI 路由器，自 2023 年以来一直为我们的客户和个人开发人员提供 JetBrains AI 服务，以可靠的稳定性处理了超过 10 亿次 LLM 请求。在服务端，我们一直在收集消耗统计信息和其他指标，通过 ETL 管道以异步模式将它们处理到独立的、高度弹性的存储中——这些存储满足上述要求。我们也在对我们自己的工具应用 AI 积分预算。

在接下来的两个月里，我们将 CLI 包装器完善成了 JetBrains Central CLI。

[LOADING...]

Central CLI 在整个体系中的位置。

我们所有人的受益方式：

• 开发人员 可以随心所欲地使用他们想要的任何模型运行终端智能体，几乎没有管理摩擦——不再需要等待数周才能获得批准。

• 管理人员 可以：

  • 在 Central Console 中创建和查看报告，显示：
    • 其部门的当前、历史和预测 AI 消耗与成本。
    • 按开发人员、智能体和 IDE 划分的 AI 成本与使用分布。
    • 通过分析 API 与其他 AI 支出汇总的所有数据。
  • 为跨每个智能体和 IDE 的单个开发人员、团队和群组设置细粒度的 AI 限制。
  • 消除来自日益增长的第三方 AI 提供商列表的大量合同和发票！

[LOADING...]

当前、历史和预测的 AI 消耗与成本。

[LOADING...]

细粒度的限制。

管理开发人员的 AI 使用不应意味着限制他们的工作流程。

试用 JetBrains Central CLI

有没有可能用开源工具、脚本和其他零散部件拼凑出这样的解决方案？可以。我们知道，因为我们试过。但是中型组织（比如我们）希望解决方案开箱即用地可靠运行，而无需额外的部署、配置和维护开销。开发人员希望获得他们需要的 AI 工具，而不是为了让每个人都满意而额外增加工作。这就是我们构建这个解决方案的原因。

当我们快速推出时，发生了什么

我们在几个月内构建并在内部推出了这个解决方案。这对我们来说出奇地快，随之而来的是：

好的问题

• 快速增长暴露了边缘情况。 在短短几周内，超过一千名 JetBrains 开发人员切换到了这个工具。然而，他们中的许多人带来了边缘情况——这里有一个生僻的 Windows 终端，那里有一台远程机器。我们不得不努力微调登录流程以覆盖所有人。

• Central CLI 一夜之间变成了基础设施。 我们的开发人员开始每天依赖它，随之而来的是功能请求和支持问题。CLI 团队规模很小，目前他们的大部分工作就是跟上这种需求，对于一个问世仅几个月的工具来说，这是一个好迹象。

遗留问题

• 我们需要更精细的策略。 既然我们有了设置 AI 使用策略的明确机制，下一个问题就是这些策略应该是什么。我们需要确定某个开发人员可以消耗多少、他们是否可以请求更多、他们是否可以将配额用于个人目的等等。许多部门有不同的 AI 工作流程和消耗模式。我们现在正在开发一个高级权限系统，将限额设置权交给工程经理，因为他们最了解自己的团队需要多少 token，以及谁需要这些 token。

• 我们正在扩大覆盖面。 该 CLI 目前支持三种最流行的终端智能体。还有四种处于内部 Beta 阶段。小众配置和个人 AI 订阅将不在范围内，因为我们的目标是覆盖开发人员最依赖的工具所运行的 AI 流量。

亲自试一试

在让自己成为测试对象之后，我们在 7 月 8 日向公众开放了 Central CLI 的早期访问。任何拥有 JetBrains AI 积分的个人或组织都可以使用。快速提醒：此解决方案专为在多个第三方工具上运行大量基于 API 的使用量的团队而设计。如果你的 AI 使用量不是那么大，成本还不是压力点，那么在经济上可能不划算。但如果你已经感受到了压力，值得一看。

该 CLI 是 JetBrains AI for teams and organizations（我们面向智能体软件开发推出的系统）的几个入口之一，该系统于 7 月开始以早期访问形式推出。它涵盖了一切，从开发人员选择的工具、智能体和模型，到本文一直在讨论的治理层。

我们取得了快速的进展，但前方仍有很多工作要做。请在评论中告诉我们你还想了解什么——无论是我们如何走到这一步，还是我们下一步的方向。

人工撰写，由 claude-opus-4-8 校对（$0.60）：3.9k 输入，3.9k 输出，105.3k 缓存读取，43.0k 缓存写入