Agent 时代，为什么有人开始重新造 Google？

作者 ｜ 蔡芳芳

当 Google 已经索引了几乎整个开放互联网，还有必要从头再造一个搜索引擎吗？

前 Yandex 搜索、AI 和云业务负责人 Andrey Styskin 的 答案 是：有必要。只不过这一次，搜索引擎最重要的用户可能不再是人。

近日，一家名为 Keenable 的创业公司正式走出隐身状态，同时宣布完成 2600 万美元种子轮融资，由 Accel 领投。Styskin 是这家公司的联合创始人兼 CEO，在 Yandex 工作近二十年后，他曾进入 Amazon AGI 负责 Web 基础设施；另一位联合创始人 Matthias Petri 同样来自 Amazon AGI，此前参与 Alexa 背后的 Web grounding 基础设施建设。

这是一支只有约 15 名工程师组成的团队，但干的事情相当“重”：重新爬取互联网，建立自己的 Web Index，再把它变成专门服务 AI Agent 的搜索基础设施。

据 Keenable 官网 披露，其索引已经覆盖超过1000 亿份文档，在美国东部的查询延迟低于 250ms（p95）；面向 100 RPS 以上的大规模客户，价格最低可以做到每千次请求 1 美元。更值得注意的是，它声称 API 已经进入数家 AI Labs 和推理服务提供商的生产环境，同时用于模型训练和运行时检索，但并未披露具体客户名称。

Styskin 给它定下了一个颇为野心勃勃的目标：成为 AI Agent 时代的“下一个 Google”。

Agent 搜索互联网的方式不一样了

Keenable 和今天已经很常见的 AI 搜索产品有所不同。它不想再做一个面向普通用户的 AI 搜索框，也不是简单在 Google 或 Bing Search API 上套一层大模型。Keenable 从底层重新做抓取（Crawl）、索引（Index）、检索（Retrieval）和排序（Ranking），再通过 REST API、MCP Server 和 CLI 把搜索能力交给 Agent。公司甚至直言，当前 Agent 使用的是一套“为人类优化”的 Web 访问工具，而它希望让 Agent 访问 Web 知识便宜到近似调用模型自身知识，不再因为成本和延迟而“舍不得搜索”。

这也是为什么一家刚刚走出隐身状态的创业公司，愿意承担重新索引整个互联网这样一件极其烧钱的工作。

Styskin 在接受 TechCrunch 采访 时解释，扫描整个互联网的服务成本非常高，如果索引结构没有针对具体任务优化，成本很快就会失控。真正的技术问题之一，是能否针对一次 Query 足够快地缩小搜索空间。他甚至用“painfully expensive”来形容构建巨大 Web Index 的成本。

但这笔昂贵投入背后，其实是一个比“搜索质量”更根本的变化：人和 Agent 使用互联网的方式完全不同。

过去二十多年，搜索引擎的典型链路是：

人提出 Query → 搜索引擎返回结果页 → 用户浏览链接 → 点击 → 阅读网页。

因此，传统搜索长期围绕人类行为优化：哪个结果最值得排在前面，用户更可能点击什么，找到答案之后是否还会继续搜索。

Agent 的工作流则可能变成：

接到 Task → Search → Fetch → Read → 发现信息缺口 → 修改 Query → 再 Search → 交叉验证 → 最终 Action。

一个 Research Agent 为了回答一个复杂问题，可以连续执行几十次搜索；Coding Agent 需要不断寻找最新文档、Issue、GitHub 仓库和 Changelog；销售 Agent 为了判断一个客户是否值得跟进，可能同时查询公司官网、融资新闻、招聘信息和高管动态。对这些 Agent 来说，“搜索”已经不再是用户主动点击一次按钮产生的动作，而是任务执行循环中的一个步骤。

这也意味着 Agent 没必要像人一样面对“十个蓝色链接”。它真正需要的是足够完整、足够新、来源可信，同时又尽可能精简、方便模型继续推理的上下文。

