How Netflix Made AI Coding Agents More Efficient with JetBrains IDE Intelligence

构建项目索引需要实际时间，这与首次在IntelliJ IDEA中打开大型项目时的体验类似。编码代理通过许多小而精细的步骤调用LSP（Language Server Protocol），而实际任务需要多次这样的调用。如果每次调用都启动一个新的LSP服务器，那么每次调用都将产生数秒的冷启动成本——即使该项目的索引在几分钟前就已经构建完成。

为了避免重复调用时LSP服务器进程冷启动的开销，需要一个守护进程（daemon process）。JetBrains正在开发一个守护进程，但评估时尚未提供该功能，因此Netflix为自身需求构建了一个：

- 每次工具调用都是短暂且无状态的——它只是通过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框架。

**任务类型**

两种任务类型：

- 小型/聚焦任务：代理尝试理解代码库中的具体信息，例如“这个接口在项目中哪里被使用”、“这个接口有哪些实现”、“这个类的结构是什么”。

- 完整端到端任务：例如实现新功能、重构类或删除代码。

**模型**

- 使用Opus 5的Claude Code（中/高努力程度）

- 使用Sonnet 5的Claude Code（中/高努力程度）

- 使用GPT-5.6 Sol的Codex（中/高努力程度）

**评分**

实验中最关键的指标是令牌消耗和完成时间，但为了检查正确性，实现了将大语言模型（LLM）作为裁判。它针对端到端任务的参考变更集进行判断，并对导航任务应用确定性评分指标。

**异常值处理**

如果任务崩溃、达到预算上限或在任一处理分支中出现震荡，将从两组中排除，因此单次异常不会影响比较结果。

基准测试多次运行以验证结果并观察新LSP版本发布带来的变化影响。

## 结果

在所有测试的模型、代理和任务类型中，JetBrains IDE智能总体上使编码代理更加高效——通常提升20-30%，在最佳情况下甚至可达约65%，具体取决于特定模型、代理和任务。高努力程度的强模型获得了最大的提升。这些模型成本更高，因此效率提升更为重要，但这些模型在使用索引方面也更有效。

效率提升（结合节省的令牌数和时间）。每个比较均运行相同任务、模型和代码库两次——一次启用 JetBrains IDE 智能功能，一次不启用。

~25%

平均提升

20–30%

典型范围

~65%

最佳情况

配置

代码导航

端到端

强模型，高努力度

~24%

中等模型，高努力度

~29%

~30%

中等模型，中等努力度

~22%

轻量配置，高努力度

~17%*

~21%

效率是每种配置节省的令牌数和时间的平均值。每次运行的正确性保持稳定或有所提升。*仅令牌：此配置的批量搜索调用使代码导航时间比较不具代表性——详见文章正文。这些数据是快照，随着新模型发布将发生变化。

这些数字是快照，而非固定基准结果。每次新模型发布都会改变代理的搜索、推理和工具使用方式，因此具体百分比会持续变化——这也是本文报告范围而非每种模型结果的原因。在 Netflix 的所有运行中保持一致的是总体趋势：所有测试的模型和代理效率均提升，最大提升来自强模型在高努力度设置下的表现，且不同模型之间的提升幅度差异明显。

### 代码导航任务：整体效率提升，正确性保持或提升

所有测试的模型和努力度在启用 JetBrains IDE 智能功能后使用的令牌数均减少——无一例外，节省幅度在约 15% 至 60% 之间。提升幅度主要取决于模型：最强模型的提升幅度远超其他模型，而轻量配置则处于两个范围的低端。大多数运行中正确性保持稳定，有两次运行甚至有所提升——从未出现下降。

针对代码导航任务，有一种工具/模型组合已将多个搜索调用批量合并为单个命令，因此无论是否启用 JetBrains IDE 智能功能，它在此处仅调用一次工具。对于该单一调用，调用 JetBrains IDE 智能功能比批量搜索命令稍慢——这正是该组合时间收益不明显的直接原因，而非真实使用场景的反映。因此，更全面的端到端任务套件在时间效率上更具参考价值，其中 JetBrains IDE 智能功能在所有测试模型和代理中均更快。

### 端到端任务：效率持续提升，正确性不受影响

在扩展的端到端运行中，所有测试模型和代理的正确性均保持稳定，因此效率提升完全体现在效率指标上，而非任务是否完成。启用 JetBrains IDE 智能功能后，所有模型和代理组合在完成时间和令牌消耗方面效率均提升约 10–30%。这在很大程度上归因于达成相同结论所需的工具调用次数减少。

## 其他评估的替代方案

在采用上述方法之前，Netflix 排除了其他两种方案。第一种被拒绝的是一个内部开发的 CLI 工具，它通过连接运行中的 IntelliJ IDEA 实例来访问项目索引。该过程与本文描述的类似，但需要运行 IDE。这种方案不适合无头代理环境（如 Otto、Bitbot、分布式重构工具、CI 等）。

第二，考虑了现有的Eclipse LSP（该LSP在VS Code中用于Java）。但对于Netflix的构建系统（基于Gradle），它根本无法正常工作。

## 下一步计划

### Netflix的下一步行动

测试结束后，Netflix得出结论：“基准测试表明，在代理旁边拥有一个确定性智能层是有益的。”当然，它并不能按固定百分比削减所有编码代理任务。但对于这个特定问题——跨JAR边界解析真实结构——这种好处是显著的，适用于所有模型，且不会影响正确性。

Netflix计划将相同的基准测试方法应用于Python、TypeScript/JavaScript和Go语言。这些语言的编码代理面临类似的问题。但当然，不同语言在项目中下载库的方式存在差异，因此问题的机制和可能的解决方案也有所不同。JetBrains计划继续合作，并进一步支持这项评估。

### JetBrains的观点：LSP只是其中一步，而非最终目标

Netflix已测试了JetBrains的Java智能功能，并将其作为IntelliJ IDEA的Java & Kotlin扩展的一部分进行发布。JetBrains仍在继续尝试LSP+CLI方法，并将在结果准备就绪后进行报告。

LSP的基本原始单位是文本文档中的一个位置。规范将位置定义为“两个字符之间，就像编辑器中的插入光标”。这对键盘操作的人类来说是一个自然的原始单位。但代理并不真正以光标位置来思考。它们会提出关于程序的问题，例如“为什么createUser()中的这个调用无法解析？”或“哪些测试覆盖了这个方法？”等等。这涉及理解代码各部分之间的关系，而非关注光标位置。而文本位置是一个脆弱的身份——在任意给定位置之前插入一个字符就会导致该位置移动。

代理真正需要的不是更精确的光标，而是一个能以与任务本身相同方式（即以符号、诊断、测试关系、运行时行为等）提供答案的层，并返回足够的上下文来推理答案，而不仅仅是文本文档中的位置。

> “这就是我所说的代码引擎：不是另一个让代理模仿编辑器交互的协议，而是一组对程序结构和执行的精确操作——能够返回足够上下文来真正推理结果。LSP很有用，但它不应定义最终面向代理的抽象。如果将代理视为编辑器前的小型人类来构建代理工具，你就会迫使它用光标坐标进行交流。代理需要的是代码引擎，而非虚拟编辑器。” —— JetBrains IDE部门负责人Aleksey Stukalov

Netflix的数据证明代码智能值得投入。决定这种智能的具体形态，是摆在我们面前的挑战。

Air

案例研究

- 分享

- Facebook

- Twitter

- Linkedin

上一篇

你的下一步行动距离两个点还有一步之遥
 /think