format v4 报错怎么修:DeepSeek Harness 的 source kind 定位与三步恢复
format v4 报错看起来有三个版本,根因只有一个:消息的 source kind 不是生产者自有的。 先分诊是写入还是读取,再按三步恢复;不要被前缀带偏。
三种前缀,同一根因
同一个校验失败,会以三种形式出现。 对上前缀,才知道自己卡在哪一层。
| 前缀 | 出现位置 | 说明 |
|---|---|---|
| format v4 message requires a producer-owned source kind | 底层报错原文 | 准入校验失败 |
| 本轮运行失败 + 原文 | 中文界面 | turn 级提示叠加原文 |
| this turn failed + 原文 | 英文界面/日志 | 同上,英文表述 |
三者的处理方式一致。 前缀只影响你在哪里看到它,不改变根因;先按原文定位,再按同一套步骤修复。
前缀里带「本轮运行失败」不代表会话坏了。 它只说明这一轮写入或读取失败,历史数据通常还在(来源)。
为什么写入与读取都会报
format v4 在编码与解码两条路径都做 source kind 校验。 这是很多人误判成「两个 bug」的原因。
写入路径: 插件把消息写进会话时,v4 准入检查来源形状;还是旧的 plugin 包装,就直接拒绝。
读取路径: 打开会话时,解码同样检查来源;遇到非法来源,整条消息读不出来,表现为会话打不开或缺内容。
两条路径的共同点是「只认生产者自有 kind」。 通用包装被拒绝,不是权限问题,也不是会话损坏。
所以修复要针对写入方。 读不出来只是结果,根因在写入时留下了非法来源;只修读取端没有用(来源)。
第一步:确认是哪个插件在写
报错出现前,先找出写入会话的那个插件。 不是所有已装插件都会写消息。
- 回想最近装过或升级过哪些插件,尤其是会话、消息、摘要、面板类。
- 在已安装列表里核对版本与更新时间,最近更新的优先怀疑。
- 看系统日志的调用栈或上下文,确认报错来自哪个包。
- 临时停用可疑插件,复测同一操作;报错消失,写入方就找到了。
「最近装了什么」比「报错说了什么」更快。 这类报错几乎都和最近变更有关;先缩小到一两个插件,再谈修法。
不要一次停用全部插件。 全停能消除报错,但无法定位;一次停一个,才能找到写入方。
第二步:按三条路恢复
找到写入方后,三条路按代价从低到高。
- 升级插件。 优先找适配 format v4 的版本;升级后重启,复测写入与读取。大多数插件的问题在这一步解决。
- 改 source kind。 插件支持配置来源类型时,把通用 plugin 包装改成本生产者自有的 kind;改完复测同一条消息。
- 卸载插件。 前两条都不可行时卸载,避免它继续往会话里写非法形状;受影响的会话按迁移流程处理。
升级优先于改配置。 作者通常会随 v4 发布修复版本;自己改 kind 容易与后续版本冲突。
卸载是止损,不是修复。 卸载能阻止新增非法消息,但已经写入的历史数据仍需迁移或清理。
第三步:验证读写都恢复
修复后要同时验证写入与读取,不能只看一边。
- 新开一个会话,用可疑插件执行一次写入操作。
- 关闭并重新打开会话,确认内容完整可读。
- 在旧会话里重复一次读取,确认不再抛同一报错。
- 看日志里是否还有 source kind 相关记录;有记录说明还有插件在写旧形状。
- 记录修复版本与操作,方便下次对照。
只验证写入,会漏掉解码路径。 写入成功但读取失败,说明历史数据仍有非法来源;需要迁移或清理。
旧会话不一定能自动修好。 已经写入的数据不会因为升级插件而改变;必要时按迁移流程处理。
与迁移拒读的区别
两个报错都涉及会话格式,但方向相反。 混在一起会修错地方。
| 报错 | 发生在哪 | 本质 |
|---|---|---|
| format v4 message requires a producer-owned source kind | 写入/解码准入 | 来源形状不合法 |
| session format migration refusal | 旧会话迁移 | 清单漏项,合法数据被拒 |
前者是「新格式不收旧来源」,后者是「迁移清单不认旧数据」。 一个修写入方,一个修迁移清单。
判断方法看报错里有没有 source kind。 有就是前者;只提 migration、manifest 或缺项,就是后者。
两者可能同时出现。 先修 source kind,再处理迁移;顺序反了,迁移会反复失败。
预防:升级前先看兼容声明
这类报错可以提前避免,代价是升级前多看一眼。
- 看插件的兼容版本: 支持 format v4 的插件通常会在说明里写明。
- 先升级核心再升级插件: 核心先到 v4,插件再跟;反过来容易出现插件写新格式、核心还不认。
- 升级后先跑最小写入: 不要等大批操作后再发现;一条消息就能验证。
- 保留升级前快照: 会话目录与插件清单各一份,出问题能回退。
兼容声明比版本号更重要。 版本号只说明发布顺序,兼容声明才说明能不能在你的环境里用。
小步升级,问题好定位。 一次升一个插件,报错出现时不用猜;一次升十个,只能全停。
下一步
先找写入方,再升级或改 kind,最后验证读写。 想看完整的根因与 kind 形状,看《format v4 message requires a producer-owned source kind》;想处理迁移拒读,看《会话格式迁移被拒》;想理解会话格式演进,看《DeepSeek Harness 会话存在哪怎么查》。
来源:deepseek-ai/deepseek-harness、DeepSeek Harness 官方文档 - Web UI 指南、社区插件 dsh-tui-compact-carry
常见问题
format v4 message requires a producer-owned source kind 的三个前缀根因一样,处理方式一致。三个前缀只说明报错发生在哪一层:原文是底层准入,本轮运行失败是界面提示,this turn failed 是英文 turn 级提示。
同一个会话读写都失败,不是两处 bug:format v4 在编码与解码两条路径都会做 source kind 准入校验。写入时拒绝非法来源,读取时同样拒绝,所以一个不兼容插件会导致读写都失败。
升级插件后仍报 format v4,先确认升级的是真正写入会话的那个插件,再看会话是否已经升到 v4、插件是否声明支持 v4。升级了外围插件但没升级写入方,报错不会消失。
format v4 报错和 session format migration refusal 不是同一个问题。前者是新格式对 source kind 的准入失败,后者是旧会话迁移清单漏项、把合法历史数据当非法格式拒读;一个在写入路径,一个在迁移路径。
相关术语
- source kind
- source kind 是 DeepSeek Harness 会话事件中标识消息来源的字段,format v4 要求它报出生产者自有的值,不再接受通用 plugin 包装。— deepseek-ai/deepseek-harness
- format v4
- format v4 是 DeepSeek Harness 会话格式的一代 schema,对消息来源执行更严格的准入校验,编码与解码都会检查。— deepseek-ai/deepseek-harness
- 生产者自有 kind
- 生产者自有 kind 是由消息生产方自己声明的来源类型,第三方插件按约定带插件名前缀,官方组件使用官方类型。— deepseek-ai/deepseek-harness
- 迁移拒读
- 迁移拒读是旧会话在升级到新格式时,因迁移清单漏项被判定为非法格式而拒绝读取,与写入准入失败不同。— deepseek-ai/deepseek-harness
来源
- deepseek-ai/deepseek-harness· deepseek-ai
- DeepSeek Harness 官方文档 - Web UI 指南· deepseek-ai
- 社区插件 dsh-tui-compact-carry· community