企业官网建设流程全解析

简介：这份PDF文档聚焦DeepSeek多轮对话API，面向希望构建上下文感知型聊天机器人的开发者与AI应用实践者，帮助解决多轮对话中上下文丢失、意图理解不准确等常见难题。文档共22页，以pdf格式呈现，压缩包约1.77MB，内容完整、目录清晰，涵盖API概述、上下文感知基础原理、搭建步骤、对话状态跟踪与历史信息压缩等优化技术，并配有常见问题解决方案与完整案例分析。读者可系统掌握从注册获取API密钥、环境搭建到调用API实现上下文管理的全流程，理解注意力机制、词向量表示等核心概念，并借鉴项目架构设计与效果评估方法。目前已有80人学习，适合具备一定自然语言处理基础、希望将DeepSeek能力落地到智能客服或问答系统中的技术人员参考。

1. 多轮对话 API 的上下文断片：为什么你的聊天机器人总在第三轮开始装失忆

你调通 DeepSeek API 的那一刻，单轮问答往往很惊艳。但把同一个messages数组连续用上三轮，机器人就开始答非所问：上一句刚说“我叫老张，做工业质检”，下一句它又问“请问您怎么称呼”。这不是模型变笨了，而是多轮对话 API 的上下文管理没做对。DeepSeek 的对话接口本身是无状态的，服务端不会替你记住任何东西，每一轮请求你都得把历史消息重新拼进messages里发过去。所谓“上下文感知”，本质就是一套围绕messages数组的工程活：怎么存、怎么裁、怎么在 token 上限内保住关键信息。这篇笔记面向已经能跑通单轮调用、准备把 DeepSeek 接进真实聊天机器人（包括 QQ 聊天机器人、企业微信接入 DeepSeek 这类场景）的开发者，把上下文感知从概念落到可复现的代码和参数上。

2. 上下文感知的底层账本：messages 数组与 token 预算怎么算

2.1 DeepSeek 对话接口的无状态本质

先把一件事说透：DeepSeek 的/chat/completions接口是纯无状态的。你发一次请求，它按你给的messages生成一次回复，然后忘得干干净净。下一轮你想让它“记得”之前聊过什么，唯一办法就是把之前的对话内容按顺序塞回messages数组。这个数组的标准结构是每条消息一个对象，带role和content两个字段：

messages = [ {"role": "system", "content": "你是一名工业质检领域的助理，回答简洁。"}, {"role": "user", "content": "我叫老张，做工业质检。"}, {"role": "assistant", "content": "你好老张，有什么可以帮你？"}, {"role": "user", "content": "我们产线想上视觉检测，怎么起步？"}, ]

role只有三种：system定人设和规则，user是用户输入，assistant是模型历史回复。顺序不能乱，模型是按顺序读的。很多人第一次翻车就是把assistant的历史回复漏掉，只传user消息，结果模型看不到自己说过什么，自然接不上话。这里的关键认知是：上下文不是模型的能力，是你请求里带过去的数据。

2.2 token 预算：上下文窗口不是无限抽屉

DeepSeek 的上下文窗口有上限（不同模型版本不一样，以你所用模型的官方文档为准），messages里所有内容加上模型要生成的回复，总 token 数不能超。所以你不能无脑把全部历史都塞进去，聊到几十轮必然爆。常见做法是给历史留一个预算，比如总窗口 64K，system 占几百 token，那历史加当前问题控制在 60K 以内，剩下的留给输出。

算 token 不能靠len(text)，中文一个字大约 1 到 2 个 token，英文一个词约 1.3 个 token，精确值要用对应模型的分词器。工程上我一般先用估算函数做粗算，再留 20% 余量：

