如何用 DeepSeek API 搭建可上线的网站客服聊天机器人

快速总结： 要用 DeepSeek API 搭建网站客服机器人，推荐做法是：在网页和 DeepSeek 的 /chat/completions 之间加一个轻量后端，把 API Key 放在服务器端；从 deepseek-chat 模型起步；由于接口本身无状态，每轮请求都要重发裁剪后的历史；回答内容要严格锚定在已审核的业务资料上；在正式上线前加入人工接管和应用级限流。思考模式（thinking mode）可以后续按需接入，而不是一开始就默认开启，除非你的客服流程确实需要长链路推理或大量工具调用。

最近校对时间： 2026 年 4 月 4 日（基于当前 DeepSeek API 文档和 openai-python README）。

很多“聊天机器人教程”覆盖面很广：一会儿讲网站，一会儿讲 WhatsApp、Slack、Teams，但很少真正帮团队把一个可靠的生产实现做扎实。这篇指南反其道而行，只聚焦一个高价值场景：网站客服机器人——回答重复的公开问题、严格遵守企业事实边界、在遇到风险或敏感请求时交给人工。这一场景与 DeepSeek 目前的 API 能力高度契合：接口与 OpenAI 兼容，主域名是 https://api.deepseek.com，核心工作集中在 POST /chat/completions。当前公开 API 中，deepseek-chat 和 deepseek-reasoner 都映射到 DeepSeek-V3.2，支持约 128K 上下文窗口。

为什么只聚焦“网站客服机器人”这一用例

把 DeepSeek 接入网站客服通常是最合适的第一步，因为它：

职责范围窄，边界清晰
成功与否容易度量（自助解答率、转人工率、满意度等）
主要回答价格、上手流程、集成方式、基础账单等公开问题
不需要一上来就扮演真人客服、修改用户数据或编排大量工具

这种“窄场景”比大多数团队想象的更重要。一个机器人什么时候值得信任？当它“被允许做什么”非常清楚时。如果它只负责回答公开支持问题，就可以用经过审核的业务内容做知识基座，并用真实网站流量做测试。如果它被定义成“什么都能帮你做的 AI 助手”，往往会变得昂贵、难监控，也更难建立信任。

一个合格 v1 聊天机器人该做什么，不该做什么

一个靠谱的 v1 至少要把这四件事做好：

稳定回答公开支持问题
在缺少事实时坦诚“不确定”或“无法回答”
遇到敏感或高风险请求时，明确交给人工
当上游模型或你自己的后端出问题时，能安全降级

它不应该在你的应用还没实现对应能力时，就尝试做账号级操作。也就是说：

不要自动批准退款
不要修改发票
不要取消订阅
不要处理隐私数据请求
不要说“我已经查看了你的账号”，除非背后真有鉴权和业务流程支撑

暂时不要自动化的内容： 账号变更、退款审批逻辑、发票修改、泛化“AI 代理人”行为、一次性塞入海量未整理知识库、多渠道扩张（在网站版本还不稳定之前）。

上代码前先做好的架构决策

后端应该负责：

持有 DeepSeek API Key
维护系统提示词（system prompt）
管理已审核的 FAQ / 政策片段
会话管理（session）
日志与观测（request id、错误记录等）
重试策略与降级策略

DeepSeek 的鉴权是标准的 Bearer Token，这也是绝不能在浏览器里暴露密钥的原因。

前端应该尽量“瘦”：

收集用户输入
渲染机器人回复
保存一个轻量的会话标识
在后端不可用时展示安全的兜底文案

浏览器不应该知道任何价格逻辑、审批逻辑，更不应该知道 DeepSeek 的密钥。

提前设计“记忆”策略

DeepSeek 的 /chat/completions 是无状态接口，服务端不会替你记住历史对话。因此你的应用必须在每次请求时，把“相关的历史”重新发给模型。后端需要自己维护一段滚动窗口式的对话历史，并在每轮请求中附带最近若干轮。

如果后续启用思考模式（thinking mode），要注意 DeepSeek 文档明确说明：之前返回的 reasoning_content 不应该被简单拼接进下一轮普通用户消息中。

约束式“知识锚定”

知识锚定要克制：

起步时只用一小段经过审核的上下文，而不是把整个帮助中心原封不动塞进每个请求
DeepSeek 的上下文缓存（Context Caching）默认开启，只有“重复的前缀”才会命中缓存
这意味着：稳定的系统提示词和稳定的政策前缀，既有利于一致性，也能降低成本