Styskin 因此认为，Agent 会形成一套不同于 Google 从人类点击行为中学习出来的反馈飞轮。传统搜索关注点击、排序和用户满意度，Agent Search 则会越来越关心Recall、Freshness、Latency、QPS、机器可读性、Token Efficiency、Provenance，以及最终完成一个任务究竟花了多少钱。

换句话说，搜索引擎过去优化的是“帮人找到网页”；Agent Search 要解决的，则更接近“用尽可能低的成本，找到足够完成任务的信息”。

Keenable 不是第一家发现这门生意的公司

Keenable 最直接的竞争对手 Exa 已经拥有同样量级的独立 Web Index。根据 Exa 官方数据，目前其向量数据库已经覆盖1000 亿份文档，跟踪约1.4 万亿个 URL，每天抓取数十亿份文档，平台开发者已经超过 50 万。Cursor、AWS、Groq 等都出现在其客户列表中，Devin 背后的 Cognition 联合创始人 Walden Yan 也公开表示，传统搜索方案无法满足需求，Exa 已经被用于 Devin 的多个环节。

今年 5 月，Exa 又完成了 2.5 亿美元 C 轮融资，估值达到 22 亿美元。它甚至预测，今年 AI Agent 发起的 Web Search 数量就会超过人类，并认为未来几年 LLM 产生的搜索量可能达到今天 Google 搜索量的千倍。后一个数字显然属于公司的前瞻性判断，但资本已经开始为这种可能性下注。

Exa 的产品 也早已不止 Search API。它已经覆盖 Search、Contents、Deep Search、Agent 和 Monitors：既可以在 200ms 左右完成低延迟搜索，也可以启动多步骤 Agent 做深度研究。其 Contents 服务还会抽取与任务相关的网页内容，提供所谓 token-efficient highlights，而不是一股脑把完整网页交给模型。

这也给刚刚出隐身的 Keenable 留下一个很现实的问题：既然 Exa 已经做到 100B Index、有明确客户，还有更完整的产品矩阵，为什么还值得再索引一次互联网？

目前两者公开可见的侧重点有所不同。Exa 已经从底层 Search 向 Research、Agent 和结构化数据服务延伸；Keenable 则更强调自己作为AI Labs 和 inference platforms 的底层 Search Infrastructure，把低延迟、高 QPS 和规模化调用成本放在非常核心的位置。Keenable 面向普通开发者的价格是每千次请求 4 美元，100 RPS 以上的专用容量可降至 1 美元；Exa 当前公开 Search API 基础价格为每千次请求 7 美元。由于两家的结果数量、内容处理和服务等级并不完全相同，这些数字不能简单换算成谁“便宜几倍”，但已经能说明：当搜索进入 Agent 高频调用循环，单次调用成本本身开始成为竞争指标。

国内也已经出现类似竞争。

博查 AI 提供面向 AI 应用的 Web Search 和 AI Search，搜索结果可以直接通过 Function Call、MCP 等方式交给 Agent；心流·搜索 则更加直接地把自己定位为“为智能体链接真实世界”，提供 Web Search、Web Fetch、Image Search，并支持 MCP、Skills、OpenClaw、Claude Code、LangChain 和 AutoGPT。后者甚至把“极省 Token”放到了产品首页：先过滤广告和网页冗余内容，再把重排后的精炼片段交给模型。

大厂也在重新改造原来的搜索能力。腾讯云联网搜索 API 基于公开互联网资源和腾讯内容生态，从数据收录、召回到精排都针对大模型重新设计，提供分钟级更新、最快 300ms 返回，并在 8 月 24 日进一步推出了面向 Agent 的联网搜索 MCP。阿里云 OpenSearch 也已经提供独立联网搜索 API，可以让 LLM 重写 Query、过滤搜索结果，并选择返回摘要或最长 3000 字符的正文。