def rough_token_count(text: str) -> int: # 粗估：中文按 1.5 token/字，英文按 0.3 token/字符，取偏大值留余量 chinese = sum(1 for ch in text if '\u4e00' <= ch <= '\u9fff') other = len(text) - chinese return int(chinese * 1.5 + other * 0.3) + 4 # +4 是每条消息的结构开销 def total_tokens(messages: list) -> int: return sum(rough_token_count(m["content"]) for m in messages)

rough_token_count里那个+4是每条消息 role、分隔符等结构开销的经验值，别省。total_tokens用来在拼装前判断是否超预算。注意这是估算，真要精确得调分词接口，但估算够用来做裁剪决策，误差 10% 以内不影响。

2.3 裁剪策略：滑动窗口、摘要、还是混合

预算不够时怎么裁，是上下文感知的核心决策。三种常见策略：

我一般用混合：最近 6 到 8 轮保留原文，更早的每积累 10 轮触发一次摘要，把摘要作为一条system或assistant消息插在历史最前面。这样既控住了 token，又不至于把“我叫老张”这种关键事实丢掉。滑动窗口适合客服问答这种短会话，摘要适合长陪伴型对话，选哪个看你的场景对早期信息的依赖程度。

3. 从零搭一个上下文感知的 DeepSeek 会话管理器

3.1 会话存储：内存字典够不够用

单机 demo 用内存字典存会话就行，key 用用户 ID，value 是messages列表：

import time class SessionStore: def __init__(self, ttl_seconds=1800): self._data = {} # {user_id: {"messages": [...], "ts": 时间戳}} self.ttl = ttl_seconds def get(self, user_id: str) -> list: item = self._data.get(user_id) if not item: return [] if time.time() - item["ts"] > self.ttl: del self._data[user_id] # 过期清理，防止内存泄漏 return [] return item["messages"] def save(self, user_id: str, messages: list): self._data[user_id] = {"messages": messages, "ts": time.time()}

ttl_seconds是会话过期时间，默认 1800 秒。为什么要 TTL？因为内存字典不清理会一直涨，线上跑几天就 OOM。get里顺手做过期判断，比单独起定时任务简单。但内存方案有个硬伤：进程重启会话全丢，多实例部署时用户请求打到不同实例会串会话。生产环境常见做法是换 Redis，key 设 TTL，value 存 JSON 序列化的 messages。本地部署 DeepSeek 或内网场景，如果不想引 Redis，至少要把会话落 SQLite，别裸用内存。

3.2 拼装请求：system 提示词与历史消息的顺序

拼装顺序有讲究。system永远放第一条，然后是历史，最后是当前用户输入。历史里 user 和 assistant 要成对出现，别只留一半：

def build_messages(system_prompt: str, history: list, user_input: str, max_tokens: int = 60000): messages = [{"role": "system", "content": system_prompt}] # 从最近往远取，保证近期对话优先保留 trimmed = [] budget = max_tokens - rough_token_count(system_prompt) - rough_token_count(user_input) for msg in reversed(history): cost = rough_token_count(msg["content"]) if budget - cost < 0: break trimmed.insert(0, msg) budget -= cost messages.extend(trimmed) messages.append({"role": "user", "content": user_input}) return messages

build_messages从历史尾部往前取，这是关键：近期对话比早期对话重要，预算不够时先丢最早的。max_tokens默认 60000，你要按自己模型的窗口改。trimmed.insert(0, msg)用 insert 而不是 append，是为了保持时间顺序。注意这里没处理摘要，如果用了摘要策略，摘要那条消息要在trimmed之前插入。

3.3 调用与回写：把 assistant 回复存回历史

调完接口，必须把这一轮的 user 输入和 assistant 回复都追加回历史，否则下一轮又断片：

from openai import OpenAI client = OpenAI(api_key="你的key", base_url="https://api.deepseek.com") def chat_once(store: SessionStore, user_id: str, user_input: str, system_prompt: str): history = store.get(user_id) messages = build_messages(system_prompt, history, user_input) resp = client.chat.completions.create( model="deepseek-chat", messages=messages, temperature=0.7, max_tokens=1024, ) reply = resp.choices[0].message.content # 回写：user 和 assistant 都要存 history.append({"role": "user", "content": user_input}) history.append({"role": "assistant", "content": reply}) store.save(user_id, history) return reply

