任何对技术基础设施有敬畏心的开发者心里都有一个共识：做搜索引擎是一件极其困难的事。在 PC 互联网到移动互联网的漫长二十年里，全球真正拥有显著市场份额的通用搜索引擎，来来回回一只手就能数得过来（Google、Bing、Baidu、Yandex）。想要搞定全网高频抓取、防爬虫对抗、反垃圾网页以及秒级新鲜度，背后需要海量的硬件、带宽与工程沉没成本，这使得通用搜索一直是个极高门槛的巨头游戏。
但到了 2026 年中这几个月，一个看似反直觉的现象出现了：专注于 Agent 搜索的 Exa、Tavily 刷屏不说，连 AWS 都连续发布了 AgentCore Web Search 和 Bedrock Web Search。搜索接口一下子堆到了每个开发者的桌头上。
我和团队给 Agent 重构外部检索架构时，心里最先冒出来的疑惑就是：做搜索明明那么难，为什么到了 Agent 时代，突然间感觉好像任何公司都能跑出来做 Web Search API 了？难道在大模型时代，搞定全网搜索突然变便宜、变简单了吗？我们之前在讨论 多模型路由进入 Agent 会话 以及 Agent 上下文演进 时，也一直在关注底层检索成本的真实变迁。
把这几家 API 真正接进生产环境、拆开数据流看了一圈，我们才明白背后的真实逻辑：搞定全网搜索一点都没变简单，底层抓网页、搞防爬、做索引的重活依然极其硬核。真实发生的，其实是搜索需求的改变与供应链的拆分。
要理解为什么过去几乎没有人能挑战传统搜索，得看看旧搜索引擎那套垂直一体化的黑盒到底是怎么运转的。
传统搜索的极难之处，在于你必须同时做对三件事：看见足够多的全网网页、把最相关的排到人类面前、并且靠广告收回高昂基础设施成本。这构成了旧搜索看似不可战胜的商业飞轮：靠默认入口拿海量查询 → 把查询与点击转化为训练信号 → 用信号把长尾与突发查询的排序越调越准 → 靠精准排序支撑广告展示变现 → 再拿赚钱买断浏览器默认位、养庞大的抓取团队。在 美国诉 Google 反垄断案判决书 中披露的数据显示，Google 向浏览器、设备厂商等分发商支付的默认搜索位 revenue-share 在 2021 年合计超过 260 亿美元。
这背后真正起决定性作用的技术纽带，是他们内部叫 NavBoost 的系统，一个靠海量聚合查询与点击行为持续校准相关性的反馈机制，详见 DOJ 提交的 NavBoost 证词文档。
这套飞轮把全网抓取、算法排序与广告商业模式死死打包在一起。在过去，你不可能单独把抓取网页或相关性排序拿出来做成独立生意，因为单拆任何一步都无法收回基础设施成本。必须由同一家巨头把所有重活全包下来，直接输出给人看的网页列表并靠广告变现。
到了 Agent 时代，调用检索的主体从人类变成了大模型。模型既不看广告，也不去地址栏敲字，它不需要包含复杂的 HTML 样式和广告位的网页列表，它只要能直接塞进 Context Window 的干净正文、抽样片段以及权威 URL 引用。
交付契约从人看网页变成模型吞吐 Token，使得原本闷在搜索引擎肚子里大包干的抓取、召回、解析、压缩各个步骤被拆开了。这一拆分并非 LLM 单独驱动，也依赖公共 crawl（如 Common Crawl）、开源搜索基础设施、定向索引和云账单直接变现的同时成熟。
市面上并没有十几家公司在重新复制 Google，大家其实是在用不同的方式偷懒或借力，把搜索 stack 的某一层变便宜、可单独出售的：
第一种是透传大厂结果的代理层。以 Serper 为代表，它们工程实现非常轻量，根本不上网抓网页，也不建立任何索引。它们只是包装了一层 API 去透传 Google 的原始排序列表。最硬核的全网抓取、反垃圾和相关性排序，依然是 Google 以年度数十亿美元级基础设施和工程投入在替它们做。
第二种是缩小战场的定向语义索引。以 Exa 为代表，面对 Google 自报每天数十亿级垃圾网页（厂商自报数字）的对抗压力，Exa 选择优先抓取 GitHub、ArXiv、Wikipedia 和高质量技术博客等信息密度高的站点，把抓取和存储成本大幅降低。它在特定技术或学术领域搜得很准，但做不了全网生活通用搜索；其 index 规模属厂商自报、未经独立审计。真正建立在自建通用爬虫和物理索引之上的，市面上只有 Brave 这一类极少数玩家（详见 Brave 声明独立索引）。
第三种是上下文精炼与混合检索层。以 Tavily 为代表（参考 Tavily 服务条款），它的核心卖点不是凭空自建一套替代 Google 的全网搜索引擎，而是专注于针对 LLM 的 RAG 需求做网页降噪、正文抽取和文本压缩，专门输出高信息密度的片段。
第四种是云原生基础设施层。就是 AWS 在 2026 年推出的两个独立产品面——AgentCore Web Search Tool（6 月 GA，MCP 连接器）和 Amazon Bedrock Web Search（8 月 GA，模型 server-side tool），把检索能力直接挂进云端的模型 API 运行时里。
至于大家常用的 Perplexity，本质上是面向 C 端用户的端到端答案引擎，里面混了自研爬虫和第三方 crawling/indexing 服务，并不是开发者直接拿来拼装的基础设施中间件。
明白了 Search Stack 的分层，再看 AWS 在 2026 年先后推出 AgentCore Web Search Tool 和 Bedrock Web Search 这两个产品面，就能看懂它进场的深层逻辑了。
很多开发者可能会好奇：为什么是 Amazon？为什么偏偏选在 2026 年？
这背后并不是 AWS 突然决定去和 Google 抢 C 端搜索市场，而是两个因素重叠的结果：
第一是内部基础设施的二次商业化机会。在把搜索 API 卖给开发者之前，Amazon 内部为了支撑 Alexa+（新一代语音助手）、Amazon Quick（企业智能分析）和 Kiro（云开发环境），已经建立了庞大的 Amzn-SearchBot 网页抓取与检索基础设施。在过去，这只是一笔昂贵的内部支持成本；到了 2026 年，当外部企业在 Bedrock 上搭建 Agent 成为主流，AWS 敏锐地捕捉到了这个新的 B2B 变现机会——把内部现存的基础设施包装成云服务输出。理论上，外部开发者的 API 调用可以和内部工作负载一起分摊抓取与新鲜度维护的固定成本；但 AWS 未披露后端共用比例和单位经济，这属于战略推断而非已公开事实。
第二是搜索分发渠道发生了根本性的 B2B 转型。在传统的 C 端搜索时代，获客靠的是争夺浏览器默认位，Google 每年砸下数百亿美元买断 Safari 和 Android 地址栏；但在 Agent 时代，搜索变成了一个纯粹的 B2B 开发者产品，流量入口从手机/浏览器的地址栏，转移到了 Bedrock 或 SageMaker 上的模型 API 运行时。
这对云巨头来说是一个巨大的结构性机会。AWS 根本不需要去 C 端买断任何设备入口，因为它本身就掌握着企业级 Agent 的云端运行环境。开发者已经在 AWS 上管理 IAM 鉴权、结云账单、跑模型上下文，原生的 Web Search 自然就成了开箱即用、合规摩擦最小的默认选项。用”云端 B2B 基础设施分发”部分替代”C 端浏览器分发”，是云巨头捕捉搜索供应链重构红利的核心牌局。
把整个搜索供应链的重构梳理一遍，壁垒的迁移路径就看得更具体了。
那些被顺手绕过去的是传统 SERP 相关的商业与交互栈：SERP 页面排版、广告竞价系统、基于搜索框的流量分发，以及由系统厂商控制的默认搜索入口。
但那些依然横在眼前的工程硬骨头一点没少：全网高频抓取需要的带宽和 IP 资源、防爬虫对抗和版权许可谈判、网页新鲜度索引，还有防垃圾网站的权威度计算。这些物理世界的工程约束，大模型再聪明也没法替你省掉。
同时，新的护城河与数据闭环也开始显现。在分发这端，模型 SDK、MCP 协议标准和云厂商的模型 API 运行时，成了新的默认入口；在数据这端，校准排序质量的信号从人类的点击与停留，变成了 Agent 跑任务时的代码运行成功率、工具重试率和引用链接打开率。
对我们架构师来说，给 Agent 选联网方案时，千万别被大家都能做搜索的假象误导。纯透传 SERP 的包装层在面对自建索引厂商和云巨头时，长期来看存在确定性劣势；而深耕上下文精炼或者持有独立索引的数据源，会在特定 Agent 场景里保持独特价值。看清不同供应商在 Stack 里真实的位置，按自己系统对延迟、隐私、COGS 和证据深度的需求去组合采购，才是应对这场供应链解耦最踏实的方式。