1. DeepSeekClient 到底在解决什么问题
这几年 AI 对话类产品层出不穷，但多数团队对"API 对接"的理解还停留在"发个 HTTP 请求拿个 JSON 回显"的阶段。真正把一个对话工具做成可上线、可维护、可扩展的系统，你会发现最难的往往不是模型能力本身，而是客户端这一整层工程：消息怎么送、上下文怎么管、流式响应怎么接、断线了怎么办、多用户并发怎么扛。DeepSeekClient 这个名字听起来像个简单的客户端封装，实际上它承载的是一个完整的 AI 对话系统前端工程骨架，把模型能力、会话管理、交互体验和持久化全部串在一起。
从业务角度看，这类客户端要解决的问题可以归纳成三件事：第一，把大模型的无状态 API 包装成有状态的对话体验；第二，让上层业务不用关心模型供应商的差异，换模型、加模型不伤筋动骨；第三，把工程层面的稳定性兜住——超时、重试、限流、流式断开这些事，不能每次出问题都让业务方去裸奔调试。
1.1 从聊天窗口到"对话系统"的鸿沟
很多人会问：用官方网页版不就行了，为什么还要自己写客户端？答案是官方页面解决的是"一个人和模型对话"，而对话系统解决的是"业务里的对话"。这两者的差别在于上下文来源不同、使用形态不同、治理要求不同。
举个例子：你要做一个知识库问答机器人，除了把用户的问题转发给模型，你还得在请求里拼接检索到的知识片段、注入系统角色设定、限定输出格式，甚至要在多轮对话中自动剔除过期的上下文。这些如果都用裸代码散落在业务逻辑里，第一个版本能跑，第三个月就没人敢动了。DeepSeekClient 这种架构的价值，就是把这些"对话系统才有的脏活"收拢到统一的工程层里，让上层业务只关心两件事：用户说了什么、希望得到什么。上层的答案反过来也能更好地让模型发挥能力，而不是在业务堆里攒技术债。
1.2 三个边界的划分
我在实际设计这类客户端架构时，习惯把职责切分成三条清晰的边界，这也是后续所有模块设计的基础。
- 交互边界：负责输入输出协议、消息格式转换、前端展示层的数据结构。它不关心模型，只关心"对话长什么样"。
- 会话边界：负责上下文组织、会话生命周期、状态持久化。它同时面对交互层和模型层，是状态管理的核心。
- 模型接入边界：负责所有与具体模型服务的通信，包括认证、请求构造、流式解析、错误映射。它不关心业务，只关心"怎么稳定地调用模型"。
这三条边界一旦定下来，后面新增功能就变成了在固定管道里接积木，而不需要每次推倒重来。接下来我会从一次完整请求的视角，把这三层内部的运作细节拆开讲。
2. 整体分层：一次请求在客户端内部走过的完整链路
我们假设用户在输入框里敲了一句"帮我总结一下这份合同的风险点"，然后点击发送。这一瞬间开始，客户端内部会发生一次有序的接力，每一棒都有自己明确的职责。这一节我把链路从头到尾走一遍，顺便解释每一层为什么要这样设计。
2.1 输入构造层：消息与元数据的归一化
输入构造层处理的第一件事，是把前端传来的原始输入统一成标准消息结构。在 DeepSeekClient 这类架构里，消息一般会被归一化成这样：
@dataclass class ChatMessage: role: str # system / user / assistant / tool content: str name: str | None tool_calls: list | None tool_call_id: str | None这里有个容易忽略的点：role列表在模型侧是固定几类的，但在客户端内部，我们要额外区分"来自用户的原始输入"和"经过预处理后的输入"。比如说，用户可能上传了一个文件，前端拿到的是文件元数据，而客户端要负责把文件内容做摘要、截断、拼进消息里。这个转换过程放交互层做的好处是，后续所有模块看到的都是纯文本消息，不会出现"拿着文件对象去拼请求"的尴尬局面。
输入构造层还要处理的一件事是多模态输入的前置计算。如果这个对话系统支持图片，那客户端要在请求发出前就完成图片的压缩、base64 编码或者上传到对象存储并换取 URL，并把 token 占用预算算进本次请求的上下文窗口里。这块不处理好，模型侧经常报上下文超长，而且你根本不知道是哪条历史消息超的。
2.2 会话调度层：请求编排、重试与并发兜底
消息构造完成后，控制权交给会话调度层。这一层的工作可以概括为"决定这一次请求该怎么打出去"。
首先是会话 ID 的确定。客户端要根据当前会话的状态决定：是继续现有会话，还是新建一个；是携带全部历史消息，还是只携带最近 N 轮；需不需要附带检索结果，如果需要，检索请求该怎么并发发出。很多时候，一次模型调用前会掺杂若干前置依赖调用，比如检索、查库、取用户画像。这些依赖可能是串行的，也可能是并行的。会话调度层就是那个决定"先干什么、后干什么、哪些可以同时干"的编排器。
其次是请求兜底策略。网络请求从客户端到模型服务，中间要经过公网链路，超时、抖动、5xx 错误几乎不可避免。所以引导层必须内置重试机制。这里我强烈建议采用"有限次重试 + 指数退避 + 抖动"的组合策略，而不是简单地重试三次。实际经验是，第一次重试等待 500ms，第二次 1.5s，第三次 3s，每次加一个 [-20%, 20%] 的随机抖动，能显著降低模型服务侧的瞬时拥塞导致的重试风暴。光设置重试还不够，会话调度层还需要给每个请求一个全局超时预算，也就是"我最多等这次对话多少秒"。一旦超时预算耗尽，直接回调业务层走降级逻辑，而不是无限等下去。
2.3 模型接入层：一个接口接住所有模型服务
模型接入层是整个客户端的腹部，也是最体现架构功底的地方。DeepSeekClient 在设计上会把所有模型服务抽象成统一的调用接口，对外暴露的核心方法无非是chat(messages, config) -> Response，但内部要处理的是不同模型的差异。
不同模型服务的差异体现在这几个维度：API 路径不同、鉴权方式不同、参数命名不同、工具调用格式不同、流式事件结构不同，甚至连上下文窗口大小都不同。如果业务代码直接调用某个模型的 SDK，那将来换模型就是一次全局代码改动，这谁顶得住？
我的做法是给每个上游模型写一个适配器，适配器内部做协议转换，对外暴露同一套数据结构和错误码。比如 DeepSeek 的自定义解析器和 OpenAI 兼容协议解析器，在适配器这一层完成的是同一件事：把上游的响应统一映射成客户端内部的消息对象。这样上层业务完全不感知底层用的是哪家模型，甚至可以在一次会话中切换不同的模型。
这里顺便说一个真实教训：很多团队在对接模型服务时，习惯直接把官方 SDK 的对象传进内部代码里，导致后续升级 SDK 版本时，所有调用点都要跟着改。正确姿势是定义自己的消息结构体，在适配器边界完成一次拷贝转换，后续 SDK 怎么变都不影响内部核心逻辑。
3. 会话状态机：上下文与多轮对话的核心
如果说请求链路是对话系统的血管，那会话状态机就是心脏。多轮对话里最复杂的问题——"模型到底记得什么"——完全由这一层说了算。从工程角度看，会话状态机要解决三个核心问题：状态怎么存、上下文怎么控制长度、历史怎么裁剪。
3.1 会话状态模型与上下文窗口控制
我先给出一个实践中比较通用的状态设计：
@dataclass class SessionState: session_id: str messages: list[ChatMessage] token_count: int system_prompt: str tools_schema: list[dict] created_at: datetime updated_at: datetime metadata: dict每一轮用户消息进来，客户端做的第一件事不是直接把消息追加进messages，而是先计算这条消息的 token 数，加上系统提示词和工具定义的 token 数，判断是否还在模型上下文窗口内。如果超了，就要在追加前做裁剪。这个提前计算的动作非常关键，否则等请求打到模型侧再报上下文超长，不仅浪费时间，用户感知还很差，经常表现为"上一条还能聊，这一条突然报错"。
Token 计算这块，不同模型有不同的分词方式，建议不要用通用字符长度估算。客户端内部应该维护一个轻量级计费器，离线加载模型对应的 tokenizer，或者集成模型官方提供的计数接口。实测下来，字符长度估算的误差在中文场景可以达到 30%，对于一次性只能容纳几千 token 的小模型来说，这种误差会导致大量的无效请求。你还不如花点时间，启动时预加载一份词表进来，准确性要好一个量级。
3.2 消息压缩与历史裁剪策略
历史裁剪不是"删掉最旧的消息"这么简单，这里有几个策略，按长期效果排序如下：
- 截断丢弃：最省事，但容易让模型丢失重要的早期信息。适合超长对话里的临时会话。
- 摘要压缩：把早期消息定期交给一个小模型做摘要，把摘要作为一条 system 消息放进上下文。适合需要长期记忆的助手类产品。
- 关键信息提取：通过规则或模型，在用户输入里识别出关键实体、偏好，存入侧边记忆区，每次请求时动态拼接回上下文。适合个性化助手。
- 滑动窗口 + 摘要锚点：保留最近 N 轮原始消息，把更早的消息摘要后固定挂在一角。这个组合是长期对话中体验和成本的平衡点。
我在应用里比较推荐"滑动窗口 + 摘要锚点"的方案。具体来说，客户端维护一个窗口阈值，比如最近 20 轮消息为完整保留区，超出部分每 10 轮做一次摘要，摘要结果挂在系统提示词后面。这样模型的注意力能被引导到"近期发生的事"上，同时全局背景也没有丢失。要注意的是，摘要的触发不应该放在每次请求里，而是放在一轮对话结束后异步触发，否则会在高并发时把模型调用量翻倍。
切换到这里，很多人会忽略一个问题：上下文裁剪之后，裁剪动作本身也要同步给用户。我在实际使用里，如果客户端悄悄砍掉了早期消息，用户会觉得模型"失忆"了，体验非常糟糕。所以我会在会话元数据里记录truncated: true标志，并把它传给前端，展示一条轻量提示："更早的内容已被摘要覆盖"。这既是产品体验，也是工程上的信息透明。
4. 流式响应：接入、心跳与断线重连的取舍
对话系统如果还是"等接口全部返回再展示"，那用户的体验就是长时间的白屏等待。大模型生成本来就慢，完整返回动辄几秒到几十秒，所以流式响应不是一个可选项，而是一个必选项。这一节讲讲流式接入的几个核心工程细节——这些往往是线上事故的高发地段。
4.1 事件流协议的选择与解析
目前主流模型服务都支持 SSE（Server-Sent Events）格式的流式响应。SSE 本质上是 HTTP 连接上一个持续打开的数据流，每一帧数据以data:前缀开头，帧之间用空行分隔。DeepSeekClient 在接入时可以直接基于 HTTP 客户端做流式解析，但我要强调几个容易踩的坑。
第一个坑是连接建立成功不代表服务端真正开始推送。有的模型服务在接到请求后，要先做内部排队，连接上会有一个静默期。如果客户端把"连接建立"当成"开始输出"，前端就会出现"一直转圈但没有任何字"的假死状态。我的做法是在客户端侧给"首帧延迟"设置一个阈值，比如 15 秒。如果超过这个阈值还没有任何数据帧，判定为超时并主动断开，走重试逻辑，同时给前端回调一个"排队中"的状态，让用户知道服务端并不是挂了，只是前面任务很多。
第二个坑是流式数据的完整性。网络抖动时，一帧完整的 JSON 可能被拆成两个 TCP 包，或者两帧被包在一个包里。解析器绝不能按"收到的每个包就是一个完整事件"来处理。客户端必须维护一个小的 Buffer，按 SSE 的空行规范去切帧，切完再反序列化。这个 Buffer 要处理半包和粘包，流程图都不复杂，但每家的真实实现却各不一样。切帧这块我可以直接给一段参考逻辑：
def parse_sse_stream(raw_chunk: bytes, buffer: bytearray) -> list[dict]: buffer.extend(raw_chunk) events = [] while True: line_end = buffer.find(b"\n") if line_end == -1: break line = buffer[:line_end].decode("utf-8", errors="ignore").strip() del buffer[: line_end + 1] if not line: # 空行，表示一个事件结束 if buffer_head: events.append(json.loads(buffer_head)) buffer_head = "" continue if line.startswith("data:"): buffer_head += line[5:].strip() return events这只是一个极简版本，真正工程里还要处理[DONE]结束标记、多行 data 拼接、事件类型字段等，但核心思想就是：永远不要假设网络包边界等于事件边界。
4.2 断线重连与退避策略
流式响应中最崩溃的场景，是模型已经生成了一半内容，连接断了。此时用户那里显示的是一段半截回答，后面再也续不上。怎么办？
这里有个重要的产品兜底原则：无论客户端怎么努力，连接断了之后，服务端那边的生成任务有两种可能——还在继续跑，只是推送通道断了；或者已经因为异常中止。客户端无法在断开瞬间直接知道是哪种情况，所以需要执行一个"恢复协议"。
恢复协议的第一步，是在业务链路里给每次流式请求分配一个唯一的generation_id，并带上断点位置。客户端重连时，携带这个 ID 请求服务端返回"从这个断点开始的增量内容"。这个能力下游不一定支持，但 DeepSeekClient 在架构上不应该因为下游不支持就放弃设计。你可以先实现一个降级版本：断线后展示提示条，并提供"点击重新生成后半段"的按钮，而不是直接报错清屏。不要小看这个降级，它能把一次失败体验变成一次可交互的兜底，用户流失率会明显下降。
退避策略上，我的经验是"断线重连最多三次，三次不到就直接放弃"。原因很简单：流式请求本身有很强的实时性要求，用户的耐心不会超过你重试的时间。与其反复重连让用户看转圈，不如快速放弃并给出清晰的失败 UI。三次重试的建议间隔是 0.5 秒、2 秒、5 秒，每次加大约 20% 的随机量。注意第一次重试不能零延迟立刻发起，那样只会复现同一条网络链路的瞬时抖动。
4.3 心跳与连接健康检测
流式连接建立后，如果模型侧长时间没有推送，但又没有断开，客户端怎么判断这条连接是健康的？答案是要依赖心跳。不过 SSE 协议本身没有心跳帧，所以我们通常要借助模型服务的"注释帧"或"空事件"来识别服务端还活着。很多模型服务在排队或思考期间，会定期推一个: keep-alive的注释行，解析器遇到注释行直接忽略，但它本身就是活着的信号。
如果上游不支持任何形式的心跳帧，那客户端就要在等待超时后主动发送一个 Ping 或者发起一个轻量请求去探测。但要注意，探测请求不能干扰正在进行的生成任务，尽量走独立连接。这块设计得不好，会造成探测流量把生产链路的连接池挤爆。
5. 数据与存储层：模板、角色设定与会话记忆
如果把对话系统比作一家餐厅，模型是后厨的厨师，那存储层是食材仓库和菜单。一个成熟的客户端，不会把"厨师每次炒什么菜"交给业务代码临时决定，而会事先定义好菜单模板、配菜规则、配料库存。这节讲存储层的三个设计点：提示词模板、角色设定、会话记忆持久化。
5.1 提示词模板渲染管线
很多初学者的做法是把提示词写死在代码里，像这样：
prompt = f"你现在是一个{role}，请回答用户的问题：{question}"这在原型阶段没问题，一旦进入产品化，问题就很明显：运营想改话术要发版，不同渠道要不同人设，包含大量敏感信息时还要做脱敏。所以客户端必须内置一个提示词模板渲染管线。
我的设计是把模板分成两层：第一层是"系统基础模板"，定义模型的基础行为边界，比如"你是一个严谨的技术文档助手，不得编造不存在的 API"。 第二层是"业务渲染模板"，由上层应用传入业务语义，比如用户昵称、产品名、参考文档片段。两层之间通过模板变量拼接：
你是{{ assistant_name }}。 你的任务是根据下面的参考材料回答用户问题： {{ references }} 如果材料不足以回答，请明确回答“根据现有材料无法确定”，不要猜测。模板引擎的选择，我的建议是不要用标准模板语言整套引入，而是尽量做一套受限的渲染器，只保留变量替换、条件判断、循环三种能力。这样可以避免用户输入中的模板语法意外触发解析。使用 JINJA 时需要小心，用户消息中若包含意外闭合标记，可能导致注入；最稳妥的方案是先将用户内容与提示词模板隔离，再在组装请求时拼接。
5.2 会话记忆与恢复的存储结构
会话记忆是对话系统的核心资产。用户聊到一半刷新页面，再进来时如果上下文丢了，那这个客户端在用户心里基本等于废了。所以存储层必须要做持久化，不光是消息内容，还包括 token 计数、会话状态、最后更新时间。
存储选型上，简单的单机部署可以使用 SQLite，分布式场景推荐带有 High Availability 的 PostgreSQL 或者兼容 Redis 协议的内存数据库做热数据。这里不追求复杂的图数据库，因为一个对话会话本质上是线性消息序列，偶尔涉及到树形分支（用户改写了问题）。我就是用一张消息表加一个parent_msg_id字段来实现分支能力的：
CREATE TABLE session_messages ( id TEXT PRIMARY KEY, session_id TEXT NOT NULL, role TEXT NOT NULL, content TEXT NOT NULL, token_count INT NOT NULL, parent_msg_id TEXT, created_at TIMESTAMP DEFAULT NOW() ); CREATE INDEX idx_session_time ON session_messages (session_id, created_at);parent_msg_id这个字段平时不填，用户选择"重新生成"时，系统把新消息挂在旧消息上面。读历史时，如果用户想切回不同分支，客户端通过这个字段回溯即可。这是对话系统中一个必要但很少被文档提及的细节。
另外，存储层还要做"会话快照"的概念。意思是每隔一段时间，把会话的摘要、元数据、上下文状态编码成一个 JSON，存入快照表。这样即使主会话消息表出了意外，也能从最近快照恢复，而不是完全从头开始。快照的生成频率可以放在每次会话空闲后延迟 30 秒执行，避免每轮都写造成的性能负担。
5.3 隐私与清理策略
存储层涉及用户对话内容，清理策略必须设计好。我的原则是分级控制：明文保存在主存储的时间，根据产品需求控制在一个窗口期内，比如 30 天；超过窗口期的数据，异步做脱敏汇总，仅保留必要的查询维度；用户主动删除时，要有级联删除逻辑，把消息、快照、索引关联数据一并清干净。
这一点在架构文档里一定要写清楚，否则后续安全审计会成为灾难。DeepSeekClient 这类独立客户端还有一个特殊点：它可能同时对接多个隔离的部署环境，比如私有化部署和公共 API。数据路由规则必须在存储接口层显式实现，不能让业务代码在调用时自己决定写哪个库。
6. 性能优化与可观测的三板斧
架构好看没用，线上稳才算数。对话系统的性能瓶颈往往不在模型本身，而在客户端怎么处理并发、缓存和观测。这一节我把我认为最值得投入的三个方向讲透。
6.1 并发控制与连接池
模型服务一般都有并发限制，客户端如果无节制地并发请求，等来的就是 429 限流或者 503 错误。所以客户端内部必须有一层并发控制，而不是把压力全部抛给模型侧去兜底。
比较实用的方案是"令牌桶 + 请求队列"。每个用户的会话有一个软性 QPS 配额，客户端在发出请求前先从桶里取令牌，取不到就排队等待，而不是直接拒绝。排队逻辑在整体上能平滑流量峰值，尤其适合企业内部多部门共用同一个 API Key 的场景。
连接池这块，我要多说一句。很多 HTTP 客户端默认连接池不够大，流式请求又特别容易把连接占住。一旦连接池耗尽，后面普通请求也会被牵连排队。我的配置经验是：连接池最大连接数设为并发配额的两倍，空闲连接存活时间 60 秒，每个路由单独统计。并且一定要为流式请求设置独立的连接池，避免长时间挂着的流把健康检查请求饿死。
6.2 缓存策略：不是所有请求都要打模型
对话系统的缓存比传统 Web 缓存要小心，因为模型是生成式的，同样的问题往往期待多元化的答案。但依然有两个场景适合缓存。
第一个场景是系统性消息，比如从外部知识库检索到的固定参考材料。这部分内容通常不变，可以缓存它的 embedding 结果或文本摘要，减少每次检索的耗时。第二个场景是高复用的系统提示词和工具定义，这些是每次请求都要带的，完全可以在内存里缓存序列化结果，省去重复 JSON 序列化和 token 计算的 CPU 开销。
另外，如果产品允许，用户手动点击"重新生成"时，不要一股脑把上一轮的响应也算入缓存——除非产品明确要求“相同问题返回相同答案”。我的建议是：会话级和消息级的缓存默认关闭，基础模板级的缓存默认开启，这样风险最小，收益却稳定。
6.3 日志埋点与链路追踪
对话系统最怕的是出了问题不知道是哪一环导致的。用户在 UI 上看到"模型回答失败"，背后的可能原因有好多种：不是只有模型超时，用户鉴权过期、会话上下文超长、下方配置的模型参数非法、网络 DNS 解析失败、代理超时，甚至上游模型服务本身限流。没有链路追踪，流式响应出现故障时，你必须抓瞎。
我的最小埋点方案是给每个请求分配一个trace_id，从输入到模型接入层全程透传。日志统一采用结构化 JSON，包含这些字段：trace_id、session_id、generation_id、model_name、prompt_tokens、completion_tokens、latency_ms、error_code、retry_count。只要这些字段齐全，就能很迅速地定位环节。
绩效上，前端首字耗时（TTFT）是最核心的体验指标。可以在模型接入层每次收到第一个数据帧的时间点记录一次first_token_ms。这个指标不仅反映了网络状态，也反映模型服务排队情况。如果它持续偏高，多半是并发配额不够用，而不是模型能力变差了。相比之下，完整生成时长受生成长度影响很大，反而不及 TTFT 有普适性。
7. 实测踩坑与个人体会
最后这部分聊聊我实际接入和使用 DeepSeek 模型服务时遇到的一些问题，没有什么比真实的故障经历更能说明一个架构哪里薄弱。这里列出三类最常见的问题，以及我的处理方式。
7.1 工具调用协议的版本之坑
在对话系统里接入函数调用能力，是最常见的刚需，也是最容易翻车的地方。之前我在一个版本里发现，模型在流式返回中声明要调用工具，但客户端在解析tool_calls时，怎么都拿不到完整的参数 arguments，因为服务端把 arguments 拆成了多个增量片段，客户端需要做增量拼接而非常量替换。这个坑的典型症状是：工具调用的参数偶尔齐全、偶尔丢失后半段、同时完整的 JSON 无法解析。
对策是让解析层在流式结束时判断tool_calls是否完整，如果不完整，要从普通字段里做容错匹配，或者标记为"工具调用不完整"并转交给用户确认。这个问题在接入不同供应商时几乎一定会遇到，因为在“流式工具调用增量表达”这个规范上，各家并没有完全达成一致。
7.2 超时配置与首字漏斗
我接过的很多对话客户端，对"超时"的理解只是"整个请求不报错就行"。实际上，对话系统的超时要分三层配置：连接建立超时（3~5 秒）、首帧数据超时（15~25 秒）、整体生成超时（60~120 秒，视场景而定）。把三个超时混成一锅，会导致一种诡异现象：短问题也经常失败，长问题却一直卡着不报错，用户体感极其割裂。
我用过一个土办法来检测这类问题：写一个后台脚本，每次请求记录连接时间、首帧时间、帧间隔中位数。如果首帧时间正常、帧间隔正常，但整体时间非常长，那就是内容长度限制问题；如果首帧时间就一直飙高，那就是网络/服务端排队问题。脚本跑一周，客户端超时配置的问题基本都能暴露出来。
7.3 流式响应的内存与连接泄漏
还有一个容易被忽略但非常致命的问题：流式响应的连接没有正确关闭。有些客户端因为在解析流程里抛了异常，导致 HTTP 连接没有被释放，短时间里就把服务端的连接数打满。我建议在客户端里强制用上下文管理器来包裹流式请求，并且无论正常结束还是中途异常，都要在finally块中调用关闭动作。另外，上传到堆上的临时事件缓冲区，在一次事件结束后一定要清空，否则内存会随对话轮数线性增长，这种问题大多发生在上线后的第 48 小时，前一两天的观测往往发现不了。
7.4 个人体会
说了这么多技术细节，最后说一点我的真实体会。做 AI 对话系统客户端，最大的敌人不是模型的笨拙，而是工程上的"半吊子状态"——请求发出去没结果、结果断在半截、历史记录对不上、重试把客户拖入黑洞。这些情况只要有一个没处理好，用户对产品的信任就会瞬间归零。
所以我一直坚持一个原则：宁可让架构多一层抽象，也不要把所有流程都堆在一个函数里；宁可让用户体验到一次"明确失败"，也不要让他面对一次"无声卡死"。DeepSeekClient 这种客户端架构，本质上就是把"对话"这种原本感性的事情，用工程手段变得可预期、可度量、可恢复。它不会让模型变得更聪明，但能让每一次模型回应都完整、可靠地抵达用户手中。
如果你也在搭自己的对话客户端，我建议先别急着写业务功能，把会话状态、流式解析、重试策略、日志追踪这四件事想清楚，再往上堆功能。这些基础稳了，后续加什么能力都不慌。
