一句话定义
Search & Fetch（检索 + 抓取）是一对配套的检索原语（retrieval primitive）：search 只返回标题、链接、摘要这类候选清单，fetch 才按某个链接把正文取回来。两次独立调用，中间留出一次决策。DeepSeek 这类模型厂商把它做成对话接口里两个可调用的工具，具体形态和额度以官方页面为准。
像查目录，再让人去书架取书
老式检索像“我帮你查完，顺便把书复印好塞给你”：一个请求下去，十条结果连正文一起进上下文。二段式像图书馆：先给你一叠索引卡片（标题、位置、一句话简介），你圈出想要的三本，再让管理员跑一趟书架。前者省事，却常搬回一堆废纸；后者多一次往返，但几乎没有浪费。
为什么非要拆成两步
搜索命中十条，智能体真正会读的常常只有一两条。正文动辄几千 token，一股脑塞进上下文，既挤窗口，也稀释注意力。拆开之后，模型能在中间做判断：换个说法重搜一次、只挑两条权威来源、或者核对两个站点说法是否一致。
抓取这一步还可以单独把关：内容类型、robots、超时、反爬，出了问题只影响那一次 fetch，不至于污染整轮检索。反过来，如果搜索和抓取捆在一起，这些检查就只能全都前置到搜索阶段，非常别扭。
和相邻概念的区别
| 概念 | 返回什么 | 典型场景 |
|---|---|---|
| Search & Fetch | 候选列表或单页正文 | 开放互联网上的实时查证 |
| RAG 里的 retriever | 向量库中的文本块 | 企业内部知识库问答 |
| 爬虫或浏览器自动化 | 整站页面或多步交互后的结果 | 批量采集、填表下单 |
“按成功请求计费”改了什么账
关键不在单价，而在计价单位：只有真正取回内容的那次 fetch 才计数。于是智能体的成本曲线从“抓多少算多少”变成“读到手才算”。这鼓励两件事：一是失败后大胆重试或换源，因为失败通常不计入；二是成功请求要省着用，先拿便宜的 search 把候选筛到两三条，再 fetch。
反过来也有坑：如果 search 本身也计价，多轮改写查询就不是免费的，召回率和成本得一起权衡。写 agent 的人可以把这条明确解释给模型听：“先看摘要，再决定抓谁。”
实际意义
对从业者，这是一个显式的两段式状态机：候选生成、筛选、精读，每一步都可观测、可计费、可调参。对普通职场人，它解释了一个常被忽略的事实：AI 查资料做得准不准，往往不取决于“搜得多”，而取决于“读得省”。