API 工作流

面向开发者的 DeepSeek API 使用说明,覆盖 deepseek-chat、deepseek-reasoner、Thinking、Tool Calls 与 JSON 输出。

DeepSeek API 工作流

这部分主要面向开发者。
如果你只是日常对话体验,可以先看网页端与提示词。
如果你要接入业务系统,下面这些概念必须先搞清楚。

1. 先理解三个层次

网站与聊天入口

适合人工使用和快速试验。

API 文档

适合查看参数、返回结构、工具调用方式和示例代码。

API 地址

真正发请求的地址是 https://api.deepseek.com
文档中出现的 /v1 更多是兼容路径,不等于模型版本号。

2. 常见模型与模式

根据官方文档,当前开发者最常接触的是:

  • deepseek-chat
  • deepseek-reasoner

此外,部分能力可以通过 thinking 参数切换,而不只是靠模型名区分。

3. 最小调用示例

下面是一个 OpenAI 兼容方式的简化示例:

import OpenAI from 'openai';

const client = new OpenAI({
  apiKey: process.env.DEEPSEEK_API_KEY,
  baseURL: 'https://api.deepseek.com'
});

const response = await client.chat.completions.create({
  model: 'deepseek-chat',
  messages: [
    { role: 'system', content: '你是一个结构化输出助手。' },
    { role: 'user', content: '把这段内容总结成 5 个要点。' }
  ]
});

console.log(response.choices[0].message.content);

4. Thinking 模式要注意什么

Thinking 模式的重点不是“看起来更聪明”,而是:

  • 适合更复杂的推理任务
  • 可能会输出 reasoning_content
  • 多轮对话时要正确处理上下文
  • 与 Tool Calls 混用时要遵循官方要求

如果你做的是简单改写、FAQ、摘要等任务,不一定要默认开启。

5. Tool Calls 适合哪些场景

当任务需要调用外部能力时,例如:

  • 查询数据库
  • 调用搜索接口
  • 触发内部函数
  • 读取业务工具输出

这时候 Tool Calls 往往比纯文本回答更稳定。

6. JSON Output 什么时候该用

只要你的输出要被程序继续使用,就尽量别收自由文本。

典型场景:

  • 内容审核结果
  • 表单字段抽取
  • FAQ 结构化落库
  • 工作流节点之间的数据传递

7. 一个更稳的生产调用习惯

调用前

  • 定义任务目标
  • 明确模型与模式
  • 规定输出格式
  • 限制字段和长度

调用中

  • 打开日志
  • 记录失败原因
  • 标记截断或空响应

调用后

  • 做字段验证
  • 对关键任务加人工复核
  • 统计 token 成本与成功率

8. 推荐的接入顺序

  1. 先跑通 deepseek-chat
  2. 再引入 Thinking
  3. 再测试 Tool Calls
  4. 最后做结构化输出和重试策略

不要一开始就把所有能力混在一起,否则很难定位问题。