围绕 DeepSeek API 多轮对话机制，拆解消息管理、流式调用、上下文压缩与教学智能体落地，帮助 AI 指导老师构建稳定可用的实战方案。 多轮对话不是把历史消息简单追加到请求里，而是围绕目标、记忆和成本做持续的状态管理。对 AI 指导老师而言，学生每一次追问都携带新的学习信号，API 调用既要维持辅导连贯性，也要控制 token 消耗与响应延迟。DeepSeek API 兼容 OpenAI 风格的消息结构，为教学型智能体提供了较低迁移成本的入口，但真正决定体验的，是上下文组织、摘要策略、工具调用与错误处理等工程细节。
1. 消息数组与角色边界：多轮状态的底层结构
DeepSeek API 的聊天补全接口并不在服务端保存会话状态，多轮对话的连续性完全由客户端通过 messages 数组维护。通常 system 消息放置稳定的教学规则，例如“先诊断学生思路，再给提示，不直接公布完整答案”，user 消息承载当前提问，assistant 消息保存历史回复，tool 消息用于函数调用结果。每轮请求都要把需要模型看到的全部消息按时间顺序重新发送，模型不会自动记住上一轮内容。若只发送最新问题，学生会发现“刚才说的”被忽略，辅导体验立即断裂。
在 AI 指导老师场景中，角色边界还承担教学策略约束。system 适合放课程目标、语气、安全边界和输出格式，动态信息如学生姓名、年级、错题记录则不宜塞进 system 固定前缀，否则会破坏缓存并增加 token 成本。学生会话应绑定 session_id、student_id 和 course_id，历史消息存入数据库或 Redis，并记录时间戳、模型版本和 token 用量。对于编程辅导，如果学生问“刚才的递归为什么栈溢出”，系统必须能追溯到上一条 assistant 给出的示例代码，否则模型无法判断“刚才”指代什么。
DeepSeek 提供 deepseek-chat 和 deepseek-reasoner 等模型，前者适合常规教学对话与工具调用，后者更适合复杂数学证明或算法推理。多轮结构上，reasoner 返回的 reasoning_content 不应作为后续上下文继续传递，真正进入历史的是 content。把不同模型的消息混存时，还要保留角色顺序，避免出现连续 user 或孤立 assistant 消息。消息数组看似简单，实际是教学智能体的状态骨架，决定了后续摘要、检索和评估能否可靠挂载。
2. 请求编排与流式响应：把一轮对话跑通
一次完整多轮请求通常从用户输入开始：客户端把新 user 消息追加到历史数组，调用 DeepSeek API 的 chat completions 端点，获得 assistant 回复后再写回历史。使用 OpenAI SDK 时，只需将 base_url 指向 ，选择 deepseek-chat 或 deepseek-reasoner，并传入 messages、temperature、max_tokens 等参数。教学场景建议将 temperature 控制在 0.3 到 0.7，既保留解释的灵活性，又避免答案漂移。max_tokens 要预留足够空间，否则复杂题解可能在关键步骤被截断。
流式响应是提升体验的关键。设置 stream=True 后，服务端通过 SSE 逐步返回 delta，前端可以逐字显示讲解，降低学生等待焦虑。工程上不能只把增量拼给界面，还要在流结束后得到完整 assistant 内容并落库；如果中途网络断开，需要保存已生成文本，并在下一轮明确告知模型“上一条回复未完成”。当使用函数调用时，assistant 消息可能包含 tool_calls，必须把工具返回结果以 tool 角色按顺序追加，再发起下一次请求。deepseek-chat 支持这类工具编排，可用于查询学生进度、保存错题或生成练习题。
多轮实战中最容易被忽视的是并发与重试。同一会话的请求应串行处理，避免两个请求同时改写历史导致上下文错位。遇到 429 限流或 5xx 错误时，采用指数退避重试，并记录 request_id 方便排查。对于高频相同问题，可以在应用层缓存标准解释，但涉及学生个人进度时必须绕过缓存。流式输出和完整落库要分开处理：前者服务体验，后者服务记忆。只有把一轮对话跑通并稳定写入历史，后续的摘要、检索和教学评估才有可靠数据源。
3. 上下文治理：摘要压缩、检索增强与窗口裁剪
随着多轮推进，messages 数组会迅速膨胀。DeepSeek 当前模型具备 64K 级上下文，部分版本扩展至 128K，但可用量还要扣除输出预留，且长上下文会带来更高成本和更长延迟。AI 指导老师不能把全部历史无脑发送，需要做上下文治理。常见做法是滑动窗口保留最近六到十轮原始对话，同时把更早历史压缩成摘要，例如“学生已掌握变量与循环，薄弱点在递归终止条件，偏好代码示例”。摘要可以由模型异步生成，不阻塞当前回复。
检索增强是另一条主线。课程大纲、教材段落、错题本和教师讲义可以向量化存入知识库，每轮根据学生问题检索 top-k 片段，再注入 system 或 user 消息。裁剪时要保留 system 规则、最近对话、长期摘要和检索结果，不能简单从中间截断，否则会出现 assistant 回复缺少前置问题、角色顺序错乱等问题。固定不变的课程背景和教学规则应放在消息前缀，动态学生信息放在后面，这有助于利用 DeepSeek 的上下文缓存降低输入成本。
摘要和检索都要服务教学目标，而不是单纯省 token。每轮结束后可以提取结构化状态：理解程度、错误类型、已尝试的解释、下一步建议。若学生连续追问同一概念，系统应优先检索历史错题和已用类比，避免重复相同讲解。对于隐私数据，摘要中尽量脱敏，只保留学习相关字段。上下文治理的本质是让模型在有限窗口内看到最相关的信息，而不是看到最多信息。对 AI 指导老师来说，一次精准的裁剪比一次冗长的全量回放更能提升辅导质量。
4. 教学智能体落地：记忆、评估与安全闭环
AI 指导老师的多轮对话最终要落到教学闭环。每轮 assistant 回复后，可以异步调用模型生成学习状态评估，判断学生是理解、模糊还是困惑，并写入学生画像。借助 deepseek-chat 的函数调用能力，可以定义 get_student_profile、save_mistake、generate_quiz 等工具，让模型在对话中主动查询进度、记录错题或生成针对性练习。工具调用结果要作为正式消息写回历史，这样下一轮模型才能基于最新状态继续辅导，而不是凭猜测延续对话。
教学记忆需要分层。短期记忆是最近几轮原始消息，中期记忆是会话摘要，长期记忆是学生画像和错题本。评估不应只依赖模型自评，可以结合规则引擎，例如连续三次答错同一知识点就触发降级讲解，连续两次独立答对则提升难度。指导老师的人设要稳定，但策略要动态：当学生因递归困惑时，可以先画调用栈，再给最小示例，最后让学生复述；如果摘要显示代码示例已经无效，就改用生活类比。多轮对话的价值正在于这种基于历史的策略调整。
安全与边界同样关键。面向未成年人的教学场景，要过滤不当内容，禁止直接代写作业或泄露考试答案，明确 AI 只提供引导而非替代教师。对敏感话题设置拒答模板，对个人信息做脱敏存储，并保留人工复核入口。DeepSeek API 的错误处理、超时重试和用量监控应纳入运维面板，防止成本失控。一个可用的 AI 指导老师，不是单轮回答多漂亮，而是在多轮交互中持续记住学生、调整策略并守住安全底线，让每次追问都成为可追踪的学习事件。
