最近做的企微二开里有个合规需求所有客户会话要自动归档按合规要求留存 N 年且能按客户、按时间、按内容检索。和之前聊的消息中枢不同消息中枢是支撑 AI 的实时消息层归档是合规留存的冷数据层。把落地方案记下来。底层用的是Eyun 平台开放的企微 API承接消息收发本文重点不在调接口在会话怎么自动归档和检索。归档不是备份最早理解偏了以为归档就是定时把消息表备份一份。做完发现归档和备份是两回事备份是灾备归档是合规和可查备份是整库拷贝归档是按会话维度结构化备份恢复整库归档要按客户/时间/内容精准检索备份短期归档长期几年归档的核心不是存是存完能查。按客户查某段时间的沟通按内容查某个关键词出现在哪些会话——这才是归档的价值。归档触发归档不是无脑全量要有触发时机会话结束触发客户咨询结束、工单关闭超时触发会话超过 N 天无消息定时触发每天凌晨归档前一天的所有会话手动触发运营标记某会话需归档archive_trigger 表: trigger_type session_close # 触发类型 condition session.status closed archive_template standard # 归档模板 retention_days 1825 # 留存5年 enabled true触发后把会话从热数据搬到归档库热库保持小而快。关于消息接收和会话管理接口可以看Eyun 开发文档。归档结构归档不是把消息表整体搬是按会话维度结构化会话元数据会话 ID、客户、员工、开始/结束时间、会话类型消息列表按时间排序的所有消息关键事件会话中的关键节点投诉、成交、转接摘要AI 生成的会话摘要标签会话的业务标签售后/咨询/投诉archive_session 表: session_id customer_uin staff_uin start_time end_time message_count summary AI生成的会话摘要 tags [售后, 退款] archive_time retention_until storage_path 归档存储路径摘要和标签是归档时 AI 生成的让后续检索不用翻全文也能知道会话大概聊了什么。归档存储冷热分离归档数据量大存储要分级热归档0-3 个月SSD支持快速检索温归档3-12 个月HDD按需检索冷归档1 年以上对象存储低成本长期留存冷热分离让存储成本可控。全 SSD 留 5 年成本爆炸全冷存储想查上个月的会话要等半天。归档检索检索是归档的核心价值按客户查某客户的所有历史会话按时间查某段时间的所有会话按内容查包含某关键词的会话按员工查某员工处理过的会话按标签查某类业务的所有会话按内容查最复杂——5 年的会话数据量巨大全文检索要靠搜索引擎如 Elasticsearch建索引。不建索引查一个关键词要扫全库等死。关于消息数据存储和检索接口可以在Eyun 企业微信 API 平台开通后验证。归档恢复会话续接有时需要接上某个归档的会话——客户回来找之前的客服要能看到之前的上下文客户消息进来 → 查归档库有没有这个客户的历史会话有拉最近一次会话摘要和关键消息作为新会话上下文没有新建会话归档恢复让客户体验连续——上次那个问题机器人能知道是哪个问题不用客户重述。不接归档每次客户来都是新会话体验断裂。合规留存归档要满足合规要求留存期限按行业金融 5 年、医疗 3 年等不可篡改归档后只读不能修改访问审计谁查了归档要留痕数据脱敏敏感信息按权限可见这几条不做严合规检查通不过。特别是不可篡改——归档后要有校验机制证明数据没被改过。我们用哈希链做校验每条消息带上一条的哈希改一条全链对不上。写在最后会话归档这套东西难点不在存数据在归档触发、结构化、冷热分离、检索、会话续接、合规留存这些工程细节。每一项都不深奥但少做一项归档就不可用或不合规。这套搭扎实企业会话真正能长期留存、精准检索、合规可查——而不是堆在数据库里没人敢动。