企业官网建设流程全解析

简介：这份文档面向具备一定编程基础的开发者与研究人员，系统讲解DeepSeek API从注册到流式输出的完整调用流程，帮助读者快速将DeepSeek的语言理解与生成能力集成到聊天机器人、客服系统、智能助理等文本交互项目中。资源包内含1个docx文件，大小约13KB，以图文与代码片段结合的方式组织内容，便于边看边练。文档覆盖账号注册与API Key获取、Python 3.8以上环境准备与OpenAI SDK安装、基于OpenAI SDK和原生HTTP请求两种调用示例、请求与响应数据的解析及错误处理、temperature等生成参数调整，以及stream流式输出与多轮对话上下文维护等进阶用法，并附有密钥保护与速率限制等注意事项。目前已有3160人学习下载，适合希望迅速熟悉DeepSeek API特性、并以此为复杂项目打基础的开发者参考。

1. DeepSeek API 调用环境搭建：从注册到跑通第一条请求

上周帮一个做智能客服的团队排查问题，他们的服务上线三天，调用量一上来就频繁报 429，日志里全是限流错误。翻代码一看，API Key 硬编码在客户端，每次请求都新建连接，流式输出也没开，用户等十几秒才看到完整回复。这套环境本身不复杂，但装不好、配不对，后面全是坑。

DeepSeek API 兼容 OpenAI 的接口格式，意味着你现有的 OpenAI SDK 代码几乎不用大改就能迁移过来。但兼容不等于完全一致，模型名称、流式响应的字段结构、错误码的处理方式都有差异。这篇文章面向的是需要把 DeepSeek 接入自己项目的开发者，不管你是第一次调 API 的新手，还是从其他平台迁移过来的熟手，下面这套流程都是我实际跑过、踩过坑之后整理出来的。环境先列清，再一步步装，最后能验证跑通，照着走就行。

2. 环境准备与 SDK 安装：Python 版本和依赖怎么选

2.1 Python 版本与虚拟环境

DeepSeek API 的调用本身不限制语言，但官方示例和社区生态以 Python 为主。我一般要求 Python 3.8 以上，实际推荐 3.10 或 3.11，原因是这两个版本对异步请求和类型提示的支持更完整，后面如果要上 asyncio 并发调用，不用再折腾兼容性。

虚拟环境这一步别省。我见过太多人直接往系统 Python 里 pip install，结果和系统包管理器打架，最后连 pip 本身都跑不起来。用 venv 隔离是最省事的做法：

# 创建虚拟环境，指定 Python 3.11 python3.11 -m venv deepseek-env # 激活虚拟环境（Linux/macOS） source deepseek-env/bin/activate # 激活虚拟环境（Windows） deepseek-env\Scripts\activate # 确认当前 Python 路径指向虚拟环境 which python

激活之后，命令行提示符前面会出现(deepseek-env)标识。which python的输出应该指向deepseek-env/bin/python，如果还指向系统路径，说明激活没生效，检查一下 shell 类型和激活命令是否匹配。

提示：Windows 下如果用 PowerShell 激活报执行策略错误，先运行Set-ExecutionPolicy -Scope CurrentUser RemoteSigned，再重新激活。

2.2 安装 OpenAI SDK 与 requests

DeepSeek API 兼容 OpenAI 的接口规范，所以直接用 OpenAI 的 Python SDK 就能调。同时我也建议装上 requests，方便在 SDK 出问题时用原生 HTTP 请求做对照排查。

# 安装 OpenAI SDK，指定 1.x 以上版本 pip install "openai>=1.0.0" # 安装 requests 用于 HTTP 直连调试 pip install requests # 查看已安装版本，确认没有装成 0.x 的老版本 pip show openai

这里有个版本坑要特别注意：OpenAI SDK 在 1.0.0 版本做了一次大重构，openai.ChatCompletion.create()这种写法在 1.x 里已经废弃，改成了client.chat.completions.create()。网上大量教程还是 0.x 的写法，你照着抄会直接报AttributeError。pip show openai的输出里 Version 字段必须是 1.x，如果是 0.x，先pip uninstall openai再重新装。

2.3 获取并配置 API Key

API Key 在 DeepSeek 开放平台的「API Keys」页面创建。创建时注意两点：一是 Key 只在创建时完整显示一次，关掉页面就看不到了，必须当场保存；二是不要重复创建，每个账号能创建的 Key 数量有限，用同一个 Key 就行，需要轮换时再新建。

保存 Key 的方式，我强烈建议用环境变量，不要写死在代码里：

# Linux/macOS：写入当前用户的 shell 配置 echo 'export DEEPSEEK_API_KEY="sk-你的实际Key"' >> ~/.bashrc source ~/.bashrc # 验证环境变量已生效 echo $DEEPSEEK_API_KEY

Windows 下用setx DEEPSEEK_API_KEY "sk-你的实际Key"，然后重开一个终端窗口生效。环境变量的好处是代码里只引用变量名，Key 不会进版本库，也不会在日志里被打印出来。如果团队协作，把 Key 放在 CI/CD 的 secrets 里，本地开发各用各的。

3. 编写调用程序：SDK 方式和 HTTP 直连方式

