怎么读 DeepSeek Harness 的 Trajectory 日志

先读会话头，再看聊天气泡

一次运行失败之后，怎么读 DeepSeek Harness 的 Trajectory 日志：先放下最后那条气泡，打开持久会话日志。JSONL 持久化说明写的是每个会话一条仅追加的逻辑日志，默认落成 .jsonl.zstd，关掉压缩才是原始 .jsonl。第一条逻辑行是会话头：type: session，以及 version、id、可选的 cwd、createdAt、可选的 parentSession，还有必填的 delegationDepth。agentPreset 会被写进去，因为恢复会话时，工具和提示词以它为准。

顶层会话的 delegationDepth 是 0。缺了或非法，整份日志会被拒绝。数字不是 0，说明你在委托出去的子会话里：你点的那个预设上不该出现的工具名，可能属于子会话。parentSession 指向上一层。cwd 是当时绑上的工作区根——会话日志入门问的第一件事。本文是这件事已经发生、运行已经失败时的阅读顺序。

默认分支上的持久化目录把 SESSION_FORMAT_VERSION 钉在 0，并写明预览格式不承诺兼容。本站 0.1.5 RC 笔记说的是会话数据升级之后不能按旧格式回读。这两句不是同一个整数。读你解码出来的头字段 version。自写读取器对着另一代格式写的，就改读取器。

后面每一行是一条存储记录。解码之后序号连续：下标 i 的事件满足 seq === i。出现空洞，是读取器丢掉了一行——常见是打包过的 chunk，或它不认识的插件事件——不是模型把历史删了。下游插件可以并入持久化目录没收录的事件类型。

把每条 tool/call 配上 tool/result

目录把事件分成界面事件和仅日志。界面事件才会变成给模型看的消息。这次阅读要盯的是 user/message、assistant/message 和 tool/result。tool/call 是仅日志。聊天导出可以看见结果正文，同时藏起模型吐出的原始参数。

一条 tool/call 带 turn、step、callId、name 和 arguments。arguments 是模型原样产出的 JSON 字符串，没有解析。callId 用来配 tool/result。结果带 turn、step、一条工具结果消息、可选的 error（含 name 和 code），以及可选的 meta。meta 必须是 JSON。文件工具 dsh-tool-fs 可能把当时的差异放在这里；别的工具没有 meta 是正常的。

从末尾往前找调用。失败通常是最后那个没有结果的 callId，或者结果上 error 有值。不要一次翻开三个插件。name 若是你从没打算加载的工具，先停，按插件安全清单处理，再重新提示。

TOOL_NOT_STARTED 还是 TOOL_OUTCOME_UNKNOWN

会话核心说明给了两句恢复用语。它们不是同义词。

• TOOL_NOT_STARTED：助手侧已经提出工具请求，但没有落下持久的 tool/call。上游的说法是：调用在 Harness 把它记成「已开始」之前被打断，若仍需要可以重试。你没有证据表明工具跑过。
• TOOL_OUTCOME_UNKNOWN：持久的 tool/call 在，结果没有落下。结局未知。只有只读或幂等的操作才重试。可能有副作用时，先核对外部状态或问用户。不要盲目重试。

Shell 是同一形状、不同的类型：command/run 用 commandId 配 command/done，而且 command/run 是仅日志。有 run 没有 done，就是「有调用没有结果」的 Shell 版。发出「再试一次」之前，先看工作区。

llm/retry 也是仅日志：一次失败请求之后的提供方重试。失败的模型请求不会有 assistant/message。聊天看起来像模型突然沉默时，先找 llm/retry 或缺失的助手消息，再怪工具。用量若存在，是类型为 usage 的 assistant/chunk；只有没有用量 chunk 时，才回退到 assistant/message.usage。

聊天界面不会显示的仅日志行

批准是审计，不是气泡。approval/asked 和 approval/decided 共用一个 id，两条都是仅日志。有人说 Agent 没问就跑了 Shell，先找到这两行，再争论界面文案。预览版按钮名字会变；今天目录里的名字是这些事件类型。

同一块里连续三条以上的 assistant/chunk 增量，可能存成一行打包记录：text-chunks、reasoning-chunks 或 tool-call-chunks。这些标签没有斜杠，所以不是事件类型。加载时会解回去。文件行数少于最大 seq，只要这些打包行在，就不是历史被截断。

日志事件不是 Cordis 事件。目录写明实时总线是另一次 session/event 发出。在插件源码里 grep Cordis 钩子，看不到那条持久行。

十分钟走一遍

1. 解码日志（认 .jsonl.zstd）。读头上的 cwd、agentPreset、delegationDepth 和 version。
2. 确认解码后 seq 连续。不连续就先修读取器，再解释空洞。
3. 找到最后一条没有 tool/result 的 tool/call，或带 error 的结果。
4. 重试之前，把缺口分成 TOOL_NOT_STARTED 或 TOOL_OUTCOME_UNKNOWN。
5. 工具名出乎意料，就卸掉最近一个插件。不要再加一个。
6. 缺陷单里引用 callId、name 和头上的 version。最后一句道歉的截图不是模板。

这个顺序决定不了什么

本文不是「为什么要留飞行记录仪」。那仍是会话日志入门。慢走是可观测性教程。agentPreset 上的名字仍以运行模式为准；本文不替你选 Standard 还是 PTC。「界面在、工具全瞎」仍是排错，不是缺了一条 tool/result。

你这份标签上的头字段 version 或类型名，若和上面链的目录不一致，以该标签为准。预览版故意会破兼容。把 DSH 版本和插件 SHA 写在同一张便条上。读取器只解了一半的日志，不要拿去开缺陷。