迁移会丢什么：逐项列清元数据的去向
配方模板 · 尚未在本站完成实测
本页是配方模板，尚未在本站完成实测。运行记录、token与耗时会在复测后补上；在那之前不填任何估算数字。
适用场景
对话迁过去了，能看能搜，但「这条是谁在什么工作区跑的」「父子会话关系还在不在」这些问题已经答不出来了。
准备
- 宿主版本
- 待填（实测时记录具体rc版本号）
- 模型
- 待填
- 模式 / 权限
- 建议先用标准模式 + 工作区内修改
- 需装插件
- 无（如用到插件，在实测后补齐名称与版本）
- 输入材料
- 放在独立工作区，原始文件先备份
完整指令
我要迁一批旧对话进 DSH，想知道会丢什么。请先列出 DSH 会话头里有哪些字段，再逐项判断迁移时的去向。
【第一步：列出会话级字段】
从会话文件第一行与相邻的元数据事件里，列出你能确认的全部字段，每个写：字段名 | 含义 | 例子 | 依据。
【第二步：逐项判断去向】
做成表：字段 | 迁移时能否保留 | 如果不能，为什么 | 建议怎么处理。四列都必须填，不许留空。
判断标准：
- 「能保留」= 直接写入新会话的同名字段
- 「需转换」= 能保留但值要重新算（例如时间戳格式不同、路径要重新转义）
- 「必然丢失」= 目标格式里没有对应概念
【第三步：说清丢失的后果】
对每个「必然丢失」的字段，写一句：丢了会影响什么具体功能？（例如「父子会话关系丢了，就没法从子会话跳回父会话」）不要写「可能影响部分功能」这种空话。
【硬约束】
1. 每个字段必须有依据。凭推测的标「推测」，并说明推测理由。
2. 不许笼统写「元数据基本都能保留」。如果某个字段在新格式里没有对应概念，直接说「必然丢失」。
3. 不要建议「写个脚本转换」而不说清转换规则——转换规则本身就是答案。
最后给一句总结：这批迁移值不值得做，取决于你最在意哪个字段。运行记录
| 项目 | 数值 | 备注 |
|---|---|---|
| 耗时 | 待实测 | |
| 结果 | 待实测 | |
| 输入 / 输出token | 待实测 | |
| 残留 | 待实测 |
产物
跑通后在这里给出文件清单与截图，并说明原始文件有没有被改动。
验收清单
点一下可勾选，用来逐条核对。
- 会话头字段列全了，每个都有依据
- 四列表格没有空单元格
- 把「能保留 / 需转换 / 必然丢失」分开判了，没有笼统结论
- 每个丢失项都写清了影响哪个具体功能
- 给了「取决于你最在意哪个字段」这类可操作的收尾，没有泛泛劝退
失败与边界
- 实测事实：会话头字段为type / version / id / createdAt / cwd / parentSession / origin / delegationDepth / agentPreset。其中parentSession与delegationDepth是父子会话与委派链，origin记录来源（实测样本里是subagent），agentPreset记录用的哪个预设（standard）。
- 实测事实：每行事件带seq与time两个字段。seq是会话内序号，time是毫秒时间戳。这两个字段在别的工具里往往没有对应概念——迁过来要么重编seq，要么留空，留空会让某些按seq定位的功能失效。
- 最容易被忽略的是delegationDepth与parentSession：别的工具的对话通常只有平铺的消息列表，没有「子会话」这个概念。所以迁移后你得到的是独立会话，不是原来的会话树。
- 这条配方的价值是把「丢什么」从模糊的担心变成逐项清单。迁移值不值得做，取决于你在意的是消息内容还是对话结构。
- 卡在哪：同上：DSH会话头字段已实测（type/version/id/createdAt/cwd/parentSession/origin/delegationDepth/agentPreset，事件行带seq与time），缺另一侧的字段清单做逐项对照。