给客服 Agent 加一个"能上网查资料"的能力，技术侧通常会陷入同一场争论：爬虫自己写、按量买搜索 API、还是直接挂一个 MCP 服务。三种方案在演示环境里都跑得通，真正拉开差距的是第一张账单和第一次供应商变更。长上下文能不能顶替外部检索，是另一个问题，见长上下文 vs RAG 的选型对比。
下面把"联网检索"拆到能逐项报价、逐项验收的粒度，再对着 2026 年能查证的公开事实，说清每种选择各自买到了什么、放弃了什么。
一、把"搜索"拆成四层，别当成一个整体
把搜索 API 当作一个整体去比价，等于把四件成本结构完全不同的活打包成一个价格标签：
- 候选发现：给定一个查询词，从海量页面里捞出几十上百个候选。这一层已经高度商品化，谁都能给你一堆 URL。
- 正文切片：把候选页变成模型能读的干净文本，并且保住标题层级和表格结构。它决定了答案里有没有那张价目表，还是只剩一堆被清洗掉的段落。
- 权威性排序：决定排在最前面的是官网原文，还是某个把原文洗了一遍的聚合站。它决定了 Agent 敢不敢引用。
- 时效与降级：高峰期是慢三秒还是直接报错；上游挂了之后，Agent 还能不能退化成"不带搜索的回答"。
自建方案最常见的误判是：把第 1 层做通就以为接近完工，真正的工期和预算几乎都压在第 2 到第 4 层——而那部分恰好是看不见的。第 2 层的分块与结构保留怎么取舍，见RAG 从 PoC 到生产的工程实录。
二、元宝搜索 2026 年 10 月对外开放，开放的具体是什么
腾讯云开发者社区在 2026 年 10 月 21 日发布的《元宝搜索，正式开放》，给了一份口径相当完整的现状描述：
- 索引规模为千亿级，日均调用量达数亿次，支撑 WorkBuddy、ima、腾讯金融科技、腾讯视频等 50 多个业务；
- 接入金融、医疗、法律、出行等 13 个垂直行业的 157 个权威信源，A 股、港股、美股、日股、韩股财报收录覆盖率达 99% 以上；
- 入库前由大模型解析网页并保留标题、表格结构，从站点、账号、页面三个层面评估质量，优先权威来源；
- 保持 94% 召回率的同时，底层索引检索平均耗时 8 毫秒，核心排序模型推理耗时由 149 毫秒降至 30 毫秒；
- 链路层为每个环节单独设定耗时上限，外部服务响应超时即自动降级；
- 接入方式有 Skill、MCP、API 三种，公告写明每月有 2000 次免费调用额度。接口以 JSON 返回搜索结果的排序信息与数据字段，可直接在业务场景里结合检索结果。
这份清单里最该被注意的是第三条。它描述的正是自建方案里最难估工期的部分：不是"抓到页面"，而是"判断这个页面的发布主体值不值得信"。三层打分背后是持续运营的规则库和人工校准，不是一个一次性爬虫项目能收工的活。
这里要划一条边界：以上数字全部来自厂商自述的转载文章，没有第三方复测。它能证明"官方声称做到了这个水平"，不能证明你的场景下一定拿到同样的召回率。
三、按量买：能公开查到的价格锚点不多
海外这一侧，Tavily 的定价页是少数把价格写在明面上的：免费档每月 1,000 API credits，按量付费每 credits 0.008 美元。
再往上一档，Project 按月计费 30 美元，含 4,000 API credits；Enterprise 档未公开标价，需要单独谈。以上是 2026 年 11 月 11 日抓取到的页面口径，价格随时可能调整，签合同前必须重新核。
但真正决定预算的不是单价。Tavily 的说明写得很清楚：credits 按请求类型消耗，搜索、正文抽取、站点爬取各不相同，越重、量越大的请求消耗越多。而 Agent 的请求形态天然偏重——腾讯那篇文章里有一句很实在的描述，Agent 的一次提问通常会拆成 3 到 5 个子问题，还可能调用 10 多个外部服务。用户眼里的"一次问答"，在检索侧可能是十几次计费请求。
所以每千次问答的检索成本必须用自有问题集实测：挑 20 条真实问题跑完整链路，记下消耗，再乘峰值并发。多轮串联场景的记账口径，可对照多轮 Agent 的成本实录。
四、自建真正贵的地方，不在索引
如果决定自建，下面六项必须写进预算和排期，缺一项都会在上线后以事故形式出现：
- 合规边界：抓取礼仪不等于抓取授权。RFC 9309 在定义 robots 规则时明确写了，这些规则不构成一种访问授权。遵守 robots.txt 只说明你遵从对方的爬取偏好，不说明你拿到了内容使用许可。
- 正文抽取与结构保留：列表页、PDF、动态渲染页、表格页各有各的坑，至少要能做到不把一张报价表压成一行字。
- 去重与权威判定：同一篇通稿会被几十个站点转载，不去重就会让 Agent 拿五份相同内容当"多方印证"。
- 失效页与增量：链接半年后失效、内容被悄悄改写，都会让引用变成事故。
- 多语种与垂直源：口语错别字、多语种混写、专有名词歧义，都会直接拉低召回。
- 降级与耗时预算：每个环节单独设耗时上限、超时自动跳过，这是"还能答"和"整条链路卡死"的分界线。
自建不是不能做，而是要承认你在做一个垂直搜索团队的活，而且这个团队要长期在线。
五、供应商结构在变，采购对象会跟着变
2026 年 2 月 10 日，Nebius 发布公告宣布收购 Tavily，把 agentic search 直接并入自己的 AI 云平台，理由是免去开发者东拼西凑多家厂商的麻烦；公告同时写明，Tavily 团队并入后继续以现有品牌运营、服务现有客户。
公告没有披露交易金额，坊间流传的数字口径互相矛盾，本文不引用任何金额——金额不重要，结构才重要：检索能力正从"独立的搜索 API 公司"被吸收进"推理云平台"，未来你谈判的对象大概率是一个云厂商销售，检索会像存储和 GPU 一样被捆绑报价。
两个动作：把检索调用收敛在自己的一层接口后面，换供应商时改适配层不改业务逻辑；从第一天起就保留第二家可切换的供应商，定期用同一套问题集做对照。
六、MCP 是接口层，不是第三种产品
把"接 MCP"当成第三条路，是把维度搞混了。MCP 官方文档的定义很朴素：它是一套开源标准，用来把 AI 应用连接到外部系统。它解决的是"工具怎么以统一形态暴露给不同客户端"，不解决"检索质量归谁负责"。工具层的权限、审计与网关细节，我们在MCP 协议接入内网里单独拆过。
顺序应该是：先决定谁做检索，再用 MCP 把"这个决定"变成可替换的形态。反过来先选 MCP 再找源，容易接进来一个召回质量配不上场景的服务，而换源时才发现业务代码里到处是它返回的字段名。MCP 在企业环境里的落地要点也值得放在同一张判断表里看。
七、三类场景，怎么落地
| 场景 | 特征 | 建议路径 | 验收重点 |
|---|---|---|---|
| 内部知识库为主，少量公网信息 | 并发低，要求可溯源 | 买一家搜索 API，先用免费额度验证召回 | 权威源覆盖；引用能否给出原文链接 |
| 客服问答，面向终端用户 | 并发高，重复度高，延迟敏感 | 买 API 或接厂商 MCP，必须做缓存与降级 | 每千次问答的真实成本；超时后的行为 |
| 深度研究型 Agent，多轮多源汇总 | 单次拆成多个子问题，调用链长 | 混合：检索层可采购，排序与引用治理自建 | 去重效果；来源是否可审计 |
八、上线前的五条验收项
- 召回：准备 50 条真实用户问题，人工标注"应该命中的页面"，统计前三条命中率。厂商宣称的 94% 不是你的召回。
- 时效：自己发一个测试页、改一个字，量出从发布到能被检索到的时间，别接受"分钟级"这类描述。
- 权威：故意构造一个洗稿域名，看它会不会被排进前几位。
- 成本：实测每次问答的消耗次数，乘峰值并发，再算上缓存命中率的折减，才是月预算。
- 降级：断掉检索服务或注入超时，确认 Agent 还有"不带搜索但能给出已知信息"的路径，而不是直接报错。
三条路径没有普适答案，但有两个几乎普适的约束：检索必须能被替换，成本必须能按请求类型拆开算。把这两点做进架构和预算表，剩下的"自建还是采购"就只是钱和排期的问题，而不是信仰问题。把检索接进整条链路时，AI 客服 Agent 的 5 步上线清单也值得一起看。