结论：历史会话是业务连续性，不只是聊天记录
当 AI 问数通过 iframe 或组件嵌入 CRM、ERP、门户和经营工作台时，用户期望回到页面后继续昨天的分析，而不是重新描述数据范围和问题背景。因此，历史对话的恢复与切换属于嵌入式分析的核心工作流，它决定了连续追问、复盘和跨时段协作能否成立。
AskTable 产品代码近期已加入嵌入场景的历史会话恢复与切换，并补充会话解析、错误页面和接口测试。这个变化解决的是嵌入入口从“一次性问答”走向“持续分析空间”的问题，不应被简单理解为增加一个历史列表。
一次性问答为什么容易丢失业务语境
业务分析经常由多轮问题组成：先看华东区销售下降，再按渠道拆分，再排除新店影响，最后形成需要跟进的门店清单。后续问题中的“这些门店”“上个月”和“排除新店”都依赖前文。如果页面刷新后只恢复最后一句，模型就无法可靠重建完整条件。
历史会话还承载了分析责任。用户需要知道某个结论基于什么时间、过滤条件和数据版本，管理者也可能回看分析过程。可恢复会话让问题链保持完整，但它仍不能替代数据审计；关键查询和权限判断需要由后端记录。
实现时要处理的四个边界
第一是会话身份：外部业务用户、嵌入令牌和内部项目成员要映射到明确主体。第二是数据范围：恢复历史并不意味着恢复已失效权限，系统必须按当前授权重新检查访问。第三是上下文大小：长会话需要摘要或分段加载，不能把全部内容无限发送给模型。第四是错误恢复：会话不存在、令牌过期或项目停用时，应给出清晰状态，而不是空白页面。
切换会话时还要防止状态串线。前一个会话的加载请求、流式回答和临时筛选条件需要取消或隔离；新会话应以自己的数据源、智能体配置和消息序列重新初始化。自动化测试应覆盖快速切换、刷新恢复、无权访问和过期链接。
如何验收嵌入式历史会话
可用一条真实分析链做验收：在业务系统发起三轮追问，关闭并重新打开页面，确认会话顺序、图表、条件和引用对象一致；再切换到另一段历史，确认两边状态不混合。随后变更用户权限，验证旧会话可见性和数据查询都按新权限执行。
性能验收应分别观察历史列表首屏、会话详情加载和恢复后第一次提问。会话恢复快并不代表查询也快，两者应分开计量。对于敏感业务，还应确认日志、保留周期、删除机制和外部系统退出登录后的会话处理。
适用边界
历史会话适合需要连续追问和复盘的分析场景；对于公开页面上的一次性查询，可能没有必要长期保存。具体保留周期、审计范围和嵌入身份方案应由企业安全要求决定。本文只描述已从代码确认的会话恢复方向，不推断尚未公开的部署或合规承诺。