DeepSeek给Agent接上实时网页

DeepSeek今天正式上线Search与Fetch API，把实时网页搜索和正文抓取能力直接放进了自家API体系。两项接口均由DeepSeek自研搜索引擎提供支持，面向Agent与RAG应用开放，开发者不再需要额外拼接搜索服务、网页解析器和内容清洗工具，就能完成从“找到网页”到“读取正文”的基本链路。

这次更新看起来只是增加了两个工具接口，实际补上的却是Agent落地过程中最常见的一块基础设施。大模型拥有的知识通常停留在训练数据或后续更新的时间点，而新闻、价格、产品文档、政策公告和软件版本每天都在变化；没有实时检索能力，模型再强，也只能依靠旧知识回答新问题。

**Search API是一个按查询词检索公开网页、并返回结构化搜索结果的接口。**它负责解决“哪些网页可能有答案”的问题。

**Fetch API是一个抓取指定网页，并将页面标题和正文转换为Markdown文本的接口。**它负责解决“网页里面具体写了什么”的问题。

两者组合后，Agent可以先搜索，再挑选高相关、高权威度的页面抓取全文，最后把这些材料交给模型阅读、交叉验证和生成答案。这是一条更完整的实时信息链路，而不只是给聊天模型加一个搜索框。

两个接口分别做什么

DeepSeek在官方文档中明确表示，Search与Fetch都是原始JSON API，Base URL为api.deepseek.com，沿用DeepSeek API现有的Bearer鉴权方式。对应端点分别是POST /v1/tools/search和POST /v1/tools/fetch。

两项接口的职责划分相当清楚：Search返回候选信息源，Fetch返回单个页面的可读正文。开发者既可以只使用Search提供的摘要，也可以在需要核查细节时继续调用Fetch。

| 项目 | Search API | Fetch API | |---|---|---| | 核心用途 | 按查询词搜索网页 | 抓取指定网页正文 | | Endpoint | POST /v1/tools/search | POST /v1/tools/fetch | | 输入 | 查询词、结果数量、是否需要全文等 | 单个HTTP或HTTPS网址 | | 输出 | 结构化结果数组 | 页面标题与Markdown正文 | | 单次结果范围 | 1至50条，默认10条 | 1个网页 | | 主要限制 | query不超过128个字符 | URL不超过8192个字符 | | 账号级速率 | 每秒5次 | 每秒5次，另有域名级限制 | | 计费方式 | 每千次成功请求5元 | 每千次成功请求5元 |

Search API的价值不只是“返回十个链接”。按照DeepSeek公开的响应结构，每条结果可以包含标题、URL、短摘要、面向模型生成的较长摘要、网页全文、站点名称、发布日期、重排序分数以及权威度评级。

其中，rerank_score用于表达结果与当前查询的相关程度，authority则用于辅助判断来源质量。对Agent来说，这两个字段比传统搜索结果中的展示顺序更容易利用：应用可以先按相关性筛选，再提高官方文档、权威媒体或一手信源的优先级，而不是把搜索引擎返回的前几条内容不加区分地塞进上下文。

Fetch API的输出则刻意保持简单，只返回页面标题和Markdown格式正文。Markdown比原始HTML更适合进入模型上下文，因为导航栏、脚本、样式和大量页面标签已经被剥离，标题、段落、列表与链接仍能保留基本结构。对于长文章、产品文档和公告页面，这能减少无关Token消耗，也降低模型把菜单或推荐内容误当成正文的概率。

每千次5元，失败和空结果不收费

DeepSeek为Search和Fetch采用按成功请求次数计费的模式，两项服务的价格都是每千次5元，折合每次成功请求0.005元。返回多少条搜索结果不影响单次价格，因此Search请求返回1条还是50条，接口费用相同，但返回全文后增加的模型上下文与推理成本仍需由应用自行控制。

| 费用项目 | 价格或规则 | |---|---:| | Search成功请求 | 5元/千次 | | Fetch成功请求 | 5元/千次 | | 单次成功请求折算 | 0.005元 | | Search空结果 | 不收费 | | Fetch未返回正文 | 不收费 | | 失败或超时请求 | 不收费 | | Search结果数量变化 | 不影响接口单价 |