这几类产品的起点并不相同：Exa、Keenable 希望掌握 Crawl、Index 和 Retrieval；博查、心流更直接地争夺 Agent Search API 和经过处理的 Context；腾讯、阿里则拥有原有搜索积累、内容生态和云平台入口。

但它们正在争夺同一个位置：谁能成为 Agent 访问互联网的默认接口。

Agent 搜索可能带来下一笔巨额账单

Agent Search 之所以可能成为一层独立的基础设施，还有一个非常现实的原因：Agent 太能搜了。

传统用户一次搜索行为可能只产生几个 Query，一个 Agent 完成复杂任务却可能搜索几十次甚至上百次。假设一个任务调用 100 次 Web Search，按照 Keenable 普通开发者每千次 4 美元的价格，仅搜索请求就是 0.4 美元；按照 Exa 当前每千次 7 美元的基础价格，则是 0.7 美元。真正进入生产环境后，还要叠加 Fetch、网页处理、模型 Context 和 Reasoning Token。

因此，Agent 时代真正值得计算的单位可能会从cost per search变成search cost per completed task。

阿里云 OpenSearch 的计费结构已经很能说明问题。一次联网搜索除了 Search Invocation，还可能触发大模型进行 Query Rewrite；结果过滤同样会消耗模型 Token。其 API 返回字段甚至单独记录 rewrite model 和 filter model 的输入、输出 Token。一次看似简单的“联网搜索”，背后已经变成了Query 理解 → 改写 → 检索 → 过滤 → Context 整理的一串计算。

这也是为什么越来越多 Agent Search 产品开始强调 Token Efficiency。

Agent 真正需要的通常不是一篇 5000 字网页全文，而是其中能够帮助当前任务继续推理的几段内容。如果搜索层能够先删除广告、导航、推荐模块和无关段落，只把最相关的 Passage 送进上下文，它节省的不只有 Search 成本，还会进一步降低后续模型的输入 Token 和推理成本。

于是，一条新的成本链条开始形成：

Search Quality → Context Quality → Token Consumption → Agent Cost。

搜索 Infra 和模型 Infra 开始出现在同一张账单里。

但成本只是 Agent Search 变化的第一层。更深的一层在于，Agent 最终需要的可能已经不再是传统意义上的“搜索”。

比如让 Agent 完成这样一个任务：

“找出过去六个月完成 A 轮融资、创始人来自 Google、同时正在招聘推理工程师的欧洲 AI 公司。”

互联网上很可能不存在一张网页直接给出完整答案。融资信息可能在新闻里，创始人履历在公司官网或 LinkedIn，招聘状态则藏在 Careers 页面。Agent 必须自己完成Search → Fetch → Join → Filter → Verify。

这也是 Keenable 仍在开发的WebQueryLanguage最值得关注的地方。Styskin 在采访中透露，它希望让 AI 系统组合多个 Web 来源，回答任何单一页面都无法提供完整答案的问题。这个产品目前尚未正式发布，也没有足够技术细节证明它已经具备类似数据库 Query Planner 的能力，但方向很明确：搜索系统正在尝试把开放 Web 从“网页集合”变成一个可以被机器查询的数据集。

搜索由此可能从find documents继续走向query the Web。

如果这条路线成立，Agent Search 的终局可能并不是一个“更聪明的 Google API”，而更像某种SQL for the open Web：Agent 不再关心哪一个网页排在第一，而是提出自己真正想解决的问题，底层系统负责从不同来源找到实体、组合事实并保留证据链。

这可能也是 Agent 给搜索带来的最大变化：网页仍然存在，但“网页”未必还是机器获取知识时最重要的组织单位。

但给 Agent 重建互联网没那么容易

不过把 Web 变成 Agent 随时可以查询的外部数据库并没有听起来那么简单。

第一个问题是谁来为这个“数据库”提供数据。Google 搜索时代存在一套持续二十多年的交换关系：网站允许 Googlebot 抓取内容，Google 再把用户和点击流量送回网站。Agent 却可能读取十个网站后直接综合答案，甚至继续替用户执行下一步操作，用户从头到尾都不需要打开原网页。内容生产者提供了知识，却可能拿不到访问量、订阅转化和广告收入。

