3. 統一 Runtime Host と App Server は何が先進的なのか
3.1 「全端統一」の最大の価値は契約の統一
素朴な設計では、CLI・IDE・デスクトップの各クライアントがそれぞれ独自のループを実装しがちです。「承認後に継続する」機能を追加する場合、各クライアントで個別にコードを修正する必要があり、状態のセマンティクスが分岐しやすくなります。 共有ランタイムの発想は次のとおりです。クライアントは構造化された意図を送信し、ホストがタスクと実行を管理し、イベントストリームをクライアントに返します。ツール開始、ツール終了、承認待ち、完了、失敗などの状態を、同一のセマンティクスで表現できます。 App Server は双方向通信と、thread、turn、item などのプロトコルプリミティブを提供します。公式ドキュメントによれば、リッチクライアント統合に利用でき、CLI からリモートホストへの接続もサポートします。これは「再利用可能なホストインターフェース」を裏付けるものですが、すべての製品が単一の OS プロセスで動作していること、あるいはすべてのスレッドが同一の JavaScript ヒープを共有していることを証明するものではありません。 App Server 公式ドキュメント3.2 1 回のリクエストはどのように流れるのか
プロトコルメッセージは JSON-RPC スタイルに従いますが、App Server はワイヤ上でjsonrpc フィールドを省略します。リクエストには id があり、通知には id がありません。逆方向の承認リクエストにも id があります。したがって、「最初の JSON 行を読んだらそれを現在のリクエストの結果とみなす」といった実装はできません。
app_server_client.py を参照してください。このコードは initialize のみを実行し、実際の stdio ハンドシェイクを検証します。
3.3 なぜ request ID、thread ID、turn ID、call ID、cell ID を区別するのか
これらの概念は関連しますが互換ではありません。サーバーが生成した ID はそのまま伝達すべきです。ビジネスレイヤーで追加する revision は要件の変化を記録するために使い、プロトコル本来のフィールドの代替として使用しないでください。
3.4 統一ホストの利益とコスト
「1 セッション 1 プロセス」はアーキテクチャ上の原罪ではありません。 信頼できないコードにとっては、より強い隔離が価値を持ちます。Rust、Bun、Node、Python のどれを選ぶかも、タスクスケジューリングと状態復元の設計が優れているかを証明するものではありません。
エンジニアリング上、共有ホストには少なくとも次のものが必要です:スレッド単位で分離された権限と状態、グローバルおよびスレッド単位の並行制限、有界キュー、出力バックプレッシャー、キャンセル伝播、切断復旧、バージョンネゴシエーション。統一実装は隔離の放棄を意味しません。
3.5 リモート接続とバージョンドリフト
公式ドキュメントの localhost の例:--code-mode-host wss://... が示されていますが、固定リビジョンのソースコード中の CodeModeHostTransport::Grpc と URL 検証は http/https を受け付けます。したがって、本記事ではバージョン横断で汎用的なリモート Code Mode デプロイコマンドは提示しません。実際にデプロイするバージョンが生成する schema、ヘルプ、および対応するソースコードを基準にしてください。リモート公開ではさらに認証と伝送保護の設定が必要で、実験的インターフェースを自動的に本番保証と見なすことはできません。固定リビジョンのソース:ホスト伝送設定
3.6 面接での回答
統一 Runtime Host の核心は、Agent の実行セマンティクスをクライアントから引き離し、安定したタスクプロトコルで複数のフロントエンドを支えることだと理解しています。利益はセッション、ツール、承認、イベントの挙動の一貫性であり、コストは共有ホストで隔離、バックプレッシャー、復旧、バージョン互換を補う必要があることです。プロセス数や実装言語だけでアーキテクチャの優劣を判断することはしません。
4. Agent GUI:見た目は UI、本質はランタイム状態の投影
スクリーンショットでは UI/UX が称賛されていますが、面接で議論する価値があるのは「UI がどのようにユーザーに『何が起きているか』と『まだ何を制御できるか』を伝えるか」です。本節はイベント駆動システムに基づくエンジニアリング設計であり、クローズドソースのデスクトップコードを復元したものだと主張するものではありません。4.1 使いやすい UI にはどのような裏付けが必要か
フロントエンドのタイマーだけで「ファイル読み込み中」「もうすぐ完了」を偽装してはいけません。そうすると、バックエンドで失敗しても UI に成功と表示される可能性があります。
4.2 なぜ reducer が必要なのか
以下では独自の教材用イベントプロトコルを用います。Codex のフィールドではありません。reducer はイベントを UI 状態に更新し、「イベント処理」と「描画」を分離します。lastSeq で欠落を隠すのではなく、補読やスナップショット再取得を行うべきです。複数スレッドのイベントはさらに thread/turn 単位で振り分ける必要があります。教材用のイベントシーケンス番号を、App Server の各通知が持つフィールドに直接対応付けないでください。
再接続では「スナップショット + スナップショットのカーソル以降のイベント」のパターンが有効です。スナップショットとカーソルが同一の一貫性境界から得られることを保証してください。そうしないと、スナップショットの読み取りと購読の間でイベントを取りこぼします。特定の製品がイベント再生をサポートするかは対応するプロトコルを確認する必要があり、UI が復旧しているように見えるからと実装を推測してはいけません。
4.3 インタラクションで最も重要な 3 つの区別
- リクエストの受理 ≠ 作業完了:RPC の戻り値は起動確認ですか、それとも完了結果ですか?
- ツール完了 ≠ タスク成功:テストコマンドが終了したからといって終了コード 0 とは限らず、終了コード 0 であっても受け入れ要件を満たしているとは限りません。
- 新要件のキュー投入 ≠ 新要件の適用済み:steering は実際の状態を提示すべきで、送信ボタンを押した瞬間に「調整済み」と宣言してはいけません。