基于MS Bot Framework实现对话长期历史的方案及DirectLine存储疑问

针对你提到的对话历史实现方案和DirectLine的相关疑问，我结合官方文档和实际开发经验整理了以下内容：

DirectLine核心疑问解答 #

• 对话内容存储时长：DirectLine v3.x 默认会存储对话活动（通过它发送的所有消息、事件等）30天，超过这个期限的历史数据会被自动清理，无法再通过API获取。
• ConversationId过期时间：ConversationId的有效期和对话的活跃状态绑定。如果对话在30天内没有任何新的活动产生，该ID会被标记为过期，之后无法再通过它查询历史；如果对话持续有活动，有效期会自动顺延，只要在活跃状态下就可以正常使用。
• 能否随时获取指定对话内容：在对话的有效期内（即未超过30天无活动，且历史数据未被清理），只要持有有效的DirectLine访问令牌，就可以通过GET https://directline.botframework.com/v3/directline/conversations/{convId}/activities端点获取该对话的全部历史活动。如果历史数据量大，API会返回分页结果，你可以通过continuationToken参数来获取后续页的内容。

两种实现方案对比 #

方案1：使用DirectLine API获取历史 #

• 优势：
  • 零额外开发成本，直接调用官方API即可快速实现历史查询功能
  • 官方维护API的稳定性和安全性，无需自己处理令牌验证、分页等基础逻辑
• 局限性：
  • 存储时长受限，仅支持30天内的历史，无法满足长期存储需求
  • 无法自定义数据存储结构，难以关联业务系统的其他数据
  • 数据依赖DirectLine服务，若服务出现故障或规则调整，可能影响历史查询

方案2：自定义存储至MongoDB #

• 优势：
  • 完全自主控制存储时长，支持长期甚至永久保存对话历史
  • 可根据业务需求自定义存储结构，比如添加用户ID、对话分类、业务元数据等字段，方便后续灵活查询
  • 数据完全由自己掌控，不受DirectLine服务限制，查询逻辑可按需定制（比如按用户、时间范围、关键词筛选）
• 局限性：
  • 需要自行开发活动拦截逻辑（通过Bot Framework中间件捕获所有对话活动）、存储逻辑和查询接口，开发量较大
  • 需要维护MongoDB的部署、备份和运维工作，增加了运维成本
  • 需确保活动捕获的完整性，避免出现数据丢失的情况

方案选择建议 #

如果你的业务仅需要保留短期（30天内）的对话历史，方案1是最省心的选择；如果需要长期存储对话数据、自定义查询规则或关联业务数据，方案2更适合你的需求。

内容的提问来源于stack exchange，提问作者CoL