JetBrains推出Junie Eco模式：用强模型规划、低成本模型执行

并非编码任务的每一步都需要世界上最聪明的模型。

Junie Eco 模式会使用你选择的模型来调查编码任务并制定计划，然后将实现和测试交给成本更低的模型。在两项内部基准测试中，这种方法将每个任务的平均模型成本降低了 48% 和 57%，而平均解决率的变化不到一个百分点。

观察任何 AI 编码代理执行任务，你会发现它是一小步一小步推进的。它会打开文件、搜索项目、进行编辑、运行测试、读取错误信息、补上缺失的一行、再次运行测试。这就是编写软件的本来面貌，经验丰富的工程师也是以同样的方式工作。其中只有少数步骤需要艰难判断：理解请求、在代码中找到正确位置、决定采用哪种方法。其余都是执行，即落实已经做出的决定。

然而，编码代理通常在整个任务中只运行一个 AI 模型。如果这是可用的最聪明、最昂贵的模型，那么每一步都要支付其高昂价格，包括第二十次“再次运行测试”。

想一想一栋建筑是如何建成的。你聘请建筑师来设计它，而不是让他砌每一块砖。建筑师做出艰难决策，把它们写下来，然后由施工队完成建造。

Eco 模式将这一理念引入 Junie。你选择的模型（Opus、Fable、Grok、GPT）充当架构师：它研究代码并编写计划。一个成本低得多的模型充当构建者：它接过计划并完成实际工作。在我们最新的内部基准测试中，Eco 模式将每个任务的平均模型成本降低了约一半： 基准测试 B 上降低 57%，基准测试 A 上降低 48%。在各个受测配置中，平均解决率的变化不到一个百分点。

Eco 模式目前面向 IDE 中的 JetBrains Air EAP 用户开放：在 IntelliJ IDEA 2026.3 Beta 中可用，其他 IDE 的 Beta 版将随后推出；在 JetBrains IDE 的 2026.2 版本中也可用。从版本 26.10.20 开始，它在 Junie CLI 中正式可用。对于受支持的模型与投入级别配置，Eco 模式默认启用。

Junie Eco 模式如何工作

Eco 模式将编码任务分为两部分，并将每一部分交给最适合它的模型。

第 1 步：架构师制定计划。 当你要求 Junie 修改代码时，它首先会将任务交给你选择的模型，并以你选择的投入级别运行。在此阶段，模型只被允许查看：它会阅读和搜索代码，但不做任何更改。（唯一的例外：如果你报告了一个 bug，它可能会编写一个小测试来复现该 bug。）它已经了解你到目前为止与 Junie 讨论的所有内容，因此你无需重复说明。它的设计目标是快速，通常约 15 步，一旦知道要改什么以及如何改就会停止。

结果是一份结构固定的简短计划：

• 目标：变更应实现什么
• 范围：包含什么、不包含什么
• 修改位置：具体的文件和代码部分
• 方法：如何实施变更
• 测试：如何验证其有效
• 风险与边界情况：可能出现什么问题

第 2 步：构建者按照计划执行。 然后，Junie 将同一段对话（包括计划）交给一个成本低得多的模型（目前是 GPT-6 Luna）。构建者负责漫长、动手操作的部分：编辑文件、运行构建和测试、修复出错之处，并完成任务。 [LOADING...]

Junie 使用你选择的模型进行调查，然后将对话和结构化计划交给成本更低的模型进行实施。

这之所以有效，是因为任务成本是这样累加起来的。规划只涉及少量步骤，但需要良好的判断力。构建涉及许多步骤，而其中大多数只是按计划执行。使用 Eco 模式，你只需为需要高端判断力的部分支付高价。

为什么不直接为每个任务选择模型？

显而易见的替代方案是：查看每个请求，并预先猜测它是困难（使用昂贵模型）还是简单（使用廉价模型）。我们认为这并不能很好地奏效：

• 仅凭请求无法判断任务有多难。 “修复有时会失败的测试”可能只需改一行，也可能需要长达一周的调查。预先猜测意味着在任何人查看代码之前就做出决定。Eco 模式会让智能模型先查看。
• 每个任务仍然获得高质量思考。 廉价模型从不决定要构建什么。它只执行智能模型已经做出的决定。
• 交接的是一份书面计划，而不是猜测。 由于计划始终具有相同的结构，构建者一开始就知道要改动哪些文件、如何测试变更，以及需要注意什么。

