Ohhnews

分类导航

$ cd ..
Jetbrains Blog原文

为编程代理集成IDE原生搜索工具：显著提升效率与降低成本

#人工智能#编程代理#ide工具#软件开发#效率优化

我们针对多种模型和编程语言，在有无预打包工具（prebundled tooling）的情况下运行了相同的编码任务。以下是具体的变化。

评估驱动开发

IDE 原生搜索降低了延迟、成本和预算超支

下表采用了配对任务级增量进行对比。聚合中位数和总量仅供参考。预算超支指单个任务成本超过 0.50 美元上限的情况。

指标变化幅度结果对比
中位数延迟8.33%83.11s → 79.03s
P95 延迟16.44%268.71s → 213.17s
总成本5.60%44.17 美元 → 41.67 美元
预算超支33.28%6.67% → 4.44%

我们为何构建此功能

当编码智能体（Coding Agent）搜索代码时，它们通常默认使用 shell 工具。grep 和 find 虽然有效，但它们无法感知项目结构、符号边界和语言语义。智能体往往会因为筛选冗余输出和进行后续调用来缩小范围，从而浪费大量 Token。

因此，我们尝试了一个显而易见的方案：如果智能体能够直接使用 IDE 自带的搜索功能会怎样？

我们构建了一个预打包的技能（Skill），将搜索提示词与统一的 MCP（Model Context Protocol）工具相结合。该工具包含四种模式：文件搜索、文本搜索、正则搜索和符号查找。一个通用路由负责将调用分发到正确的后端。

MCP 工具

智能体在任务执行期间通过 MCP 服务器调用的函数。IDE 原生工具可以利用 shell 工具无法触及的索引、抽象语法树（AST）和项目模型。

技能（Skills）

封装的智能体行为：包含提示词加上编排逻辑。一个技能可以独立工作、使用工具，也可以与其所需的工具捆绑发布。

在评估结果验证其有效性之前，我们不会发布任何默认功能。在选定最终方案前，我们测试了四种不同的工具配置。

方法论

评估流水线在 IDE 旁边启动一个 MCP 服务器，使智能体能够访问配置好的工具和技能。我们运行完全相同的编码任务，并使用配对增量分析进行对比。

我们追踪四个维度：质量、延迟、成本和预算纪律。质量评估所有测试是否通过；延迟追踪中位数和 P95 任务耗时；成本将 Token 消耗转换为美元；预算纪律追踪单项任务超过 0.50 美元上限的频率。

我们仅在统计结果达到显著性阈值（p < 0.05，95% 置信区间的配对检验）时才报告改进增量。未达到显著性变化的指标要么从图表中省略，要么被明确标注。我们尝试了四种配置变体，选择了延迟与成本权衡最优的一种，并在不同模型和语言上重新运行，以验证结果的稳健性。

评估框架

相同任务，相同评分，唯一受控差异。

  • 质量：所有测试通过率，在性能评估前进行核查。
  • 延迟：中位数和 P95 任务耗时，通过配对增量进行比较。
  • 成本：整个任务集中 Token 使用量转换后的美元金额。
  • 预算纪律：超过 0.50 美元单项任务上限的任务占比。

结果

选定的配置方案是“预打包搜索技能 + 统一 IDE 原生工具 + 通用路由”。与无工具基准相比，它在没有产生统计学意义上的质量变化的前提下，降低了延迟和成本。

绝对指标均向优化方向移动

  • 中位数延迟：基准 83.11s → 工具加持 79.03s
  • P95 延迟：基准 268.71s → 工具加持 213.17s
  • 总成本：基准 44.17 美元 → 工具加持 41.67 美元
  • 预算超支：基准 6.67% → 工具加持 4.44%

质量方面没有统计学上的显著变化。所有显示的增量均通过了显著性阈值。

追踪快照

这种差异在智能体对项目的处理路径中清晰可见。以下是在时间和成本上均有改进的案例简短追踪记录。基准方案花费更多步骤来探索上下文；而预打包方案能更快定位到相关文件。

案例：服务层注释与回复更新

  • 前（无预打包 IDE 搜索）：智能体执行列表文件 → 搜索 x2 → 列表文件 x2 → jar 检查 x5 → javap → jar 检查 → javap x5 → curl 下载 → 反编译 → 搜索 → 查找文件 x2 → 读取 9 个文件 → 编辑文件 x8 → 响应。耗时：472s
  • 后（预打包技能与统一搜索）：智能体读取 SKILL.md → 搜索 x3 → 读取 5 个文件 → 读取 FeatureController.java → 读取 4 个文件 → 编辑文件 x2 → 响应。耗时：127s

配置探索

在选择最终方案前，我们测试了四种工具配置。较低的延迟和较低的总成本是我们的目标，因此图表左下角为最优区域。

跨模型验证

我们使用 GPT 5.4 在 Java 和 Kotlin 代码库上重新运行了实验。结果模式一致：延迟和成本均有所下降。Kotlin 代码库的成本改善最为显著，总成本下降了 13.48%。

跨模型检查结果

  • Codex 5.2：中位数延迟下降 8.33%，总成本下降 5.60%，P95 延迟下降 16.44%。
  • GPT 5.4 (Java)：中位数延迟下降 3.75%，总成本下降 4.07%，P95 延迟下降 13.00%。
  • GPT 5.4 (Kotlin)：中位数延迟下降 6.92%，总成本下降 13.48%，P95 延迟无显著变化。

模型如何采用新工具

Codex 91% 的搜索调用通过新的 IDE 原生工具进行。Claude 的情况则不同：Opus 约有一半的搜索使用该工具，而 Haiku 仅使用 28%，更倾向于使用 grep 和 find。

这很合理。Claude 本身已具备强大的内置代码搜索能力，因此它依赖于自身熟悉的工具。Codex 则不然，所以当有更好的工具时，它会优先选择使用。结论是：预打包工具填补了模型能力的空白。模型搜索能力越强，预打包工具带来的增益越小；搜索能力越弱，其差异越明显。

未来展望

评估流水线已验证有效，目前我们正在全面应用。 接下来，我们将在更小的模型上运行相同的实验。我们推测它们获益会更大，因为它们可依赖的内置搜索能力较少。

目前的实验结果在 Java 和 Kotlin 上表现最强。我们正将测试规模扩大至 Python、.NET 和 TypeScript。

同时，获胜的配置方案正准备集成到 IntelliJ IDEA MCP 服务器中，以便在启用服务器时，智能体会话可以使用 IDE 原生工具。

下一步是将此功能在 AI Assistant 插件的后续更新中设为默认开启。

想要在正式推送前试用？

  1. 将以下注册表键值设为 true：llm.chat.agent.codex.mcp.idea、llm.chat.agent.skills.settings.enabled 和 llm.agents.contrib.bundled.skills.sync.enabled。
  2. 在 AI Assistant 中选择 Codex 以获得最佳效果。
  3. 要求智能体在当前项目中进行搜索。

先测量，后发布，发布后持续测量。这就是我们的完整方法论。