JetBrains 分享 AI 工具成本管理经验

让众多 JetBrains 产品中的 AI 功能，为你的工具注入更强能力。

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

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

在一个月内，大多数开发者会使用三到五种 AI 工具。他们使用我们 IDE 的频率和以往一样高，只不过现在又加入了更多 CLI Agent、Agentic 开发环境（用于并行运行多个 AI Agent），以及集成到 IDE 中的 AI 工具。

大多数 JetBrains 开发者至少会使用三种 AI 工具。他们会在我们的 IDE 内部以及配合 IDE 使用所有这些工具。

要解决成本不断膨胀的问题，一种办法是限制开发者可以使用的 AI 工具数量。与其他公司的人交流时，我们经常听到他们决定只保留一到两个选项。这样或许能减少混乱，并降低管理所有工具带来的额外开销。

然而，以这种方式限制自己，很可能会让我们错过每个阶段的最佳选择。这周的最佳组合可能是搭载 Opus 模型的 Claude Code，明天可能变成 Codex，下周又可能是混合使用 GLM 和 Opus 的 Claude Code。

理想情况下，我们需要在开发者自由度与“工具动物园”的管理之间取得平衡，同时兼顾成本、效率、预算、合规与安全。下面是我们为实现这种平衡所做的尝试。

成本飙升。从 2026 年 1 月开始，我们看到 AI 工具的采用率急剧上升，token 消耗量也随之增长。我们认为，这一波增长源于 Claude Opus 4.5 和 4.6 模型的发布，这两个模型显著提升了 Agent 的表现。JetBrains 开发者开始在多个场景中使用这些模型，例如 Claude Code CLI、JetBrains IDE 中的 AI chat，以及 Junie。

此后，使用量几乎每个月都会翻一番。没过多久，我们就达到了 150 个 Claude Code 席位，并升级到按照 API 使用量计费的 Enterprise 方案。也正是在那时，成本真正开始起飞。

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

管理上的麻烦。每位开发者的平均消耗量不断上升，希望获得不同工具访问权限的开发者数量也越来越多——比如比较 Claude Code 和 Codex，或者尝试第三方 Agent。每项申请都需要多人审批。管理员手里的工单越积越多，漫长的等待也拖慢了开发者的工作节奏。

通过不断实验寻找解决方案

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

我们的工具动物园已经囊括了 JetBrains IDE 的 AI chat 中提供的各种 Agent，以及 Junie CLI、Claude Code 和 Codex 的 CLI 与桌面版本、Cursor、GitHub Copilot，还有一长串其他工具。为了开始预测和管理这种增长及其成本，我们手动打开不同的管理控制台、下载数据，再按照部门和业务单元等多个维度对数据进行分组。

这项一次性工作花了四天。我们得到了一张现状快照，但在制定组织级使用规则或持续管理这些工具方面，几乎没有更多收获。作为起点，这种做法尚且合理，但如此高昂的时间成本显然意味着它无法长期持续。

内部仪表盘 → 只能查看持续支出

包括 JetBrains 自家产品在内，大多数 AI 工具都提供集中式 API，可以拉取每位用户的使用数据。我们快速拼出了几个能完成这项工作的简易方案，也试用了几个更加成熟的第三方方案，然后将结果整合进与组织结构对应的仪表盘。

这让我们能够深入查看持续产生的费用，但仍然无法方便地设置或执行支出上限。

内部控制台与 CLI wrapper → 胜出的原型

对于自家的 AI 工具，我们已经拥有一个管理控制台，其中内置了消耗量和效率分析。问题在于，它并不覆盖第三方工具，而这些工具恰恰是大部分增长发生的地方。

我们的一位开发者一直在悄悄为自己开发一个 CLI wrapper：用它验证自己的 JetBrains 账户，通过我们的 AI 流量路由层发送请求，并在开发过程中调试本地的第三方 Agent。它原本是一个个人工具，而不是治理工具，但事实证明，它正是我们缺失的那块拼图。

从原型到产品

2026 年 4 月初，我们开始把这个改造自个人调试工具的原型变成一款每位 JetBrains 开发者都能用、也愿意真正使用的产品。这意味着它必须：

• 处理身份验证，消除登录方面的麻烦。

• 自动检测已安装的 Agent，不再把时间浪费在配置上。

• 通过我们的流量路由层发送所有请求，使我们能够以 AI credits 的形式，将 token 预算规则同时应用到第三方工具和自家工具上。

• 满足我们的安全、加密和访问隔离要求。

其中一些能力我们已经具备。JetBrains AI Platform 是我们底层的 AI 路由器，自 2023 年以来一直为客户和个人开发者使用的 JetBrains AI 提供支持，已经稳定处理了超过 10 亿次 LLM 请求。

在服务端，我们收集消耗统计数据和其他指标，通过 ETL pipeline 进行处理，并以异步方式写入独立且具备高度弹性的存储系统，而这套存储系统符合上述要求。我们也已经在自家工具上实施了 AI credit 预算。

接下来的两个月里，我们不断完善这个 CLI wrapper，最终将它打造成 JetBrains Central CLI。

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

我们所有人如何从中受益

开发者几乎不需要经历任何管理流程，就可以使用任意模型运行终端 Agent——再也不用等待数周审批。

管理者可以：

