初期のコーディング エージェントは、驚くほど強力な機能を明らかにしました。エージェントに Bash へのアクセスを許可すると、コードの作成からコンテキストの収集から完全な Git ワークフローの管理まで、ほぼ何でも実行できます。
この洞察は、CLI ファースト ソフトウェアへの幅広い動きを促進するのに役立ちました。コマンドライン インターフェイスは、AI エージェントが複雑なアプリケーションにアクセスできるようにする標準的な方法のように見え始め、次のようなよく知られたスローガンが生まれました。
必要なのは CLI だけです。
しかし、隠れたコストもあります。エージェントは多くの場合、人間と同じようにターミナルを使用します。つまり、短いコマンドを実行し、結果を検査し、次に何をするかを決定します。タスクが複雑になると、モデルとそのツールの間でのやり取りが増え、LLM 呼び出しが増え、コンテキストが無駄になり、待機時間が長くなります。
エージェントに複雑なシェル スクリプトを組み立てるよう依頼するのではなく、エージェントがすでに理解しているプログラミング言語でタスクを調整することを望んでいます。これにより、アーキテクチャが少し異なります。
CLI を汎用エントリ ポイントとして維持しますが、ソフトウェアと対話する実際の方法としてコードを使用します。
エージェントは、操作、決定、およびデータ処理を含むコード ブロックを送信します。これがなければ、これらのブロックは対話の複数ラウンドにまたがって分散されます。次に、ローカル ランタイムがワークフローを実行します。
ego-browser はこのアイデアに基づいて構築されました。その CLI はプログラム可能な環境を起動し、ブラウザは小さな関数セットを通じてその機能を公開し、エージェントは既存のプログラミング スキルを使用してそれらの関数を構成し、 それらを調整する.
この記事では比較してみます ヒアドキュメントとREPL、CLI を介してコードを実行する 2 つの方法、および ego-browser の実験結果を共有します。ヒアドキュメントを使用すると、エージェントは 44% 少ない実行ラウンドで同じタスクを完了し、35.5% 少ないツール呼び出しで、21.6% 低いコストで完了しました。
「必要なのは CLI だけです」—それではどうでしょうか?
「必要なのは CLI だけである」という主張は、モデルがその CLI の使用方法をすでに知っていることを前提としています。
Git、Docker、FFmpeg などのよく知られたツールの場合、これは通常問題になりません。モデルはトレーニング中に数え切れないほどのコマンド、チュートリアル、スクリプト、エラー メッセージを見てきており、引数とコマンドがどのように組み合わされるかをすでに知っています。
しかし、エージェント用にまったく新しい CLI を構築すると、状況は変わります。すべての CLI には、独自のサブコマンド、引数、出力形式、およびエラー セマンティクスがあります。 モデルにとって、それは本質的に新しいミニ言語です。 完全なドキュメントがあっても、モデルは最初にルールを学習し、次に繰り返し呼び出しを通じてコマンドがどのように組み合わされるかを理解する必要があります。
代わりに JavaScript API または他の言語の API として同じ機能を公開すると、モデルは新しいドメインの概念を学習する必要がありますが、制御フロー、データ構造、または構成を再学習する必要はなくなります。ループ、条件、例外処理、データ処理はすべて、既知のプログラミング言語のままです。
簡単なタスクを実行してください。Web ページを開いて、その主な見出しを読みます。 ego-browser が従来のコマンド スタイルのインターフェイスを公開した場合、エージェントはそれを完了するためにいくつかの手順を必要とする可能性があります。
# First call: open the page
ego-browser open https://example.com
# Tool response: the page is open
# Second call: locate the main heading
ego-browser find --role heading
# Tool response: a heading was found
# Third call: read the heading
ego-browser read --role heading各ステップの後、エージェントはツールを待ち、結果を読み取り、次に何をするかを決定します。
実際に使用されるコード インターフェイス ego-browser により、ワークフロー全体を一度に表現できます。
await taskSpaces.useOrCreate("read example page");
await browser.openOrReuseTab("https://example.com", { wait: true });
const heading = await page.getByRole("heading").textContent();
console.log(heading);どちらのアプローチでも同じことが行われます。コマンド スタイルのインターフェイスは、プロセスをモデルとツールの対話の複数のラウンドに分割します。コード インターフェイスを使用すると、エージェントは完全なプロセスを一度書き出して、それをローカル ランタイムに渡すことができます。
これはまさに前述した設計上のアイデアです。つまり、CLI をユニバーサル エントリ ポイントとして維持し、ソフトウェアへの実際のインターフェイスとしてコードを使用します。これにより、呼び出しや統合が簡単であるという CLI の利点が維持され、モデルがすでに持っているプログラミング スキルを構成やオーケストレーションに使用できるようになります。
CLI がコードへのゲートウェイになるとき
CLI がコードを受け入れたら、次の問題は、エージェントがそのコードを実行環境にどのように渡すかということです。
厳密に言うと、ヒアドキュメントはシェル入力構文であり、REPL はインタプリタの実行モードです。この 2 つは同じ抽象化層にありません。この記事で実際に比較しているのは、ego-browser のヒアドキュメントを通じて入力されたワンショット コードの実行と、REPL 上に構築された永続的な対話型セッションです。簡潔にするために、今後はそれらを単にヒアドキュメントおよび REPL と呼びます。
1 つのオプションはヒアドキュメントです。 ego-browser では、エージェントは JavaScript のブロック全体を一度に送信します。
ego-browser nodejs <<'EOF'
await taskSpaces.useOrCreate("read example page");
await browser.openOrReuseTab("https://example.com", { wait: true });
const heading = await page.getByRole("heading").textContent();
console.log(heading);
EOFシェルはコードを ego-browser に渡し、終了するのを待ち、結果を受け取って終了します。エージェントにとって、これは従来のツール呼び出しのように動作します。
Submit command → wait for process → receive resultREPL は動作が異なります。インタプリタは生きたままであるため、エージェントは変数とセッション状態を保持しながらコードを繰り返し入力できます。
> await browser.openOrReuseTab("https://example.com", { wait: true })
< Tab {...}
> await page.getByRole("heading").textContent()
< "Example Domain"表現力という点では両者はほぼ同等です。 REPL はループ、条件、例外処理を含む完全なプログラムを 1 回で実行でき、ヒアドキュメントは 1 行だけ送信できます。
明らかな違いはプロセスのライフサイクルです。ヒアドキュメントを使用すると、コードの実行が終了するとすぐにプロセスが終了します。 REPL はインタプリタ プロセスを生きたままにして、さらなる入力を待ちます。これは、両者がエージェント ツールに対して異なる要求を課していることも意味します。ヒアドキュメントは、よく知られたリクエストとレスポンスのモデルで直接実行されます。
submit the command → wait for the process to exit → get the resultREPL は、永続的なプロセス、セッション管理、継続的な入力、中断、回復など、ツールにさらに多くのことを要求します。ほとんどのエージェントの組み込み Bash ツールには、これらの機能がありません。現在主流の製品の中で、それらを適切にサポートしているのは Codex だけです。また、ツールのサポートは REPL を使用するための必要条件にすぎません。モデルが実際にどのように使用するかは決まりません。両方の環境で同じコードを実行できる場合でも、モデルはそれぞれの環境で異なるコードを記述する可能性があります。
モデルが各環境でコードを記述する方法
理論的には、モデルは両方の環境で同じプログラミング能力を備えています。実際に、一貫した動作の違いが観察されました。
- REPL では、モデルはコードを段階的に入力する傾向があります。
- ヒアドキュメントでは、1 回のパスで完全なプログラムを生成する可能性が高くなります。
人間用のソフトウェアは人間工学を考慮する必要があります。エージェント用のソフトウェアにも同様の規律が必要です。 モデルエクスペリエンスエンジニアリング。インターフェイスは、トレーニング中に開発された行動パターン モデルと連携する必要があります。
REPL とヒアドキュメントの対照は、トレーニング データの分布を反映しています。
REPL の例は通常、チュートリアル、デバッグ セッション、質疑応答のやりとりから得られます。彼らの典型的なパターンは探索的です。
> Get the page
< Return page information
> Find an element
< Return element information
> Read its contents
< Return the textヒアドキュメントのコード ブロックは、スクリプトまたはソース ファイルに似ています。これらには明示的な開始境界と終了境界があり、これによりモデルが継続的なワークフローを生成することが促進されます。
const page = await openPage();
const element = await findElement(page);
const text = await readText(element);
console.log(text);これは、REPL が完全なプログラムを実行できないという意味ではありません。このモデルは、同じコード ブロックを 1 ステップで REPL に送信できます。
区別は状況に応じて異なります。 REPL は、 実行する、観察する、継続する パターン。ヒアドキュメントは、 まず整理してから実行する パターン。
この傾向は、制御フローがどこに存在するかを決定します。 REPL では、モデルはタスクをいくつかの段階に分割し、すべての結果の後に何を行うかを決定する可能性が高くなります。ヒアドキュメントでは、ループ、条件、フィルタリング、およびデータ処理をプログラムに直接組み込み、ローカル ランタイムに処理させる可能性が高くなります。
実験でわかったこと
確実に統合できた主流のエージェント ツールの中で、Codex は永続的な REPL に必要な実行機能を提供しました。そこで、Codex SDK で自動ベンチマークを構築しました。同じエージェントが REPL とヒアドキュメントの両方を通じて 4 種類の実際のブラウザ タスクを完了し、比較のために繰り返し実行された結果を集計しました。
タスクは次のとおりです。
- X トレンド投稿分析: 過去 7 日間の OpenAI の元の投稿を収集し、固定された投稿、再投稿、返信を除外し、閲覧数でトップ 5 をランク付けし、エンゲージメント率と全体の平均を計算します。
- OpenAI 求人応募: サンフランシスコで適切なクラウド インフラストラクチャのポジションを見つけ、履歴書をアップロードし、応募フォームに記入し、最終提出の前に停止します。
- Redfin 住宅ローンの計算: オースティンの物件を家のタイプと価格でフィルターし、並べ替え後の最初の結果を開き、頭金を 20% に変更して、更新された推定月々の支払い額を取得します。
- Expedia フライト検索: JFK 発 MIA 行きの片道直行便を検索し、指定した航空会社から最も安いオプションを選択し、乗客の情報を入力して、支払い前に停車します。
これらのタスクには、ページを開いたりテキストを読んだりする以上のことが含まれていました。これらには、構造化抽出、条件付きフィルタリング、ページ間のナビゲーション、ファイルのアップロード、フォーム入力、ページ状態の変更、計算が含まれており、ブラウザー エージェントによって実行される一般的な操作のほとんどをカバーしています。
どちらのアプローチでも、ほとんどのタスクが完了しました。 Heredoc の成功率は 77.5% でしたが、REPL の成功率は 75.0% でした。信頼性の差はわずかでした。
より大きな違いは効率でした。
- 平均完了時間が短縮されました 35.0%.
- 完了時間の中央値が低下 30.7%.
- ツール呼び出しが失敗しました 35.5%.
- トークン消費量が減少 29.8%.
- 平均コストは低下しました 21.6%.
REPL は実行時の状態を再利用できますが、その利点によって対話が減少するわけではありません。実際には、ヒアドキュメント エージェントが行うツール呼び出しは少なくなりました。
結果は以前の観察と一致しました。 REPL 内に入ると、エージェントは多くの場合、小さなコードを実行し、結果を調べて、次に何をするかを決定します。単一のプログラム内で処理できたはずのループ、フィルター、決定が、代わりに複数のモデルとツールの交換に分散されました。
2 つの環境は同様の表現力を提供します。それらの効率の違いは主に、対話パターンがエージェントの動作をどのように形成するかによって生じます。少なくともこれら 4 つのブラウザー エージェント タスクについては、ヒアドキュメントは、モデルが完全なプログラムを編成し、ループ、フィルター処理、決定をコードにプッシュし、段階的な意思決定の余分なラウンド トリップを回避することをより一貫して奨励しています。
また、Odyssey データセット上の同様の REPL ベースのブラウザ自動化製品と ego-browser を比較することで、同じパターンがより大規模に保持されるかどうかも調べました。上記の対照実験とは異なり、この比較には、2 つのインターフェイスを介して動作する同じモデルではなく、2 つの完成した製品が含まれていました。したがって、これは全体的な効率の比較として役立ちますが、その違いを完全にヒアドキュメントと REPL に帰することはできません。
これはヒアドキュメントの永続的な勝利ではありません
私たちはヒアドキュメントが本質的に REPL よりも優れているとは考えていません。
私たちの結論は、2026 年に存在するモデルの機能、トレーニング データの分布、エージェント ツールの設計に依存します。
今日のエージェントは一般に、1 回のパスで完全なコード ブロックを生成することに優れています。これらのシェル ツールも、コマンドを送信し、終了するのを待って、結果を返すという単純なライフサイクルを中心に設計されています。このような状況下では、ヒアドキュメントを使用すると、対話ラウンドを削減し、制御フローをローカルで実行されるコードに移動することが容易になります。
これらの状況は急速に変化する可能性があります。
将来のエージェント ツールは、信頼性の高い永続セッション、構造化された出力、および堅牢な状態回復を提供する可能性があります。エージェントは、REPL プロンプト、プロセス状態、中断されたセッション自体を処理する必要がなくなります。ターゲットを絞ったトレーニングでは、不必要な段階的な対話に陥るのではなく、完全なプログラムを REPL 内で積極的に送信するようにモデルを教えることもできます。
そうなれば、REPL はさらに多くのモデル呼び出しを必要とせずに、状態の再利用と即時フィードバックの利点を維持できる可能性があります。これらは、高価な初期化、長期間にわたる状態、または真に探索的なワークフローを伴うタスクにとって、より良い選択肢になる可能性もあります。
だからこそタイトルで明記しているのは、 2026。私たちは恒久法を発見したと主張しているわけではありません。これは、現在利用可能なモデルとエージェント ツールに基づいた、その時点でのエンジニアリング上の判断です。