DeepSeek把App拆成了API，顺手开源了前端

2026年11月13日，DeepSeek宣布把DeepSeek App背后的能力开放到API。范围包括联网搜索、文件输入、URL读取、模型内容安全、语音输入和朗读。对开发者来说，变化不在模型多了一个参数，而在原本要自己拼接的搜索、解析、语音链路，现在可以走同一个服务。

官方给了两种用法。第一种在请求里开内置工具：deepseek_web_search负责搜索，deepseek_read_url负责读链接；safety_check开内容安全；title自动生成会话标题。第二种单独调OCR、ASR、TTS。聊天能力在Messages、Responses、Chat Completions三套协议里都能用，模型写的是deepseek-flash。

搜索和读链接由服务端执行。客户端只需要把返回的块展示出来，下一轮原样传回。响应里有thinking、搜索步骤、网页读取、带引用的文本。官方文档给了渲染位置示意图。

开源demo是这次比较实用的部分。它是静态前端，没有应用后端，浏览器直接连API。API key和设置放localStorage，对话和原始附件放IndexedDB。支持导入从DeepSeek Chat导出的历史，导入会替换本地已有对话和附件。Demo地址、源码、文档都在下面：

• 在线demo
• 源码
• 搭建文档

价格要单独看。官方回复里明确，扩展能力会在标准token费用之外产生工具使用费。定价图如下：

有网友整理称，搜索每1000次0.75美元，语音转文字更便宜且限时五折。这个说法来自用户总结，正式账单以官方价格页为准。评论区也有人问搜索和语音是在同一次调用里计费还是分开计费，TTS价格是否偏贵。官方这次没有在推文里逐项解释。

一个容易被忽略的细节：请求一旦声明deepseek_web_search、deepseek_read_url，或把safety_check设为high、开启title，服务会接管一部分参数，请求里的temperature、top_p等会被忽略。max_tokens仍然生效，但它限制的是每一轮推理步骤的输出，不是整轮总输出。接之前最好把这些行为写进产品预期。

有网友的判断是，把应用层能力直接做成API，省下的是搭建时间，算力不是重点。竞争点会从模型分数转向谁能更快做出能用的产品。这个判断有道理，但账单会变复杂：token费用、搜索工具费、语音费分开算，实际成本要看用量结构。对想快速做聊天产品的团队，这套东西降低了起步门槛；对已经自建搜索和语音链路的团队，值不值得换，要看工具费和省下的维护时间哪个更划算。