观测能力不是“以后再说”的功能

当前 openai-python SDK 已经提供：

可配置重试
可配置超时
请求 ID

这足以让你：

记录失败请求
关联用户投诉或故障工单
判断问题来自提示词、输入数据，还是上游服务不稳定

一个典型的架构可以抽象成：

浏览器聊天组件
   │
   ▼
POST /chat
   │
   ▼
后端服务
   ├── 会话状态
   ├── 已审核业务上下文
   ├── 守护规则与人工接管策略
   ├── 重试 / 日志 / 限流
   └── DeepSeek /chat/completions
           │
           ▼
       机器人回答或人工接管

DeepSeek API 基础要点（上线前务必核对）

基础 URL：
- 当前快速上手文档列出的基础地址为 https://api.deepseek.com
- https://api.deepseek.com/v1 仍然兼容，但 /v1 与模型版本无关
核心接口：
- 本文场景主要使用 POST /chat/completions
- 请求体必须包含 model 字段和 messages 数组（至少一条消息）
模型命名与模式：
- deepseek-chat 与 deepseek-reasoner 都对应 DeepSeek-V3.2，支持约 128K 上下文
- 区别在于模式：前者为“非思考模式”，后者为“思考模式”
- 当前文档给出的输出上限：
  - deepseek-chat：默认 4K，最大 8K tokens
  - deepseek-reasoner：默认 32K，最大 64K tokens
开启思考模式的两种方式：
- 直接使用 model="deepseek-reasoner"
- 或在请求中传入 thinking 参数
- 使用 OpenAI SDK 时，thinking 需要通过 extra_body 传递
- 文档还说明，在思考模式下，temperature、top_p、presence_penalty、frequency_penalty、logprobs、top_logprobs 等参数不支持或效果有限
结构化输出：
- DeepSeek 支持在 chat 接口上开启 JSON 输出
- 设置 response_format={"type":"json_object"}，并在提示词中明确要求返回 JSON
- max_tokens 要控制在合理范围，避免 JSON 被截断
- 如果需要“严格工具调用 schema”，需要：
  - 使用 base_url="https://api.deepseek.com/beta"
  - 在工具定义中设置 strict: true

模型选择建议

基于上述约束，大多数团队应优先选择 deepseek-chat 作为起点。这是基于产品和工程视角的建议，而非营销口径。

原因很直接：网站公开客服更看重“可预测、简洁、易运维”，而不是长链路推理。思考模式很有价值，但并不是一个窄场景客服 v1 的最佳默认选项。

最小可用请求示例

DeepSeek 的快速上手文档展示了 OpenAI 兼容的调用方式（自定义 base_url），而 openai-python README 推荐使用 from openai import OpenAI 的现代客户端写法，并通过 client.chat.completions.create(...) 调用。

DeepSeek 的参数说明中提到，默认 temperature 为 1.0。对于客服机器人，通常会把温度调低，以获得更稳定、少随机的回答风格。

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com",
)

completion = client.chat.completions.create(
    model="deepseek-chat",
    messages=[
        {"role": "system", "content": "You are a concise website support assistant."},
        {"role": "user", "content": "Do you offer annual billing?"}
    ],
    temperature=0.2,
    max_tokens=250,
)

print(completion.choices[0].message.content)

这段代码足以验证：鉴权是否成功、基础 URL 是否正确、模型是否可用、首个提示词是否生效。在这一层没跑通之前，不要急着加记忆、工具调用或多渠道接入。

生产级集成蓝图

在考虑多渠道、智能代理或工具调用之前，先把“后端形状”打磨好。一个可上线的 v1，其实只需要几块核心拼图：

一段短历史的会话窗口
一块经过审核的业务上下文
明确的人工接管规则
可预期的降级行为

系统提示词：先定“边界”，再谈“能力”

系统提示词（system prompt）最重要的决策是“范围”：

机器人被允许回答什么
必须拒绝什么
何时必须升级为人工处理

提示词要短而清晰。试图在提示词里塞进“整个公司”的信息，往往会让模型变得更贵、更乱、更不稳定。

一个典型后端路由的流程

一个合理的服务端路由通常按以下顺序工作：

接收用户消息
根据会话重建一小段上下文窗口（含系统提示词和业务片段）
调用 DeepSeek
根据返回结果决定：直接回复用户，还是改为人工接管提示

