Netflix 为编程智能体接入 IDE 代码分析引擎

用 JetBrains 多款产品内置的 AI 功能，为你的工具提效。

Netflix 将 JetBrains 的无界面代码智能引擎，也就是 IntelliJ IDEA 背后的同一套引擎，接入 Claude Code 和 Codex，并在多种场景下进行了基准测试。下面是具体做法和测试数据。

项目	详情
公司	Netflix 的应用开发平台（ADP）、GenAI 平台和 Agentic SDLC 团队
挑战	编程 Agent 难以准确导航 Java/Kotlin 代码，尤其是在跨越已编译库（JAR）边界时
技术	JetBrains 面向 Java 的 IDE 代码智能，基于 IntelliJ IDEA 使用的同一套代码索引引擎，在不开启 IDE 的情况下以无界面模式运行
Netflix 的工作	构建了让 Agent 能够调用 LSP 所需的 daemon 和 CLI；评估时，JetBrains 尚未交付这部分基础设施
结果	在真实编程任务中，效率通常提升 20–30%（token 更少、耗时更短），最佳情况下约为 65%。提升幅度取决于模型、Agent 和任务，通常模型越强、effort 设置越高，收益越大
评估范围	2026 年 7–8 月，在多个当时的编程 Agent 和模型上，使用两个真实代码库进行评估：一个内部生产服务，以及 Netflix 开源的 DGS Framework

目标：提高 Agent 的投入产出比

JetBrains 和 Netflix 希望在无界面环境中，为编程 Agent 提供准确、达到 IntelliJ IDEA 水准的代码理解能力，而且不需要运行 IntelliJ IDEA 实例。

“Claude Code 这样的编程 Agent 在导航 Java/Kotlin 代码时，速度慢，也不可靠，尤其是在跨越库（JAR）边界时。我们集成了 JetBrains IDE 的无界面代码引擎，让 Agent 在不运行 IDE 的无界面环境中，也能获得 IntelliJ IDE 级别的代码智能。我们用真实编程任务建立了一套基准测试。结果表明，借助 JetBrains IDE 的代码引擎，Agent 的效率始终更高，消耗的 token 更少，耗时也更短，具体提升幅度取决于模型。”

上面 Paul 提到的，正是 Netflix 想解决的 JAR 问题：JVM 项目中的库通常只以 JAR 文件的形式分发，并不附带源码。Agent 必须先猜测哪些 JAR 可能相关，再将它们解压，可能还要反编译 class 文件，最后用 grep 搜索这个并不完整的代码视图。

解决方案：JetBrains IDE 代码智能

JetBrains 多年来一直在打造 IntelliJ IDEA 背后的代码智能引擎。它以项目源文件的确定性索引为基础，覆盖项目使用的全部库。如今，这套代码智能已通过 LSP 对外提供，也可以在兼容 VS Code 的编辑器中使用。Netflix 使用的是该引擎的无界面构建版本。

但只有 LSP，还不足以让编程 Agent 直接使用：它只是一个通过协议通信的服务器，既没有方便 Agent 调用的入口，也没有内置的进程管理机制，无法在多次调用之间复用已经运行的实例。Netflix 自己补齐了这一环，构建了下一节介绍的 daemon 和 CLI。

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

为项目构建索引需要实实在在的时间，就像第一次在 IntelliJ IDEA 中打开大型项目一样。编程 Agent 会通过许多细粒度的小步骤调用 LSP，一个真实任务通常需要多次这样的调用。如果每次调用都启动一个新的 LSP 服务器，那么每次都要付出数秒的冷启动成本，即便这个项目的索引一分钟前才刚构建完成。

要避免重复调用时冷启动 LSP 服务器进程的开销，就需要一个 daemon 进程。JetBrains 正在开发 daemon，但评估时尚未提供，因此 Netflix 根据自身需求构建了一个：

• 每次工具调用都是短生命周期、无状态的，只负责通过 shell 执行 CLI。
• daemon 则持续运行：它的会话管理器根据项目根目录，将每次调用路由到对应的服务器进程；该进程在内存中持有这个项目的索引。
• 对同一项目的第二次调用会完全跳过索引构建，通过 stdio 直接访问已经预热的服务器。
• daemon 和 CLI 都使用 Java 开发，并以 GraalVM 可执行文件的形式分发，因此没有 JVM 带来的启动或运行时开销。

