agent的瓶颈，不在推理，在找文件

一个300亿参数的agent在SWE-Bench Verified上解一道题，平均要跑23轮交互、烧掉63.1万token；同一个任务真正需要写进代码的改动，往往只有二三十行。这些数字摆进同一条时间线，“瓶颈在推理能力”这个说法就站不住了——推理不是账单上的大头，钱都花在grep、glob和反复打开文件上，agent不是在编程，是在图书馆里找一本不知道在哪个架子的书。一年前我把这道题的答案押在模型能力这边，现在得改掉一半：能力不是卡点，成本才是。

CodeGrep把找文件这个环节单独拆了出来：一个140亿参数的检索代理专职干搜索，并行发起多轮检索，把候选文件交给下游冻结住的编程代理；相当于给agent配了个专职图书管理员，研究员不用再自己满图书馆乱转。效果上，它在500个实例上把解决率从25.8%抬到27.0%，这不是个好看的提升；真正值钱的是另一个数：在已经解掉的实例上，轮次少了15%，token消耗少了19%。同一个任务，同样的完成质量，成本掉了将近五分之一。方向不在这两年大家都在追的“更强推理”上，在一条安静得多的曲线上：把同样的活干得更便宜。

论文里有三个检索精度数字，我盯着看了几遍：BM25的0.375，喂给下游代理反而把性能拉低；Jina的0.445，不帮忙也不添乱；CodeGrep的0.677跨过某条线之后，rollout成本才开始真的往下掉。反直觉的地方在这：给agent多喂相关文件不是免费的，精度不够的检索比不检索还糟，噪声会把代理往错误的方向使劲。检索的及格线，比大部分人以为的高。

所以过去两年那种“在工具列表上加几个搜索API”的近路，大概走不通。加搜索API解决的是有没有，解决不了准不准；而CodeGrep做的恰恰是把“准”这件事直接端到端训练出来，不是把工具拼上去。这里要认一个错。三层棋盘我一直习惯把检索、定位这类动作归进壳层，当作工作流组织的一部分；这个分法在功能视角下说得通，但CodeGrep把检索做成一个独立训练的模型之后，格子明显分错了：检索不是壳层的工具整合，是模型层内部正在长出垂直分工——编代码的模型负责改，检索模型负责找，两个都是被训练出来的能力，只是干的活不同。护城河没有消失，只是这轮搬家，搬到了模型层内部。

这条曲线放到agent格局上看，我压的注是：未来两三个季度，agent层面的竞争焦点会从benchmark分数转向单位成本曲线——谁能把同等任务的token消耗压出显著的梯度差，谁就拿走下一轮定价权。定价模式从按token转向按结果、按订阅，跟这条曲线是同一件事：按结果计费的前提是厂商对单次任务的成本心里有底，否则每个任务都是一个黑洞。这个判断的证伪条件也摆在这：如果半年内SWE-Bench Verified的整体解题成本没有出现可观测的下移，或者效率提升最终只能靠更强、更贵的模型硬怼出来，而不是靠这种中间层的分工优化，那这条曲线就是我想错了，该扔就扔。