下面的示例代码刻意保持简洁，方便理解结构。在生产环境中，应把会话状态和限流逻辑迁移到 Redis 等共享存储中。

import os
import uuid
from fastapi import FastAPI
from pydantic import BaseModel
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com",
)

app = FastAPI()
sessions = {}

SYSTEM_PROMPT = """
You are the website support assistant.
Answer only public questions about pricing, onboarding, integrations, and billing basics.
If the request needs account access, refund approval, invoice changes, or privacy handling,
stop and hand off to a human agent.
"""

APPROVED_CONTEXT = """
- Annual billing is available.
- Supported integrations: Slack, HubSpot, Zapier, Google Drive.
- Refunds are reviewed by the support team.
- Human support: support@example.com
"""


class ChatIn(BaseModel):
    session_id: str | None = None
    message: str


@app.post("/chat")
def chat(payload: ChatIn):
    session_id = payload.session_id or str(uuid.uuid4())
    history = sessions.get(session_id, [])
    history.append({"role": "user", "content": payload.message})

    messages = [
        {
            "role": "system",
            "content": SYSTEM_PROMPT + "\n\nApproved context:\n" + APPROVED_CONTEXT,
        }
    ] + history[-8:]

    response = client.chat.completions.create(
        model="deepseek-chat",
        messages=messages,
        temperature=0.2,
        max_tokens=350,
    )

    answer = response.choices[0].message.content or "Please contact support@example.com."

    history.append({"role": "assistant", "content": answer})
    sessions[session_id] = history[-8:]

    return {"session_id": session_id, "answer": answer}

浏览器端要比后端更简单：它不负责“运行 AI”，只负责把消息发给你的服务器，并把回复展示出来。前端保持“瘦身”，能显著降低安全风险，也能减少产品复杂度。

const state = { sessionId: localStorage.getItem("chat_session_id") };

async function sendMessage(text) {
  const res = await fetch("/chat", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      session_id: state.sessionId,
      message: text,
    }),
  });

  if (!res.ok) {
    return {
      answer:
        "Sorry, support is temporarily unavailable. Please email support@example.com.",
    };
  }

  const data = await res.json();
  state.sessionId = data.session_id;
  localStorage.setItem("chat_session_id", data.session_id);
  return data;
}

用 JSON 输出先做“路由决策”，再生成长回答

如果你希望“自动回答还是转人工”的决策更稳定，可以先用 JSON 输出做一次路由判断，再决定是否生成长文本回答。DeepSeek 文档明确支持在 chat 接口上使用 JSON 模式，只要设置好 response_format 并在提示词中要求返回 JSON。

router = client.chat.completions.create(
    model="deepseek-chat",
    messages=[
        {
            "role": "system",
            "content": (
                "Return valid json only. "
                'Schema: {"route":"answer|handoff","reason":"string"}'
            ),
        },
        {
            "role": "user",
            "content": "Customer asks for a refund after a duplicate charge.",
        },
    ],
    response_format={"type": "json_object"},
    temperature=0,
    max_tokens=120,
)

print(router.choices[0].message.content)

这种模式对账单、投诉、隐私请求等场景尤其有用：先做“路由决策”比直接生成一大段自然语言更关键。

安全、守护规则与失败模式

你的机器人应该只回答公开问题，绝不能在没有真实后端流程的情况下：

声称取消订阅
声称发放退款或积分
声称修改发票
声称“已经查看了你的账号”

DeepSeek 的工具调用文档也明确指出：模型只会“提出”函数调用建议，本身不会执行函数。真正的执行逻辑必须由你的后端控制。

至少，你的后端要理解 DeepSeek 的核心错误类型，并据此设计用户可见的兜底文案：

400：请求格式错误
401：鉴权失败
402：余额不足
422：参数非法
429：被限流或压力过大
500 / 503：服务端错误

网站访客不应该看到任何原始 API 报错信息。

如果后续在思考模式下尝试工具调用，工程纪律就更重要了。DeepSeek 的思考模式文档指出：推理与工具调用的循环可能需要在同一链路中回传 reasoning_content，如果实现不当，API 可能直接返回 400 错误。这是一个很强大的能力，也正是为什么大多数网站客服团队不应该从这里起步。

观测、重试与限流

DeepSeek 当前的限流文档说明：

