为什么到 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 工具的时间点工程判断。