怎麼讀 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 寫在同一張便條上。讀取器只解了一半的日誌，不要拿去開缺陷。