この章の答え
Prompt を通信の要求に変え、届いたストリームを内部のイベントとして読む。
画面に文字が少しずつ現れる裏側では、完成した一つの文章を待つだけではない処理が動いています。Model Client は、内部の入力と外部 API の応答をつなぐ境界です。
01|図でつかむ
ストリーム中のデータと、応答全体の完了を区別する。
02|3つのポイントで理解する
1. 送信内容を先に見る
Prompt にはユーザーの一文だけでなく、履歴やツール定義などが関わります。まず何が入力として渡されるかを確認し、それから通信処理を読みます。
2. Client と Session の役割を追う
ModelClient と ModelClientSession の生成場所、保持する情報、stream の呼び出し元を見ます。名前から寿命を推測したら、実際にどこで再利用されるかで確かめます。
3. 途中のデータを完了と混同しない
ResponseStream を読む側は、文章やツール呼び出しに関するイベントを処理します。通信が切れた場合、途中までの出力がある場合、完了した場合を分けて追うと、再試行の扱いも理解しやすくなります。
03|ソースで確かめる
以下の検索は Codex リポジトリのルートで実行します。最初に対象 commit を記録し、検索結果から定義と呼び出し元を一つずつ開いてください。
git rev-parse --short HEAD
rg -n "ModelClientSession|ResponseStream" codex-rs
読む入口: codex-rs/core/src/client.rs 。リンク先は照合に使った固定 commit のファイルです。手元の版と異なる場合は、上の検索語から探し直します。
小さく試す
ModelClientSession の呼び出し側から stream の戻り値へ進み、完了とエラーを処理する分岐を探します。
04|30秒で復習
- Prompt と通信要求の境界を見る。
- ストリームは複数のイベントとして届く。
- 途中出力・完了・通信失敗を分ける。