官方不会对用户给出一个固定的公开限流数值
在高并发场景下，请求可能会保持打开一段时间
非流式请求在等待期间可能返回空行
流式请求可能通过 SSE 注释发送 keep-alive
如果 10 分钟内推理尚未开始，服务器会关闭连接

openai-python README 进一步补充了实用的运维细节：

连接错误、408、409、429 和 5xx 错误默认会重试两次
默认超时时间为 10 分钟
每个请求都有可用于日志的 request id

这意味着，你可以在不自建 HTTP 客户端栈的前提下，利用 SDK 提供的能力搭建一个合理的重试与观测基线。

但供应商侧的行为不能替代你的自有控制：

为每个 IP 或每个会话设置调用上限
增加熔断器（例如连续失败后短时间内直接走兜底）
提供友好的降级文案
在必要时退回到邮件或表单支持

“没有固定公开限流”绝不等于“可以无限安全地打满流量”。

成本模型与优化思路

当前公开定价页面显示：deepseek-chat 与 deepseek-reasoner 的单价一致：

输入命中缓存：每 100 万 tokens 收费 0.028 美元
输入未命中缓存：每 100 万 tokens 收费 0.28 美元
输出：每 100 万 tokens 收费 0.42 美元

文档也提醒价格可能随时间调整，这也是很多旧教程很快失效的原因。

上下文缓存文档指出：

缓存默认开启
只有“重复的前缀片段”才会触发缓存命中

这让提示词形状变成一个运营问题：

稳定的系统提示词
稳定的政策 / 业务前缀
短而滚动的历史窗口

通常都比“每轮都重新拼一个完全不同的 prompt”更省钱也更稳定。

一个简单的成本估算：

若一次对话轮次使用 1500 个未命中缓存的输入 tokens 和 300 个输出 tokens
- 成本约为：
  - 输入：1500 / 1,000,000 × 0.28 ≈ 0.00042 美元
  - 输出：300 / 1,000,000 × 0.42 ≈ 0.000126 美元
  - 合计 ≈ 0.000546 美元
如果其中 1000 个输入 tokens 因为前缀稳定而命中缓存：
- 未命中输入：500 / 1,000,000 × 0.28 ≈ 0.00014 美元
- 命中输入：1000 / 1,000,000 × 0.028 ≈ 0.000028 美元
- 输出：不变 ≈ 0.000126 美元
- 合计 ≈ 0.000294 美元

单次对话的绝对金额很小，但在大规模流量下差异会被放大。因此：

让前缀尽量可复用
控制历史长度
避免发送无关上下文
控制输出长度

都是非常实际的成本杠杆。

常见错误

在 DeepSeek 上搭建网站客服时，最常见的坑包括：

使用过时的 SDK 写法，而不是当前推荐的 OpenAI() 客户端
在浏览器中直接发送 API Key
把 chat 接口当成“有状态”的，忘记每轮重发历史
在没有明确需求前就默认启用思考模式
在思考模式下错误处理 reasoning_content，导致 400 错误

还有一个更隐蔽的问题是“过度知识锚定”：

很多团队会把整段帮助中心内容原样塞进每个请求，觉得这样“更安全”
实际上往往适得其反：
- token 成本飙升
- 上下文被噪音淹没
- 回答更难控制

小而精的“已审核片段”通常比“巨量未整理文本”更好用。

下一步可以怎么扩展

当网站机器人稳定后，可以在不改动核心后端逻辑的前提下：

复用同一后端接入 Slack、WhatsApp 等渠道
让各渠道适配层保持“薄”，只负责：
- 把渠道消息转成统一格式
- 把后端回复再转回对应渠道格式

不要为每个渠道各写一套业务逻辑。保持统一的：

路由规则
已审核上下文
日志与观测
人工接管策略

如果后续加入函数调用，当前文档说明：

工具调用在非思考模式和思考模式下都可用
严格工具 schema 需要使用 beta base URL

结语

最强的 DeepSeek 聊天机器人，并不是从“巨型 AI 平台”起步，而是从一个纪律严明的网站客服系统开始：

范围窄
服务端边界清晰
记忆短而可控
上下文经过审核
降级路径明确
人工支持通道清楚

如果你的目标是做一个“真能扛住生产环境”的 DeepSeek 聊天机器人，这样的 v1 是更稳妥的起点：

从 deepseek-chat 开始
把实现做得“无聊而可靠”
等网站版本稳定后，再一点点“赚来”复杂度