2026 年 8-9 月,由前 Yandex Search CEO Andrey Styskin 与前 Amazon AGI 首席应用科学家 Matthias Petri 联合创办的 Keenable(累计融资 $26M,Accel 领投,Google、xAI、NVIDIA、Amazon、Hugging Face 等机构天使参与)先后上线两个互补产品:8 月 25 日发布的 Keenable Search API for Agents(12 颗星),通过 MCP 提供 `search_web_pages` 与 `fetch_page_content` 两个工具;9 月 1 日发布的 Keenable SELECT(60 颗星),以「用 SQL 写自然语言查询的 Web 搜索 Agent」为定位,把整个 web 当作 DuckDB 数据库,允许 Agent 直接写 `SELECT SEM_EXTRACT(content, 'researcher'), SEM_EXTRACT(content, 'left lab') FROM WEB_SEARCH(...) WHERE SEM_MATCH(content, ...)` 这样的 SQL 查询。SELECT 单次调用可以搜索 1000+ 网页、用精确 WHERE 子句过滤、逐行做小 LLM 调用抽取字段、按任意维度聚合——所有这些都不需要 Agent 自己去打开链接、读页面、做语义理解。两个产品合在一起,清晰勾勒出 2026 年 Agent 检索层的工程新基线:**检索应该从「返回链接让 Agent 自己读」迁移到「检索-检索-融合三层解耦」,让每一层独立优化、独立测试、独立替换**,这一架构原则与企业级 Agent 检索基础设施的演进方向高度吻合。
一、传统「返回链接」模式的根本局限
在过去两年所有主流 Agent 框架里,「Web 搜索 + 阅读」是默认模式:Agent 调用搜索 API(Perplexity、Tavily、Exa、Brave 等),拿到 10 个链接;Agent 决定哪些链接值得阅读;Agent 逐个访问、抓取内容;Agent 把抓取的内容汇总后推理,生成最终答案。这一模式在演示场景里表现尚可,但在生产环境暴露了五类根本性局限。
第一类是「Token 浪费」。每个网页内容都要进入 Agent 的上下文,Agent 阅读 10 个网页就消耗数十万 Token,大多数网页内容与最终问题无关,Agent 仍然要阅读、解析、丢弃。Anthropic 在自家 Claude Code 与 MCP 检索相关的工程实践中明确把这一点列为「高 Token 消耗」的反模式。
第二类是「可重现性差」。Agent 在每一轮都重新决定「读哪些链接」「读到什么程度」「什么时候停止」,同一查询在不同时间会得到不同的 Agent 推理路径与最终答案。这对企业级场景(同一查询应该得到同一答案)是不可接受的。
第三类是「精确过滤能力弱」。传统搜索 API 返回的是「与查询语义相关」的链接列表,但 Agent 真正需要的是「满足特定过滤条件」的精确子集——例如「过去 90 天内来自特定作者、包含特定关键词、被引用超过 10 次的论文」。传统搜索 API 无法表达这类复合过滤条件,Agent 必须自己实现。
第四类是「数据融合困难」。当 Agent 需要把多个搜索结果按某个维度做聚合(按作者统计、按时间排序、按地区分组)时,需要在多次搜索调用之间维护状态、合并结果、去重。LLM 在「精确合并多个数据源」任务上的准确率显著低于「在已有数据上做单一聚合」任务。
第五类是「可观测性差」。Agent 阅读网页、抽取信息、汇总答案的全过程不可重现——同样的查询可能因为 Agent 随机性而得到不同推理路径,审计与复盘都难以实现。
二、Keenable SELECT 的工程解法:SQL 作为检索层抽象
Keenable SELECT 把整个 web 抽象为一张 SQL 表,Agent 通过 SQL 直接对这张表做查询。具体的工程实现是:MCP server 提供一个 `select` 工具,接收只读的 DuckDB SELECT 语句,服务端在 DuckDB 外部运行 web 与语义算子(`WEB_SEARCH`、`SEM_EXTRACT`、`SEM_MATCH`),把输出重新塞回 DuckDB 的 row set,最后用 DuckDB 执行最终 SQL。
这一设计的工程价值在四个维度。第一,**Token 消耗显著降低**:Agent 不再需要读取 10 个网页自己理解,只需要提供查询语义,SELECT 把「读网页、抽取字段」这些工作下沉到「一次小 LLM 调用 per row」的精准执行模式,LLM 调用次数减少一个数量级。第二,**精确过滤能力表达力提升**:WHERE 子句支持任意复合条件,Agent 可以表达「过去 90 天内来自特定作者、包含特定关键词、被引用超过 10 次」这样的精确筛选。第三,**数据融合内置**:GROUP BY、JOIN、聚合函数都是 SQL 标准能力,Agent 写一个 `GROUP BY author` 就能完成「按作者统计」,不需要自己实现合并逻辑。第四,**可重现性显著改善**:同一 SQL 查询在服务端确定性执行,只要底层 web 索引不变,Agent 多次执行得到同一结果。
Keenable 展示页(60 颗星)给出了一组具体示例。「Which AI researchers moved between frontier labs since 2025? For each move list the researcher, the lab they left, where they went and the month.」这一查询被翻译为一条 SQL,包含 `SEM_EXTRACT(content, 'researcher')` 等四个字段抽取、`WEB_SEARCH(8 diverse queries)` 触发 8 个不同角度的搜索、`SEM_MATCH(content, 'named researcher moving between frontier labs, 2025+')` 做语义过滤。整条查询在一次 MCP 调用中完成,Agent 不需要自己决定「读哪些链接」「怎么抽取」「怎么合并」。
三、三层解耦的检索架构
Keenable 的工程设计展示了 Agent 检索层的「查询-检索-融合」三层解耦架构。查询层负责「把自然语言问题翻译为可执行的查询」,包括选择搜索源、确定查询语义、规划查询步骤。检索层负责「执行查询并返回候选文档」,包括实际 web 抓取、文档解析、字段抽取。融合层负责「把多个检索结果合并为最终答案」,包括去重、排序、聚合、生成。
每一层都可以独立优化与独立替换。查询层可以用不同 LLM、用不同 prompt 工程、用不同规划算法,但只要查询层输出格式稳定,检索层不需要改。检索层可以用不同 web 源、不同缓存策略、不同抽取模型,但只要检索层输出格式稳定,融合层不需要改。融合层可以用不同排序算法、不同聚合方法、不同生成模型,但只要融合层输入格式稳定,查询与检索层不需要改。
这种解耦在企业级 Agent 检索场景下尤其重要。企业往往需要私有 web 源(内部知识库、合作伙伴 API、内部 wiki),希望与公共 web 源共存于同一查询中。如果 Agent 必须直接处理两套不同 API(公共 web 搜索 + 内部知识库搜索),它必须自己处理协议差异、权限控制、结果合并。Keenable 的 SQL 抽象把这一切都封装在 `FROM` 子句里,Agent 只写一个 `FROM WEB_SEARCH(...) UNION ALL FROM INTERNAL_SEARCH(...)` 就能查询多源。
四、企业级 Agent 检索层新基线
把 Keenable SELECT、Keenable Search API、传统 MCP 检索工具、WebMCP 协议层的工具注解机制合并起来,可以提炼出企业级 Agent 检索层必须落地的五项关键基线。
第一项基线是「检索层必须支持 SQL 或类似声明式抽象」。Agent 不应该在每个查询里都重复「调用搜索 API、解析结果、抽取字段、合并答案」的流程,而应该用 SQL 或类似声明式语言一次表达完整查询。Keenable SELECT 展示的可重现性、Token 节省、融合能力都是这一抽象的直接收益。任何企业级 Agent 检索产品都应该提供类似抽象,而非把 Agent 当作「会自己读网页的助手」。
第二项基线是「检索层必须支持复合过滤」。传统「返回 10 个链接」的搜索 API 在生产环境是不够用的,Agent 必须能够表达「特定时间窗口 + 特定来源 + 特定关键词 + 特定引用次数」的复合条件。SQL WHERE 子句是表达力最强的复合条件语言,任何检索层产品都应该至少支持类似 WHERE 语义。
第三项基线是「检索层必须可观测」。任何检索调用都必须有完整日志——查询 SQL、检索源、命中数、过滤条件、抽取字段、聚合结果。日志进入企业 SIEM,与已知攻击指标(异常查询模式、异常数据外泄)交叉比对。
第四项基线是「检索结果必须有 provenance 与 untrusted annotation」。WebMCP 规范第 6.4.4 节的「Untrusted Annotation for Tool Responses」专门为此设计——检索结果应该标注「来自不可信来源」「基于 LLM 抽取可能含错误」「与查询的相关性分数」。Agent 客户端根据这些标注决定如何处理检索结果,而非默认把检索结果当作确定事实。
第五项基线是「检索层必须支持多源融合」。企业级 Agent 检索的真实场景几乎总是需要同时查询公共 web + 内部知识库 + 第三方 API。检索层应该原生支持多源融合,无论是通过 SQL UNION ALL、GraphQL 多源查询,还是 MCP 多工具编排,而不是让 Agent 自己实现跨源合并。
五、链路视角下的最终结论
Keenable SELECT 的工程价值,可以用一句格言概括:**「让检索结果直接是结构化数据,而不是 Agent 自己抽取结构化数据」**。传统检索模式下,Agent 必须自己从 10 个网页里抽取字段、合并数据、生成答案,这一过程的 Token 消耗、错误率、可重现性都不可控。Keenable SELECT 把这一过程下沉到检索层,Agent 只写一条 SQL,服务端用 DuckDB 确定性执行,把 1000+ 网页的检索-抽取-聚合工作用一次小 LLM 调用完成。这一迁移让 Agent 从「网页阅读者」变成「查询编写者」,工程范式与过去三十年 SQL 数据库的演进一脉相承。
把视角拉到企业 AI 落地的长周期,可以看到三个必然迁移。第一,Agent 检索层必须从「返回链接让 Agent 自己读」迁移到「返回结构化数据让 Agent 整合」,SQL 或类似声明式抽象是这一迁移的工程抓手。第二,检索-检索-融合三层架构必须解耦,每一层独立优化、独立测试、独立替换,这是企业级 Agent 检索基础设施可维护性的关键。第三,检索结果必须带 provenance 与 untrusted annotation,WebMCP 规范的协议层注解机制是这一基线的工程实现路径。
模型可以迭代——Claude Sonnet 5 之后会有更强的 Sonnet,Fable 5 之后会有更强的 Opus——但 Agent 检索层的链路基线(声明式 SQL 抽象 / 复合过滤能力 / 可观测日志 / provenance 标注 / 多源融合)不会因为模型升级而失效。把资源投到这些不散的链路层要素上,是企业 AI 落地性价比最高的工程方向,也是把「模型可换、链路不散」立场落到 Agent 检索层领域的具体实践。Keenable SELECT 与 Keenable Search API 的相继出现,标志着一个清晰的事实:Agent 检索层正在从「文档阅读基础设施」迁移到「结构化查询基础设施」,这一迁移对所有依赖检索的 Agent 应用都有根本性影响。
