Почему исполнение в стиле heredoc лучше подходит для агентов ИИ, чем REPL в 2026 году

Ранние агенты кодирования показали нечто удивительно мощное: дайте агенту доступ к Bash, и он сможет делать практически все — от написания кода и сбора контекста до управления полными рабочими процессами Git.

Это понимание помогло стимулировать более широкое движение в сторону программного обеспечения, ориентированного на интерфейс командной строки. Интерфейсы командной строки стали выглядеть как стандартный способ сделать сложные приложения доступными для агентов ИИ, что породило знакомый лозунг:

CLI — это все, что вам нужно.

Но есть скрытая стоимость. Агенты часто используют терминал так же, как человек: запускают короткую команду, проверяют результат, а затем решают, что делать дальше. По мере того, как задачи становятся более сложными, это приводит к увеличению количества взаимодействий между моделью и ее инструментами, что означает больше вызовов LLM, больше потерь контекста и больше времени, затрачиваемого на ожидание.

Вместо того, чтобы просить агентов собирать сложные сценарии оболочки, мы бы предпочли, чтобы они координировали задачи на языке программирования, который они уже понимают. Это приводит к немного другой архитектуре:

Сохраняйте CLI как универсальную точку входа, но используйте код как реальный способ взаимодействия с программным обеспечением.

Агент отправляет блок кода, содержащий операции, решения и обработку данных, которые в противном случае были бы распределены по нескольким раундам взаимодействия. Затем локальная среда выполнения выполняет рабочий процесс.

ego-browser был построен на этой идее. Его CLI запускает программируемую среду, браузер раскрывает свои возможности посредством небольшого набора функций, а агент использует свои существующие навыки программирования для составления этих функций и организовать их.

В этой статье мы сравниваем Хередок и REPL, два способа выполнения кода через CLI и поделитесь результатами экспериментов ego-browser. С помощьюheredoc агент выполнил те же задачи за меньшее количество циклов выполнения на 44 %, с меньшим количеством вызовов инструментов на 35,5 % и с меньшими затратами на 21,6 %.

«CLI — это все, что вам нужно» — и что дальше?

Утверждение, что «CLI — это все, что вам нужно», предполагает, что модель уже знает, как использовать этот CLI.

Для таких известных инструментов, как Git, Docker и FFmpeg, это обычно не является проблемой. Во время обучения модели видели бесчисленное количество команд, учебных пособий, сценариев и сообщений об ошибках и уже знают аргументы и то, как команды сочетаются друг с другом.

Но когда мы создаем совершенно новый интерфейс командной строки для агентов, картина меняется. Каждый CLI имеет свои собственные подкоманды, аргументы, форматы вывода и семантику ошибок. Для модели это, по сути, новый мини-язык. Даже при наличии полной документации модель все равно сначала должна изучить правила, а затем путем повторных вызовов выяснить, как команды сочетаются друг с другом.

Вместо этого предоставьте те же возможности, что и API JavaScript или API на любом другом языке, и модели все равно придется изучать новые концепции предметной области, но ей больше не нужно заново изучать поток управления, структуры данных или композицию. Циклы, условия, обработка исключений и обработка данных — все остается на уже известном языке программирования.

Возьмите простую задачу: откройте веб-страницу и прочитайте ее основной заголовок. Если 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 принимает код, следующий вопрос: как агент должен передать этот код среде выполнения?

Строго говоря, heredoc — это синтаксис ввода оболочки, а REPL — это режим выполнения интерпретатора; они не находятся на одном и том же уровне абстракции. В этой статье на самом деле сравнивается однократное выполнение кода, введенного через heredoc в ego-browser, и постоянный интерактивный сеанс, построенный на REPL. Для краткости в дальнейшем мы будем называть их просто heredoc и REPL.

Один из вариантов — heredoc. В 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 result

REPL работает по-другому. Интерпретатор остается активным, позволяя агенту многократно вводить код, сохраняя при этом переменные и состояние сеанса:

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

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

С точки зрения выразительной силы они по сути эквивалентны. REPL может запустить полную программу с циклами, условиями и обработкой исключений за один раз, а heredoc может отправить только одну строку.

Явное различие заключается в жизненном цикле процесса. При использовании heredoc процесс завершается, как только код завершает работу; REPL поддерживает работу процесса интерпретатора в ожидании дальнейших входных данных. Это также означает, что они предъявляют разные требования к инструментам агентов. Heredoc работает непосредственно на знакомой модели запрос-ответ:

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

REPL требует от инструмента большего: постоянные процессы, управление сеансами, непрерывный ввод, прерывание и восстановление. Встроенные инструменты Bash большинства агентов не имеют таких возможностей. Сегодня среди основных продуктов только Codex поддерживает их достаточно хорошо. А поддержка инструментов — лишь необходимое условие использования REPL. Он не решает, как модель на самом деле будет его использовать. Даже если обе среды могут выполнять один и тот же код, модель все равно может писать код в каждой из них по-разному.

Как модели пишут код в каждой среде

Теоретически модель имеет одинаковые возможности программирования в обеих средах. На практике мы наблюдали устойчивую разницу в поведении:

• В REPL модель имеет тенденцию вводить код постепенно.
• В Heredoc более вероятно создание полной программы за один проход.

Программное обеспечение для людей должно учитывать эргономику. Программному обеспечению для агентов нужна аналогичная дисциплина: назовите это модельно-опытное проектирование. Интерфейс должен работать с моделями поведенческих шаблонов, разработанными в ходе обучения.

