DeepSeek 搜索接口 11 月起按次收费，Agent 联网的账要重算了

DeepSeek 在 10 月 17 日上线了 Search 和 Fetch 两个接口，10 月 18 日公布价格：每 1000 次成功请求 5 元，海外站标价 0.75 美元/千次。11 月 1 日 00:00（北京时间）起正式计费。

真正值得注意的不是这个单价，而是收费的位置。公告里写得很清楚：目前通过 DeepSeek Harness、Claude Code、Codex 调用 DeepSeek API 时，服务端工具调用已经在打这两个接口，这部分现在不收费，11 月 1 日开始按次收。

也就是说，被计价的是模型自己决定"要不要上网查一下"的那个动作。

计费口径比价格更值得看

按官方文档，计费单位是"成功的请求"，不看 token，也不看一次返回几条结果：

• 只算 HTTP 200 且真的拿到结果——Search 必须返回非空的results，Fetch 必须拿到正文；
• • 请求失败、搜索无结果、超时，都不计费；
• • count参数只控制返回条数（1 到 50，默认 10），不影响单价。
    这个口径其实挺宽松：模型可以放心多试几轮，搜空了不花钱，只有真拿到东西的那一次才计费。对做 RAG 和 Agent 的人来说，试错成本被平台接走了一部分。

但有个容易漏算的地方：need_content默认是false，此时返回的content是空字符串。想要正文，要么把need_content打开，要么再调一次 Fetch。"搜一下再读页面"在账上是两个计费单位，不是一次。

和外面的搜索 API 比，位置在哪

据媒体对各家的定价整理，Tavily 按量付费大约 8 美元/千次，Brave Search 和 Google Custom Search 约 5 美元/千次，Exa 在 4 到 15 美元之间，以低价著称的 Serper 也要 1 美元左右。DeepSeek 的 0.75 美元大致是主流方案的十分之一上下。

换算成项目里能感知的数：一天 200 个任务、平均每个任务成功发出 3 次搜索或抓取，一个月约 18000 次，按 5 元/千次算就是 90 元左右。对中小项目来说不算压力。

问题不在总额，在于这部分消耗是模型自主触发的，平时不显形。以前它摊在 token 里，你只看到一个总数；现在它变成一个独立科目，账单上会多一行。

技术上的本质：把"检索"从推理里拆出来单独定价

大模型自己并不知道今天的文档长什么样。所谓"联网能力"，本质是模型在推理过程中发起一次外部检索，把结果塞回上下文，再基于新上下文继续生成。

过去这套动作被当成模型的隐式能力，成本混在推理费用里。现在检索被拆成独立接口、独立计量单位、独立限流——Search 账户级 100 QPS，Fetch 25 QPS，而且 Fetch 还有单域名的 QPS 限制。

这个思路和云上按请求计费是一回事：按可计数的动作收钱，而不是按结果值多少钱。好处是透明，坏处是"透明"意味着你得自己管。

变了的是联网从默认免费变成了有单价；没变的是模型仍然要靠检索结果吃饭，token 该花还是花。两笔钱现在分开了。

三件该在 11 月前做完的事

第一，把计费请求数单独记下来。任务数、请求数、结果条数是三个不同的量，混在一起估一定错。在工具封装层把任务 ID、工具类型、HTTP 状态、重试次数分开打点：

importos,time,requests BASE="https://api.deepseek.com"HEADERS={"Authorization":f"Bearer{os.environ['DEEPSEEK_API_KEY']}"}defsearch(query,count=5,need_content=False,retries=2):"""返回结果列表；空列表表示搜到但无结果（不计费）。"""foriinrange(retries+1):resp=requests.post(f"{BASE}/v1/tools/search",headers=HEADERS,json={"query":query,"count":count,"need_content":need_content},timeout=20,)ifresp.status_code==200:results=resp.json().get("results",[])returnresults# 非空 = 计费一次# 文档建议：408 / 429 / 5xx 等待后重试ifresp.status_codein(408,429)orresp.status_code>=500:time.sleep(1.5*(i+1))continue# 400/401/402/403/404 改请求再说，重试没意义resp.raise_for_status()return[]```**第二，别重复抓同一个页面。**Fetch 按 URL 抓取，返回 Markdown 正文。同一个文档在一个任务里被读两遍，就是两次计费。做一层按 URL 的短周期缓存，命中的直接走本地，这比任何优化都直接。**第三，接受"质量指标不公开"这件事。**官方没有公布索引规模、更新频率、反爬成功率这些指标。冷门英文资料、需要登录或反爬严格的站点表现如何，只能拿自己真实的 query 去测。别拿别人的测评当结论，你的 query 分布和别人不一样。**第四，选型上别只比单价。**便宜十倍的前提是"够用"。如果你的场景是查中文技术文档、查公开新闻、查 GitHub 上的仓库，这套接口的覆盖大概率够；如果是查付费数据库、查需要登录的后台、查很小众的行业资料，先跑一批真实 query 看召回率，再谈单价。单价上省下的那点钱，比不上一次答错带来的返工。## 顺带说一句限流Search100QPS、Fetch25QPS 是按账户算的，不看你用哪个 API Key，也不占模型的并发额度。Fetch 额外还有单域名限制，超了同样返回429。 这意味着并发抓同一批站点时，最先撞墙的不是你自己的机器，是对方的域名配额。批量抓取的任务，队列里最好按域名分桶，而不是一把梭。---联网能力从"选配"变成"标配"，价格也就从"包含"变成"单列"。5元一千次不贵，但从这个月开始，Agent 每查一次资料都会在账上留个印子。11月1日之后第一波真实账单出来，才是这套定价的第一次考试。你的项目一个月大概会跑多少次检索？评论区聊聊。