摘要

JetBrains 与 Netflix 联合公布一项实测结果。Netflix 把 JetBrains 无头运行的代码智能引擎（与 IntelliJ IDEA 同源）接入 Claude Code 与 Codex，并在两个真实代码库上做了对照评测。结果显示，在相同的模型、任务与代码库条件下，接入 JetBrains IDE 智能后，编码智能体整体效率更高，典型提升 20–30%，最好情况接近 65%，增益大小取决于模型、智能体与任务，模型越强、推理力度设置越高，增益越大。效率是 token 节省与耗时节省的平均；所有运行中，正确性保持稳定或有所提升。评测在 2026 年 7 月至 8 月进行，覆盖一个内部生产服务与 Netflix 开源的 DGS Framework。

正文（译文）

Netflix 如何用 JetBrains 的 IDE 智能让 AI 编码智能体更高效

Netflix 把 JetBrains 的无头代码智能引擎（与 IntelliJ IDEA 同源的那个）接进了 Claude Code 与 Codex，然后针对多种场景做了基准测试。细节与数据如下。

一览

• 公司：Netflix，应用开发平台（ADP）、GenAI 平台与智能体 SDLC 团队

• 挑战：编码智能体在导航 Java/Kotlin 代码时表现吃力，尤其在跨越已编译库（JAR）边界时

• 技术：面向 Java 的 JetBrains IDE 代码智能，构建于驱动 IntelliJ IDEA 的同一套代码索引引擎之上，无头运行，无需打开 IDE

• Netflix 的角色：自行构建了让智能体可以调用 LSP 所需的守护进程与 CLI，这部分基础设施当时 JetBrains 尚未提供

• 结果：在真实编程任务上，典型提升 20–30% 的效率（更少的 token、更短的时间），最好情况接近 65%；增益大小取决于模型、智能体与任务，通常模型更强、推理力度设置更高时增益更大

• 评测环境：两个真实代码库，一个内部生产服务与 Netflix 开源的 DGS Framework，覆盖多个当前主流编码智能体与模型，2026 年 7 月至 8 月

目标：提升智能体的投资回报

JetBrains 与 Netflix 的目标是，在无头环境下为编码智能体提供准确的、IntelliJ IDEA 级别的代码理解能力，且无需运行任何 IntelliJ IDEA 实例。

"像 Claude Code 这样的编码智能体，在导航 Java/Kotlin 代码时既慢又不可靠，尤其是跨库（JAR）边界时。我们集成了一个无头 JetBrains IDE 的代码引擎，在没有 IDE 运行的情况下，为智能体提供 IntelliJ IDEA 级别的代码智能。我们创建了一套基于真实编程任务的基准，结果显示，有了 JetBrains IDE 的代码引擎，智能体的效率持续提升，使用的 token 更少、耗时更短，具体增益取决于模型。" —— Paul Bakker，Netflix 首席软件工程师

Paul 上面提到的 JAR 问题，正是 Netflix 要解决的：JVM 项目通常只以 JAR 文件的形式发布库，从不发布源码。智能体必须先解压这些 JAR（还得猜测哪些是相关的），可能需要反编译 class 文件，然后在这个不完整的视图上做 grep 搜索。

解决方案：JetBrains IDE 智能

JetBrains 花了多年时间构建 IntelliJ IDEA 背后的代码智能引擎。它基于对项目源文件（包括所有库）的确定性索引。这套智能现在通过 LSP 对外暴露，并可在兼容 VS Code 的编辑器中使用。Netflix 使用的是该引擎的无头构建版本。

仅有 LSP 并不足以让编码智能体直接使用：它只是一个讲协议的服务器，智能体没有便捷的方式调用它，也没有内置的流程管理来在多次调用之间复用运行中的实例。Netflix 用下一节描述的守护进程与 CLI，自己补上了这个缺口。

架构细节：让索引保持热状态

为一个项目建立索引需要真实的时间，正如第一次在 IntelliJ IDEA 中打开一个大型项目那样。编码智能体以许多细小的步骤调用 LSP，一个现实的任务需要多次这样的调用。如果每次调用都拉起一个全新的 LSP 服务器，那么每一次调用都要承担数秒的冷启动成本，哪怕这个项目的索引一分钟前才刚建好。