Netflix 如何衡量 JetBrains IDE 代码智能的投入产出比

为了弄清 JetBrains IDE 代码智能是否能提升编程 Agent 的表现，以及提升幅度有多大，团队开发了一套基准测试。模型相同、任务相同、代码库相同，唯一的变量是 Agent 能否调用 JetBrains IDE 代码智能。结果以启用和未启用 JetBrains IDE 代码智能的两组运行之间的性能差异来呈现。

评估环境与方法如下：

项目	详情
数据集	两个真实代码库：一个使用 Spring Boot 4 和 Gradle 的内部服务，项目规模中等；另一个是 Netflix 自己开源的 DGS Framework，这是一个公开的、混合使用 Kotlin/Java 的 GraphQL 框架
任务	两类任务：一类是范围较小、目标明确的任务，让 Agent 理解代码库中的具体情况，例如“这个接口在项目的哪些地方被使用”“这个接口有哪些实现”“这个类的结构是什么”；另一类是完整的端到端任务，例如实现新功能、重构一个类或移除代码
模型	Claude Code 搭配 Opus 5（medium/high effort）；Claude Code 搭配 Sonnet 5（medium/high effort）；Codex 搭配 GPT-5.6 Sol（medium/high effort）
评分	实验最关注的指标是 token 消耗和完成时间，同时也引入了 LLM as a judge 来检查正确性。端到端任务以参考变更集为依据进行评判，导航任务则采用确定性评分指标
异常值处理	如果某个任务在任意一组中崩溃、触及预算上限或陷入反复尝试却无法推进的状态，就会从两组中同时剔除，避免单次失控扭曲比较结果

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

在所有受测模型、Agent 和任务类型中，JetBrains IDE 代码智能都提升了编程 Agent 的整体效率：通常提升 20–30%，最佳情况下约为 65%，具体取决于模型、Agent 和任务。能力更强、effort 设置更高的模型收益最大。这些模型的成本更高，因此效率提升也更有价值；同时，它们也更善于有效利用索引。

各配置的效率提升综合了 token 和时间节省。每组比较都对同一任务、同一模型、同一代码库运行两次：一次允许使用 JetBrains IDE 代码智能，一次不允许。

效率提升取各配置下 token 节省比例和时间节省比例的平均值。每次运行的正确性都保持稳定或有所提升。*仅统计 token：该配置会批量执行搜索调用，使代码导航耗时的比较失去代表性，详见正文。这些数字只是当前快照，会随着新模型发布而变化。

这些数字只是一个时间点的快照，并非固定不变的基准结果。每次发布新模型，Agent 的搜索、推理和工具使用方式都会变化，因此具体百分比也会持续变化。这也是本文报告区间，而不逐一列出各模型结果的原因。Netflix 多轮测试中始终成立的是整体趋势：所有受测模型和 Agent 都变得更高效；能力最强的模型在 high effort 设置下收益最大；不同模型之间的收益幅度有明显差异。

代码导航任务：效率全面提升，正确性保持稳定或有所改善

所有受测模型和 effort 级别在使用 JetBrains IDE 代码智能后，token 消耗都减少了，无一例外，节省幅度约为 15% 到 60%。收益大小主要取决于模型：能力最强的模型提升幅度遥遥领先，而较轻量的配置在两项指标的收益区间中都处于较低端。大多数运行的正确性保持稳定，两次运行有所改善，没有一次下降。

具体到代码导航任务，有一种工具与模型的组合本来就会把多次搜索合并成一条命令，因此无论是否启用 JetBrains IDE 代码智能，它都只会进行一次工具调用。对于这一次调用，调用 JetBrains IDE 代码智能比执行批量搜索命令稍慢。这正是该组合没有明显时间收益的原因，却不能公平反映真实使用情况。因此，衡量时间收益时，覆盖范围更广的端到端任务集更有参考价值；在这组任务中，所有受测模型和 Agent 使用 JetBrains IDE 代码智能后都更快。

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