这套计费规则对生产环境比较友好，因为只有真正获得内容的请求才进入账单。Search只有在返回非空结果列表时收费；Fetch则必须返回页面正文且HTTP状态码为200才收费。失败请求、空结果和超时均不收费，开发者不必为失效链接或搜索不到内容的查询承担接口费用。

成本也很容易估算。一个Agent每天执行1万次搜索，其中30%的任务再抓取两个网页，那么每天会产生1万次Search和6000次Fetch，共计1.6万次成功请求，对应费用约80元；按30天计算约2400元。这个数字不包含模型输入、输出Token费用，但已经足以让团队在产品设计阶段算清检索成本。

DeepSeek还为部分编码Agent提供了限时优惠。2026年11月1日之前，通过Claude Code的Web Search工具或Codex的web_search功能触发的搜索免收Search费用。优惠只明确覆盖Search请求，不能据此推断Fetch或模型推理同样免费。

5 QPS意味着它更适合Agent，而非通用搜索后端

Search与Fetch在每个账号下分别限制为每秒5次请求，也就是两套独立的5 QPS额度。Fetch还设置了按目标域名计算的额外限制，超过限制会返回HTTP 429。

这个速率设计透露出明确的产品定位：DeepSeek当前提供的是给Agent和RAG使用的工具能力，而不是让开发者拿它搭建高并发通用搜索引擎。5 QPS足以支持个人编码助手、企业知识助手、研究Agent和中小规模自动化任务，但如果一个消费级应用需要同时服务大量用户，就必须加入队列、缓存、请求合并和退避重试机制。

按理论上限计算，单个接口以5 QPS持续运行，一天最多可发出43.2万次请求；如果这些请求全部成功并计费，单个接口一天费用为2160元。不过真实应用通常不会全天跑满，而且Fetch的域名级限制会阻止系统持续高频抓取同一个网站。

域名级限流也是必要约束。网页抓取不是纯粹的数据库查询，目标站点有自己的容量、访问策略和内容版权要求。一个失控的Agent可能在几秒内反复访问同一页面，既浪费预算，也会给网站造成压力。合理的实现应当缓存抓取结果，并根据页面时效设置不同的过期时间：新闻页面可以按分钟更新，稳定的技术文档则可以缓存数小时甚至数天。

对RAG来说，变化在于知识不必提前入库

RAG是检索增强生成，即在模型回答之前先检索相关资料，再把资料作为上下文交给模型生成答案。传统RAG往往依赖一套预先建设的知识库，包括网页采集、文本切分、向量化、索引和定期更新；它适合企业内部文档，却不擅长处理刚刚发布的新闻或随时变化的公开网页。

Search与Fetch带来的是一种“即时RAG”能力。应用不必提前把整个互联网收入自己的向量库，而是可以在问题出现后临时搜索，在几十条候选结果中选择数个页面，再抓取正文完成回答。它更像按需查资料，而不是先建一座图书馆再等待用户提问。

这种模式尤其适合四类任务：

• 新闻与市场监控，需要发现数小时内出现的新信息；
• 技术支持，需要查询最新版产品文档、发布说明和兼容性变化；
• 研究型Agent，需要围绕一个问题连续检索、阅读和交叉验证；
• 事实核查，需要比较官方公告、媒体报道和原始材料之间的差异。

即时RAG并不会取代传统知识库。企业制度、合同、内部工单和私有代码仍然适合放进可控的内部索引；公开网页搜索则负责补充外部、实时和长尾信息。更合理的架构是混合检索：先查内部知识库，再根据问题类型决定是否访问公开网页，并在答案中区分内部依据与外部来源。

DeepSeek补齐的是一块关键产品短板

DeepSeek此前的优势主要集中在模型能力和价格，但开发者要构建能访问互联网的Agent，通常仍需接入第三方搜索服务，再自行处理网页正文。搜索、抓取、清洗、排序和模型调用分属不同系统，任何一环不稳定，最终答案都会受到影响。