3.1 用 OpenAI SDK 发起第一条请求

环境准备好之后，先跑通一条最简单的请求，确认 Key 和网络都没问题。新建一个test_deepseek.py：

import os from openai import OpenAI # 从环境变量读取 API Key，避免硬编码 client = OpenAI( api_key=os.environ.get("DEEPSEEK_API_KEY"), base_url="https://api.deepseek.com/v1" # 指向 DeepSeek 的接口地址 ) # 发起对话请求 response = client.chat.completions.create( model="deepseek-chat", # 模型名称，对话场景用这个 messages=[ {"role": "user", "content": "你好，请用一句话介绍你自己。"} ] ) # 打印模型返回的文本内容 print(response.choices[0].message.content)

这段代码里三个参数最关键。base_url必须显式指向https://api.deepseek.com/v1，不设的话 SDK 默认打到 OpenAI 的地址，会直接报 401。model指定deepseek-chat，这是对话模型的标识，不要写成gpt-3.5-turbo之类的名字。messages是一个列表，每个元素包含role和content，role可以是user、assistant或system。

运行python test_deepseek.py，如果终端输出了一句中文回复，说明环境通了。如果报AuthenticationError，检查环境变量是否生效；如果报ConnectionError，检查网络能否访问api.deepseek.com。

3.2 用 HTTP 请求直连排查问题

SDK 封装了一层，出问题时不容易定位是网络、认证还是参数的问题。我习惯同时准备一个 HTTP 直连的版本，用 requests 发原始请求，方便看完整的响应头和状态码：

import os import requests url = "https://api.deepseek.com/v1/chat/completions" headers = { "Authorization": f"Bearer {os.environ.get('DEEPSEEK_API_KEY')}", "Content-Type": "application/json" } data = { "model": "deepseek-chat", "messages": [ {"role": "user", "content": "你好，请用一句话介绍你自己。"} ] } # 发送 POST 请求，打印状态码便于排查 response = requests.post(url, headers=headers, json=data) print(f"状态码: {response.status_code}") # 解析 JSON 响应 result = response.json() print(result["choices"][0]["message"]["content"])

HTTP 直连的好处是你能看到response.status_code和response.headers，429 限流、503 服务不可用这些错误码一目了然。Authorization头的格式是Bearer加 Key，中间有一个空格，少写空格会报 401。Content-Type必须是application/json，否则服务端解析不了请求体。

3.3 请求参数怎么调

基础请求跑通之后，根据业务场景调整生成参数。这些参数直接影响输出质量和成本：

我一般会先把 temperature 设成 0.3 跑一批测试，看输出稳定性，再根据业务反馈微调。max_tokens 不要设成模型上限，按实际需要的最长回复来设，能省不少额度。

4. 流式输出与多轮对话：让响应体验和上下文都到位

4.1 开启流式输出

默认情况下，API 会等模型生成完整回复后一次性返回，用户等待时间长，体验差。流式输出让内容边生成边返回，前端可以逐字显示。开启方式是在请求里加stream=True：

import os from openai import OpenAI client = OpenAI( api_key=os.environ.get("DEEPSEEK_API_KEY"), base_url="https://api.deepseek.com/v1" ) # stream=True 开启流式输出 response = client.chat.completions.create( model="deepseek-chat", messages=[ {"role": "user", "content": "请介绍一下流式输出的原理。"} ], stream=True ) # 逐块读取响应内容 for chunk in response: # 检查 chunk 是否包含有效内容 if chunk.choices and chunk.choices[0].delta.content: content = chunk.choices[0].delta.content print(content, end="", flush=True) print() # 最后换行

流式响应的结构是每个 chunk 包含一个delta对象，delta.content是本次新增的文本片段。注意判断chunk.choices是否为空，最后一个 chunk 的choices可能是空列表。flush=True确保每次打印都立即输出，不加的话 Python 会缓冲输出，看起来还是一次性出来的。

注意：流式模式下错误处理要单独做。如果中途连接断开，已经输出的内容不会回滚，需要在应用层做重试或提示用户重新生成。

4.2 维护多轮对话上下文

API 本身不保存对话状态，每次请求都是独立的。要实现多轮对话，需要在客户端维护一个消息列表，每次把历史消息一起发过去：

import os from openai import OpenAI client = OpenAI( api_key=os.environ.get("DEEPSEEK_API_KEY"), base_url="https://api.deepseek.com/v1" ) # 用列表维护对话历史 messages = [ {"role": "system", "content": "你是一个简洁的技术助手。"} ] def chat(user_input): # 把用户输入追加到历史 messages.append({"role": "user", "content": user_input}) response = client.chat.completions.create( model="deepseek-chat", messages=messages ) # 把模型回复也追加到历史，供下一轮使用 reply = response.choices[0].message.content messages.append({"role": "assistant", "content": reply}) return reply # 连续对话测试 print(chat("Python 里怎么读文件？")) print(chat("那写文件呢？")) # 模型能理解"那"指的是什么

关键点是每次请求后要把模型的回复以assistant角色追加回messages，这样下一轮请求时模型能看到完整的对话历史。system消息放在列表开头，用来设定模型的角色和行为边界。

