API 工作流
面向开发者的 DeepSeek API 使用说明,覆盖 deepseek-chat、deepseek-reasoner、Thinking、Tool Calls 与 JSON 输出。
DeepSeek API 工作流
这部分主要面向开发者。
如果你只是日常对话体验,可以先看网页端与提示词。
如果你要接入业务系统,下面这些概念必须先搞清楚。
1. 先理解三个层次
网站与聊天入口
适合人工使用和快速试验。
API 文档
适合查看参数、返回结构、工具调用方式和示例代码。
API 地址
真正发请求的地址是 https://api.deepseek.com。
文档中出现的 /v1 更多是兼容路径,不等于模型版本号。
2. 常见模型与模式
根据官方文档,当前开发者最常接触的是:
deepseek-chatdeepseek-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. 推荐的接入顺序
- 先跑通
deepseek-chat - 再引入 Thinking
- 再测试 Tool Calls
- 最后做结构化输出和重试策略
不要一开始就把所有能力混在一起,否则很难定位问题。