DeepSeek开放全家桶API：联网搜索价格不到OpenAI、Claude的8%

让大模型答个问题不算难。难的是让它上网搜索、读网页、解析 PDF，再把找到的东西整理成带引用的回答——这中间开发者通常得自己搭一整套工具系统。这部分工程负担，在 AI 应用开发里一直容易被忽视。

11 月 13 日，DeepSeek 宣布开放“全家桶应用 API”，想把这部分活接过去。官方称，开发者用上这些能力后，能做出和官方 App 基本一致的对话体验，完整的 DeepSeek App 甚至可以 1:1 复刻出来。

联网搜索和网页阅读怎么用？开发者在 API 请求里声明相应工具就行，模型会根据任务自己判断要不要调用，搜索、抓网页、处理上下文这些事都由 DeepSeek 服务端完成。文件输入则要先通过

知乎上，开源项目《GSYVideoPlayer》作者恋猫评价说：“产品化之后确实不一样了，DeepSeek 这都开始把自己的 App 能力拆出来了，从搜索到 OCR、再到语音，这个感觉怎么有种冲着百度来的即视感。”

价格上，官方说法是：调用 DeepSeek API 使用扩展能力，除了 Token 费用，还要另收工具调用费。具体价格如下：

知乎用户 药尘 Ray 算了一笔账：“我按官方价格表算了一下，写一篇带资料检索的文章，成本不到 4 毛钱。”他接着总结，“API 的钱已经便宜到可以忽略，贵的是三样东西：控制调用次数的工程、合规，以及你自己的判断。第三样最贵。”

也有在 DeepSeek App 里免费用语音聊天的用户泼了冷水，说文字转语音的效果“其实是有点拉的”，商用 API 要是同样的水准，“那这个价格就不值了，不如火山引擎接豆包”。

还有一位用户提到：“语音识别和语音合成的定价看起来有点让人摸不着头脑，但也不能算贵，大概就是给用户留个底，毕竟有些人自己搭语音识别、语音合成服务不太方便。文字识别这块算下来未必比百度划算，百度 2.5 元 / 千页是更贵些，可人家有 1000/2000 次免费额度。”

其实这条路上，DeepSeek 已经有不少先行者。

有人把三家的价格摆在一起比过：DeepSeek 联网搜索每千次 5 元，OpenAI 和 Anthropic 的同类工具每千次都是 10 美元。

过去的做法是，开发者先在请求里向模型声明有哪些工具可用。模型觉得需要查外部信息，就把工具名称和参数返回，应用程序照着参数去搜索、查数据库或者做别的操作，再把结果送回模型。工具选哪个由模型定，但工具怎么执行、什么时候重试、返回哪些数据，主要靠应用程序自己管。

任务一复杂，这套流程就变得麻烦。比如一个需要反复搜索的 Agent，一轮对话里可能调用好几次工具，每次都要传数据、整理结果、更新上下文。不同工具的参数格式不一样，调用会失败，模型还可能用错工具，这些都得开发者兜着。

这次 DeepSeek 把工具放到服务端，流程有一截就不一样了。

