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 と対にする

カタログはイベントを サーフェス と ログ専用 に分けます。サーフェスだけが LLM 向けメッセージになります。今回見るのは 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 はあるが、結果が記録されていない。結末は不明です。再試行してよいのは読み取り専用か冪等な操作だけです。副作用があり得るなら、先に外部状態を確認するか利用者に聞いてください。盲目に再試行しません。

シェルは同じ形で型が違います。command/run は commandId で command/done と対になり、command/run はログ専用です。run があって done が無いのは、結果の無い呼び出しのシェル版です。「もう一度」と送る前にワークスペースを見てください。

llm/retry もログ専用で、失敗したリクエストのあとのプロバイダ再試行一つです。失敗したモデル要求には assistant/message がありません。チャットが急に黙ったように見えたら、ツールを責める前に llm/retry か、欠落したアシスタントメッセージを探してください。用量があれば、型が usage の assistant/chunk です。用量 chunk が無いときだけ assistant/message.usage に戻ります。

チャットが隠すログ専用の行

承認は監査であり、吹き出しではありません。approval/asked と approval/decided は同じ id を共有し、どちらもログ専用です。尋ねずにシェルが走ったと言う前に、この二行を見つけてください。プレビューのボタン文言は動きます。今日カタログが名指しするのはこれらのイベント型です。

同じブロックの assistant/chunk 差分が三つ以上続くと、一行のパック列になることがあります。text-chunks、reasoning-chunks、tool-call-chunks です。スラッシュが無いのでイベント型ではありません。読み込み時に展開されます。行数が最大 seq より少なくても、パック列があれば履歴の切断ではありません。

ログイベントは Cordis イベントではありません。カタログはライブバスを別の session/event 送出だと書いています。プラグインソースで Cordis フックを grep しても、永続行は出ません。

十分の読み順

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 を選びません。「UI はあるがツールが全部盲目」は、欠落した tool/result ではなくトラブルシュートです。

お使いのタグのヘッダ version や型名が、上にリンクしたカタログと違えば、そのタグが勝ちます。プレビューの互換は意図して壊れます。DSH の版とプラグイン SHA を同じメモに残し、半分しかデコードしていないログで不具合を出さないでください。