JetBrains Context 上线 12 天：coding agent 的瓶颈不是模型，是仓库上下文

2026 年 7 月 21 日，JetBrains 上线了一个叫 JetBrains Context 的东西。JetBrains 自己测出来的数字是这样的：在 205 个 SWE-bench 任务、175 个生产 monorepo 任务、1953 个 code-localization 任务上，给 Claude Code、Codex、Junie 装上这一层之后，agent 的轮次减少最多 68%、延迟降低最多 59%、执行成本减少最多 48%（来源：JetBrains 博客 2026-07-21，JetBrains 自家基准）。

这三个数字比今年所有新模型发布都更值得停下来看一眼。它不是在说"agent 更聪明了"，它在说"agent 没变聪明，但少走了三倍弯路"。

<!-- 配图：JetBrains Context 工作流对比 -->

一、Honeymoon 结束了

JetBrains 博客里有一句相当冷静的判断，原文是："the honeymoon phase is ending"——蜜月期结束了。

过去两年，开发者对 AI 编码的态度是"能跑就行"。代码风格不对、能跑；逻辑有点别扭、能跑；review 起来头大，也能跑——反正比我自己写快。但这一轮过去之后，老板们开始算账了。一个 agent session 烧掉几万 token 并不稀奇，单价降下来只是把账期往后推了半年。真正缺的不是更便宜的 token，而是 token 真正花在刀刃上的工作流（来源：JetBrains Context 原文 "The new reality for agents" 一节）。

JetBrains 把这种"token 浪费"具体拆成了三步：agent 接到任务，先跑搜索，再起一个探索子 agent，然后挨个读文件。这三步吃掉了多少时间和预算？他们没有给独立审计的精确数字，但他们的基准结论很干脆："agent 在仓库里搜索和读文件的时间越少，留在真正任务上的时间就越多"——而"留出时间"这件事，恰好是 JetBrains Context 要解决的问题。

这件事的真正反直觉之处在于：模型本身没动，agent 的框架也没动，只换掉了"怎么读仓库"这一层。三项硬指标——68%、59%、48%——就这么来了。

模型的智力上限早被解锁，agent 的工作流才刚被认识。

二、它到底做了什么

JetBrains Context 不是新模型，也不是新 IDE。它是一层"仓库智能"（repository intelligence），给 coding agent 用的索引层。

具体地说，它做两件事：第一，对你的 repo 做增量语义索引——不需要你手动触发，agent 在跑的时候 hook 会自动维护；第二，给 agent 一套语义检索工具，让它不用每次都从 grep 开始找代码（来源：JetBrains Context 原文 "What JetBrains Context is" 一节）。

听起来不稀奇？重头在后面：multi-repo search。

agent 不仅能搜当前 checkout 的 repo，还能跨组织内未 checkout 的仓库找代码。验证一个 API 在别处怎么用、评估一个改动的连锁影响、发现远程项目里早就存在的可复用实现——这些动作之前要么靠"老员工的记忆"，要么靠 agent 自己一个 repo 一个 repo 去 grep。现在 JetBrains Context 把这条路径压成了一条语义查询。

这才是给大公司 coding agent 的真正杠杆。中小企业 10 个 repo，开 IDE 翻一翻还能搞定；跨国企业的代码库动辄上千个 repo，跨 repo 复用是真正的工程瓶颈。JetBrains 做 IDE 二十年，索引、跳转、引用查找本来就是他们的老本行——这次只是把同一套能力反向开放给 AI agent 用。

可以这么理解：IDE 给人类装的是 GPS（跳转到定义、查找引用），JetBrains Context 给 agent 装的是同一套 GPS，但语义可机器读。新员工进公司靠 wiki 翻手册，老员工直接问同事——后者效率高出几十倍，因为后者调的是结构化知识。JetBrains Context 在做的就是把 agent 从"翻 wiki"提升到"问同事"那一档。

<!-- 配图：JetBrains Context 三项硬指标 -->