用户先在网页问账单，随后到社区补一句“还是不行”。如果只按昵称拼接会话，Agent可能接错人；如果把原对话原封不动贴过去，又可能把订单信息带进公共频道。所谓跨渠道接续，首先是身份与可见范围的交接。
我会让系统交接一张经过裁剪的工单卡，而不是无限增长的聊天记录。原消息仍留在原渠道，卡片只提供下一步需要的事实和出处。
会话不是身份凭据
社区昵称、头像和邮箱显示名都不适合作为跨系统唯一身份。关联操作需要用户在已经验证的会话中主动完成，并保留撤销入口。服务端据此建立内部映射，而不是让模型推测两个人是否相同。
MCP工具规范可以约定工具输入输出，但跨渠道的可见范围属于应用政策。不能因为某个工具查得到消息，就默认当前频道可以展示它。
图里的公共卡片没有账单和联系方式。内图的丢弃符号仅表示字段不进入交接卡，不代表删除原始消息。若需要继续讨论敏感内容，卡片应提供回到私有会话的入口，而不是在公共频道补全原文。
用白名单生成公开摘要
下面是人工构造的工单，不调用Slack、Discord或模型。它验证公开对象只含允许字段，排除隐式扩散。
const assert = require('node:assert/strict'); function publicHandoff(ticket) { if (ticket.visibility !== 'shareable' || !ticket.id) throw new Error('not shareable'); return { id: ticket.id, topic: ticket.topic, nextStep: ticket.nextStep, status: ticket.status }; } const source = { id: 'T-demo', visibility: 'shareable', topic: 'login', nextStep: 'continue in private support', status: 'waiting', email: 'demo@example.com', invoice: 'private' }; const card = publicHandoff(source); assert.equal('email' in card, false); assert.equal('invoice' in card, false); assert.throws(() => publicHandoff({ ...source, visibility: 'private' })); console.log('handoff: 3 assertions passed');保存为handoff.cjs，运行node handoff.cjs。白名单不意味着字段内容天然安全：topic和nextStep仍要防止混入隐私，真实系统需要字段约束、人工预览与审计。这里没有实现文本脱敏，也没有证明渠道集成成功。
交接后谁负责继续？
卡片要有接手状态和更新时间，但不必自动发送一串通知。用户应看得出当前由谁处理、还缺什么材料；维护者也要能区分“已交接”和“已解决”。
并发消息需要版本条件：卡片基于版本4生成，版本5已补充新事实时，旧摘要不能覆盖新状态。编辑失败应保留原卡并提示刷新。真正的连续体验来自状态一致，而不是让模型记得更多。
