DeepSeek Search 和 Fetch 为实时网络访问标出 0.75 美元价格
DeepSeek 已开放其 Search 和 Fetch API，价格为每 1,000 次成功请求 0.75 美元，为 AI 智能体的实时网络访问定下了极低的价格。DeepSeek Search 和 Fetch 的发布将网络检索与模型推理分离，开发者可通过两个原始 JSON 端点搜索或提取页面内容。
这改变了研究智能体、编程助手和检索增强生成（RAG）的经济账。RAG 会在运行时向模型提供外部信息。搜索常被视为次要功能；但在生产环境的智能体中，重复搜索和页面抓取可能成为一项独立的基础设施开支。
这一极低的标价立即引起关注。不过，更重要的竞争并非 DeepSeek 与某一家搜索供应商之间的对比，而是低成本检索与可靠检索之间的较量。开发者仍需要证据证明，DeepSeek 能够返回相关来源、提取复杂页面、保护敏感查询，并支撑生产流量。
比较范围也延伸至集成式模型平台。OpenAI 对网络搜索调用及相关模型输入分别收费，而专业供应商则将搜索、提取或研究作为独立服务销售。DeepSeek 正押注于：简洁的接口和激进的请求定价，能够让网络访问成为智能体的常规基础能力。
DeepSeek Search 和 Fetch 将检索拆分为两项 API
DeepSeek 将两项常见的智能体操作——查找页面和读取页面——变成可独立计费的服务。
Search 和 Fetch 指南记录了公司现有 API 域名下的两个端点。Search 接受查询并返回结构化结果；Fetch 接受一个 URL，并以 Markdown 返回页面标题和内容。
Search 端点可返回 1 至 50 条结果。其响应包含标题、URL、摘要片段、更长的概述、可用时的发布日期，以及权威性评分。DeepSeek 表示，评分为 3 或 4 代表高度权威的来源，而负 1 表示权威性未知。
开发者还可要求在每条搜索结果中返回完整页面内容。need_content 选项可在搜索调用中实现这一点，不过检索失败时内容仍为空。对于同时需要发现来源和获取可读文本的智能体而言，这种设计可减少编排工作。
查询语法支持精确短语、排除条件、语言限制、日期边界和站点过滤。开发者无需构建独立的查询转换器，即可将结果限制在选定域名内或排除某个来源。原始用户问题也可随搜索短语一并提交，以帮助 DeepSeek 理解意图。
Fetch 执行的是更聚焦的任务。它检索一个 HTTP 或 HTTPS URL，并将可提取的内容转换为 Markdown——一种能保留标题和链接的纯文本格式。与未经处理的 HTML 文档相比，这种输出更容易传递给语言模型。
两项服务均使用 Bearer 身份验证和常规 JSON 请求，并不局限于专有的软件开发工具包。应用可以从函数工具、工作流引擎、命令行智能体或自定义后端调用它们。
这种拆分之所以重要，是因为搜索和提取会以不同方式失败。搜索可能返回不相关的结果，而 Fetch 则可能遇到受阻域名、不支持的格式，或没有可用内容的页面。将操作分开，开发者便可对任一阶段进行重试、替换或缓存。
DeepSeek 列出了针对无效输入、账户余额不足、安全拒绝、内容不可用、速率限制和下游超时的明确错误代码。它建议对超时、速率限制和服务器错误进行重试，但对于其他客户端错误，除非修改请求，否则不建议重试。
该服务为只读服务。它可以发现并检索内容，但不会点击按钮、提交表单或操作浏览器会话。对于交互式网站、需要身份验证的资源，或在用户操作后才渲染重要信息的应用，团队仍需浏览器自动化层。
Search 请求的账户级限制为每秒 100 次请求。Fetch 设有独立的每秒 25 次请求限制，并附加每域名限制。独立配额可防止提取工作的突发流量耗尽全部搜索容量。
这些细节使此次发布不止是一项模型功能。DeepSeek 正在提供可置于其模型旁边或更广泛智能体系统内部的检索基础设施。下一个问题是，计费规则将如何改变应用设计。
每 0.75 美元费率奖励成功检索
DeepSeek 按可用响应收费，而非按每次尝试收费，因此将部分检索失败风险转回给供应商。
Search 每 1,000 次成功请求收费 0.75 美元，Fetch 的费率相同。DeepSeek 将成功的 Search 请求定义为：返回包含非空结果数组的 HTTP 200 响应。Fetch 仅在返回页面内容时才产生计费。
失败调用、超时及没有结果的搜索均不收费。结果数量不会改变请求价格，因此请求 50 条结果与请求 1 条结果的搜索费用相同。模型处理和其他 API 使用仍是独立费用。
因此，一个执行一次搜索并抓取五个页面的工作流，会产生六次可能计费的检索调用。按公布费率计算，1,000 个此类工作流将产生 6,000 次成功调用，检索费用为 4.50 美元。Token 处理还会增加另一项成本。
这种区分避免了对标价的误读。广告中的数字并不意味着完整的研究任务只需 0.00075 美元。智能体可能会改写查询、检查多个来源、跟踪引用，并在生成答案前抓取多个页面。
深度研究工作流可能产生数十次调用。当来源相互矛盾，或初始查询缺少有用结果时，自主智能体也可能重复搜索。低廉的单位价格很重要，但最终账单仍由编排方式决定。
DeepSeek 的规则仍为开发者提供了一定程度的可预测性。搜索费用不随结果数量变化，未成功的检索也不会消耗付费额度。团队可依据成功的工具调用来估算成本，而无需再对额外的检索 Token 流进行建模。
此次发布也影响了 DeepSeek 的编程和智能体集成。其文档称，来自 DeepSeek Harness、Claude Code 和 Codex 的服务器端工具调用已在使用 Search 和 Fetch 服务。这些调用将在 2026 年 11 月 1 日北京时间午夜开始计费之前保持免费。
这一日期在运营层面非常重要。开发者可能并未直接发出端点请求，但智能体可以在解决任务时触发搜索。因此，使用情况仪表板和预算需要统计自主工具调用，而不仅仅是由人明确发起的操作。
DeepSeek 的 Responses API 指南展示了服务器端搜索如何参与模型响应。在该设置中，平台运行检索，将结果加入模型上下文，并继续生成。便利性也使搜索消耗更不易在较长的智能体会话中被察觉。
作为对比，当前的 OpenAI API 定价将网络搜索列为每 1,000 次调用 10 美元，搜索内容 Token 则按所选模型的费率计费。这些服务并不相同，因此数字差距并不能证明其价值等同。
集成式搜索可能包含排序、来源处理、引用、安全控制、区域功能或针对模型的优化。独立 API 则可能对检索循环暴露更多控制权。采购方需要比较完整任务，而不是定价页上的一行内容。
不过，DeepSeek 的方案确实对市场低端形成压力。尝试数千次调用的开发者，现在可以将托管检索视为一项很小的可变成本。这削弱了这样一种假设：每个智能体团队都必须运营自己的抓取和搜索栈才能控制成本。
这一变化也有利于模块化架构。Search 可以服务于一种模型，而 Fetch 可以向另一种模型提供内容。团队可以保留其模型选择，并将 DeepSeek 作为检索组件进行测试，不过账户条款和数据处理方式仍需审查。
低成本 AI 搜索向集成式和专业供应商施压
DeepSeek 正在检验：搜索应继续作为高价 AI 功能，还是成为低成本基础设施。
AI 应用会将网络检索用于几种不同任务。支持智能体检查最新文档；研究助手为某项主张寻找证据；编程智能体阅读其训练截止日期后出现的发布说明、问题跟踪器和库参考资料。
这些任务需要的不只是熟悉的搜索结果页面。应用需要机器可读的输出、稳定的响应字段、可预测的延迟，以及能够进入模型上下文的文本。它还需要一套不会惩罚合理重试行为的计费系统。
专业供应商通过索引覆盖范围、排序质量、提取成功率、时效性和工作流功能展开竞争。一些供应商提供整页文本、答案综合、域名过滤或研究端点；另一些则强调数据驻留与合同控制。
模型供应商则采取不同路径。它们可以将搜索嵌入响应中，并让模型决定何时使用。这降低了集成工作量，但可能使检索行为更难观察，或更难在平台之间迁移。
DeepSeek 结合了两种方法的部分特点。其原始端点类似专业基础设施，而其服务器端工具将检索连接至 DeepSeek 模型和兼容的智能体客户端。这为公司进入开发者技术栈提供了两条路径。
这一低费率对高频、低单次价值的任务最具吸引力。设想一个每小时检查供应商文档的内部监控系统：搜索质量必须达到可接受水平，但每个单独查询都不足以支撑昂贵的研究流程。
对于高风险工作，计算方式则会改变。法律、医疗、金融或安全工作流对可靠来源覆盖的重视程度，可能远高于请求价格。遗漏一份权威文件造成的成本，可能高于数千次搜索。
延迟同样重要。聊天助手不能在每个简短问题之后，都因缓慢的一连串搜索和抓取而暂停。研究任务或许能容忍更长时间，但仍需要在许多域名上成功完成提取。
在 Hacker News 讨论帖中讨论此次发布的开发者，强调了这种权衡的两面。一些人认为，托管检索比维护抓取器更简单且更可靠；另一些人则质疑覆盖范围、隐私、速率限制和提取质量。
这些评论属于轶事，而非基准测试结果。它们展示了买家正在提出的问题，但并不能证明某一家供应商表现更好。这项服务过于新颖，尚无广泛的生产证据能够为这一比较下定论。
自托管搜索仍是另一位竞争对手。开源元搜索系统可以聚合公共搜索引擎，而无需按请求向供应商付费。直接提取工具也能将许多普通页面转换为干净文本。
不过，“免费”自托管仍意味着服务器、代理、更新、可观测性，以及对封锁的应对。团队必须判断，这些运维工作是否值得用来避免托管服务费用。答案会随规模、人员配置和可靠性要求而变化。
DeepSeek 的定价削弱了维护这类基础设施的经济理由，但并未消除对控制权的考量。本地运行的系统可以让查询留在组织内部，并应用自定义排序或允许列表。
实际可行的应对方式是进行测量。团队应建立一套固定评估集，覆盖真实的领域和问题。随后可比较相关性、来源多样性、提取完整度、延迟，以及完成每项任务的总调用次数。
可搜索的内部技术资料集合可以补充实时检索。团队往往既需要最新的公开来源，也需要私有上下文。结构化的工程知识库可以让内部证据保持可用，而无需将每个问题都发送到公共网络。
这种组合架构还能减少不必要的搜索。智能体可以先查阅本地资料，识别缺失的信息，再将外部检索留给需要最新验证的信息。
DeepSeek Search API 质量仍是缺失的关键数据
定价已获验证，但评判搜索质量所需的证据仍不完整。
DeepSeek 表示，Search 运行在其自研搜索引擎上。其响应结构提供摘要、排序分数、权威级别和可选的页面内容。这些字段很有用，但响应结构无法证明底层结果是否相关或完整。
搜索质量会因语言、地域、主题和查询类型而异。某个引擎可能在中文技术来源上表现良好，却遗漏北美本地报道；它或许能稳定找到官方文档，却难以处理小众论坛或刚刚更新的页面。
抓取质量也有其自身的失效模式。现代网站可能需要 JavaScript、拒绝自动化客户端、将内容置于认证之后，或把重要信息放在文档中。DeepSeek 指出，抓取仍受网站可用性和访问政策限制。
成功的 HTTP 响应同样不保证能获得有用证据。提取出的 Markdown 可能遗漏表格、将导航内容误判为正文，或丢失图片说明与图片之间的关联。智能体随后可能基于不完整材料给出看似自信的回答。
“成功请求”的计费定义，比成功完成任务的标准更窄。只要搜索返回至少一个结果，即使该结果无关，也会被计费；只要抓取返回内容，即使内容缺少所需事实，也会被计费。
因此，团队应将语义成功与计费成功分开监测。有用的指标包括：是否出现正确来源、提取内容是否包含目标段落，以及最终答案是否引用了支持其主张的证据。
来源多样性是另一项测试。一个引擎如果反复返回同一篇报道的转载版本，可能制造出相互印证的假象。仅按 URL 去重无法识别联合供稿或改写后的材料。
开发者还需要审查权威评分。DeepSeek 定义了该量表，但其公开指南并未说明完整的评分方法。高分应当用于辅助排序，而不能替代对来源的独立判断。
政治和区域性内容值得谨慎测试。搜索引擎会在索引、排序、安全和法律合规方面作出选择。这些选择会影响语言模型开始推理之前智能体所能看到的内容。
隐私是另一项独立问题。查询可能泄露产品计划、安全问题、客户名称、收购目标或未发表研究。抓取 URL 也可能暴露组织正在调查哪些文档和系统。
在敏感部署之前，应结合 API 协议审查 DeepSeek 的公开隐私政策。Search 和 Fetch 指南说明了功能与计费方式，但未针对这些端点提供专门的零数据保留承诺。
采购审查应明确请求数据记录了什么、在哪里处理、保留多久，以及是否可用于服务改进。合同承诺比从低价中推断出的假设更重要。
安全团队还应审查间接提示注入。被抓取的页面可能包含旨在操纵智能体、索取机密或重定向其行为的文本。将页面转换为 Markdown 并不会使其中的指令变得可信。
应用需要将检索内容视为不可信数据。工具权限应与页面文本保持分离，智能体不应仅因指令出现在某个来源中就执行它。敏感操作需要在模型生成计划之外进行明确的策略检查。
缓存可以同时降低成本和暴露风险。在新鲜度要求允许复用的情况下，频繁请求的公开页面无需反复检索。缓存还提供了记录，说明先前回答究竟依据了哪些内容。
不过，缓存会引入版本问题。如果团队需要可复现的结果，就必须记录检索时间、来源 URL 和内容哈希。否则，后续抓取可能返回已变更的页面，无法再支持原先的主张。
DeepSeek 让成本变得易于理解，但并未消除让检索准确、安全且可审计所需的工程工作。
DeepSeek Search 和 Fetch 如何改变智能体设计
此次发布让检索成本低到可以更频繁使用，但优秀的智能体应更审慎地搜索，而非毫无节制地搜索。
强健的工作流始于判断是否确实需要实时信息。稳定的定义和内部流程可能已存在于可信知识库中；而最新价格、发布信息、政策和新闻通常需要外部验证。
随后，智能体可以将用户问题转换为一个小型搜索计划。一个查询应针对一手来源，另一个可寻找独立报道或批评意见。额外搜索应解决具体缺口，而不是重复宽泛措辞。
DeepSeek 的运算符支持这种模式。查询可以针对官方域名、设定发布时间范围或限制语言。这些控制使智能体能够带着证据目的搜索，而不是收集一大批缺乏重点的结果。
结果数量也带来了优化机会。由于公开的请求费率在返回 1 条和 50 条结果之间并无差异，系统可以请求足够多的候选项用于重排序。但仍应避免将所有返回内容都塞入模型上下文。
独立的排序阶段可以按相关性、权威性、时效性和多样性选择来源。随后，Fetch 应只抓取最可能影响答案的页面。这能减少提取调用，并限制进入模型的不可信文本。
工作流应在整个处理过程中保留引用。摘要固然方便，但最终答案需要提供支持每项重要主张的 URL 和段落。当证据相互冲突时，系统应报告分歧，而不是将其混合为一个缺乏支持的结论。
抓取失败需要有边界的重试机制。对于限流或超时请求，延迟后重试是合理的；但如果不改变请求，就反复重试安全拒绝或不支持内容错误，只会浪费时间并可能形成循环。
生产系统还需要在多个层面设置预算。会话限制可防止单个用户请求触发数百次搜索；账户每日限额可以控制意外流量；按域名设置控制则可减轻对单个网站的压力。
新的经济模式可能会鼓励过度检索，因为每次调用看起来几乎免费。这是个错误。更多搜索结果会增加延迟、重复证据、上下文大小，以及提示注入的机会。
智能体设计者应衡量每个被接受答案的成本，而不是每次 API 调用的成本。该指标包含检索、模型 token、重试、验证和人工审核，也反映答案是否真正解决了用户问题。
有用的评估集可以包含四类问题。时效性问题用于测试近期更新；已知项目问题用于测试引擎能否找到特定的权威页面；比较性问题用于测试来源多样性；困难页面用于测试提取行为。
每项测试都应记录预期来源的排名、提取完整度、延迟和付费请求数量。评估者可以对引用支持程度评分，并记录何时需要使用其他服务商或人工审核。
原始端点也让回退路由变得可行。应用可以先使用 DeepSeek 进行常规搜索，随后在覆盖范围或提取失败时使用其他来源。这能在保持较低平均成本的同时保护质量。
这种策略需要标准化。不同服务商返回的字段、分数、摘要和日期格式各不相同。统一的内部结构可以避免应用的其余部分依赖某一家供应商的响应格式。
因此，DeepSeek 的 API 易于测试，却不一定易于替换。开发者应将认证、错误处理和供应商特定的排序字段隔离在适配器中。这样，智能体可以请求“搜索”，而无需知道由哪项服务执行。
这种架构将价格竞争转化为买方优势。服务商必须通过可衡量的表现赢得流量，而团队在政策或质量发生变化时仍保有迁移工作负载的能力。
三个信号将决定低价是否重要
下一个考验是，DeepSeek 能否在不削弱质量或信任的前提下，将开发者的好奇心转化为持续的生产使用。
第一个信号是独立检索基准测试。有效测试必须覆盖多种语言、近期事件、技术文档、本地信息和对抗性页面。它们应公开查询集和评分方法，而不只是给出单一平均值。
如果 DeepSeek 能持续找到权威来源并提取完整内容，低费率就将获得战略意义。如果结果需要反复搜索或频繁切换至备用服务商，标题层面的优势将在任务层面缩小。
第二个信号是企业数据处理。买方需要明确了解查询保留、处理地点、训练用途、安全控制和合同删除机制。一个有文档说明的零保留选项，将强化 DeepSeek 在敏感工作负载中的地位。
沉默或模糊表述则会产生相反效果。许多组织愿意为可执行的控制措施支付更高费用，因为搜索词可能暴露机密意图。廉价检索无法弥补不可接受的数据路径。
第三个信号是竞争对手的反应。搜索专业服务商和模型平台可以降价、捆绑检索、提高免费额度，或强调更高质量的研究能力。它们还可以通过区域化处理、引用、浏览器执行或企业协议形成差异化。
如果出现广泛的降价回应，将证实 DeepSeek 已重新设定基础检索的预期；如果回应有限，则意味着竞争对手认为买方更看重质量、集成和治理，而非单次请求费用。
开发者还应关注 11 月 1 日开始计费后的使用情况。持续采用将表明用户看重的并不只是其最初的免费期；若使用量急剧下降，则说明早期关注是由好奇心而非生产需求推动的。
公布的价格让 DeepSeek 获得了一个有效切入点。Search 和 Fetch 简单到几个小时内即可完成测试，而且失败请求不会产生检索费用。这降低了开展真实评估的成本。
但这并不能决定采购选择。团队应比较具有代表性的任务，审查相关协议，并追踪从查询到带引文答案的完整路径。在将客户或公司数据经由该服务传输之前，还应测试各种失败情形。
DeepSeek Search 和 Fetch 提出了一个难以忽视的主张：实时网页访问不再必须是附加在模型上的昂贵高级功能。剩下的问题是，DeepSeek 能否以这一价格提供可靠、可治理的检索能力。
在当前供应商与 DeepSeek 之间运行同一套评估集。衡量相关来源、完整提取、延迟、计费调用次数和引文准确性。然后，在移除敏感查询后重复测试，直到数据条款满足你的要求。如果 DeepSeek 在完整任务而非孤立调用上胜出，其 $0.75 的价格就会变得重要。如果它只在价格表上占优，最便宜的搜索请求仍可能产出成本更高的答案。
