17｜对话引擎（下）：让智能客服真正开口说话

Robert

你好，我是 Robert。
16 讲把对话引擎的所有设计决策都定好了——六步链路、数据模型、SSE 流式方案、适配层扩展、接口格式。这一讲把它们全部落地，让智能客服真正开口说话。
但在写 CRUD 之前，有一个核心问题要先解决：上下文。
上下文是什么你可能觉得“上下文”是个显而易见的概念，就是对话历史嘛。但它在技术实现上没那么简单。
AI 对话里的“上下文”到底是什么？LLM 本身有记忆吗？多轮对话是怎么实现的？
Claude Code 的回答纠正了一个常见误解：
LLM 本身没有记忆。  每次调用都是无状态的，你上一轮告诉它“我的订单号是 12345”，下一轮它完全不知道。它不像数据库会持久化状态，每次调用都是一张白纸。
那 ChatGPT 怎么做到记住你说过什么？答案是每次调用都把历史消息重新塞进请求里，让模型在同一次推理中“看到”历史，造成记得的假象。
上下文就是你传给模型的 messages 数组的全部内容：
{
  "messages": [
    { "role": "system",    "content": "你是专业客服" },
    { "role": "user",      "content": "我的订单在哪里" },
    { "role": "assistant", "content": "请提供订单号" },
    { "role": "user",      "content": "订单号是 12345" },
    { "role": "assistant", "content": "您的订单正在配送中" },
    { "role": "user",      "content": "大概几天到" }
  ]
}

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
法语
德语
日语
韩语
俄语
西班牙语
解释
总结

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《Claude Code 企业级全链路开发实战》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(1)

最新
精选

灿若繁星先生
Claude说双写是过度设计, 双写有一致性风险(上下文就会缺消息或出现脏数据), 收益低(一条sql语句走索引), 场景不匹配(Hify面向的人少单机部署), 思考题 1. 可以做个pin功能, 把关键消息做标记, 被定住的消息"不在maxContextTurns统计范围内"或者"永远占一个位置" 2. 理论上讲LLM是无状态的, 只要保证会话id不串, 就能保证上下文不串 3. 我觉得可以在对话结束时, 判断是否达到摘要压缩阈值, 然后异步让LLM总结前面的上下文, 再用Queue防止重复触发压缩, 应对快速对话的场景.
2026-04-22归属地：江苏



收起评论