この章の答え
文字列が型付きの入力になり、Turn の処理へ渡る境界を追う。
「git status を確認して」という短い依頼にも、入力の受付、モデルへの送信、コマンド実行、結果の説明という段階があります。同じ入力を追い続けると、ファイル一覧だけでは見えない実行経路がつながります。
01|図でつかむ
結果は次の判断の材料になる。ツールを使わず、直接回答する経路もある。
02|3つのポイントで理解する
1. 画面の文字から、処理用の入力へ
入力欄に見えるテキストと、内部で渡される UserInput は同じ層ではありません。送信ボタンやキー操作の先で、どの型へ変換されるかを探します。
2. Turn の開始地点を見つける
受付後の処理は、会話の状態や実行条件と結び付きます。Turn の入口からモデル呼び出しまでを追い、入力だけでなく既存の履歴も材料になることを確認します。
3. Tool Call と Tool Result を対で読む
モデルが出すのは実行の要求です。実際の操作はツール側が行い、その結果をモデルに返します。同じ呼び出しの識別子と出力をたどると、別の操作と混同せずに追跡できます。
03|ソースで確かめる
以下の検索は Codex リポジトリのルートで実行します。最初に対象 commit を記録し、検索結果から定義と呼び出し元を一つずつ開いてください。
git rev-parse --short HEAD
rg -n "UserInput|run_turn" codex-rs
読む入口: codex-rs/core/src/session/turn.rs 。リンク先は照合に使った固定 commit のファイルです。手元の版と異なる場合は、上の検索語から探し直します。
小さく試す
変更を行わない git status の依頼を一つだけ使い、入力受付、ツール呼び出し、ツール結果の順にメモします。
04|30秒で復習
- 一つの入力を固定して経路を追う。
- 型が変わる境界で呼び出し元と先を見る。
- ツール結果はモデルの次の入力になる。