1.1 无状态 HTTP 调用让“记忆”变成重复计费Grok Bot 底层的模型接口通常是无状态的。服务端不保存上一次调用时聊了什么每次请求都需要调用方把上下文完整带过去模型才能接着聊。于是常见的 Bot 实现就变成了这样messages [] while True: user_input input(你) messages.append({role: user, content: user_input}) resp client.chat.completions.create( modelMODEL_NAME, messagesmessages, ) reply resp.choices[0].message.content messages.append({role: assistant, content: reply}) print(Bot, reply)这段逻辑非常直观messages数组放在内存里每一轮都往里面追加消息然后原封不动发给模型。问题在于模型每次定价都按“输入的 token 数 输出的 token 数”计算messages越长输入计费越高。假设第一轮消息体是 300 token每轮用户和助手消息加起来大约 500 token那么第 10 轮请求可能已经带了几千 token 的历史。第 30 轮请求可能带上万 token 的历史。第 50 轮请求的输入长度会明显影响延迟和费用。这就是无状态调用的代价应用层用内存保存的“记忆”本质上是在每次请求时重新购买一遍相同内容。真正新产生的只有最后一条用户输入前面几十轮背景都被重复计费了。1.2 durable state 在对话机器人里的准确含义durable state直译是“持久化状态”。它和程序运行时的内存变量不同具有两个关键特征可以跨请求存活数据写入数据库、Redis、文件或任何外部存储进程重启后仍然存在。可以被多个请求读取和更新不同请求之间可以共享同一份状态而不是每次从零开始。在 Grok Bot 场景里durable state 通常包括三类内容会话状态当前会话的摘要、最近几条消息、用户偏好、上下文标签。幂等状态某个请求是否已经处理过、处理结果是什么避免重试时重复调用模型。缓存状态与上下文无关或极少变化的问答结果可以直接复用不用再花 token。需要强调一点持久化状态并不是让模型“变聪明”而是让应用层减少无效输入。模型仍然是每次独立计算的只是我们把该传的历史从“全部消息”压缩成“摘要加少量最近消息”把不必计算的请求从“每次都调模型”改成“先查状态”。1.3 引入持久化状态后消耗从四个环节降下来梳理一下无状态实现里钱花在哪里完整历史被反复发送输入 token 随轮次非线性增长。相同问题每次重新调用模型产生了可消除的重复计算。客户端超时重试时没有幂等机制同一请求被模型执行两次。大量上下文无关的指令、系统设定、FAQ 被当成历史打包发送。引入 durable state 后对应的优化路径是用会话摘要代替完整历史把输入长度控制在稳定区间。用结果缓存取代重复调用命中缓存时零费用。用请求幂等表承接重试已经成功的请求直接返回结果。用持久化的用户状态动态拼装 system 消息避免每条消息都夹带固定背景。这四条路径不是互相独立的通常组合使用。下面先盘清楚消耗来源再设计状态结构。2. 先盘清楚消耗都花在哪些环节再决定持久化什么状态2.1 消耗来源一每条请求都携带完整历史输入 token 呈二次增长如果每一轮都发送完整消息列表可以估算整体消耗的增长趋势。假设固定系统提示词为 C token每轮对话平均新增 K token那么第 n 轮请求的输入长度大约是C K * (n - 1)总消耗是每一轮调用的累加总输入 ≈ Σ [C K * (i - 1)]i 从 1 到 n ≈ n * C K * n * (n - 1) / 2也就是说输入 token 的总消耗不是随 n 线性增长而是接近 n 的平方增长。对话越到后面每轮请求的开销越明显。这不是一个理论推演。在一个真实的长会话场景里用户问了 50 个问题如果每轮都给模型补全 49 条历史后 20 轮请求的大部分 token 都在重复传输。持久化状态要做的事情就是打断这个增长曲线只保留摘要和最近消息让后续每轮输入稳定在设定的阈值附近。2.2 消耗来源二固定问答和规则型问题被当成模型计算任务Bot 并不一定只处理开放式对话。实际项目里会有大量重复问题例如产品价格、营业时间、客服电话。设备状态的快速查询。用户反复询问同一个操作步骤。这类问题的答案往往和上下文无关或者只依赖极少量用户参数。如果每个问题都调用 Grok 模型等于用昂贵的模型做一件规则引擎或缓存就能完成的事。更隐蔽的是很多开发者在 system 消息里塞了大量静态说明例如“你是某某客服机器人”“请使用礼貌语气”“你的知识截止到……”等。这些内容每轮都在重复计费。正确做法是把它持久化为配置文件或用户状态在真正需要时才参与消息构造而不是每条请求都完整携带。2.3 消耗来源三失败重试导致同一请求被执行多次HTTP 请求失败、超时、网络抖动时常见的处理方式是重试。但 LLM 接口的重试和普通接口不同第一次调用可能在服务端已经成功了只是响应没回到客户端如果客户端不携带任何幂等标识就重试同一段上下文会被模型处理两次账单也会产生两次费用。这类消耗在低并发场景下容易忽略但一旦 Bot 开始面向真实流量超时和限流出现频率上升重试成本就会明显放大。持久化状态中的 request_id 和 pending_result 就是为了解决这个问题。2.4 状态分层会话级、用户级、全局缓存要设计 durable state先要区分状态的作用范围。不同范围的状态生命周期、访问频率和安全性完全不同。状态类型示例生命周期存储建议会话级当前对话历史、摘要、最近消息从会话创建到关闭或过期Redis、SQLite、Postgres用户级用户偏好、语言、昵称、上下文标签用户生命周期持久化数据库可加密全局缓存FAQ、固定问答、公共知识按 TTL 或内容更新时间Redis、内存缓存、本地表幂等状态request_id、请求结果、创建时间请求完成后保留一段时间数据库表带过期时间分层的意义在于不要把所有状态塞进一个 JSON 字段。会话级状态需要高频读写全局缓存需要快速过期用户级状态需要备份和审计。它们的持久化策略、并发模型和清理策略都不一样。3. 设计状态存储选型、表结构和数据结构3.1 环境准备与依赖下面代码用 Python 演示思路实际项目可以换成 Java、Node.js 等语言。只需要保证状态存储具备“跨请求读取和写入”的能力即可。准备一个虚拟环境python -m venv venv source venv/bin/activate pip install openai redis如果只是单机学习项目SQLite 是标准库自带能力不需要额外安装import sqlite3如果将来要部署多个实例建议使用 Redispip install redis依赖版本建议锁定openai1.30.0、redis5.0.0。安装完成后先确认 Python 版本在 3.10 以上下面代码使用了类型注解和 dataclass 等特性。3.2 状态存储选型SQLite、Redis、内存状态存储没有绝对最优需要根据并发量、部署方式和运维能力选择。存储方案优势劣势适用场景SQLite零运维、文件级持久化、标准库支持单实例写入、并发能力有限学习项目、单机 Bot、内部工具Redis读写快、支持 TTL、并发能力强需要额外部署内存占用高多实例服务、高频缓存Postgres/MySQL事务能力强、适合复杂查询运维成本高用户体系复杂、需要审计内存字典实现最简单重启丢失、多实例不一致临时验证不作为正式方案从“减少 Grok Bot consumption”这个目标出发存储本身的成本也要考虑。单机小规模项目用 SQLite 完全够用既不需要额外服务又能保证进程重启后状态还在。等需要横向扩容时再迁移到 Redis。3.3 核心状态数据结构一个合理的对话状态不是简单存一份 JSON而应该包含摘要、最近消息、元数据和过期时间。下面是用 SQLite 建表的示例CREATE TABLE IF NOT EXISTS conversation_state ( conversation_id TEXT PRIMARY KEY, user_id TEXT NOT NULL, summary TEXT, recent_messages TEXT, metadata TEXT, version INTEGER DEFAULT 1, updated_at