Keenable SELECT：用SQL查询全网的Agent新思路

当搜索变成一条SQL查询

在AI Agent工具层出不穷的今天，一款名为 Keenable SELECT 的产品在 Hacker News 上引发了关注（48 分、12 条评论）。它的核心理念极具冲击力：把「搜索网络」这件事变成一条 SQL 语句。

对于开发者而言，SQL 是最熟悉的结构化查询语言。而 Keenable SELECT 的巧思在于，它把互联网当作一张可查询的「虚拟数据表」，让你能够像查询数据库一样，用 SELECT 语句去检索、筛选和聚合网络上的信息。这种设计哲学，本质上是把 Agent 的能力封装进开发者已经烂熟于心的接口之下。

Keenable SELECT 在 Hacker News 的讨论

从自然语言到结构化查询的回归

为什么选择SQL作为Agent接口？

过去两年，主流的 AI 搜索 Agent（如 Perplexity、各类 RAG 系统）几乎都以自然语言对话为交互入口。自然语言的优势是门槛低、表达灵活，但它的问题也很明显：结果不可控、难以程序化调用、无法保证输出结构。

Keenable SELECT 选择了一条相反的路径——用 SQL 这种高度结构化的语言来约束搜索行为。这带来几个直接好处：

结果结构化：SELECT 出来的字段是明确的列，天然适合写入数据库或喂给下游程序。
可组合性强：WHERE、ORDER BY、LIMIT 等子句让你能精确控制筛选逻辑和返回数量。
对开发者友好：无需学习新的 DSL 或复杂 API，会写 SQL 就能直接上手。

这其实是一种「回归」：在大模型让一切都倾向于自然语言之后，重新用结构化的方式来驾驭 Agent，反而让系统更可预测、更适合工程化集成。

Agent在SQL查询背后扮演什么角色？

有意思的是，SQL 只是接口层，真正干活的仍然是背后的 AI Agent。当你写下一条查询时，系统需要：

解析 SQL 语义，理解你想查什么；
将查询意图转化为实际的网络搜索和抓取动作；
从非结构化的网页内容中，抽取出符合所选字段的结构化数据；
按照 SQL 的约束条件返回结果。

这中间的第 3 步——把杂乱的网页内容映射成整齐的数据表——正是大模型的用武之地，也是这类产品的技术核心与难点所在。

这种架构在工程上与「虚拟化表函数」（Table-Valued Function）的思路一脉相承。传统数据库中，表函数允许开发者把一段计算逻辑封装成一张可查询的虚拟表，调用方完全不需要关心内部实现。Keenable SELECT 的本质也是如此——web_search(...) 看起来像一张表，但背后实际上是一个完整的搜索-抓取-抽取 Agent 流水线。这种设计与 PostgreSQL 的 Foreign Data Wrapper（FDW）机制颇为相似：FDW 允许用户用标准 SQL 查询外部数据源（如 CSV 文件、REST API、其他数据库），系统在内部自动完成协议转换。Keenable SELECT 相当于把「互联网」注册为一个 FDW 数据源，由 AI 来充当传统 FDW 中手写的连接适配器。理解这一类比，有助于评估其能力边界：FDW 的经典痛点——谓词下推效率、JOIN 代价不可控——在这里同样存在。

Keenable SELECT解决了什么真实痛点

数据管道中的「搜索缺口」

在很多数据工程场景里，开发者需要从公开网络获取实时信息，比如「某类产品在各大电商的价格」「特定公司的最新招聘信息」「某个话题的近期新闻」。传统做法是写爬虫、清洗数据、结构化入库，整个链路又长又脆弱。

Keenable SELECT 试图用一条 SQL 把这条链路压缩成一步。理论上，你可以写：

SELECT title, price, url
FROM web_search('wireless headphones under $100')
WHERE price < 100
ORDER BY price ASC
LIMIT 10;

然后直接拿到干净的结构化结果。这对于需要把网络数据接入现有数据栈（如数据仓库、BI 工具）的团队而言，吸引力显而易见。

可编程搜索意味着什么

更深一层看，把搜索「SQL 化」等于让搜索可以被程序调用、被 cron 定时任务触发、被嵌入更大的自动化工作流。相比手动在对话框里提问，这是一种面向自动化的能力升级。你可以把它接进 Airflow、接进后端服务，让「获取网络信息」成为数据流水线中的一个标准节点。

RAG（Retrieval-Augmented Generation，检索增强生成）是当前 AI 应用中最主流的知识获取范式：先用检索系统找到相关文档片段，再将这些片段作为上下文喂给大语言模型生成答案。然而标准 RAG 通常依赖预先建好的向量索引，只能检索已收录的内容，对于实时网络信息无能为力。Keenable SELECT 代表了一类「实时 RAG」或「开放域检索」的思路——每次查询都直接触达公开互联网，绕过了索引构建环节。这使它在时效性上优于传统 RAG，但也因此失去了向量索引带来的语义召回能力和成本摊薄优势。将两者结合——用 SQL 接口触发实时抓取，同时对结果做向量化缓存——可能是这类产品未来演进的方向。

技术挑战与开放问题

尽管理念优雅，Keenable SELECT 这类产品仍面临几个绕不开的难题：

数据抽取准确性：把自由格式的网页可靠地映射成固定 schema，本身就是 NLP 领域的老大难问题。字段抽错、遗漏、幻觉，都会直接污染查询结果。
实时性与成本的平衡：每次查询都可能触发实时搜索和大模型推理，延迟和费用如何控制是一个现实问题。
SQL表达能力的边界：网络信息的模糊性和 SQL 的精确性之间存在天然张力。当查询意图本身就很模糊时，SQL 的严格语法反而可能成为束缚。

Hacker News 上的讨论热度也反映出开发者社区对这类「结构化 Agent 接口」既好奇又审慎的态度。

「幻觉」（Hallucination）在此场景下的危害尤为值得关注。在对话式 AI 中，幻觉通常表现为生成不存在的事实，用户往往能凭常识识别。但在结构化查询场景下，幻觉会以「数字看起来合理但实际错误」的形式出现——比如价格字段被模型凭经验填补而非真实抓取、URL 被生成而非实际爬取。这类错误进入数据管道后会被无声地传播，污染下游分析结果，排查成本极高。因此，这类产品在工程上必须建立严格的「来源可溯性」机制：每一个返回字段都应附带原始网页的精确定位（URL + 文本偏移量），让下游系统能够独立验证，而不是盲目信任模型的抽取结果。

Agent接口设计的另一种可能

Keenable SELECT 最大的价值或许不在于产品本身，而在于它提出的接口设计思路：AI Agent 不一定非要以聊天对话的形式呈现，它完全可以藏在开发者熟悉的抽象之下——比如一条 SQL 语句、一个函数调用、一个 API endpoint。

当 Agent 能力逐渐成为基础设施，如何把它「工程化封装」将成为一个关键命题。用 SQL 查询全网，只是这场探索中一个颇具启发性的样本。它提醒我们：好的 AI 产品，往往是把强大的能力装进用户早已熟悉的容器里。