DeepSeek把搜索API的价格打到了每千次0.75美元。

Tavily基础档8美元，Exa即时检索4美元，Brave约5美元。0.75美元这个数字，比最便宜的竞品还低5倍多，比Tavily低了将近10倍。

我第一反应是：Agent的“查资料”能力终于便宜到可以随便用了。第二反应是打开GitHub，搜了一下DeepSeek Harness的搜索计费问题。

然后我看到了一条帖子：一个3轮对话的会话，产生了854次API请求，余额直接耗尽。

它到底便宜在哪

DeepSeek这次开放的是两个独立端点：Search和Fetch，各0.75美元/千次成功请求。

计价规则对开发者很友好：只有返回HTTP 200且结果非空才收费，失败、空搜、超时一概不计费。返回1条结果和返回50条结果，价格一样。

真正拉开差距的是 need_content 参数。传统RAG流程是“先搜索拿URL，再挨个抓取正文”，一次任务拆成好几次调用。Tavily基础版8美元、Exa即时检索4美元，抓正文往往还要加钱。DeepSeek的Search API加上 need_content: true ，搜索和正文提取压在一次调用里完成，还是0.75美元。

延迟数据也能看。社区实测直连Search API的耗时在630到877毫秒之间，常规页面Fetch在431到439毫秒，有开发者单次请求0.7秒内直接带回约11.9万字符。

按这个价格和速度，一个每天跑一万次搜索-抓取循环的Agent，DeepSeek的成本大约是7.5美元。同样的量给Tavily，账单是80美元起步。

便宜是真的便宜。但便宜不等于账单不会失控。

GitHub那条854次请求的帖子，把问题说清楚了

DeepSeek Harness的Discussion #6106记录了一个具体案例。

用户在一个已有会话里粘贴了3个GitHub仓库链接，说了一句“分析这三个”。主代理自己决定派发子代理，其中一个子代理又派生了两个，委派深度到了2。最终一个3轮对话的会话产生了854次计费请求，开放平台统计约800次，本地成本插件只显示了176次，差了4.85倍。余额在5分钟内耗尽，报错 Insufficient Balance 。

根因在 web_search 的实现方式：它的 queries 是一个数组，每一条查询都会单独发起一次完整的Messages请求。帖子里的实测放大倍率：44次工具调用对应171次计费请求（3.89倍），55次对应207次（3.76倍），52次对应146次（2.81倍）。198次搜索调用，叠加子代理后变成了668次计费请求。

0.75美元/千次的前提是“1000次请求”。当一次搜索动作在后台膨胀成三四次计费请求时，你的实际单价就是2.25到3美元/千次。 这个价格仍然比Tavily便宜，但“便宜6.7倍”那个数字已经不成立了。

帖子还指出了一个更隐蔽的问题：本地成本 assistant/message 统计和官方计费口径不一致。本地只统计的usage，完全不计 web/deepseek-search-llm-request 事件。你看着本地插件以为花了0.2美元，官方账单可能是1美元。

5 QPS和128字符，是给“单线程Agent”设计的

定价之外，两个硬限制决定了它适合什么、不适合什么。

每个账号下Search和Fetch各自5 QPS，独立计数。 对单线程、串行搜索的Agent，5 QPS绰绰有余。但你如果跑的是多Agent并行检索、或者一个主代理同时派发五六个子代理各自去搜，5 QPS的天花板会立刻撞上。Tavily和Exa的企业级套餐在并发上给得宽得多，这不是DeepSeek“小气”，是它当前的基础设施还没准备好承接高并发检索。

查询词上限128个Unicode字符。 Agent天生喜欢写长查询——“帮我找一下2026年10月DeepSeek搜索API在Agent场景下的定价和限制对比”。这种查询一写就超。超了直接报错，没有截断降级。你得在提示词里强制Agent生成紧凑查询，或者保留原始问题到 ori_question 字段让模型自己压缩。

还有一个实际体验层面的问题：服务器在中国。国内开发者延迟很低，但海外Agent调用时的网络延迟会成为额外开销。这不是定价问题，是物理距离。

和Tavily、Exa的差距，不只在价格上

价格差摆在那里，但检索质量是另一件事。

有早期用户测试后指出，DeepSeek与Exa的结果重叠率只有2.1%。这不是说DeepSeek差，是说两个搜索引擎的索引和排序逻辑完全不同。Exa有学术索引和语义检索的优势，DeepSeek的强项在中文内容和实时性。如果你的Agent做的是学术调研，Exa的溢价有它的道理；如果你做的是中文互联网的日常信息检索，DeepSeek的覆盖和价格都更合适。

信源覆盖上有一个明确的盲区：DeepSeek对YouTube和微信内容的发现能力偏弱。如果你的Agent需要从视频或公众号里提取信息，光靠DeepSeek Search不够，得补其他通道。

Tavily的8美元买到的不只是搜索，还有更成熟的Agent工具链集成、更宽的企业并发额度、以及“不用自己处理限流和报错”的省心。0.75美元买的是价格，8美元买的是一部分确定性。

接入其实很简单，但免费窗口只剩十来天

DeepSeek的搜索能力已经内置在DeepSeek Harness、Claude Code和Codex的服务端工具调用里。如果你在这三个工具里用DeepSeek API，搜索是自动生效的，不需要额外配置。

关键时间点：北京时间2026年11月1日0时起，这部分服务端搜索调用开始计费。 在此之前通过Harness、Claude Code、Codex触发的Search和Fetch免费。

如果你想把Search API单独接进Claude Code作为MCP工具用，社区已经有现成的包。一条命令：

“claude mcp add deepseek-websearch -s user -e DEEPSEEK_API_KEY=sk-你的key -- npx -y @frankzhang.ai/deepseek-websearch-mcp”

装完之后 webSearch 和 webFetch 两个工具就挂在Claude Code里了，支持 count （1-50）、freshness（按天/周/月/年过滤）、need_content （是否返回全文）等参数。

免费窗口期的用法建议很简单： 趁11月1日之前，在Harness或Claude Code里把搜索功能跑起来，观察你的Agent在一次典型任务里实际触发多少次搜索调用。这个数字比任何定价表都重要。如果一次任务触发20次搜索、每次背后膨胀成3次计费请求，你的真实成本是0.045美元/任务。一天跑100个任务，就是4.5美元。放在Tavily上是48美元。

它值得用，但别只看那个0.75

DeepSeek的搜索API定价确实击穿了行业地板，need_content 把检索和抓取压成一次调用，也是实打实的架构优势。

它最适合的场景是：单线程Agent的中文互联网信息检索。 日常查资料、做摘要、监控公开信息，0.75美元的价格让“让Agent自己去查”这件事变得几乎不需要犹豫。

需要谨慎的场景是：多Agent并行检索、长会话中Agent自主决定反复搜索、以及需要YouTube/微信信源的任务。 前两个会让计费请求数在后台放大，后一个会直接撞上覆盖盲区。

最实际的建议：在11月1日之前，用免费窗口跑一次完整的任务，然后去开放平台对一下账单。 不要看本地插件的数字，看官方计费统计。那个数字会告诉你，0.75美元对你来说到底是“便宜”，还是“便宜的开始”。