不给搜索不行，上下文太长也不行

agent 能力的边界在哪？最近两份评测从两端给出了刻度：一端量检索，不给搜索工具，agent 在专业任务上几乎失能；另一端量注意力，把任务硬塞进超长上下文，准确率先自罚一大截。

Vals Web Search Index：把搜索引擎拉上考场

Vals AI 的 Web Search Index 思路干净：固定模型与 agent harness，只换背后的搜索引擎，厂商原生搜索与 Exa 这类第三方 API 同台竞技，端到端量法律与金融领域的真实专业任务。题库来自 FAB v2 金融基准的九百二十七道专家审校题目与法律研究基准，agent 与 harness 代码在 GitHub 开放，方法可复现。

读数相当清醒：榜首快照约 48.45%，顶级搜索工具也只能解不到一半的专业任务。Latent Space 周报的口径更直观：无搜索时法律任务正确率约 2.9%、金融约 7.4%，配上好搜索能拉到 30 至 50%。上周站内写过的 HyperBrowseComp 考的是 agent 会不会搜，这份基准考的是搜索引擎本身好不好，两者互补。配套动态是 Artificial Analysis 同步推出了 Search Index，按质量成本速度给搜索 API 排名，搜索引擎正在成为被独立评测的组件品类。

NVIDIA 长上下文研究：128K 不是免费的

另一端来自 NVIDIA 的研究：七个开源模型，把同一批任务从 4K 上下文拉到 128K，平均准确率衰减 62.8%。长上下文营销里默认开大窗口就能装更多活，这份研究给出的账是：把 4K 规模的任务硬塞进 128K 窗口，等于先自罚六成再开工。

两条线合起来就是一张实用的工程对照表：能靠检索解决的，别靠堆上下文；确实要处理长文的，先做压缩、分段与检索路由。站内此前写过的 FOCUS 上下文压缩（峰值上下文砍 48%、任务成功率反升 8.9 个点）正好是这张表的第三行注脚。

一句话收束

agent 栈的两大传统信仰，窗口越大越好与搜索可有可无，正在被逐一打上折扣标签。选型时先看任务属于哪一格，再决定钱花在窗口、检索还是压缩上。