DeepSeek开放App全套能力API，联网搜索价格远低于OpenAI

作者｜褚杏娟

让一个大模型回答问题并不难，但要让它搜索互联网、阅读网页、解析 PDF，再将找到的信息组织成带有引用的回答，开发者往往需要额外搭建一套工具系统。这些工作构成了 AI 应用开发中一层容易被忽略的工程负担。

11 月 13 日，DeepSeek 宣布开放“全家桶应用 API”，试图减少这部分工作。它将官方 App 和网页端使用的联网搜索、深度思考搜索、文件输入、网页阅读等能力整合进现有 API，同时开放搜索、网页抓取、OCR、ASR 和 TTS 等独立接口。

DeepSeek 声称，开发者可以利用这些能力实现与官方 App 基本一致的对话体验，甚至 1:1 复刻出完整的 DeepSeek App。

对于联网搜索和网页阅读，开发者只需在 API 请求中声明相应工具，模型即可根据任务需要自主决定是否调用，搜索、网页抓取及相关上下文处理由 DeepSeek 服务端完成。文件输入则需要先通过 Files API 上传并解析，再将返回的文件 ID 加入对话；OCR、ASR、TTS 等能力则支持通过独立接口调用。

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

价格方面，官方表示，用户调用 DeepSeek API 使用扩展能力时，除收取 Token 费用外，也将收取相关工具的调用费用。具体价格如下：

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

用 DeepSeek App 里免费语音聊天的用户表示，文字转语音的效果“其实是有点拉的”，商用 API 如果是一样的效果，“那这个价格就不值了，不如火山引擎接豆包”。

还有用户认为，“语音识别、语音合成的价格感觉有点抽象，不过价格也不算贵，应该只是用来给用户兜底的，考虑到那些不方便部署自己语音识别和语音合成服务的人。文字识别这个好像综合下来不一定比百度便宜，百度的是 2.5 元 / 千页更贵，但有 1000/2000 次的免费额度。”

实际上，DeepSeek 这条路线已经有不少先行者。OpenAI、Anthropic 和 Google 都在通过各自的 API，将模型、搜索、文件处理和工具执行整合到一起。DeepSeek 此次补齐应用层能力，也让模型厂商之间的竞争延伸到开发者过去自行维护的工具链。

也有用户对比了三家价格：DeepSeek 的联网搜索每千次 5 元。作为对比，OpenAI 和 Anthropic 的同类工具每千次都是 10 美元。

从调模型到调完整应用，
开发者可以省掉什么？

传统模式下，开发者会在请求中向模型声明可用工具。模型认为需要查询外部信息时，返回工具名称及参数，应用程序根据这些参数执行搜索、数据库查询或其他操作，再把结果传回模型。模型能够选择工具，但工具如何执行、何时重试、返回什么数据，主要由应用程序负责。

随着任务复杂度提高，这套流程也会变得繁琐。例如，一个需要多次搜索的 Agent 可能在一轮对话中产生数次工具调用。每次调用都涉及数据传递、结果整理和上下文更新。开发者还需要处理不同工具之间的参数格式、调用失败以及模型误用工具等情况。

DeepSeek 此次提供的服务端工具改变了其中一部分流程。

根据官方开发文档，开发者可以在现有 API 请求中声明`deepseek_web_search`和`deepseek_read_url`两个工具。前者负责联网搜索，后者负责读取用户提供的链接。

开启非思考模式时，模型可以根据用户问题自动搜索网页或图片，并生成带有来源引用的回答。开启思考模式后，模型还可以在推理过程中多次搜索、打开网页和查找页面内容。DeepSeek 称，开启思考模式后，模型最多可以执行约 20 次工具调用，包括联网搜索、打开网页和页内查找，让模型能够在多步推理过程中持续检索和核对信息。

与开发者自行组织搜索流程相比，新接口将搜索决策、工具执行及结果处理整合到了服务端。客户端不再需要分别向搜索和抓取接口发起请求。

返回结果中仍保留工具调用记录、搜索结果和引用信息。开发者需要将这些内容正确展示在界面中，并在后续对话中按协议回传相关内容块，但无需自行执行 DeepSeek 提供的服务端搜索工具。

这一变化尤其适合需要联网问答、新闻检索和资料查询的应用。开发者可以直接使用官方维护的搜索链路，将更多精力放在业务功能和用户体验上。

文件处理也是类似的思路。新版 API 允许开发者将 PDF、Word、PowerPoint 和图片上传至 DeepSeek Files API，解析完成后返回文件 ID，再将其加入对话。开发者可以选择纯文本识别，也可以选择图文混排识别。

后者能够提取文档中的图片、图表和示意图，并按照原始位置与文字一起提供给模型。这意味着开发者无需另外整合 OCR 和基础文档版面解析服务，就可以让模型阅读一部分包含图文内容的复杂材料。

不过，文件解析仍然需要上传和引用两个步骤。官方也明确指出，图文混排识别无法保证提取所有图表，解析后的图片仍会消耗模型输入 Token。