在扩展后的端到端测试中，所有受测模型和 Agent 的正确性都保持稳定。因此，收益完全体现在效率上，而不是任务能否完成。综合完成时间和 token 消耗来看，每一种模型与 Agent 组合在使用 JetBrains IDE 代码智能后，效率都提升了约 10–30%。其中很大一部分原因是：得出相同结论所需的工具调用更少了。

评估过的其他方案

在确定本文介绍的方案之前，Netflix 排除了另外两种方案。首先被否决的是一个内部自研 CLI，它连接正在运行的 IntelliJ IDEA 实例，从而访问项目索引。这个过程与本文介绍的方式类似，但要求 IDE 必须处于运行状态。这不适合 Otto、Bitbot、分布式重构工具、CI 等环境中的无界面 Agent。

第二个考虑过的方案是现有的 Eclipse LSP，VS Code 的 Java 支持也使用它。但对于 Netflix 基于 Gradle 的构建系统，它就是无法正常工作。

Netflix 接下来会做什么

测试结束后，Netflix 得出的结论是：“基准测试表明，在 Agent 旁边配备一层确定性的代码智能，确实有收益。”当然，它不会让每一种编程 Agent 任务都按固定比例缩短。但对于跨越 JAR 边界、解析真实代码结构这一具体问题，收益相当可观，在不同模型上都成立，而且不牺牲正确性。

Netflix 计划用同一套基准测试方法评估 Python、TypeScript/JavaScript 和 Go。这些语言的编程 Agent 也面临类似问题。当然，不同语言在项目中下载库的方式各不相同，因此问题的具体机制和可能的解决方案也会不同。JetBrains 计划继续合作，进一步支持这项评估。

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

JetBrains 面向 Java 的 IDE 代码智能已经过 Netflix 测试，如今已随 Java & Kotlin by IntelliJ IDEA 扩展一同发布。JetBrains 也在继续试验 LSP+CLI 方案，待结果准备就绪后会对外公布。

LSP 的基本原语是文本文档中的位置。规范将位置定义为“两个字符之间，就像编辑器中的插入光标”。对于坐在键盘前工作的人来说，这是很自然的原语。但 Agent 并不会真正从光标位置的角度思考。它们会提出关于程序的问题，例如“为什么 createUser() 中的这个调用无法解析？”“哪些测试覆盖了这个方法？”等等。它们关心的是理解代码各部分之间的关系，而不是查看光标位置。而且，文本位置是一种脆弱的标识：只要在某个位置前面插入一个字符，这个位置就会移动。

Agent 需要的是一层能够按照任务本身的表达方式提供答案的能力：围绕符号、诊断信息、测试关系和运行时行为来回答问题，并返回足够的上下文，让它能够推理和理解答案，而不只是返回文本文档中的位置。

“这就是我所说的代码引擎：它不是又一种让 Agent 模仿编辑器交互的协议，而是一组针对程序结构和执行过程的精确操作，能够返回足够的上下文，让 Agent 真正推理和理解结果。LSP 很有用，但不应该由它来定义最终面向 Agent 的抽象。如果你把 Agent 当成一个坐在编辑器前的小人来构建工具，就会迫使它用光标坐标来交流。Agent 需要的是代码引擎，而不是虚拟编辑器。”

Netflix 的数据证明，代码智能值得投入成本。接下来的挑战，是决定这套智能应该以怎样的形式提供。

谢谢，我们收到啦！

上周，我们分享了对 Agent 驱动开发未来方向的看法，并介绍了 JetBrains 的答案：JetBrains Air，一套面向 Agent 驱动开发的开放产品体系。今天，我们正式推出 Air 在 JetBrains IDE 中的 Early Access Program。现在，它已经可以作为插件……

第 1 部分：解析、分块与向量化。前段时间，我们着手打造力所能及的最佳语义代码搜索平台：一条 RAG 流水线，为 LLM Agent 提供来自真实代码仓库的精确、可引用依据，而不是 grep 碰巧搜出来的内容。最终的解决方案就是 Air Context。……

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

这是一个系列的第 3 部分，我们会选取公开的编程 Agent“token 节省”附加工具，对每一个运行相同的配对 A/B 基准测试。第 1 部分测试的是 caveman skill（宣称减少 65%，实测减少 8.5%）。第 2 部分测试的是 rtk（宣称减少 60–90%，实测增加 7.6%）。我们运行了 80 组配对任务来测试 pony……