需要一个守护进程来避免重复调用时冷启动 LSP 服务器进程的开销。JetBrains 正在交付一个守护进程，但截至评测时还没有可用版本，因此 Netflix 为自己的需求自建了一个：

• 每次工具调用都是短生命周期且无状态的，只是去 shell 调 CLI。

• 守护进程是长期驻留的部分：它的会话管理器按项目根目录把每次调用路由到对应的服务器进程，该进程在内存中持有该项目的索引。

• 对同一项目的第二次调用完全跳过索引建立，直接通过 stdio 连到已热启动的服务器。

• 守护进程与 CLI 均用 Java 开发，并以 GraalVM 可执行文件分发，因此不存在 JVM 的启动或运行时开销。

Netflix 如何衡量 JetBrains IDE 智能的投资回报

为了判断 JetBrains IDE 智能是否（以及在多大程度上）提升了编码智能体的表现，他们开发了一套基准套件。相同的模型、相同的任务、相同的代码库，唯一的变量是智能体能否调用 JetBrains IDE 智能。结果以启用与不启用 JetBrains IDE 智能两次运行之间的性能差异来报告。

评测环境与方法：

• 数据集：两个真实代码库。一个内部服务（中等规模项目），使用 Spring Boot 4 与 Gradle；Netflix 自有的开源 DGS Framework，一个公开的 Kotlin/Java 混合 GraphQL 框架。

• 任务：两类。聚焦型小任务，智能体试图理解代码库中的具体信息，例如"这个接口在项目里哪里被用到""这个接口有哪些实现""这个类的结构是什么"；完整的端到端任务，例如实现一个新功能、重构一个类或删除代码。

• 模型：Claude Code 配 Opus 5（中/高推理力度）；Claude Code 配 Sonnet 5（中/高推理力度）；Codex 配 GPT-5.6 Sol（中/高推理力度）。

• 评分：实验中最重要的指标是 token 消耗与完成耗时，同时实现了 LLM as a judge 来检查正确性。它对端到端任务参照一个参考变更集工作，并对导航类任务套用确定性评分指标。

• 异常值处理：在任一分支中崩溃、触达预算上限或反复空转的任务，会从两个分支中同时剔除，以免一次失控扭曲对比结果。

基准被运行了多次，以验证结果并观察新 LSP 版本带来的变化。

结果

在所有被测试的模型、智能体与任务类型上，JetBrains IDE 智能都让编码智能体整体更高效：典型提升 20–30%，最好情况接近 65%，具体取决于模型、智能体与任务。模型更强、推理力度更高时增益最大。这些模型更贵，因此效率提升更有价值，同时它们也更善于有效利用索引。

各配置的效率增益（合并 token 与耗时节省）。每次对比都在相同的任务、模型与代码库上运行两次，一次启用 JetBrains IDE 智能，一次不启用：

• 平均增益：约 25%

• 典型区间：20–30%

• 最好情况：约 65%

按配置拆分（代码导航 / 端到端）：

• 最强模型 + 高推理力度：约 65% / 约 24%

• 中等模型 + 高推理力度：约 29% / 约 30%

• 中等模型 + 中推理力度：约 24% / 约 22%

• 较轻配置 + 高推理力度：约 17%（仅 token）/ 约 21%

效率为各配置下 token 与耗时节省的平均值。所有运行中，正确性保持稳定或有所提升。标注星号的一项仅计 token：该配置的批量搜索调用使代码导航的耗时对比不具代表性，详见正文。这些数字是快照，会随新模型发布而变化。

这些数字是快照，不是固定的基准结论。每一次新模型发布都会改变智能体搜索、推理与使用工具的方式，因此具体百分比会持续变化，这也是本文报告区间而非逐模型结果的原因。在 Netflix 的多次运行中稳定成立的是整体形态：所有被测模型与智能体都变得更高效，最大增益来自最强模型的高推理力度配置，而增益大小在不同模型之间差异明显。

代码导航任务：全面更高效，正确性保持或提升

