上一篇用杭州旅游攻略举例，讲了怎么用实体和主题缩小检索范围。这次还是做我们自己的个人 AI 助手，把时间拨回第一次对话结束的时候。助手已经发出一份攻略，用户紧接着改了坐船时间。几天后他说「上次那份再给我一下」，我们要找的是哪条回复？ 上一篇 Memory 系统如何从 0 到 1 构建
| 轮次 | 用户 | 助手 |
|---|---|---|
| ① | 帮我做个杭州两日游攻略。这次带爸妈，别安排太多走路。 | 第一天去西湖，下午坐船。第二天去灵隐寺，午饭后回酒店休息。 |
| ② | 西湖坐船放上午吧。 | 第一天去西湖，上午坐船，下午在附近休息。第二天去灵隐寺，午饭后回酒店休息。 |
| ③ | 对了，上海虹桥到机场怎么走？ | 你要去虹桥机场还是浦东机场？ |
下面的表名、字段和 ID 都是为这套个人 AI 系统设计的示例。我们先把这三轮的原文存好，再看后台能从中提取出什么。
先存原文，再判断在哪里切开
Runtime 在回复完成后，把消息和一条待处理任务写进 MySQL。同一个会话里的两份攻略分别是 (s17, a42, 1) 和 (s17, a44, 1)，依次是 session_id、msg_id、version。第二轮是新的追问，所以有新的 msg_id。如果用户在同一条回复上点重新生成，才复用 msg_id，把 version 往上加。
后台 Worker 领取任务，按会话读取上次切分游标之后的问答。先按授权过滤可用于记忆构建的消息，再组装按时间排列的 QA。每对 QA 带它最后一条消息的时间和序号。我们可以给模型一小段规则，让它判断前面的事有没有聊完，并从输入里选出旧话题最后一对 QA。杭州这组问答的示例输出如下。
{
"should_split": true,
"end_turn": 2,
"title": "带爸妈去杭州两日游"
}
Worker 核对 end_turn 对应输入里的一轮，保存第①到第②轮的范围和标题，同时在同一事务里推进游标、登记抽取任务。第③轮留在下一次处理窗口。要是第 ③ 轮问的是「西湖船票在哪买」，可以返回 should_split=false，游标留在原位。用户要是聊完杭州就关了页面，我们还可以给连续未更新的会话设一个收尾任务，让最后一段也有机会入库。
这里的标题方便人看。上一篇定义的 TRAVEL_GUIDE 可以由许多条攻略共用，留给我们在检索时缩小范围。两者各有自己的字段。
给这次杭州行程留一条情景记忆
切分模型只回答「这件事聊到了哪一轮」。抽取模型接到的才是第 ① 和第 ② 轮的原文。Worker 根据分段 seg17 读消息，先过滤没有获准进入记忆的内容，再组装下面这份输入。每条消息都带编号和版本，上海那一轮根本不在这份输入里。
{
"segment_id": "seg17",
"messages": [
{"msg_id": "u41", "version": 1, "role": "user", "text": "帮我做个杭州两日游攻略。这次带爸妈，别安排太多走路。"},
{"msg_id": "a42", "version": 1, "role": "assistant", "text": "第一天去西湖，下午坐船。第二天去灵隐寺，午饭后回酒店休息。"},
{"msg_id": "u43", "version": 1, "role": "user", "text": "西湖坐船放上午吧。"},
{"msg_id": "a44", "version": 1, "role": "assistant", "text": "第一天去西湖，上午坐船，下午在附近休息。第二天去灵隐寺，午饭后回酒店休息。"}
]
}
给模型的指令也可以很短。只抽取这一段里有证据、下次可能用得上的事。前后有修改时，摘要保留用户最后确认的要求。每条候选都要指出依据了哪些用户消息。如果这段里有一份落实修改后的完整回复，可以再引用那条助手消息。只有一句「好，我改到上午」就不填这个引用，证据不足时可以不产出候选。
这次模型可以输出下面这条候选。这里的 JSON 是接口示意。
{
"kind": "EPISODIC",
"title": "带爸妈去杭州两日游",
"summary": "用户计划带爸妈去杭州两日游，希望少走路，西湖坐船改到上午。",
"entity_mentions": [{"text": "杭州", "type": "PLACE"}],
"topic_hint": "旅游攻略",
"source_refs": [{"msg_id": "u41", "version": 1}, {"msg_id": "u43", "version": 1}],
"answer_candidate_ref": {"msg_id": "a44", "version": 1}
}
u41 支撑「带爸妈」「少走路」，u43 支撑「船放上午」。a44 的用途是找回当时给出的完整攻略。这里「少走路」只挂在这次行程下，不会上升成用户以后每次出游的偏好。
Worker 先校验输出结构，再用本次输入的消息清单核对每个引用的角色和版本。如果候选引用了一条不在清单里的消息，这条候选就不能直接入库。接着用上一篇的字典把「杭州」查成 10086，把「旅游攻略」查成 TRAVEL_GUIDE。没把握的 ID 留空，后面仍然可以用摘要做语义召回。最后由服务分配 memory_id=m17，从已校验的分段拿到 user_id 和 session_id，用杭州段最后一条消息 a44 的时间填 occurred_at。重跑任务的时间不参与这次行程的排序。
MySQL 存原文和正式记忆，向量库接上
MySQL 这边先做四张表。为了把流程讲清楚，memory只保存每条记忆的当前版本。原始消息按版本保留，才能准确回读某一版回复。
| 表 | 主键与主要字段 | 杭州这条怎么填 |
|---|---|---|
chat_message | 主键 (session_id, msg_id, version)，另存 user_id、turn_no、role、content、created_at、visible_state | (s17, a44, 1) 属于第 ② 轮，content 是上午坐船的完整攻略 |
conversation_segment | 主键 segment_id，另存 user_id、session_id、start_turn、end_turn、end_at | seg17 属于 s17，覆盖第 ① 到第 ② 轮 |
memory | 主键 memory_id，另存 user_id、version、segment_id、kind、entity_id、topic_id、occurred_at、title、summary、source_refs、answer_ref、status | m17 的 version=1，证据指向 u41 和 u43，完整回复指向 (s17, a44, 1) |
memory_index_job | 主键 (memory_id, memory_version, embedding_version)，另存 status、attempts、next_retry_at | (m17, 1, emb_v1) 等待后台写入向量库 |
memory.version 标记摘要和引用这一套记录的版本。answer_ref.version 标记原消息的版本。举个例子，我们发现摘要漏了「少走路」，可以把 Memory 升到第 2 版，answer_ref 仍然指向原来的 (s17, a44, 1)。
写入 memory 时，在同一个 MySQL 事务里登记索引任务。这版每段每种类型只产出一条记忆，可以用 (segment_id, kind) 做唯一键。初次抽取重试时复用已有的 Memory，这样同一个杭州段不会凭空变成两次旅行。建索引的 Worker 先确认任务的 memory_version 还是当前版本，再取 title + summary 生成 embedding。这条向量的输入就是「带爸妈去杭州两日游。用户计划带爸妈去杭州两日游，希望少走路，西湖坐船改到上午。」向量库只需要这一行。
| 向量库字段 | m17 对应值 | 用途 |
|---|---|---|
vector_id | m17:1:emb_v1 | 同一任务重试时覆盖同一个键 |
embedding | title + summary 生成的浮点数组 | 和查询向量算相似度 |
user_id | user_7 | 召回前限定当前用户 |
memory_id、memory_version | m17、1 | 批量回查 MySQL 并排除过期向量 |
embedding_version | emb_v1 | 查询和入库使用同一版 embedding 配置 |
向量命中后先回 MySQL，answer_ref 和攻略正文都留在那里。即使建索引任务失败，按实体和主题的 SQL 查询还是能找到 m17。只走语义检索时，如果索引还有积压，未命中只代表这次没从已建索引里搜到，不能断言用户从没聊过。旧向量也可以异步清理，查询时先通过 MySQL 排除已删除的记录和已过期的版本。
几天后找回改到上午的版本
能拿到两个 ID，先走 MySQL
用户在新会话里问「上次聊的杭州游玩攻略再给我一下」。Runtime 把整句话交给 memory_recall。查询归属从已验证的登录身份拿，提问时间取服务收到这轮消息的时间。解析器负责标出地点、主题、时间意图和返回方式，真实的归属、ID 和时间边界由服务补齐。
比如「杭州」和「游玩攻略」分别命中字典里的别名(上篇讲了)。经过授权和归一化后，服务内部拿到的是下面这份查询计划。
{
"user_id": "user_7",
"entity_id": 10086,
"topic_id": "TRAVEL_GUIDE",
"time_intent": "PREVIOUS_RELATED",
"before": "2026-11-05T09:00:00+08:00",
"delivery_mode": "ORIGINAL"
}
服务把「上次」转成 occurred_at < before，再按 occurred_at 倒序，把最近的一次放前面。这次没有「带爸妈那份」之类的附加条件，所以「属于该用户、同一实体和主题、发生在提问之前」已经足够限定候选。我们可以这样查。
SELECT memory_id, version, occurred_at, summary, answer_ref
FROM memory
WHERE user_id = :authenticated_user_id
AND entity_id = 10086
AND topic_id = 'TRAVEL_GUIDE'
AND status = 'ACTIVE'
AND occurred_at < :before
ORDER BY occurred_at DESC, memory_id DESC
LIMIT 5;
只是这次的候选上限，排序靠的是那次对话结束的时间，memory_id 只用来稳定处理同一时间的记录。如果用户特意说「上次带爸妈那份」，还要判断候选是否满足「带爸妈」，不能把 SQL 的第一条直接当答案。
ID 没解析全，再用向量找候选
如果用户只说「之前排的那个两日游」，我们就没有可靠的地点 ID。服务可以用「两日游行程」生成查询向量，把「之前」单独留给时间过滤。即使两个 ID 都拿到了，SQL 查不到时也可以补一次向量检索，因为老记录可能缺少结构化标签。向量库可以像 Milvus 的过滤搜索 那样，先按当前用户和 embedding_version 限定搜索范围，再取一批语义相近的 (memory_id, memory_version, score)。如果已经确认用户问的是杭州，就保留这个条件，回查 MySQL 时排除有明确地点却和杭州冲突的结果。
接下来用 user_id 和候选 ID 批量查回 MySQL。先滤掉不可见、已删除、版本对不上或发生在提问时及之后的记录。再看摘要能不能回答用户要找的事。比如问的是游玩攻略，只有住宿订单就淘汰。词面判断不够时，可以把少量候选的标题、摘要和原问题交给重排模型，只让它判断是否相关。举个例子，如果「游玩攻略」的别名还没配好，语义召回后可能看到下面三条。相似度仅用于示意。
| 候选 | 对话时间 | 向量相似度 | 如何处理 |
|---|---|---|---|
m12 · 杭州两日游攻略 | 10 月 28 日 | 0.93 | 相关，先保留 |
m17 · 带爸妈去杭州两日游 | 11 月 1 日 | 0.86 | 相关，比 m12 更新 |
m21 · 杭州酒店预订 | 11 月 3 日 | 0.79 | 更晚，但不符合找攻略的目的 |
m12 的向量分数更高，最终还是选 m17。分数帮我们找候选，该选哪次看的是相关记录的对话时间。相关性门槛要用我们自己的历史问法和误召回样例来定，表里的 0.86 不能拿来当通用阈值。如果只说「那个两日游」，又搜到了杭州和苏州两份都说得通的行程，就先问用户指的是哪个城市。向量 Top K 也可能漏掉更新的那次，所以只走这条路径时，「最近」是指通过校验的候选里最近的一条。
找到的是 m17，发回的是 a44
如果用户想接着聊，Runtime 可以把 m17.summary 放进 Prompt。如果要原样重发，服务就用 answer_ref 验证原会话的访问权限和这版消息的可见状态，再按 (s17, a44, 1) 读 chat_message.content，直接交给界面展示。这样拿到的是改完的上午船班安排，连摘要省略的「午饭后回酒店休息」也能一起回来。找到了 Memory 但原文不可见时，可以返回 SOURCE_UNAVAILABLE。只有摘要仍然获准使用时，界面才可以另外展示摘要。
下面这张图对应本文的用户 memory 系统设计。
