DeepSeek 悄悄上线了自己的联网搜索：几乎免费，但是个黑盒
2026-08-02 · 研究笔记 · 数据来自 2026-08-01/02 真实 API 实测
这两天 DeepSeek-V4-Flash 正式版屠榜，很多人盯着它的模型能力。但有个容易被忽略的更新其实对 Agent 开发者和重度查询用户更有价值：DeepSeek 在 Responses API 里上线了服务端联网搜索——零接入成本、几乎免费、质量在线。我花真金白银实测了一整天，把机制和成本讲透，顺便和之前一直在用的 MiMo 搜索做个对比，给你一份可落地的选型建议。
一、先说结论：这个搜索，普通用户几乎白嫖
如果你只是偶尔查个天气、搜个新闻、问一句”今天的行情怎么样”——这个搜索基本等于免费。
我实测下来的成本：
| 场景 | 一次搜索成本 |
|---|---|
| 冷启动（无缓存） | 约 0.4~1 分钱 |
| 缓存命中后 | 约 0.2~0.3 分钱 |
| 连续测十几次 | 总计约 4 分钱 |
我拿它搜”马斯克关注DeepSeek”那条新闻，一次花了 0.6 分钱。这个量级，比你自己接 Bing / Tavily 再拼 prompt 便宜得多，而且搜索 + 注入 + 回答一步完成，省了集成成本。
二、怎么用：三行代码
DeepSeek 的联网搜索只在 Responses API（/v1/responses）可用。注意：chat/completions 会 400 拒绝 web_search 工具，别走错路。
curl -X POST https://api.deepseek.com/v1/responses \
-H "Authorization: Bearer $DEEPSEEK_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "deepseek-v4-flash",
"input": "今天北京天气怎么样？",
"tools": [{"type": "web_search"}],
"stream": false
}'请求里加上 tools: [{"type": "web_search"}]，模型会根据 tool_choice（默认 auto）自主决定搜不搜、搜几次、开几个页面。
三、重点：搜索结果是个”黑盒”
这是最需要你理解的一点，也是它最大的短板。
DeepSeek 的服务端搜索，搜索结果是直接注入给模型的上下文的——模型「看到」了才能作答，但 API 不外吐搜索结果列表。
响应里 web_search_call 这个 item 只有 action 一个字段，两种形态：
形态1：search 动作 —— 只有搜索词，没有 URL/标题/摘要
{
"type": "web_search_call",
"action": {
"type": "search",
"queries": [
"北京 今天 天气 实时",
"Beijing weather today",
"ws_call_id=call_00_..."
]
}
}形态2：open_page 动作 —— 只有 URL（模型主动决定打开的页面）
{
"type": "web_search_call",
"action": {
"type": "open_page",
"url": "https://weather.com/.../beijing/today#ws_call_id=call_01_..."
}
}我实测确认的硬限制：
| 你想要的东西 | 能不能拿到 |
|---|---|
| 搜索结果标题 + 摘要 + 正文 | ❌ 拿不到，只注入给 LLM |
| 搜索出的 URL 列表 | ❌ search 动作只有 queries，无 url |
| 新闻标题 | ❌ 响应里根本没有 title 字段 |
| 引用来源 URL | ⚠️ 只有模型执行 open_page 时暴露，而且只给 url 不给 title |
用大白话说：这个搜索适合”问一句答一句”——你问它答，答得挺好。但如果你想去查验它引用的每一个来源、列出一份 Perplexity 式的引用清单——做不到，搜索结果对客户端是封闭的。
还有个流式坑：如果你用 stream: true，URL 只在 output_item.done 事件里出现，web_search_call.completed 事件里 action=null。前端如果提前渲染会看到”先没结果、后出结果”的闪变。另外搜索词和 URL 里都混着 ws_call_id= 追踪尾巴，记得剥掉。
四、跟 MiMo 搜索的区别：一个省钱省事，一个给来源
我一直有 MiMo（小米）那套搜索通道（¥16/1000 次调用，博查后端，中文覆盖好，带结构化来源 url/title/summary）。现在多了一条 DS 原生搜索，两条路各有各的适用场景：
| 维度 | DeepSeek 原生搜索 | MiMo 搜索 |
|---|---|---|
| 成本 | 极低（0.2~1 分/次） | ¥16/1000 次 = 1.6 分/次 |
| 接入 | 用 DS 自己的 API，零额外 Key | 用 MiMo API + 工具触发 |
| 来源引用 | ❌ 黑盒，拿不到 url/title | ✅ 带 url/title/summary 结构化引用 |
| 搜索质量 | ✅ 在线，会 open_page 读内容再答 | ✅ 博查后端，中文覆盖好 |
| 适合场景 | 简单查询、”问一句答一句” | 需要可查验来源的严肃检索 |
我的选型建议：
- 查个天气、问个新闻、随手一搜 → 用 DS 原生搜索，便宜同构不浪费
- 要做来源展示、要引用清单、要查证 → 用 MiMo（带引用）或直接 web_fetch 原文
- 国际新闻 / 英文内容 → 两条都别太依赖，直接 web_fetch 原文更靠谱（博查英文覆盖一般）
一句话总结：DS 原生搜索 = 便宜省事的”黑盒快搜”；MiMo 搜索 = 带来源的”可查验检索”。不是替代关系，是不同场景的两把刀。
五、给 Agent 开发者的一句话清单
如果你在做 Agent 要接搜索，先记住这几条，能少踩坑：
- 能接受来源不可见 → 直接用 DS 服务端搜索，集成成本为零，质量在线。
- 要做完整引用展示（像 Perplexity）→ 服务端搜索不够，自己接 Tavily/Serper 或对 open_page URL 抓
<title>。 - 别在
web_search_call.completed就急着渲染 → URL 在output_item.done才出现，前端保持”搜索中”扫描线等聚合完再一次性展示。 - 剥掉
ws_call_id=/#ws_call_id=尾巴 → 那是服务端追踪标识，不是数据。 - 想省 token → 在 instructions 里引导模型”搜索后最多打开 1 个最相关页面”；要展示来源就引导它开 2-4 个。
六、我的实测体验（顺手挖了个瓜）
拿这个免费搜索查”马斯克关注DeepSeek”那条新闻，它不仅答得完整，还帮我补全了背景：马斯克是 2026-08-01（DeepSeek-V4-Flash 正式版上线后一天）才关注的，而且他态度经历了明显转变——2025 年初 R1 爆红时他质疑”他们肯定有 5 万张 H100″，到 2026 年 7 月经济学人专访时已经软化，夸中国 AI 和电力优势。
这种”能开页面、读内容、再综合回答”的能力，确实是有实用价值的。它的短板从来不是”搜得不聪明”，而是”搜的结果不给你看”——明白这一点，你就能在合适的场景里把它用好。
注：本文数据来自对 https://api.deepseek.com/v1/responses 的真实调用（2026-08-01/02），官方定价见 DeepSeek API 文档。部分机制细节参考了知乎 @Rescenix 的实测文章及 Rescene 开源项目，在此致谢。