按官方开发文档的说法，开发者可以在现有 API 请求中声明`

开启

跟开发者自己组织搜索流程相比，新接口把搜索决策、工具执行和结果处理都放进了服务端。客户端不用再分别去请求搜索接口和抓取接口。

返回结果里依然带着工具调用记录、搜索结果和引用信息。开发者要做的是把这些内容正确显示在界面上，并在后续对话中按协议把相关内容块传回去，DeepSeek 提供的服务端搜索工具本身不需要自己执行。

需要联网问答、查新闻、找资料的应用，对这一变化感受会最直接。官方维护的搜索链路拿来就能用，开发者可以把更多精力放到业务功能和用户体验上。

文件处理走的是同一个思路。新版 API 支持把 PDF、Word、PowerPoint 和图片上传到 DeepSeek Files API，解析完返回文件 ID，再加进对话。识别方式可以选纯文本，也可以选

后一种能把文档里的图片、图表和示意图提取出来，按原来的位置跟文字一起交给模型。也就是说，开发者不用另外接 OCR 和基础的文档版面解析服务，就能让模型读一部分图文混排的复杂材料。

不过文件解析还是得走上传、引用两步。官方也把话说在前面：图文混排识别不保证把所有图表都提出来，解析出的图片照样要消耗模型的输入 Token。

DeepSeek 同时开放了独立的

往前看，DeepSeek 在 10 月 17 日就开放了自研搜索引擎的 Search 和 Fetch API。这次发布的主要增量，是把这些底层工具进一步整合进模型对话，让服务端接过一部分原本由应用负责的活。

为了把这套变化讲清楚，DeepSeek 同时在 GitHub 上把相关代码开源了出来，Demo 体验入口为 https://cdn.deepseek.com/chat-demo

示例代码入口：https://github.com/deepseek-ai/chat-demo

AI 应用从单纯的对话走向多步骤任务之后，模型厂商慢慢发现，光给一个文本生成接口，撑不起完整的产品体验。搜索、数据检索、代码执行、文件处理、工具调度，这些能力陆续被纳入 API 平台。

OpenAI 已经借助

不过，OpenAI 的文件搜索更偏向

Anthropic 同样在

在这种模式下，Claude 能直接完成搜索并读取网页，开发者不必自己搭一整套执行环境。Anthropic 还给出了搜索次数上限、域名过滤、结果引用等控制选项；较新的工具版本又加入了

Google 这边则通过

几家厂商的做法各有不同，但方向已经比较清楚：原先散落在应用框架、检索工具和第三方服务里的部分能力，正被收进模型厂商的 API 体系。

对开发者来说，门槛降了。过去要接好几个外部工具才能实现的功能，现在打开几个参数，基础版本可能就出来了。

对模型厂商来说，比拼的范围也跟着变大。开发者挑某个模型 API 时，看的不只是模型质量、推理速度和 Token 价格，还会看搜索结果、文档处理、工具执行稳不稳、开发方不方便，以及服务端能替自己扛多少活。

DeepSeek 这次还有一个设计值得留意：新功能同时支持 Messages、Responses 和

已经在用对应 API 协议的开发者，有机会沿用现有客户端或部分调用结构，迁移成本因此降低。但协议兼容不等于模型能力、参数和工具都能直接替换，具体还得看各家的实现。

目前 DeepSeek 明确支持这些应用层功能的，是 V4.1-Flash 模型。开发者如果想用它的托管搜索和文档处理能力，得先掂量对应模型是否合自己的业务需求。

工具编排挪到模型厂商服务端之后，一个问题跟着冒出来：开发者对模型执行过程的控制还能剩多少？

DeepSeek 的新接口就是个具体例子。官方文档显示，开发者一旦开启托管联网搜索或网页阅读工具，就不能通过`

另外，DeepSeek 眼下还没有开放托管搜索的

普通聊天应用用起来可能挺方便，可要是业务流程要求强制检索，这就意味着开发者没法再简单靠原来的工具选择参数来确保执行。

参数控制更值得留意。DeepSeek 文档写明，启用部分托管工具或安全功能后，某些请求参数由服务端说了算，开发者传了也会被忽略。对于靠固定配置做模型评测、重复跑任务，或者需要精确限制外部工具调用的应用，这是要提前考虑的变化。

在 Messages API 里，这些参数包括`temperature`、`top_p`、`

在 Responses API 里，包括`

在 Chat Completions API 里，则涉及`seed`、`temperature`和`top_p`等。

OpenAI 和 Anthropic 的部分托管工具则不同，能提供域名限制、调用次数之类的管控。两边一比，看得出模型服务平台在设计上各有取舍：封装得越全，开发者要操心的细节往往越少；可要是想自己定搜索策略、工具执行顺序和异常处理，编排层恐怕还得握在自己手里。

针对这种需求，DeepSeek 把 Search 和 Fetch 拆成独立接口开放，等于给了另一条路。开发者不走托管搜索，查询词、返回条数、网页抓取都能自己把控，结果怎么交给模型也由自己安排。

所以，做简单问答、原型开发或者标准化助手，服务端托管明显省事；产品要是看重数据来源、执行可审计性和复杂业务规则，自建工具链依然有它的用处。

参考链接：

https://mp.weixin.qq.com/s/78KBHc4-4N5b2vfL9SkutQ?scene=1

https://api-docs.deepseek.com/zh-cn/

https://developers.openai.com/api/docs/guides/tools-file-search

https://aistudio.google.com/docs/tools?hl=zh-CN

https://platform.claude.com/docs/en/agents-and-tools/tool-use/web-search-tool