所有被测模型与推理力度在使用 JetBrains IDE 智能后都用了更少的 token，无一例外，节省幅度从约 15% 到 60% 不等。增益大小主要取决于模型：最强的模型改善幅度遥遥领先，而较轻量的配置落在两个区间的下端。多数运行中正确性保持稳定，其中两次有所提升，从未下降。

具体到代码导航任务，有一个工具与模型组合已经会把多次搜索调用批处理进单条命令，因此在启用与不启用 JetBrains IDE 智能的情况下，它在那里都只做一次工具调用。对该组合而言，调用 JetBrains IDE 智能比批处理搜索命令稍慢一些，这正是它缺乏时间收益的原因，并不反映真实使用情况。因此，端到端任务套件才是衡量时间收益的更可靠口径，在那里 JetBrains IDE 智能在所有被测模型与智能体上都更快。

端到端任务：持续更高效，正确性不受影响

在扩展后的端到端运行中，所有被测模型与智能体的正确性都保持稳定，因此收益完全体现在效率上，而非任务是否完成。每个模型与智能体的组合在使用 JetBrains IDE 智能后，效率提升约 10–30%，以完成耗时与 token 支出衡量。这很大程度上可以用达成同样结论所需的工具调用更少来解释。

其他被评估的替代方案

在确定上述方案之前，Netflix 排除了另外两个。第一个被否决的是一套自研的内部 CLI，它连接到一个运行中的 IntelliJ IDEA 实例以获取项目索引。流程与本文描述的类似，但它要求有一个 IDE 在运行。这一方案不适用于 Otto、Bitbot、分布式重构工具、CI 等无头智能体环境。

第二个被考虑的是 Eclipse LSP，它在 VS Code 中用于 Java。但面对 Netflix 的构建系统（基于 Gradle），它根本无法工作。

下一步

Netflix 从这里走向何处

测试之后，Netflix 的结论是"基准表明，在智能体旁边放一个确定性的智能层是有价值的"。当然，它并不会把每一项编码智能体任务都按固定百分比削减。但对于这个具体问题，即跨 JAR 边界解析真实结构，收益很大、跨模型成立，且不牺牲正确性。

Netflix 计划把同一套基准方法跑向 Python、TypeScript/JavaScript 与 Go。面向这些语言的编码智能体有类似的问题。不过，各语言中库被下载到项目里的方式不同，因此问题的机理与可能的解法也不同。JetBrains 计划继续这一合作并支持后续评测。

JetBrains 的看法：LSP 只是一步，不是终点

面向 Java 的 JetBrains IDE 智能已由 Netflix 完成测试，并作为 Java & Kotlin by IntelliJ IDEA 扩展的一部分发布。JetBrains 也在继续 LSP + CLI 路线的实验，结果准备好后会一并报告。

LSP 的基本原语是文本文档中的一个位置。规范把位置定义为"两个字符之间，就像编辑器里的插入光标"。对在键盘前工作的人来说，这是一个自然的原语。但智能体并不真的以光标位置思考。它们问的是关于程序的问题，比如"为什么 createUser() 里的这个调用无法解析""哪些测试覆盖了这个方法"，关心的是代码各部分之间的关系，而不是看光标位置。而且文本位置是一种脆弱的标识：在任意给定位置之前插入一个字符，该位置就会移动。

智能体需要的不是更锋利的光标，而是一个以与任务本身相同的方式给出答案的层，也就是用符号、诊断、测试关系、运行时行为来表述，并返回足以据此推理的上下文，而不仅仅是文本文档中的位置。

"我所说的代码引擎就是这个意思：不是又一个让智能体模仿编辑器交互的协议，而是一组对程序结构与执行的精确操作，并且返回足以真正推理结果的上下文。LSP 是有用的，但它不该定义最终面向智能体的抽象。如果把智能体工具构建成'智能体是一个坐在编辑器前的小人'，你就强迫它用光标坐标说话。智能体需要的是代码引擎，而不是虚拟编辑器。" —— Aleksey Stukalov，JetBrains IDE 部门负责人

Netflix 的这些数字证明，代码智能值得为之付费。而决定这种智能采取什么形态，是摆在前面的挑战。