DeepSeek 同时开放了独立的 Search、Fetch、OCR、ASR 及 TTS 接口。开发者既可以使用服务端自动编排，也可以将独立工具接入自己的工作流。

实际上，DeepSeek 早在 10 月 17 日就开放了自研搜索引擎的 Search 和 Fetch API。此次发布的主要增量是将这些底层工具进一步整合到模型对话中，让服务端承担一部分过去由应用负责的工作。

为了演示这种变化，DeepSeek 还在 GitHub 上开源了 chat-demo 项目。该项目提供流式对话、搜索、文件输入、语音交互、历史记录导入和多种消息渲染功能。开发者配置 API Key 后即可运行，静态版本甚至不需要独立的应用后端。

Demo 体验入口：https://cdn.deepseek.com/chat-demo

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

OpenAI、Anthropic 早已入场

随着 AI 应用从简单对话发展为多步骤任务，模型厂商逐渐意识到，仅提供文本生成接口不足以支撑完整的产品体验。搜索、数据检索、代码执行、文件处理和工具调度开始成为 API 平台的重要组成部分。

OpenAI 已经通过 Responses API 提供托管式联网搜索和文件搜索等工具。其中，文件搜索则可以让模型检索已上传文件。开发者创建向量存储并上传资料后，由 OpenAI 负责检索工具的执行，无需自行实现向量索引和语义搜索逻辑。

需要指出的是，OpenAI 的文件搜索偏向知识库 RAG，而 DeepSeek 此次开放的文件功能主要是上传解析后将文档内容加入模型上下文。两者覆盖部分相似的开发需求，但底层处理流程与适用场景并不完全相同。

Anthropic 也在 Claude Messages API 中提供服务端网页搜索与网页获取工具。

在这种模式下，Claude 可以直接执行搜索并读取网页，开发者无需自行搭建完整的执行环境。Anthropic 还提供搜索次数限制、域名过滤以及结果引用等控制项。其较新的工具版本进一步引入动态过滤，允许 Claude 在搜索结果或网页内容进入模型上下文前，使用代码筛选相关信息，以降低无关内容带来的 Token 消耗。

Google 则通过 Gemini API 提供 Google Search Grounding、URL Context 和 File Search 等工具。内置搜索与网页读取能够在一次模型 API 调用过程中完成，Google 负责运行工具并将结果交给模型。

这几家厂商的实现方式有所不同，但方向已经比较明确：原本分散在应用框架、检索工具和第三方服务中的部分能力，正在被整合进模型厂商提供的 API 体系。

对于开发者，这种变化降低了使用门槛。一个原本需要接入多个外部工具的功能，现在可能通过开启几个参数就能完成基础版本。

对模型厂商而言，竞争范围也随之扩大。开发者选择某个模型 API 时，不再只考虑模型质量、推理速度和 Token 价格，还包括搜索结果、文档处理、工具执行稳定性、开发便利性以及服务端能够承担多少工作。

DeepSeek 还有一项值得注意的设计：此次新增功能同时支持 Messages、Responses 和 Chat Completions 三种接口，其中包含 Anthropic 和 OpenAI 风格的协议。

这使得已经使用相应 API 协议的开发者有机会沿用现有客户端或部分调用结构，降低迁移成本。不过，协议兼容并不意味着所有模型能力、参数和工具都可以直接替换，具体仍取决于各家实现。

DeepSeek 目前明确支持这些应用层功能的是 V4.1-Flash 模型。开发者如果希望使用其托管搜索和文档处理能力，需要考虑对应模型是否满足自身业务需求。

少写了代码，
也交出了一部分控制权

工具编排转移到模型厂商服务端之后，随之出现一个问题：开发者还能在多大程度上控制模型的执行过程？

DeepSeek 的新接口提供了一个具体例子。根据官方文档，当开发者开启托管联网搜索或网页阅读工具时，不能通过`tool_choice`强制指定模型执行其中某个工具，否则将返回 400 错误。是否发起搜索、是否阅读链接，由模型自行判断。

此外，DeepSeek 目前尚未开放托管搜索的域名白名单、黑名单等控制参数。如果应用需要限定搜索来源，开发者仍需通过独立 Search、Fetch 接口或自建工具链实现。DeepSeek 还对部分 API 参数设置了限制，当开发者声明托管联网工具、开启高级安全校验或启用会话标题时，部分生成与工具控制参数将由服务端决定，即使开发者传入也不会生效。

这对于普通聊天应用可能比较方便，但对于需要强制检索的业务流程，意味着开发者不能简单地依靠原有工具选择参数来保证执行。

更值得注意的是参数控制。DeepSeek 文档显示，启用部分托管工具或安全功能后，某些请求参数将由服务端决定，即使开发者传入也会被忽略。这对于依赖固定配置进行模型评测、重复执行任务，或者需要精确限制外部工具调用的应用，是一个需要提前考虑的变化。

在 Messages API 中，这些参数包括`temperature`、`top_p`、`top_k`及部分思考控制参数；

在 Responses API 中，包括`max_tool_calls`、`parallel_tool_calls`等；

在 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