Search与Fetch进入同一API体系后，工程复杂度明显下降。团队可以沿用同一套账号、鉴权和错误处理方式，搜索结果也已经包含面向模型的摘要、相关性分数与权威度信息，不必从零搭建每个组件。

| 方案 | 集成复杂度 | 实时性 | 数据控制 | 适用场景 | |---|---|---|---|---| | DeepSeek Search + Fetch | 较低，一套鉴权和接口体系 | 高 | 依赖官方搜索与抓取结果 | Agent、即时RAG、研究助手 | | 自建爬虫与搜索索引 | 高，需要采集、解析、索引和运维 | 取决于更新频率 | 最高 | 大规模垂直搜索、强定制业务 | | 传统向量知识库 | 中等，需要预处理和持续更新 | 较低至中等 | 较高 | 企业内部文档、稳定知识 | | 仅依赖模型参数知识 | 最低 | 低 | 低 | 不要求时效性的通用问答 |

不过，接口统一并不等于答案天然可靠。搜索引擎能找到网页，却不能保证网页本身正确；Fetch能提取正文，也不能判断其中是否包含广告、过时信息或恶意提示。Agent仍需要来源去重、时间判断、权威度筛选和多源验证，尤其不能让网页中的提示词直接改变系统指令或触发敏感操作。

DeepSeek返回的authority评级可以作为筛选信号，但不应成为唯一标准。一篇官方公告可能是最可靠的一手来源，也可能只陈述对发布方有利的信息；一篇媒体报道可能提供更多背景，却可能引用匿名信源。成熟的研究Agent应同时考虑来源身份、发布日期、原文引用和多个来源之间的一致性。

V4.1 Flash-1017短暂现身，但还不能算发布

在Search与Fetch上线的同一天，X平台机器人账号AI Tracker Bot曾在DeepSeek官方API列表中捕捉到deepseek-v4.1-flash-1017条目，但该条目随后很快消失。

deepseek-v4.1-flash-1017可能是一个按日期命名的模型快照，其中“1017”与DeepSeek此前V4-Flash-0731、V4-Pro-0813的命名方式相似。不过，截至10月17日，DeepSeek并未正式发布这一快照，公开的deepseek-flash仍指向V4.1 Flash，不能把短暂出现的API条目当成新模型已经上线的证据。

这一区别很重要。API列表中的临时名称可能来自灰度测试、配置预发布或内部验证，只有官方公告、稳定模型别名和公开文档同步更新后，开发者才适合把它写进生产配置。现阶段更值得关注的确定性更新，仍然是已经有正式文档、价格和限制说明的Search与Fetch API。

判断：入口统一很有用，真正考验在搜索质量

DeepSeek这次更新是一次实用性高于话题性的产品补全。每千次5元的定价足够直接，空结果和失败请求不收费也降低了试错成本；结构化摘要、重排序分数、权威度评级和可选全文，则让结果比普通链接列表更适合直接交给模型处理。

它的上限最终取决于搜索覆盖率、中文与英文网页排序质量、正文提取稳定性以及对新页面的收录速度。Agent工具接口并不难做出一个能运行的版本，难的是面对动态网页、反爬限制、重复转载和低质量内容时，仍能稳定返回正确、干净且时间相关的材料。

对开发者而言，现阶段最合适的用法不是把50条结果全部塞给模型，而是让Search承担召回与初步排序，只选少量高质量页面进入Fetch，再要求模型在多个来源之间核对事实。这样既能压低上下文成本，也能减少低质量网页对答案的干扰。

更大的信号是，DeepSeek正在从“提供模型”向“提供Agent基础能力”扩展。模型负责推理，Search负责发现信息，Fetch负责读取信息；当这些能力由同一家服务统一提供后，DeepSeek与开发者应用之间的关系就不再只是一次模型调用，而开始覆盖Agent执行任务的完整过程。

参考来源

• IT之家：DeepSeek上线网页搜索与抓取API等多项变动：汇总Search与Fetch API的功能、价格、速率限制，以及deepseek-v4.1-flash-1017条目短暂出现的情况。