作者 / 来源: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 持有MapsessionKey, 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