上下文越长，消耗的 token 越多，成本也越高。实际项目中需要做截断策略，比如只保留最近 N 轮对话，或者对历史消息做摘要压缩。我一般会设一个 token 上限，超过之后从最早的非 system 消息开始丢弃。

5. 避坑与排查：API 调用中最容易翻车的几个点

5.1 429 限流：不是 Key 坏了，是请求太猛

现象：服务运行一段时间后开始报 429，错误信息提示 rate limit exceeded。

原因：DeepSeek API 对请求频率和并发数有限制，短时间内大量请求会触发限流。常见于批量任务没有做节流，或者多个服务实例共用同一个 Key。

解决：在客户端加退避重试逻辑，遇到 429 时等待一段时间再重试，等待时间逐次递增。同时检查是否有不必要的重复请求，比如同一个问题被多个模块分别调用。如果业务量确实大，联系平台申请提高配额。

import time from openai import OpenAI, RateLimitError client = OpenAI( api_key=os.environ.get("DEEPSEEK_API_KEY"), base_url="https://api.deepseek.com/v1" ) def call_with_retry(messages, max_retries=3): for attempt in range(max_retries): try: return client.chat.completions.create( model="deepseek-chat", messages=messages ) except RateLimitError: # 指数退避：1秒、2秒、4秒 wait = 2 ** attempt print(f"触发限流，等待 {wait} 秒后重试") time.sleep(wait) raise Exception("重试次数用尽，仍然被限流")

5.2 401 认证失败：Key 没传对或者环境变量没生效

现象：请求返回 401，提示 authentication failed。

原因：三种可能——环境变量没生效、Key 复制时带了多余空格、Authorization 头格式写错。

解决：先在终端echo $DEEPSEEK_API_KEY确认变量有值。然后检查代码里读取的变量名是否一致，大小写敏感。HTTP 直连时确认Bearer和 Key 之间有一个空格。如果 Key 是从网页复制的，注意前后不要带换行符。

5.3 流式输出中断：网络抖动导致连接断开

现象：流式输出到一半突然停止，没有报错也没有后续内容。

原因：长连接被中间网络设备断开，或者服务端超时。流式请求持续时间较长时更容易出现。

解决：在客户端加超时设置和断线重连逻辑。对于关键业务，可以在流式输出结束后检查是否收到了完整的结束标志，没有的话触发一次非流式的重试。

# 设置较长的超时时间，避免流式请求被过早断开 client = OpenAI( api_key=os.environ.get("DEEPSEEK_API_KEY"), base_url="https://api.deepseek.com/v1", timeout=60.0 # 单位秒 )

5.4 模型名称写错：报 model not found

现象：请求返回错误，提示指定的模型不存在。

原因：model参数写成了其他平台的模型名，或者拼写错误。

解决：对话场景统一用deepseek-chat。不要写成deepseek、deepseek-v1之类的名字。如果平台后续更新了模型列表，以官方文档为准。

5.5 响应内容为空：max_tokens 设太小或者 stop 误触发

现象：请求成功返回 200，但content是空字符串。

原因：max_tokens设得太小，模型还没来得及输出有效内容就达到了上限；或者stop参数设置不当，第一个 token 就命中了停止条件。

解决：检查max_tokens是否至少设成了几十，stop序列是否过于宽泛。调试时先把这两个参数去掉，确认能正常输出后再逐步加上。

6. 装完怎么验证：三条命令确认环境真正跑通

环境装完不算完，得有一套验证流程确认每个环节都通了。我一般按三步走，从认证到流式再到多轮对话，逐层确认。

第一步，验证认证和基础请求。跑一个最简单的非流式请求，确认 Key 有效、网络可达、模型名称正确：

# 保存为 verify_step1.py 后运行 python verify_step1.py # 预期输出：一句中文回复，无报错

如果这一步就报错，问题一定在认证或网络层，先解决再往下走。

第二步，验证流式输出。把stream=True加上，观察内容是否逐字输出：

# 保存为 verify_step2.py 后运行 python verify_step2.py # 预期输出：文字逐字出现，最后有换行

如果内容一次性全部出现，说明flush=True没加或者终端不支持。如果中途卡住，检查超时设置。

第三步，验证多轮对话。连续发两轮请求，第二轮用代词指代第一轮的内容，看模型是否能正确理解：

# 保存为 verify_step3.py 后运行 python verify_step3.py # 预期输出：第二轮回复能正确理解第一轮的上下文

三步都通过之后，把验证脚本里的硬编码 Key 换成环境变量读取，确认环境变量方式也能正常工作。最后检查一遍代码里有没有把 Key 打印到日志的地方，有的话删掉。

我自己的习惯是，每次在新机器或者新容器里部署，这三步验证脚本必须跑一遍，不跑不放心。有一次偷懒跳过验证直接上服务，结果容器里环境变量没注入，线上跑了半小时全是 401，回滚才发现问题。从那以后我每次部署完都强制走一遍这三步，确认认证、流式、上下文都没问题才切流量。希望这套流程能帮你少走点弯路。

本文还有配套的精品资源，点击获取