在检索成本和失败开始失控前，先用一个控制平面为生产级 AI 代理路由、缓存并治理 Web 搜索。

1. 随着代理替代人在研究工作流里发起搜索，搜索量会按数量级上升，临时拼凑的检索逻辑很快就会被压垮。
2. 传统搜索封装层已经不够用了，这给一层决定代理查询如何执行的策略和路由层腾出了空间。
3. 采用已经从试验阶段跨进真实部署，买家现在要的是可靠性和治理，而不是一个能演示的 API。
4. Exa 这一轮融资的体量和估值说明，检索已经按核心基础设施来融资，这会让创业公司更愿意为周边工具单独买单。

催化因素。 Exa 正在成为默认搜索基础设施，采用量已超过 40 万开发者，而且市场已经明确预期：代理的搜索量会比人类高出 1,000 倍。问题已经从“代理能不能搜索”切到“生产规模下怎么治理搜索”。

产品作为 API 代理和控制台，夹在代理框架与检索供应商之间。它会预测查询意图和业务价值，再选出一条既满足时效性和置信度目标、又最省钱的路径：缓存证据包、快速头部搜索、深度长尾搜索，或浏览器执行。每次结果都会被标准化成一张来源图谱，里面有来源元数据、时效校验和可回放日志，方便团队排查错误答案，也能回应企业客户对引用的要求。客户还可以配置白名单域名、地域限制、预算上限和工作流 SLA，并看到每次代理动作的成本和失效模式。

差异化。 Exa 已经证明，面向代理的搜索需求确实存在；但这家公司赢的方式，不是再做一个重索引的一体化产品，而是做供应商无关、策略优先的控制层。它的防守力来自跨客户工作流积累下来的查询路由数据、来源策略配置和可回放日志——尤其是“什么时候不该搜、什么时候该复用旧证据”这些决策。一旦买家更看重毛利、来源可追溯性和企业控制能力，而不是单纯的搜索端点，它就会变得很黏。

待完成任务

flowchart LR
  Buyer[AI platform team] --> Pain[Uncontrolled search cost and weak provenance]
  Pain --> Product[Retrieval control plane]
  Product --> Outcome[Lower cost, cited answers, governed agent search]

高管要点

• 原生面向代理的检索已经明确变成基础设施：Exa 说代理的搜索量会比人类高出 1,000 倍，Tavily 也围绕同一判断完成融资，这说明这不是一个想象中的新功能，而是真实的工作负载迁移。[1][3]
• 真正的切口不是再做一个索引，而是把搜索深度、抽取、浏览器兜底、缓存和可追踪性编排起来。Exa、Tavily、Cloudflare 以及浏览器运行时厂商的公开文档都说明，买家今天已经在手工把这些原语拼到一起。[48][63][24][22][23]
• 预算已经存在，因为供应商本来就在按查询或按运行收费：Exa、Tavily、Google Agent Search、Browserbase 和 Browserless 都公开了和用量挂钩的价格，这让搜索可靠性天然变成一条运营成本线。[45][61][37][22][23]
• 真正空着的位置，是供应商无关的治理层。搜索 API 只会优化自己的表面，云平台只会优化自己的平台，浏览器运行时只会优化执行；它们都不会天然去优化什么时候不该搜、什么时候该复用证据，以及怎么让跨供应商策略保持一致。[47][39][28][77]
• 采用摩擦的核心不在 API 接入，而在企业控制。NIST、EU AI Act、Anthropic 的 computer-use 指南以及浏览器运行时安全文档都在强调：日志、监督、保留和提示词注入防护是入场门槛。[11][12][20][78]
• 这个品类会跟着代理采用一起增长，而且增速会快过传统企业搜索：Precedence 给出的 AI agents CAGR 是到 2035 年 43.57%，而 enterprise search 是 9.05%，说明真正系在实时外部检索上的那部分支出会长得更快。[10][9]

市场定义

面向生产级 AI 代理检索的供应商无关控制软件。这个品类位于搜索 API、Google 搜索 grounding 服务、缓存和浏览器运行时之上，用来决定一条查询该走快速搜索、深度搜索、抽取、缓存证据还是浏览器兜底，同时保留引用、时效策略和成本遥测。

用户与买方

核心使用者是运行重检索研究、销售情报或合规代理的 ML 基础设施工程师和代理平台工程师。真正拍板的通常是对毛利率、回答质量和企业信任负责的工程 VP、AI 平台负责人或平台 GM。

购买触发点

• 产品正式 GA 或一次企业级上线，会把外部搜索支出瞬间拉高，也暴露出直接调供应商接口缺少成本护栏。 [45][61][37]
• 过时或错误引用引发客户升级投诉后，买家会立刻发现，可回放能力和来源策略控制比“搜得更广”更急。 [15][16][51]
• 团队为了救回失败的搜索，会叠加浏览器执行或多供应商兜底；运维复杂度随之上升，也给路由控制平面留下了明确插入点。 [28][22][23]

支付意愿

