為什麼到 2026 年，heredoc 式執行比 REPL 更適合 AI Agent

早期的編碼 Agent 揭示了一些令人驚訝的強大功能：讓 Agent 訪問 Bash，它幾乎可以做任何事情 - 從編寫代碼和收集上下文到管理完整的 Git 工作流程。

這種洞察力推動了更廣泛的向 CLI 優先軟件的發展。命令行界面開始看起來像是使 AI Agent 可以訪問複雜應用程式的標準方式，從而產生了一個熟悉的口號：

CLI 就是您所需要的。

但有一個隱性成本。 Agent 通常像人類一樣使用終端：運行簡短的命令，檢查結果，然後決定下一步做什麼。隨著任務變得更加複雜，這會在模型及其工具之間產生更多的來回，這意味著更多的 LLM 呼叫、更多的上下文浪費以及更多的等待時間。

我們不希望 Agent 組裝複雜的 shell 腳本，而是希望他們用他們已經理解的編程語言來協調任務。這導致了一個稍微不同的架構：

保留 CLI 作為通用入口點，但使用代碼作為與軟件交互的實際方式。

Agent 提交包含操作、決策和資料處理的代碼塊，否則這些代碼塊將分散在幾輪交互中。然後本地執行環境執行工作流。

ego-browser 是圍繞這個想法構建的。它的 CLI 啟動了一個可編程環境，瀏覽器通過一小組函數公開其功能，Agent 使用其現有的編程技能來組合這些函數和 編排他們.

在這篇文章中，我們比較 定理和 REPL，比較透過 CLI 執行程式碼的兩種方式，並分享 ego-browser 的實驗結果。使用 heredoc 後，Agent 完成相同任務所需的執行輪次減少 44%、工具呼叫減少 35.5%，成本降低 21.6%。

“CLI 就是您所需要的”——然後呢？

“CLI 就是您所需要的一切”的說法假設模型已經知道如何使用該 CLI。

對於 Git、Docker 和 FFmpeg 等知名工具來說，這通常不是問題。模型在訓練過程中看到了無數的命令、教程、腳本和錯誤消息，並且已經知道參數以及命令如何組合在一起。

但當我們為 Agent 構建全新的 CLI 時，情況就發生了變化。每個 CLI 都有自己的子命令、參數、輸出格式和錯誤語義。 對於模型來說，它本質上是一種新的迷你語言。 即使有完整的文檔，模型仍然必須首先學習規則，然後通過重複呼叫弄清楚命令如何組合在一起。

公開與 JavaScript API 或任何其他語言的 API 相同的功能，模型仍然需要學習新的領域概念，但不再需要重新學習控制流、資料結構或組合。循環、條件、異常處理和資料處理都保留在它已知的編程語言中。

執行一個簡單的任務：打開網頁並閱讀其主標題。如果 ego-browser 公開了傳統的命令式界面，Agent 可能需要幾個步驟來完成它：

# 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

每執行一步，Agent 都要等待工具完成、讀取結果，再決定下一步。

代碼接口 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);

兩種方法都能完成相同任務。命令式介面會把流程拆成多輪模型與工具互動；程式碼介面則讓 Agent 一次寫出完整流程，再交給本機執行環境。

這正是前面提到的設計思想：保留 CLI 作為通用入口點，但使用代碼作為軟件的實際接口。它保留了 CLI 易於呼叫和整合的優勢，同時讓模型使用其已有的編程技能進行組合和編排。

當 CLI 成為代碼網關時

一旦 CLI 接受代碼，下一個問題是 Agent 應如何將該代碼交給執行環境？

嚴格來說，heredoc是shell輸入語法，REPL是解釋器的執行模式；兩者不在同一個抽象層。本文實際上比較的是通過 ego-browser 中的定界文檔輸入的一次性代碼執行，與基於 REPL 構建的持久交互式會話。為了簡潔起見，我們從這裡開始將它們稱為heredoc和REPL。

一種選擇是heredoc。在 ego-browser 中，Agent 一次性提交了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

shell 將代碼傳遞給 ego-browser，等待其完成，接收結果，然後退出。對於 Agent 來說，這就像傳統的工具呼叫一樣：

Submit command → wait for process → receive result

REPL 的運作方式不同：解譯器會持續執行，讓 Agent 能重複輸入程式碼，同時保留變數與工作階段狀態：

> await browser.openOrReuseTab("https://example.com", { wait: true })
< Tab {...}

> await page.getByRole("heading").textContent()
< "Example Domain"

從表現力上來說，兩者本質上是相當的。 REPL 可以一次性運行一個包含循環、條件和異常處理的完整程序，而 Heredoc 只能提交一行。

明顯的區別是流程生命週期。使用定界文檔，一旦代碼運行完畢，進程就會退出； REPL 使解釋器進程保持活動狀態，等待進一步的輸入。這也意味著兩者對 Agent 工具的要求不同。 Heredoc 直接在熟悉的請求響應模型上運行：

submit the command → wait for the process to exit → get the result

REPL 對工具的要求更多：持久進程、會話管理、連續輸入、中斷和恢復。大多數 Agent 的內置 Bash 工具不具備這些功能。 Among mainstream products today, only Codex supports them reasonably well.而工具支持只是使用REPL的必要條件。 It does not decide how the model will actually use one.即使兩個環境可以運行相同的代碼，模型仍然可能在每個環境中編寫不同的代碼。

模型如何在每個環境中編寫代碼

理論上，模型在兩種環境中具有相同的編程能力。在實踐中，我們觀察到一致的行為差異：

