AI 代理查资料为什么不该走人类搜索的老路

翻到 Keenable 这个项目时，注意力被它一个判断拽住了：眼下通行的搜索 API，出发点是人，返回的也是给人看的东西，而代理要的数据形态跟这完全是两码事。

主流搜索接口干的事，大多还是模仿浏览器，吐回一堆带广告的链接和摘要。放到需要多步推理的代理流程里，这种输出就是负担。模型得在冗余内容里挑拣，Token 白烧；更麻烦的是网络请求本身带来的等待，会把原本连贯的上下文硬生生截断。

Keenable 团队的人员构成有点分量，创始人此前在 Amazon 管 Alexa 的 Web Grounding，合伙人出自 Yandex。他们把接口的定位从分发链接挪到了结构化数据提取，落到开发场景里，对应的正是三个卡点。

延迟是其中之一。代理的多步推理链里，每次搜索调用都相当于一次阻塞，p95 一旦到了秒级，用户在终端上感觉到的就是卡。Keenable 给出的说法是把 p95 压进 250ms 以内，这样一来，“搜索—分析—再搜索”就能在很短的窗口里跑完，推理不会因为等接口而断掉。

数据怎么交付是另一个。它用类 SQL 的接口去查网页，这一点比较少见。老路子得走一串：调 API、拿 URL、爬 HTML、拿正则或 LLM 清洗、再提结构化数据。Keenable 让开发者直接以近似 SQL 的逻辑筛选和抽取页面内容，HTML 解析这一段最磨人的环节被跳过了。要做精准实时数据提取的话，省下的开发量不止一个数量级。

基准测试的真假也值得说。不少搜索 API 爱刷静态 Benchmark 的分数，可代理面对的是不断变化的 Web。Keenable 开源了一个叫 NEEDLE 的实时基准工具（https://keenableai.github.io/needle），跑的是那种代理风格的实时查询。接入之前，开发者能借此看清实时信息检索下 API 的召回和准确度究竟怎样，不用只信宣传页。

额度方面给得也猛，每月 10 万次免费。多数搜索 API 按千次计费，额度卡得紧，这个力度摆明了是要抢开发者。

专门为机器设计的搜索索引，更像是代理基础设施该有的样子。人要的是能阅读的搜索结果页，模型要的是一个低延迟、结构化、能高效读取全网信息的“内存扩展”。代理开发中被现有工具拖慢的话，SQL 式检索这条思路值得试。

条件同时成立时的下一步：p95 落在 250ms 以内、接口按类 SQL 返回结构化字段、NEEDLE 上实时查询的召回与准确度能看，这三样凑齐，代理的多步推理链才谈得上不被等待打断；缺了延迟这一环，结构化数据再好，推理照样在阻塞处失效。