对话锚（Conversation Anchor）

状态：现在 (Running today)

锚点基础协议、跨界面接入与后期加入恢复管线已在 Runtime 中交付。

ConversationAnchor 是 Runtime 持有的连续性身份。它让一段对话能跨多个面（桌面端聊天、Avatar、网页端）继续下去，又不至于塌成同一个全局会话。

朴素的设计是把「这段对话」按 agent_id 当成一条线程。这样会有两个方向都坏：

对话锚把这两端折中。它的键不是「按 Agent 全局」的，而是 每个 Agent + 每段对话 一把。

用户在桌面端聊天里跟某个 Agent 开始一段对话。Runtime 以 (agent_id, conversation_id) 为键创建一个 ConversationAnchor。后续在桌面端的回合都挂在这个锚上。

之后用户打开 Avatar。Avatar 解析用户的意图：「继续刚才那段对话」。Avatar 按对话 id 查到，复用同一个锚。Agent 在 Avatar 里给出的下一句继续这条线程；Avatar 这一边产生的 memory 写入也归在同一段对话血缘里。

之后又在网页端，用户挑了同一段对话。网页端做同样的锚解析。Agent 在网页端的回应继续同一条线程。

整个过程中，对话从来不会塌成「与该 Agent 的全局会话」。如果用户想跟同一个 Agent 另开一段对话，那就是另一把锚，两段对话不合并。

锚是连续性身份，不是对话内容。内容在 Realm 聊天里。锚让多个面在一条 Runtime 持有的线程下参与同一段对话。

锚的职责	归属
「这段对话」的身份	Runtime（锚）
消息线程	Realm 聊天
对话作用域内的 memory 写入	Cognition memory + Runtime memory bank
实体化面的呈现流	Runtime presentation stream

锚本身有意做窄。它只是让多个面在「这段对话是哪一段」上达成一致；它不是聊天线程本身，不是 memory，不是呈现。

某用户早上在桌面端跟自己的 Agent 聊起来。中午打开 Avatar，Agent 这时在屏幕上有了形象。晚上在手机的网页端打开。

整整一天，三块面共享同一段与该 Agent 的对话。

桌面端聊天打开对话时，锚被创建。
Avatar 解析同一组 (agent_id, conversation_id)，复用同一把锚。Agent 在 Avatar 里的声音和形象反映正在进行的回合状态。一个从桌面端开始的回合可以接着流入 Avatar。
网页端按对话 id 打开。同一把锚。用户能滚回早上的消息，因为它们都在 Realm 聊天里、同一条线程下。

从用户的角度看，三块面上是同一个 Agent 在说同一件事。从平台的角度看，Runtime 持有锚，Realm 持有聊天线程，Avatar 持有具身呈现，各管各的。

某用户的某个 Agent 是项目助手。今天他要分两件事：一段是写代码，一段是购物清单。两段他想分开。

如果没有这种「按对话」的锚，一个用户对一个 Agent 就只剩一段大对话。锚模型才让「跟同一个 Agent 开多段对话」成为一个真实的能力。

用户在 Avatar 里聊着，Avatar 突然崩了。这段对话不应丢失。

锚归在 Runtime 里，是面崩了对话还能续上的根据。