• 在 Central Console 中创建和查看报告，其中包括：

  • 所属部门当前、历史及预测的 AI 消耗量与成本。

  • 按开发者、Agent 和 IDE 划分的 AI 成本与使用量分布。

  • 通过 analytics API，与其他 AI 支出聚合在一起的全部数据。

• 针对每个 Agent 和 IDE，为单个开发者、团队及群组设置细粒度的 AI 限额。

• 不再需要处理来自越来越多第三方 AI 提供商的大量合同与发票！

在 Central Console 中创建和查看报告，其中包括：

• 所属部门当前、历史及预测的 AI 消耗量与成本。

• 按开发者、Agent 和 IDE 划分的 AI 成本与使用量分布。

• 通过 analytics API，与其他 AI 支出聚合在一起的全部数据。

为每个 Agent 和 IDE 中的单个开发者、团队及群组设置细粒度的 AI 限额。

不再需要处理来自越来越多第三方 AI 提供商的大量合同与发票！

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

治理开发者的 AI 使用，不应该意味着束缚他们的工作流。

能不能利用开源工具、脚本和其他零散组件，拼出一套类似的系统？可以。我们知道，因为我们试过。

但像我们这样的中型组织，需要一套开箱即用、稳定可靠的解决方案，不能为了部署、配置和维护再承担额外开销。开发者想要的是访问自己所需的 AI 工具，而不是为了以一种让所有人都满意的方式获得这些工具，再额外付出一番劳动。这就是我们构建这套解决方案的原因。

快速发布之后发生了什么

我们只用了几个月，就在内部构建并推出了这套解决方案。这个速度快得出乎我们的预料，同时也带来了一些情况：

快速增长暴露了各种边缘情况。短短几周内，就有超过一千名 JetBrains 开发者切换到了这款工具。不过，其中不少人也带来了各种边缘情况——这里有一个冷门的 Windows 终端，那里有一台远程机器。为了覆盖所有人，我们不得不继续微调登录流程。

Central CLI 一夜之间变成了基础设施。我们的开发者开始每天依赖它，随之而来的还有功能请求和支持问题。CLI 团队规模很小，目前他们的大部分工作就是满足这些需求。对于一款只有几个月历史的工具来说，这是个好兆头。

我们需要更细粒度的策略。有了明确的 AI 使用策略设置机制后，下一个问题就是：这些策略究竟应该是什么样的？我们需要确定一位开发者可以消耗多少资源、能否申请更多额度、能否把自己的配额用于个人用途，等等。

许多部门都有不同的 AI 工作流和消耗模式。我们现在正在开发一套高级权利与权限系统，把限额控制权交给工程经理，因为他们最了解自己的团队需要多少 token，以及谁需要这些 token。

我们正在扩大覆盖范围。CLI 目前支持三种最受欢迎的终端 Agent，另外四种正在进行内部 Beta 测试。小众配置和个人 AI 订阅仍不在支持范围内，因为我们的目标是覆盖那些经由开发者最依赖的工具产生的 AI 流量。

在亲自充当测试对象之后，我们于 7 月 8 日开放了 Central CLI 的 early access。任何拥有 JetBrains AI credits 的个人或组织都可以使用它。

提前提醒一下：这套解决方案面向的是同时使用多个第三方工具、并产生大量 API 调用的团队。如果你的 AI 使用量不大，成本也还没有成为压力，那么从经济角度看，它可能并不适合你。但如果你已经开始感受到成本压力，那就值得了解一下。

CLI 是团队和组织接入 JetBrains AI 的多个入口之一。JetBrains AI 是我们面向 Agentic 软件开发打造的系统，已于 7 月开始逐步开放 early access。它覆盖完整链路，从开发者选择的工具、Agent 和模型，到本文所介绍的治理层。

我们取得了快速进展，但前面依然还有大量工作要做。欢迎在评论区告诉我们，你还想了解哪些内容——无论是我们如何走到今天，还是接下来准备前往何处。

本文由人工撰写，并由 claude-opus-4-8 校对（$0.60）：3.9k input、3.9k output、105.3k cache read、43.0k cache write

谢谢，我们已经收到！

这是一个系列的第 3 篇。我们选取公开发布、面向 coding Agent 的“token saver”附加工具，并使用同一套配对 A/B benchmark 分别进行测试。第 1 篇测试的是 caveman skill（宣称节省 65%，实测节省 8.5%）。第 2 篇测试的是 rtk（宣称节省 60%–90%，实测反而增加 7.6%）。我们运行了 80 组配对任务，以测试 pony……

今天，我们正式发布 JetBrains Context。这是一个全新的代码仓库智能层，可以帮助 coding Agent 更高效地工作，并在复杂代码库中产出质量更高的结果。作为 JetBrains AI for Teams and Organizations 推出计划的一部分，JetBrains Context 现已开放 early access……

“rtk”能减少 Claude Code 的 token 使用量吗？这是一个系列的第 2 篇。我们选取公开发布、面向 coding Agent 的“token saving”附加工具，并使用同一套配对 A/B benchmark 分别进行测试。第 1 篇测试的是 caveman skill（宣称节省 65%，实测节省 8.5%）。简而言之：rtk 宣称可节省 60%–90%，实测结果却是……

我们在 SkillsBench 上对 Claude Code 的 token 压缩 skill Caveman 进行了配对 A/B benchmark：它真的能节省 token 吗？是否会降低 AI Agent 的输出质量？宣称节省 65%，实测节省 8.5%。在强制启用该 skill 的情况下，对真实 Agentic 任务的 output token 节省效果……