公开定价已经在训练买家把检索当成按量计费的生产支出：Exa 按每 1,000 次搜索请求收 $7，Tavily 按 credit 收费，Google Agent Search 按每 1,000 次查询收费，浏览器运行时则按搜索、抓取、浏览器小时或单位计费。因此控制平面可以把 ROI 锚定在“少花了多少路由支出”和“少失败了多少任务”上，而不必去创造一个全新的预算类别。 [45][61][37][22][23]

品类动态

增长信号 43.57% CAGR

验证信号

• Exa 的融资和采用叙事说明，大型 AI 构建者已经把 Web 搜索当成核心基础设施。
• Tavily 的融资和 LangChain 集成说明，agent 开发者会主动选择专用搜索 API，而不是默认回到通用 Web 搜索。
• Exa、Google 和浏览器运行时的公开按查询定价，让“以成本优化为切口”变得足够具体。
• 越来越多的独立对比把供应商选择、延迟和响应结构当成 agent 团队的一等工程决策。

监管与技术约束

• EU AI Act 提高了高风险部署对文档、日志、可追溯性和人工监督的要求。
• NIST 用结构化风险管理来定义可信 AI 部署，这反而强化了“可审计检索策略”这件事的价值。
• Anthropic 明确提醒，能操纵浏览器的代理会遭遇提示词注入，因此需要域名限制、最小权限和高影响动作的人类确认。
• Google 文档写明 grounding with Google Search 每天有 100 万次查询上限，这凸显了上游供应商限制，也说明路由与兜底控制有必要。
• 如果工作流里包含浏览器兜底，企业买家一定会追问日志、录屏和存储产物的保留与安全控制。

竞争来自四个方向：Exa、Tavily 这样的原生面向代理搜索 API；Google 领头的云 grounding 和企业搜索栈；Browserbase、Browserless 这样掌握执行兜底的浏览器运行时；以及平台团队自己写的胶水代码。创业公司只有在自己成为跨供应商的策略与支出层时才有机会，而不是沦为某一栈里的一块点状能力。

为什么现有厂商不会默认胜出

• 搜索 API 厂商. Exa 和 Tavily 已经把搜索质量、抽取和研究深度做得很强，但它们本质上仍是单一供应商产品，默认不会替客户把多供应商路由、证据复用和中立的支出治理做到极致。
• 云平台. Google 把 grounding、enterprise search 和治理功能打包在一起，但它的经济和技术重心仍然是 Google 栈本身，而不是横跨多家检索供应商和浏览器兜底的中立控制平面。
• 浏览器运行时. Browserbase 和 Browserless 在带认证的兜底和抽取上很有吸引力，但它们卖的是执行原语，而不是查询分类、证据准入或供应商无关的搜索治理。
• 网关与可观测性厂商. Cloudflare 证明团队确实需要分析、兜底、自定义成本记账和密钥管理，但它的范围仍是模型网关基础设施，而不是跨搜索、缓存和浏览器动作的检索编排层。
• 自研方案. 工具调用框架和供应商 SDK 让自研编排成为可能，但这会把路由策略、失效处理和可审计性工作重新压回平台团队自己身上。

这家公司应该先做成一个供应商无关的检索控制平面，服务那些已经在真实 Web 数据上跑生产级代理、同时被搜索成本、回答质量和来源可追溯性卡住的原生 AI SaaS 团队。第一批客户应是 Series B-D 的原生 AI SaaS 公司：20-150 名工程师，至少有一个重检索的研究、销售情报或合规工作流，并且每月在 Exa、Tavily、Google 或浏览器兜底上合计花掉超过 $25,000 的外部搜索费用。首版产品应以 API 代理和策略层的形态压在这些供应商之上，决定什么时候走快速搜索、深度搜索、缓存证据或浏览器兜底，并把可回放引用和成本遥测一并返回。这个切口成立，是因为买家已经把检索看成按量计费的基础设施开支，所以试点可以围绕“每次成功代理任务能省多少钱”和“多快能排查过时或无引用答案”来卖。研究支撑了一个足够大的市场：估算 TAM 为 $0.9B、滩头 SAM 为 $180.0M；如果公司能拿下约 60 个客户、混合 ACV 约 $90k，第 3 年可触达的 SOM 大约是 $5.4M。刻意不做的，是再造一个搜索引擎、做一套泛企业搜索平台，或上来就做完整的自治浏览器栈。公司应先拿下一处控制点，让多供应商路由和治理的价值先超过“自己拥有索引”这件事。最主要的反证风险有两个：一是供应商把原生治理能力打包到足以压平这个切口，二是有足够路由查询支出的团队其实没那么多，不足以支撑一个独立预算科目。所以前 12 个月要盯住 3-5 家付费共创客户，证明覆盖工作流的检索支出至少能下降 25%，同时证明浏览器兜底只是少数例外，而不是吞掉毛利的默认路径。

问题

