2026年Agent更适合Heredoc式执行而非REPL式交互

背景

2025年左右，开发者们发现一个现象：只要将 Bash 工具暴露给 Coding Agent，它似乎就能完成几乎所有事——从代码编写到上下文查找，再到 Git 工作流执行。这催生了“万物 CLI 化”的趋势，甚至流行起一句话：“CLI Is All You Need”。然而，随着任务复杂度提升，Agent 模仿人类终端操作方式——执行一条短命令、读取结果、再决定下一步——导致模型与工具之间往返次数激增，带来更多的模型调用、上下文开销和等待时间。与此同时，模型在训练数据中已经熟悉了常见 CLI 工具（如 Git、Docker、FFmpeg）的用法，但当开发者构建全新的 CLI 时，模型需要学习一套全新的“微型语言”（子命令、参数、输出格式、错误语义），这增加了学习成本和出错概率。

基于这些观察，作者团队提出了一个优化思路：仍以 CLI 作为统一入口，但以代码作为实际的软件操作接口。Agent 一次编写一段代码，将原本分散在多轮交互中的操作、判断和数据处理交给本地代码执行环境完成。ego-browser 正是这一思路的实践：CLI 负责启动可编程环境，软件将能力暴露为少量函数，Agent 使用自己熟悉的编程语言进行组合与编排。博客核心是比较两种 CLI 中的代码执行方式——Heredoc（一次性提交完整代码块） 与 REPL（持久交互会话），并分享实验数据。

核心内容

问题动机：CLI 虽是通用入口，但传统命令式接口对模型不友好

传统命令式 CLI 要求模型理解每个子命令的含义、参数顺序、输出格式，并在多次工具调用中组合它们。例如，要让 Agent“打开网页并读取主标题”，模型可能需要先调用 ego-browser open，再调用 ego-browser find，再调用 ego-browser read，每步等待返回结果后决定下一步。这种逐步交互不仅增加轮次，也引入了更多上下文 Token 消耗和等待延迟。

设计选择：Heredoc 式代码执行

ego-browser 采用的方案是：Agent 将完整的任务逻辑写成一段 JavaScript（包含循环、条件、异常处理、数据处理），然后通过 Heredoc 一次性提交给执行环境。例如：

ego-browser nodejs <<'EOF'
await taskSpaces.useOrCreate("读取示例页面");
await browser.openOrReuseTab("https://example.com", { wait: true });
const heading = await page.getByRole("heading").textContent();
console.log(heading);
EOF

Shell 将代码块整体交给 ego-browser，执行完成后进程退出并返回结果。对 Agent 而言，这是一次普通的工具调用。

对比 REPL 式交互

REPL 模式下，解释器持续运行，Agent 可以多次输入代码，在会话中保留变量和状态。例如：

> await browser.openOrReuseTab("https://example.com", { wait: true })
< Tab {...}
> await page.getByRole("heading").textContent()
< "Example Domain"

REPL 理论上也可以一次提交完整代码块，但交互形式鼓励模型“先执行一小步，观察结果，再决定下一步”。这导致模型更倾向于逐步操作，而不是一次性编排完整的控制流。

模型行为倾向差异

作者观察到，这与模型训练数据的分布有关：REPL 风格的对话在教程、调试记录中常见，呈现为“输入表达式 → 查看结果 → 继续尝试”的模式。而 Heredoc 中的代码块更像脚本或源文件，模型需要在明确的开始和结束边界内完成任务，因此更容易一次写出连续的操作过程（如 const page = await openPage(); const element = await findElement(page); …）。这种倾向性被作者称为**“模型体验工程学”**——接口要顺应模型在训练中形成的行为倾向。

实验设计与数据

团队基于 Codex SDK 构建自动化测试，让同一个 Agent 通过 REPL 和 Heredoc 分别完成 4 类真实浏览器任务（在 X（原Twitter）抓取热门帖、在 OpenAI 申请岗位、使用 Redfin 计算房贷、在 Expedia 筛选航班），并汇总多次运行结果。

| 指标 | Heredoc | REPL | 差异 | |------|---------|------|------| | 任务成功率 | 77.5% | 75.0% | 略高 | | 平均耗时 | 降低 35.0% | - | - | | 中位耗时 | 降低 30.7% | - | - | | 工具调用次数 | 减少 35.5% | - | - | | Token 消耗 | 减少 29.8% | - | - | | 平均成本 | 降低 21.6% | - | - |

尽管 REPL 支持状态复用，但并未带来更少的交互；实际结果显示 Heredoc 的工具调用次数更少，因为任务中的循环、筛选和判断被集中到代码中，减少了逐步决策带来的多轮往返。

更广泛的数据验证

团队还在 Odysseys 数据集上将 ego-browser（Heredoc 模式）与另一款基于 REPL 的同类浏览器自动化产品进行了对比。由于两套完整方案差异更多，不能全部归因于 Heredoc/REPL，但整体效率趋势与前述实验一致。

关键要点

• 核心矛盾：传统命令式 CLI 要求模型学习大量新语法和参数组合，任务越复杂，模型与工具的往返越多，效率越低。
• 优化方案：仍以 CLI 作为入口，但让 Agent 用自己熟悉的编程语言（如 JavaScript）编写完整代码块，一次提交执行。
• Heredoc vs REPL：Heredoc 是一次性提交并退出进程；REPL 是持久会话、逐步交互。两者表达能力等价，但交互形式引导模型行为不同。
• 模型行为倾向：训练数据中 REPL 风格暗示“逐步探索”，Heredoc 风格暗示“一次性完整程序”。实际测试中，Agent 在 Heredoc 下更倾向于一次组织完整控制流（循环、条件、异常处理），减少模型调用。
• 实验效率提升：相比 REPL，Heredoc 在 4 类真实浏览器任务中平均耗时降低 35%，工具调用次数减少 35.5%，Token 消耗减少 29.8%，成本降低 21.6%。
• 前提条件：这些结论基于 2026 年的模型能力、训练数据分布和 Agent 工具形态。随着模型进步和工具支持强化（如持久会话、结构化输出），REPL 可能在探索性任务中更具优势。

意义与影响

这篇博客揭示了 Agent 工具设计中的一个微观却关键的工程决策：同样的可执行能力，通过不同的交互方式暴露给模型，会显著影响模型的调用行为和整体效率。它提出了“模型体验工程学”的概念——接口设计应考虑模型在训练数据中形成的习惯模式，而非仅从人类使用便利性出发。

对于 Agent 框架开发者而言，这意味着在构建新的 CLI 或工具时，应优先考虑将能力暴露为代码接口（如 Python/JS SDK），并配合 Heredoc 式的一次性执行模式，从而减少模型的多轮往返。这与当前主流“工具调用”范式（API 函数式调用）形成了有趣对比：代码接口允许模型利用其固有的编程能力进行组合，而工具调用仍需模型理解每个函数的签名和语义。

长期来看，该博客提醒社区避免将暂时的工程优化当作永久定律。随着基础模型能力提升和 Agent 运行时环境的成熟（如更可靠的持久会话、状态恢复、结构化输出），REPL 的优势（状态复用、即时反馈）可能重新显现。但至少在当前阶段，Heredoc 式执行是一个低成本、高效率的工程选择，尤其适用于浏览器自动化等需要多步骤编排的场景。这一思路也启发其他领域：对于 Agent 需要频繁调用且逻辑复杂的工具，封装为可编程代码接口 + 单次提交可能比逐步工具调用更经济。