# 从一句聊天到 ChatGPT 级对话系统Chat 链路设计的演化思维 ## 引言 很多人在第一次实现 AI 聊天应用时会认为 Chat 系统非常简单 用户输入一句话 → 调用大模型 → 返回答案。 例如 text 用户 ↓ 输入问题 ↓ 调用 LLM ↓ 返回结果如果只是做一个 Demo这种设计完全可行。但是当系统真正面向用户使用时会不断出现新的问题用户为什么需要登录如何保存聊天记录模型如何知道之前聊过什么为什么回答可以实时输出如果生成过程中失败怎么办多个模型同时生成怎么办如何支持长期记忆这些问题不断推动 Chat 系统演化。因此设计 Chat 系统的关键不是记住某个框架而是理解一个系统如何从最简单方案开始在不断解决问题的过程中演化成复杂架构。一、最初的问题如何让用户和模型交流最开始需求非常简单用户输入一句话模型返回一句话。最简单实现response llm.generate(prompt)系统结构用户输入 ↓ 模型 ↓ 返回回答但是这个系统存在一个核心问题HTTP 请求本身是无状态的例如第一次用户 我叫 Terry模型好的我记住了。第二次用户 我叫什么如果只发送我叫什么模型并不知道 Terry 是谁。因为第二次请求和第一次请求没有关联。于是第一个核心问题出现聊天系统必须保存上下文。二、Conversation从一次请求到连续对话为了让模型知道之前发生了什么需要保存历史。系统从一次请求 一次回答演化为一次会话 多个消息因此产生Conversation会话Conversation 表示用户和 AI 之间的一段连续交流。例如User ↓ Conversation ↓ Message Message Message数据库conversation id user_id title created_at updated_at但是新的问题出现Conversation 中应该保存什么三、Message为什么聊天记录不能只是文本最简单方式把所有聊天内容拼成一段字符串。例如你好 你好我是 AI 介绍一下 RAG RAG 是一种...但是系统不知道哪句话是用户说的哪句话是 AI 说的哪句话是系统规则因此聊天记录必须结构化。于是产生Message消息Message 表示一次具体的信息事件。例如message id conversation_id role content created_at其中rolesystem user assistant tool最终Conversation | | ---- Message | ---- Message | ---- Message四、Context Builder数据库消息不是模型输入保存 Message 后又出现一个问题数据库里的消息能直接发送给模型吗不能。数据库保存的是业务数据。模型需要[ { role:system, content:你是AI助手 }, { role:user, content:介绍RAG }, { role:assistant, content:RAG是一种... } ]因此需要Context Builder职责历史消息 ↓ 筛选 ↓ 排序 ↓ 格式转换 ↓ 模型输入五、Memory为什么需要长期记忆继续思考如果用户和 AI 聊一年怎么办假设10000 条消息每次全部发送会产生1. Token 超限模型上下文有限。2. 成本增加输入 Token 越多费用越高。3. 响应速度下降上下文越长处理越慢。最简单方案只保留最近消息。例如最近20条但是又出现问题用户半年前说我是 Python 开发者半年后帮我设计项目最近20条消息可能没有这个信息。于是产生Memory记忆Memory 解决短期信息和长期信息的问题。短期记忆当前聊天上下文长期记忆用户偏好 用户背景 历史重要信息区别Conversation这次聊天发生了什么。Memory这个用户长期是什么样的人。六、Streaming为什么回答不是一次返回传统方式请求 ↓ 等待30秒 ↓ 返回完整答案体验较差。因此产生Streaming流式输出模型生成一个 Token。立即返回一个 Token。链路LLM ↓ Token Stream ↓ Backend ↓ Frontend ↓ 更新页面这就是为什么 ChatGPT 的回答像打字一样出现。七、为什么提前创建 Assistant Message这是实时聊天系统的重要设计。用户发送介绍一下 Agent前端先创建用户消息message_id100 content: 介绍一下 Agent然后创建助手消息message_id101 content: 空为什么因为后续模型返回Agent 是一种...这些 Token 必须知道应该追加到哪条消息。因此Token ↓ message_id ↓ 更新 Assistant Message提前创建 Assistant Message 的本质提前创建未来数据写入的位置。不是提前生成答案。八、状态管理Chat 本质是状态机继续思考如果模型生成过程中失败怎么办例如已经生成Agent 是一种能够...突然网络断开。数据库用户消息: 完成 助手消息: 生成一半系统不知道当前状态。因此需要状态。Message 状态pending ↓ streaming ↓ completed失败pending ↓ failed所以Chat 系统不是简单输入 → 输出而是状态不断变化 事件不断发生九、SSE / WebSocket为什么需要实时通信普通 HTTP客户端请求 ↓ 服务器响应 ↓ 结束但是聊天请求 ↓ 持续返回数据 ↓ 持续更新因此需要长连接。常见方案SSE特点服务器单向推送。适合AI 流式输出。WebSocket特点双向通信。适合实时协作场景。十、Chat 系统最终架构经过不断演化最终形成User ↓ Conversation ↓ Message Store ↓ Context Builder ↓ Memory System ↓ LLM Runtime ↓ Streaming Layer ↓ Frontend Update ↓ Persistence生产级系统还需要用户系统Authentication Authorization数据系统PostgreSQL Redis工程能力日志 监控 错误恢复 限流 缓存十一、为什么 Chat 最终演化成 Agent普通 Chat用户 ↓ 模型 ↓ 回答只能完成信息生成。但是现实任务例如帮我分析这个公司的财报。可能需要搜索资料读取文件调用工具执行代码保存结果于是系统需要规划 ↓ 调用工具 ↓ 执行任务 ↓ 保存状态 ↓ 恢复任务这就是 Agent。因此Chat 是 AI 应用入口Agent 是复杂任务执行能力的扩展。十二、总结如何用工程思维设计 Chat设计 Chat 系统不应该从我要使用什么框架开始。应该从我要解决什么问题开始。完整推导过程需要聊天 ↓ 需要连续上下文 ↓ Conversation ↓ 需要保存每句话 ↓ Message ↓ 需要模型理解历史 ↓ Context Builder ↓ 历史太长 ↓ Memory ↓ 等待时间长 ↓ Streaming ↓ 流式过程可能失败 ↓ State ↓ 任务复杂 ↓ Agent真正优秀的系统设计不是提前知道所有技术。而是在问题出现后发现问题 ↓ 拆解问题 ↓ 设计方案 ↓ 发现新问题 ↓ 继续抽象最终形成完整架构。一个成熟的 Chat 系统不是一次设计出来的。而是在不断解决问题的过程中被逐渐推导出来的。
