先看结论：搜索和抓取不再是隐含成本
DeepSeek 在官方 API 文档中新增 Search 与 Fetch 两个独立接口：Search 用于网页搜索，Fetch 用于抓取网页内容。两项能力都按成功请求计费，每 1000 次分别收费 0.75 美元。对正在搭建 RAG、研究助手、浏览器 Agent 或代码 Agent 的团队来说，这不是简单多了两个工具，而是把“让模型访问外部信息”拆成了可单独核算、可单独限流的基础能力。
这次变化有三个直接影响。
第一，Search 和 Fetch 是独立 API，不应再把它们当作模型推理价格的一部分。一个 Agent 任务可能只产生几千 token，却触发多轮搜索、打开多个页面和重复抓取；如果只看输入输出 token 单价，预算会被低估。
第二，Search 和 Fetch 按“成功请求”计费，而不是按返回字数计费。当前官方价格都是每 1000 次成功请求 0.75 美元，折算为每次成功请求 0.00075 美元。这个单价看起来很低，但在多代理并行、重试、分页和定时刷新场景中，调用次数会比用户消息数增长得快。
第三，DeepSeek Harness、Claude Code 和 Codex 触发的服务端工具调用目前免费，但免费期有明确截止时间：按请求计费从北京时间 2026 年 11 月 1 日 00:00 开始。它不是所有第三方调用都免费的长期承诺，接入方应把这一天当作成本模型切换点。
Search 和 Fetch 分别解决什么问题
Search 解决的是“找到哪些网页”。它适合把自然语言问题转换为一组带有相关性、时效性和权威性要求的搜索结果，让后续 Agent 选择要继续阅读的页面。
Fetch 解决的是“读取选中的网页”。它适合在搜索结果之后获取页面正文，再交给模型进行摘要、对比、引用抽取或事实核验。把两者拆开后，产品可以对不同阶段采用不同策略：先限制搜索次数，再只抓取真正进入上下文的页面。
这对 RAG 系统尤其重要。传统实现常把搜索服务、网页解析器、清洗逻辑和模型调用封装在一个不可见的链路里，导致成本和失败点难以定位。独立接口让团队可以记录每次 Search、Fetch 的请求、成功状态、耗时、返回页面和最终是否被模型使用。
如何接入：先把工具调用做成可观测的步骤
DeepSeek API 继续兼容 OpenAI 和 Anthropic 的调用格式。官方文档的基础地址是 https://api.deepseek.com；模型调用仍使用 deepseek-flash，但本文讨论的 Search 与 Fetch 费用应单独记账，不要混入模型 token 费用。
一个稳妥的 Agent 工具链可以拆成四步：
- 确定是否需要外部信息。 对已有知识足够回答的问题，不要默认触发 Search。
- 限制 Search。 设置单轮最大搜索次数、最大并发数和重复查询合并规则。
- 筛选后再 Fetch。 不要抓取全部结果；先按域名、时间、内容类型和相关性筛选。
- 记录成功请求。 将 Search 与 Fetch 的成功次数写入调用日志，并关联用户任务、Agent 运行 ID 和最终答案。
下面是接入层应该具备的最小字段，而不是完整的官方请求示例：
run_id
user_task_id
tool = search | fetch
request_status = success | failed | timeout
query_or_url
started_at
latency_ms
used_in_final_context = true | false
这些字段能回答三个运营问题：哪些任务最耗搜索预算，哪些页面经常抓取失败，以及哪些请求成功了却没有进入最终上下文。没有这层记录，团队很难判断是搜索质量问题、提示词问题，还是工具调用策略过度积极。
价格怎么算：模型费用之外，再加一层工具费用
按当前官方价格，Search 和 Fetch 各为每 1000 次成功请求 0.75 美元。假设一个任务平均执行 4 次 Search 和 6 次 Fetch，每个任务的工具费用约为 0.0075 美元；如果每天运行 10 万个任务，且调用模式稳定，则工具费用约为 750 美元。这个估算不含模型 token、网络代理、缓存和其他服务费用。
更重要的是，平均值会掩盖长尾。研究型 Agent 可能为了确认一个事实连续搜索十几次；浏览器 Agent 可能因为页面结构变化反复 Fetch；多代理系统可能让多个子代理重复查询同一个问题。因此预算模型至少要区分：
- 普通问答和深度研究任务；
- 搜索结果缓存命中和真正的新请求；
- 首次抓取、刷新抓取和失败重试；
- 用户触发的主动查询和后台定时任务。
如果产品允许用户自定义 Agent，最好给 Search 和 Fetch 分别设置日配额，避免用户看到的是“模型很便宜”，而后台实际被工具调用拖高成本。
上线前的四项检查
先做计费回归。 在测试环境统计一个完整任务触发多少次 Search 和 Fetch，确认失败请求、超时重试和并发分支是否符合官方“成功请求”计费口径。
再做质量回归。 用一组固定问题评测结果时效性、来源权威性、重复率和页面正文完整度。不要只看搜索结果是否返回，还要看最终答案是否引用了正确页面。
验证免费期切换。 如果当前通过 DeepSeek Harness、Claude Code 或 Codex 使用服务端工具调用，应在 11 月 1 日前完成账单、配额和告警测试，避免免费期结束后出现预算失控。
保留替代路径。 对关键任务准备缓存、备用搜索服务或人工确认流程。Search 或 Fetch 暂时不可用时，产品应该能明确告诉用户“信息未完成核验”，而不是用过期上下文生成确定语气的答案。
总结：先把调用边界设计好，再谈 Agent 能力
DeepSeek Search 与 Fetch API 的价值，不只是提供一个更方便的联网入口，而是把 Agent 的外部信息访问拆成了可以观测、限额和计费的步骤。每千次 0.75 美元的价格降低了试用门槛，但不会替团队解决重复调用、失败重试、来源质量和数据合规问题。
对产品经理，最重要的决策是定义什么任务可以联网、允许调用几次、何时必须让用户确认。对开发者，优先工作是建立 Search/Fetch 的独立日志、缓存和预算告警。等这些边界稳定后，再扩大 Agent 的自主检索范围，才能知道新增能力带来的是真正的任务完成率，还是只是更多后台请求。
HiFox