base_url指向 DeepSeek 的接口地址，model填你用的模型名。temperature0.7 适合闲聊，做严谨问答调到 0.2 到 0.3。max_tokens限制单次输出长度，别设太大，否则挤占上下文预算。回写这一步是新手最容易漏的，漏了就等于每轮都是新会话。history.append两次，顺序不能反。

4. 上下文感知的避坑清单：五个让机器人失忆的隐蔽原因

4.1 只存 user 不存 assistant

现象：机器人反复问同样的问题，像没听见自己说过什么。原因：回写时只 append 了 user 消息，assistant 回复没存，下一轮模型看不到自己的历史输出。解决：确认history.append对 user 和 assistant 各调一次，顺序是 user 在前 assistant 在后。

4.2 裁剪把 system 提示词裁掉了

现象：聊到十几轮后机器人人设崩了，开始胡说。原因：裁剪逻辑只按 token 从尾部取，没把 system 排除在裁剪范围外，或者摘要时把 system 覆盖了。解决：build_messages里 system 单独拼，永远不参与裁剪；摘要内容作为独立消息插入，不替换 system。

4.3 多实例部署会话串号

现象：用户 A 看到用户 B 的对话内容。原因：内存字典方案在多实例下，同一用户请求被负载均衡打到不同实例，各自维护一份不完整历史，甚至 key 冲突。解决：会话存储换 Redis 或数据库，用统一 key 空间；本地部署单实例才考虑内存。

4.4 token 估算偏差导致偶发超限

现象：大部分请求正常，偶尔报上下文超长错误。原因：粗估函数对某些字符（emoji、代码块、特殊符号）低估，累积后超窗口。解决：估算留 20% 余量，或在请求前用精确分词接口复核；捕获超长异常后自动触发一次裁剪重试。

4.5 摘要触发太频繁拖慢响应

现象：每轮都调一次摘要，延迟翻倍。原因：摘要触发条件设成每轮检查，且阈值太低。解决：改成每积累 N 轮（比如 10 轮）触发一次，或按 token 增量触发；摘要调用可以用更便宜的模型，别用主模型。

5. 让上下文更聪明的进阶技巧：摘要锚点与关键事实抽取

基础版跑通后，你会发现纯滑动窗口在长对话里还是丢信息。我常用的进阶做法是“摘要锚点”：在摘要之外，单独维护一份关键事实列表，比如用户姓名、行业、已确认的需求，每轮用规则或小模型抽取更新，拼装时作为一条高优先级system消息插在最前面。这样即使历史被裁光，核心事实还在。

def extract_facts(user_input: str, facts: dict) -> dict: # 极简规则示例：命中关键词就更新事实表 if "我叫" in user_input: facts["name"] = user_input.split("我叫")[-1][:10].strip("，。,.") if "做" in user_input and "行业" not in facts: facts["industry"] = user_input[:20] return facts def facts_to_prompt(facts: dict) -> str: if not facts: return "" lines = [f"{k}: {v}" for k, v in facts.items()] return "已知用户信息：\n" + "\n".join(lines)

extract_facts是规则版，生产上可以换成让 DeepSeek 自己抽 JSON，但要多一次调用。facts_to_prompt把事实表转成一段文本，拼在 system 后面。验证方法很简单：故意聊 20 轮后问“我叫什么”，看它答不答得上来；再对比开不开事实锚点的差异。我踩过的坑是事实表更新太激进，把用户随口一句“我可能做电商”当成确定信息，结果后面一直按电商回答。后来改成只抽明确陈述句，模糊表述不写入。这套东西没有银弹，核心还是把messages当账本认真记，别指望模型自己长记性。希望帮到你。

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