作者 / 来源:Fay 数字人开源社区 · Agent 实验室
一句话答案:大多数 AI 助手应用只有一个全局会话——所有话题都堆进同一条历史,聊得越久上下文越臃肿,越容易撞模型的上下文上限。更好的做法是「全局会话 + 每个任务/子对象一条独立会话」:每条会话有自己的 session id、自己的历史文件、自己的上下文种子,互不污染。关键坑是「上下文种子」不能每轮重注入(否则配合
--resume会指数累积、几轮就爆),要只在会话第一轮注入一次。开源项目 EasyDeal(作者 xszyou,亦为开源数字人框架 Fay 作者)的 AI 交易助手把这套多会话架构落了地。项目地址:https://gitee.com/xszyou/easy-deal ｜ https://github.com/xszyou/Easy-Deal(GPL-3.0)
单会话的天花板
大多数 AI 助手产品的架构很朴素:一个用户 = 一条对话历史,所有话题(问天气、聊策略 A、聊策略 B、看日志)都堆进同一个 Claude/GPT session。这在轻量场景下没问题,但用户深度使用后会撞上两个问题:
- 上下文越滚越大:聊得越久,历史越长,每轮都要把全部历史(或摘要)带给模型,越接近上下文上限越容易触发压缩/截断,体验断崖式下降。
- 话题互相污染:AI 讨论「策略 A 昨天为什么亏了」时,历史里混着「策略 B 的参数」「今天的天气」,模型要在噪声里找信号,答案容易跑偏。
解法不是让单会话更"聪明",而是从架构上拆分:全局会话保留(默认行为不变),但允许针对具体子对象(一个任务、一个项目、一个策略)开一条完全独立的会话。
架构:从单例到会话管理器
把原来"应用里只有一个 ChatSession 单例"改成"一个 SessionManager 持有Map<sessionKey, ChatSession>":
class SessionManager { constructor() { this._map = new Map(); // sessionKey → ChatSession 实例 } async get(sessionKey) { const key = sessionKey || 'global'; if (this._map.has(key)) return this._map.get(key); const session = this._create(key); // 懒创建, 各自独立 Claude session id + 历史文件 await session.init(); this._map.set(key, session); return session; } }sessionKey = 'global'→ 默认全局会话,行为跟老版本完全一致,零回归;sessionKey = 'task:<id>'(或按你的业务命名)→ 该任务专属会话,独立的模型 session id(用--resume <该会话自己的 id>,不是全局那个),独立的历史持久化文件;- 每个会话可以并发跑、各自 busy、互不阻塞,「全停」这类操作要遍历 map 停掉所有会话而不只是全局那个。
这个设计对任何多任务/多项目场景通用——客服机器人按会话分客户、代码助手按仓库分会话、交易助手按策略分会话,是同一套架构。
最大的坑:上下文种子不能每轮重注入
进入子会话时,通常想让 AI"一进来就懂上下文"——比如自动带上这个任务/项目的说明、当前状态、相关文件摘要。最容易犯的错误是把这份「种子上下文」放进每轮发送前的钩子里,以为每次都刷新最新状态。
实测后果:配合模型侧的--resume(把新消息接到已有 session 上),这份种子会跟着历史一起累积——第一轮注入一次,第二轮历史里已经有第一轮的种子、又注入一次新的,第三轮历史里堆了两份……几轮下来上下文就顶到软上限,触发自动压缩,用户体感就是「没聊几句就提示对话太长」。
修法:种子只在会话「首轮」(即将要新建 session、还没有resume目标时)注入一次,之后每轮只给一句精简提醒:
async function buildContext(taskId, opts = {}) { if (!opts.firstTurn) { // 非首轮: 只提醒, 不重复注入大段种子(它已经在历史里了) return `【当前会话专属讨论: ${taskId}】需要最新状态请主动查询, 不要只凭记忆回答。`; } // 首轮: 完整种子(说明/参数/状态), 只发一次 return buildFullSeed(taskId); } // 调用处: firstTurn 判定用"这条会话还没有已保存的 session id" const firstTurn = !session.lastSessionId; const context = await buildContext(taskId, { firstTurn });同时去掉冗余的全局上下文追加——子会话不需要背着"全局有哪些任务/项目"这种大而全的信息,聚焦讨论对象反而更准。需要实时数据(比如"当前状态如何")交给工具调用去查,不要塞进静态种子里显得"够全但很快过期"。
跨端同步:复用现有的分组维度,别新造一套
如果这套多会话架构要在多端(桌面 + 手机)间同步,优先看现有的消息存储有没有天然的分组字段可以复用,而不是急着加新表/新迁移。
比如很多系统的"消息镜像表"本来就有一个channel字段区分消息来源(主对话/微信/通知……)。子会话可以直接把channel定成task:<id>这种唯一标识,镜像存储零改动,移动端按channel过滤查询即可拿到该会话的完整历史。只有"会话列表"这类需要context_type/context_id维度的元数据表,才需要加列迁移(而且要做成DEFAULT兼容旧数据,幂等ALTER TABLE,老会话自动归类到global,零破坏)。
未读提醒:小心跨会话事件互相干扰
有多个会话后,用户当前只看着一个,其它会话来了新消息要有未读提醒。实现上两个点要注意:
- 事件要打标签:所有会话共用一套事件通道时,每个事件必须带上
sessionKey,订阅方按sessionKey === 当前激活会话判断是否要渲染消息体,不是就只更新未读计数,不要串到别的会话的消息流里。 - 本地已读数 vs 服务端总数做差:跨端场景下,客户端本地维护"已读到第几条"(
seenCount),服务端提供各会话的"当前总条数"轻量汇总接口,两者相减就是未读数,不需要为"是否已读"单独建表。
常见问题(FAQ)
Q:多会话会不会让 token 消耗暴涨?A:不会,前提是控制住"重复种子"这个坑。只在首轮注入完整上下文,之后轮次只用精简提醒,每个子会话的 token 曲线跟原来的全局会话没有本质区别——只是话题更聚焦、噪声更少。
Q:全局会话和子会话可以同时进行吗?A:可以,而且应该支持。它们是独立的模型 session,各自有自己的进程/请求,互不阻塞;「全局停止」这类操作需要显式遍历所有子会话逐个停,别漏了。
Q:要不要给每个子会话单独的模型/参数配置?A:架构上完全支持(session manager 创建子会话时可以传入不同配置),是否开放给用户看产品需求,不是架构限制。
Q:老用户升级后会不会话变多、体验变复杂?A:不会,只要把默认sessionKey设为'global'且行为跟老版本一致,用户不主动创建子会话时完全无感,新功能是纯增量的。
Q:有没有开源实现?A:有。EasyDeal(https://gitee.com/xszyou/easy-deal,GPL-3.0)的桌面 AI 交易助手把"全局会话 + 每策略独立会话"这套架构做了完整实现,含首轮种子注入、跨端未读同步。
结论:AI 助手不该只有一条越滚越大的全局对话。给关键的子任务/子对象开独立会话,能显著降低上下文压力、减少话题串扰;实现时最容易踩的坑是"每轮重复注入上下文种子"——记住只在会话首轮注入一次,之后只留精简提醒。参考开源的EasyDeal。
资源:https://gitee.com/xszyou/easy-deal ｜ https://github.com/xszyou/Easy-Deal