• 重检索代理产品一旦从试点走向生产，就会同时积累失控的搜索支出、过时或薄弱的引用，以及不一致的失效处理。
• 平台团队可以买搜索 API 和浏览器运行时，但它们依旧缺一层中立控制层，来跨供应商做路由、缓存、来源追溯、预算上限和来源策略执行。

解决方案

• 提供一个 API 代理和看板，给每条查询分类，再按时效性、置信度和成本策略，把它路由到缓存证据、快速搜索、深度搜索或受限的浏览器兜底。
• 把每一步检索都标准化成可回放的证据链，附带来源元数据、策略日志和单任务成本分析，方便团队排查错误答案，也能满足企业对引用的要求。

为什么我们会赢

• 这个产品比“再做一个搜索引擎”更聚焦，也比任何单一供应商栈都更中立，所以对已经同时管理多个检索供应商的买家来说，ROI 更容易讲清楚。
• 防守力会随着每个被覆盖工作流的路由表现数据、证据复用模式和嵌入式来源策略配置不断累积。
• 第一单可以绑在一个已经很痛的工作流和一张看得见的供应商账单上，比去推整套企业搜索替换要更快证明。

里程碑

flowchart LR
  Wedge[Retrieval-governance pilot] --> MVP[Provider-agnostic routing proxy]
  MVP --> Proof[Lower spend and replayable citations]
  Proof --> Expansion[More workflows and enterprise governance modules]

创始团队

实验路线图

风险评估

必须成立的条件

• 目标买家里，至少有相当一部分已经在外部检索上花到足以支撑一个独立控制平面预算科目。
• 轻代理层能在不牺牲回答接受率和时效性的前提下，把覆盖工作流的检索支出至少压低 25%。
• 买家足够看重可回放引用和策略控制，愿意选择一层中立平台，而不是继续深度绑定单一供应商。
• 首个切口里，浏览器兜底只占少数路由查询，因此毛利率还能维持在软件基础设施应有的区间。
• 供应商和框架的变化，不会逼出过多集成工作，导致业务最后变成服务外包。

待尽调问题

• 每月多少路由查询支出或多高的失败率，才足以让客户给一层专用控制平面批预算？
• 在前十个真实线索里，哪个 KPI 最能打动买家：节省支出、引用回放速度，还是错误答案更少？
• 在优化查询路由和缓存后，目标团队到底还有多高比例必须走浏览器兜底？
• 滩头客户最常见的是哪几种供应商组合，因此 MVP 应先集成哪些栈？
• Exa、Tavily、Google 和各类 gateway 厂商，已经在同一工作流里下放了哪些原生治理功能？

模型合理性

• 收入引擎. 基准情形的收入来自这样一条路径：Y1 有 4 个付费账户，到 Q4Y3 增长到 24 个，同时混合 ACV 从 $36K 的试点定价抬升到 $110K 的生产合同。
• 必须跑通的环节. 在 GTM 团队扩张前，创始人主导的试点必须先转成生产合同，因为销售周期敏感性是影响收入和跑道的最大单一变量。
• 模型失效条件. 如果买家不愿支持每年 $60K-$120K 的控制平面预算，或者浏览器兜底把毛利率长期压在约 68% 以下，downside 情形就会把现金打成负数。
• 下一轮融资证明点. 下一轮最强的融资故事是：Q2Y3 前做到 16 个付费客户、72% 毛利率和 3 个活跃生态伙伴，证明增长不再只靠创始人亲自带单。

情景

敏感性

flowchart LR
  QualifiedTeams[Qualified platform teams] --> PaidPilots[Paid pilots]
  PaidPilots --> ProductionAccounts[Production accounts]
  ProductionAccounts --> Revenue[Subscription and usage revenue]
  Revenue --> GrossProfit[Gross profit after provider and browser costs]
  GrossProfit --> Cash[Cash runway]

警示项: 模型到 Y3 末仍然 EBITDA 为负，因此它假设公司会凭高效率增长的证明再融一轮，而不是靠自身现金流滚动。 · 人均收入只摸到软件基准的低位，这意味着额外服务型工作或更快的支持团队扩张空间都不大。 · 毛利率假设浏览器兜底始终是少数路径；如果它高于 business-plan 里的风险阈值，融资需求就必须上调。

• 供应商打包下沉. 搜索供应商可能把自己的路由、缓存和可观测能力一起打包，压缩中间件层的空间。 缓解措施: 把重心放在多供应商治理、可回放能力和跨后端的来源策略控制上，而不是绑定某一家 API 的功能。
• 早期 ROI 不够硬. 如果团队的查询量还没到一定规模，它们未必会觉得有必要单独买一层检索控制平面。 缓解措施: 只打已经每月花 $25,000 以上做搜索的客户，把试点卖成一个能快速兑现硬节省和引用可靠性的项目。
• 代理技术栈变化太快. 框架频繁变动，会让深度嵌入式集成的维护成本很高。 缓解措施: 把集成点放在 API 代理和遥测层，这样模型、框架、搜索供应商换来换去，产品依旧有用。