每个任务一次交接

有些工具允许廉价模型在遇到困难时“呼叫更聪明的朋友”寻求建议。每一次这样的调用都意味着要把一大段对话重新发送给昂贵模型，这会迅速累积成本。Eco 模式只进行一次交接，从架构师交给构建者，而且从不来回切换。这使整个过程既简单又便宜。

Eco 模式何时不介入

Eco 模式只会在可能有所帮助的地方介入：

• 仅适用于需要修改代码的任务。 只有当你需要保留代码变更时，规划步骤才会运行。提问、解释、设置项目、“运行这个并告诉我会发生什么”等，所有这些从头到尾都由你选择的模型处理。
• 在不节省成本的地方关闭。 Eco 模式在 /remote 会话以及某些模型与投入级别组合中不可用，包括低投入级别的 Opus 5.5 和 Sonnet 5.5。

基准测试结果

对于每个受测的模型与投入级别配置，我们分别在关闭和开启 Eco 的情况下运行相同的任务。我们最新的评估涵盖两个内部基准测试：基准测试 B（29 个配对配置）和基准测试 A（21 个配对配置）。这些是配置数量，不是任务数量。每个配对都将 Eco 与相同的模型和投入级别基线进行比较。

两个基准测试完全由来自私有仓库、复杂度各异的真实任务组成。基准测试 B 涵盖不同规模和项目背景的各类私有仓库。基准测试 A 包含来自超大型仓库的任务，其规模使许多任务显著更具挑战性。

解决率是评估中标记为成功解决的基准任务所占比例。我们报告在受测配置上取平均的每任务模型成本和解决率。

模型成本与解决率

[LOADING...]

最新内部评估。基准测试 B 上 29 个模型与投入级别配对的平均值，以及基准测试 A 上 21 个配对的平均值。结果因模型和工作负载而异。

在基准测试 B 上，平均每任务模型成本从 2.61 美元降至 1.11 美元（降幅 57.3%），而平均解决率从 49.1% 变为 48.5%，下降了 0.6 个百分点。

在基准测试 A 上，平均每任务模型成本从 2.51 美元降至 1.30 美元（降幅 48.1%）。无论是否启用 Eco，平均解决率四舍五入后均为 32.1%。

单个配置的解决率变化可能更大。成本降低百分比是根据图表中更精确的数值计算的；正文中的美元金额四舍五入到美分。

评估中的示例

以下示例来自对基准测试 B 中 100 个真实编码任务的评估。在该评估中，对于 max 投入级别的 Opus 5.5，Eco 将每任务模型成本降低了约 63%。

试用

Eco 模式可用于：

• IDE 中的 JetBrains Air： 在 JetBrains IDE 的 2026.2 版本中，以及从 Beta 构建开始提供的 IntelliJ IDEA 2026.3 EAP 中可用；其他 IDE 的 2026.3 EAP 构建将随后推出。
• Junie CLI： 在 26.10.20 及更高版本中正式可用。

在这些环境中，对于 Opus 5、Opus 5.5（中等投入级别及以上）、Fable 5.1、Grok 4.5 / 4.6 / 4.7、GPT-5.6 Sol、GPT-6 Sol、GPT-5.6 Terra 和 GPT-6 Astra，Eco 模式默认启用。当你希望由一个模型处理整个任务时，可以随时关闭 Eco。

使用模型选择器开启或关闭 Eco。选择你信任、能负责思考的模型，其余工作交给 Eco 模式处理。

每个任务只用一个模型正成为过去

最聪明的 AI 模型不断变得更强，但成本仍然更高。与此同时，廉价模型已经悄然变得足够好，能够完成大多数动手工作——只要有人明确告诉它们该做什么。我们认为，AI 编码助手的未来不是单一模型，也不是一个预先猜测该用哪个模型的系统。而是一个团队，其中工作的每一部分都交给最适合它的模型。

Eco 模式是我们朝这个方向迈出的第一步。请在真实工作中试用，并告诉我们它在哪些方面表现良好、哪些方面仍有不足。