Session Stitching：为什么你的会话 ID 是个谎言
· 阅读需 12 分钟
一名用户在上午 9 点开始在她的电脑上与你的智能体谈判合同。她收到一条 Slack 消息，在午休时间切换到手机问了一个澄清问题，并在下午 4 点重新打开电脑标签页来修改草案。对她来说，这是一项任务 —— 处理一份合同的三个小时工作。对你的系统来说，这是两个设备上的三个会话，每个都有自己的 conversation-id，每个都有自己的记忆窗口，每个都呈现全新的问候并要求她重新粘贴已经讨论过两次的草案。
Bug 不在模型中。Bug 在于你的平台将“会话 (session)” —— 一个关于单一连接的传输层产物 —— 编码为上下文单位，而你的用户将“任务 (task)” —— 即合同 —— 编码为上下文单位。市面上的每个框架都悄悄地混淆了这两者，而它们之间的差距正是智能体 UX 损耗了一半的地方。