• 在 REPL 中，模型傾向於增量輸入代碼。
• 在定界文檔中，更有可能一次性生成完整的程序。

Software for humans must account for ergonomics.Agent 軟件需要類似的規則：稱之為 模型體驗工程。界面應與培訓期間開發的行為模式模型配合使用。

REPL 和 Heredoc 之間的對比反映了它們訓練資料的分佈。

REPL 示例通常來自教程、調試會話和問答交流。他們的典型模式是探索性的：

> Get the page
< Return page information

> Find an element
< Return element information

> Read its contents
< Return the text

Heredoc 代碼塊看起來更像腳本或源文件。它們具有明確的開始和結束邊界，這鼓勵模型產生連續的工作流程：

const page = await openPage();
const element = await findElement(page);
const text = await readText(element);

console.log(text);

這並不意味著 REPL 無法運行完整的程序。該模型可以一步將相同的代碼塊提交給 REPL。

區別是上下文相關的。 REPL 鼓勵 執行、觀察、繼續 模式。一個heredoc鼓勵 先組織，後執行 模式。

這種趨勢也決定了控制流的位置。在 REPL 中，模型更有可能將任務分為幾個階段，並在每個結果後決定要做什麼。在定界文檔中，更可能將循環、條件、過濾和資料處理直接放入程序中，並讓本地執行環境處理它們。

實驗表明了什麼

在能可靠整合的主流 Agent 工具中，Codex 提供了持續型 REPL 所需的執行能力。因此，我們使用 Codex SDK 建立自動化基準測試：由同一個 Agent 分別透過 REPL 與 heredoc 完成四類真實瀏覽器任務，再彙整多次執行結果進行比較。

任務是：

• X 趨勢帖子分析： 收集OpenAI過去7天內的原始帖子，排除置頂帖子、轉發和回覆，按瀏覽量排名前五名，並計算其參與率和總體平均值。
• OpenAI 職位申請： 在舊金山找到正確的雲基礎設施職位，上傳簡歷，填寫申請表，並在最終提交之前停止。
• Redfin抵押貸款計算： 按房屋類型和價格篩選奧斯汀的房產，打開排序後的第一個結果，將首付更改為 20%，並檢索更新的預計每月付款。
• Expedia 航班搜索： 查找從 肯尼迪國際機場 飛往 邁阿密國際 的單程直飛航班，選擇指定航空公司最便宜的航班，輸入旅客信息，然後在付款前停止。

這些任務不僅僅包括打開頁面和閱讀文字。它們包括結構化提取、條件過濾、跨頁面導航、文件上傳、表單完成、頁面狀態更改和計算，涵蓋了瀏覽器 Agent 執行的大多數常見操作。

兩種方法都完成了大部分任務。 Heredoc 的成功率為 77.5%，而 REPL 的成功率為 75.0%。可靠性差異不大。

更大的差異是效率：

• 平均完成時間下降了 35.0%.
• 中位完成時間下降了 30.7%.
• 工具呼叫下降 35.5%.
• Token 消耗降低 29.8%.
• 平均成本下降了 21.6%.

雖然 REPL 可以重複使用執行環境狀態，但這項優勢並未減少互動次數。實際上，使用 heredoc 的 Agent 進行了更少的工具呼叫。

結果與我們之前的觀察相符。一旦進入 REPL，Agent 通常會運行一小段代碼，檢查結果，然後決定下一步做什麼。本來可以在單個程序內處理的循環、過濾器和決策被分佈在多個模型工具交換中。

這兩種環境提供相似的表達能力。他們的效率差異主要來自於他們的交互模式如何塑造 Agent 行為。至少對於這四個瀏覽器 Agent 任務，heredoc 更加一致地鼓勵模型組織完整的程序，將循環、過濾和決策推送到代碼中，並避免逐步決策的額外往返。

我們還通過將 ego-browser 與 Odysseys 資料集上類似的基於 REPL 的瀏覽器自動化產品進行比較，檢查了是否在更大範圍內保持了相同的模式。與上面的對照實驗不同，這次比較涉及兩個完整的產品，而不是通過兩個界面操作的同一模型。因此，它對於整體效率比較很有用，但它的差異不能完全歸因於 heredoc 與 REPL。

這並不是 Heredoc 的永久勝利

我們並不認為 Heredoc 本質上優於 REPL。

我們的結論取決於模型的能力、訓練資料的分佈以及 2026 年現有 Agent 工具的設計。

如今的 Agent 通常更擅長一次性生成完整的代碼塊。他們的 shell 工具也是圍繞簡單的生命週期設計的：提交命令，等待它退出，然後返回結果。在這些條件下，heredoc 可以更輕鬆地減少交互次數並將控制流移至本地執行的代碼中。

這些條件可能會很快改變。

未來的 Agent 工具可能會提供可靠的持久會話、結構化輸出和強大的狀態恢復。 Agent 可能不再需要自己處理 REPL 提示、進程狀態和中斷的會話。有針對性的培訓還可以教會模型在 REPL 內主動提交完整的程序，而不是陷入不必要的逐步交互。

如果發生這種情況，REPL 可以保留狀態重用和即時反饋的好處，而不需要更多的模型呼叫。對於具有昂貴初始化、長期狀態或真正探索性工作流程的任務，它們甚至可能成為更好的選擇。

這就是為什麼標題指定 2026。我們並不是聲稱發現了永恆不變的定律。這只是基於現有模型與 Agent 工具所做的階段性工程判斷。