这种矛盾已经进入产品层。Cloudflare Pay Per Crawl 允许网站所有者选择免费开放给 AI Crawler、完全阻止，或者要求抓取方付费。其背后的问题非常直接：AI 公司需要持续读取 Web，Publisher 却需要重新建立内容被机器消费后的价值交换。

这给 Keenable、Exa 这类独立 Web Index 带来一个悖论：Agent Search 越成功，网站越可能失去流量；网站越积极限制 AI Crawler，重新建立和维护 Web Index 又会变得越贵。

第二个问题来自安全。传统 SEO 主要影响用户“看到什么”，Agent Search 的结果则可能进一步影响机器“相信什么、做什么”。如果恶意网页通过搜索进入 Agent 上下文，再利用间接 Prompt Injection 影响一个拥有 GitHub、邮箱、企业系统甚至支付权限的 Agent，一次检索错误的后果就不只是推荐了一个垃圾网站。

因此，Agent Search 最终要处理的指标可能还得继续增加：除了 relevance、freshness 和 latency，还包括provenance、trust 和 security。搜索引擎过去负责给用户提供信息入口，未来的 Agent Search 某种程度上还承担着 Agent 对现实世界的“感知层”。

到了中国，这件事还有另一层特殊难度：中文互联网本身就不是一张完全开放的 Web。

目前国内已经有博查、心流这样的 Agent Search API，腾讯、阿里也在开放联网搜索能力，但从公开资料来看，还很难找到一家国内创业公司像 Keenable、Exa 一样，把“独立 Crawl 整个 Web + 建立 100B 级自主 Index”明确作为最核心的技术和商业壁垒，并持续披露 Index、QPS 和 Latency 等基础设施指标。

这背后的问题并不只有成本。大量有价值的中文实时信息存在于微信、小红书、抖音、知乎、电商平台以及各种 App 内，它们并不天然属于一个能够被统一 Crawl 的 Open Web。即使一家公司的公开网页索引足够大，也不意味着它真正看见了中文互联网。

腾讯云联网搜索的产品设计已经体现出这种差异：除了全网公开资源，它还会融合腾讯新闻、搜狗百科、企鹅号等自有内容生态。

因此，100B Index 并不等于看见中国互联网。

美国 Agent Search 更多在竞争谁能更完整、更低成本地重新索引 Open Web，中国市场还多了一层问题：谁能连接更多封闭和半封闭的内容生态。平台授权、版权、反爬机制以及内容平台之间的商业关系，都可能成为搜索算法之外的壁垒。

一个拥有上千亿网页索引的中文 Agent，仍可能不知道某个话题刚刚在微信公众号刷屏，也可能看不到一款新产品正在小红书快速爆发。对中文 Agent 来说，Index 的大小不代表真正的搜索能力，它究竟能看到多少真实的中文互联网可能更重要。

小 结

Keenable 押注的其实是一笔很明确的生意：当 Agent 越来越频繁地访问 Web，会有人愿意为更快、更便宜、更适合机器消费的搜索基础设施付费。为此，它愿意承担重新 Crawl、Index 和维护整个 Web 的高昂成本，再通过低延迟、高并发的 Search API 把这套能力卖给 AI Labs 和 Agent 开发者。

但这套生意最终能不能成立，现在还远没有答案。独立 Web Index 本身成本极高，Exa 等竞争对手已经跑在前面，Google、微软以及国内大厂也掌握着现成的搜索和内容资源；与此同时，网站对 AI Crawler 的限制还在增加。Keenable 能否把技术上的低成本、低延迟真正转化成足够大的客户需求和商业壁垒，还需要时间验证。Agent 能不能真的养出一门独立于传统搜索的新基础设施生意，值得我们长期观察。