Контраст между 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 поощряет выполнять, наблюдать, продолжать узор. Гередок поощряет сначала организуйте, потом выполните узор.

Эта тенденция также определяет, где находится поток управления. В REPL модель скорее разбивает задачу на несколько этапов и решает, что делать после каждого результата. В Heredoc более вероятно размещение циклов, условий, фильтрации и обработки данных непосредственно в программе и предоставление возможности локальной среде выполнения обрабатывать их.

Что показали эксперименты

Среди основных инструментов агента, которые мы могли бы надежно интегрировать, Codex обеспечивал возможности выполнения, необходимые для постоянного REPL. Поэтому мы создали автоматизированный тест на основе SDK Codex: один и тот же агент выполнил четыре типа реальных задач браузера с помощью REPL и heredoc, и мы агрегировали результаты повторных запусков для сравнения.

Задачи были:

• X-анализ трендов: Соберите оригинальные сообщения OpenAI за последние семь дней, исключите закрепленные сообщения, репосты и ответы, ранжируйте пятерку лучших по просмотрам и рассчитайте их уровень вовлеченности и общий средний показатель.
• OpenAI заявление о приеме на работу: Найдите подходящую вакансию в облачной инфраструктуре в Сан-Франциско, загрузите резюме, заполните форму заявки и остановитесь перед окончательной подачей.
• Redfin расчет ипотеки: Отфильтруйте недвижимость в Остине по типу дома и цене, откройте первый результат после сортировки, измените первоначальный взнос на 20% и получите обновленную расчетную ежемесячную оплату.
• Expedia поиск рейса: Найдите прямой рейс в одну сторону из JFK в MIA, выберите самый дешевый вариант указанной авиакомпании, введите информацию о пассажире и остановитесь перед оплатой.

Эти задачи охватывали не только открытие страниц и чтение текста. Они включали структурированное извлечение, условную фильтрацию, навигацию по страницам, загрузку файлов, заполнение форм, изменение состояния страницы и вычисления, охватывающие большинство распространенных операций, выполняемых агентами браузера.

Оба подхода выполнили большую часть задач. Heredoc достиг показателя успеха 77,5% по сравнению с 75,0% для REPL. Разница в надежности была скромной.

Наибольшая разница заключалась в эффективности:

• Среднее время выполнения сократилось на 35.0%.
• Среднее время выполнения сократилось 30.7%.
• Вызовы инструментов сократились 35.5%.
• Потребление токенов сократилось на 29.8%.
• Средняя стоимость снизилась на 21.6%.

Хотя REPL может повторно использовать состояние времени выполнения, это преимущество не приводит к уменьшению количества взаимодействий. На практике агентheredoc совершал меньше вызовов инструментов.

Результаты совпали с нашими предыдущими наблюдениями. Попав внутрь REPL, агент часто запускал небольшой фрагмент кода, проверял результат и затем решал, что делать дальше. Циклы, фильтры и решения, которые могли быть обработаны внутри одной программы, вместо этого были распределены по нескольким обменам модель-инструмент.

Обе среды обладают одинаковой выразительной силой. Разница в их эффективности обусловлена прежде всего тем, как их модели взаимодействия формируют поведение агентов. По крайней мере, для этих четырех задач агента браузера,heredoc более последовательно поощрял модель организовывать полную программу, помещать циклы, фильтрацию и решения в код и избегать дополнительных циклов пошагового принятия решений.

Мы также проверили, сохраняется ли та же закономерность в более крупном масштабе, сравнив ego-browser с аналогичным продуктом автоматизации браузера на основе REPL в наборе данных Odysseys. В отличие от контролируемого эксперимента, описанного выше, в этом сравнении участвовали два законченных продукта, а не одна и та же модель, работающая через два интерфейса. Поэтому он полезен для сравнения общей эффективности, но его различия нельзя полностью отнести на счет heredoc и REPL.

Это не окончательная победа heredoc

Мы не считаем, что heredoc по своей сути превосходит REPL.

Наш вывод зависит от возможностей моделей, распределения их обучающих данных и конструкции инструментов агентов в том виде, в каком они будут существовать в 2026 году.

Сегодняшние агенты, как правило, лучше создают полный блок кода за один проход. Их инструменты оболочки также разработаны с учетом простого жизненного цикла: отправьте команду, дождитесь ее завершения и верните результат. В таких условиях heredoc упрощает сокращение циклов взаимодействия и перенос потока управления в локально исполняемый код.

Эти условия могут быстро измениться.

Будущие инструменты агентов могут обеспечить надежные постоянные сеансы, структурированные выходные данные и надежное восстановление состояния. Агентам больше не придется самостоятельно обрабатывать запросы REPL, состояние процессов и прерванные сеансы. Целевое обучение также может научить модели заранее представлять полные программы внутри REPL вместо ненужного пошагового взаимодействия.

Если это произойдет, REPL смогут сохранить преимущества повторного использования состояний и немедленной обратной связи, не требуя дополнительных вызовов моделей. Они могут даже стать лучшим выбором для задач с дорогостоящей инициализацией, долгоживущим состоянием или действительно исследовательским рабочим процессом.

Именно поэтому в названии указано 2026. Мы не претендуем на открытие постоянного закона. Это инженерное заключение на определенный момент времени, основанное на моделях и инструментах агентов, доступных сегодня.