Обзор AgentRun: когда workflow для ИИ-агентов оправдан

Обзор AgentRun: что это за инструмент на самом деле

AgentRun — интерпретатор workflow на TypeScript от Parcha, который добавляет детерминированную структуру вокруг инструментов, точечных решений модели и вызовов агента. Компания Parcha открыла исходный код 23 сентября 2026 года. Документ workflow задает контракты состояния, шаги, ветвления, лимиты и маршрут эскалации; инструменты, доступ к моделям, разрешения, хранилище и доставку предоставляет ваше приложение. Это не одноименный продукт Alibaba Cloud, не старый Python-пакет для выполнения кода, созданного моделью, и не мобильная игра 2014 года, которая до сих пор попадает в поисковую выдачу. Текущий основной пакет — @parcha/agentrun-dsl версии 0.1.0-beta.4, выпущенный по лицензии Apache-2.0.

Кому подходит Parcha AgentRun, а кому лучше пройти мимо

AgentRun рассчитан на команды разработки на TypeScript, у которых уже есть агентная среда и хотя бы одна повторяющаяся задача, где обычный код стало трудно анализировать. Хороший пример — маршрутизация обращений в поддержку: сначала выполнить поиск, затем оценить достаточность ответа, потратить один вызов агента только при необходимости расследования, после чего вернуть результат или передать случай человеку. Так же устроены проверка доказательств, маршрутизация согласований и исследовательские конвейеры. Максимальную пользу инструмент приносит, когда владельцу продукта, операционного процесса или риска нужно понимать поток управления, не распутывая сеть функций обратного вызова.

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

Выбирайте LangGraph.js, если главная задача — долгоживущий агент с состоянием, персистентностью, потоковой передачей и вмешательством человека. Выбирайте Temporal, если непреложное требование — надежное исполнение приложения при сбоях, сетевых ошибках и длительном ожидании. AgentRun предоставляет хуки восстановления, но не включает отказоустойчивый планировщик. Если команде нужны Python, выполнение в браузере, облачная панель или SLA для продакшена, beta.4 также будет неверным выбором: в этот релиз ничего из перечисленного не входит.

Возможность AgentRun DSL 1: типизированное состояние ловит расхождение контрактов

Первый сильный аргумент в пользу AgentRun DSL — отказ принимать итоговое значение, которое перестало соответствовать объявленному контракту. Это кажется базовой функцией, пока workflow не объединяет результат поиска, семантическое решение и отправку данных агентом. Без единого финального валидатора изменение формы данных в любой ветви может дойти до вызывающей стороны под видом частичного успеха.

В workflow поддержки свободная схема Candidate отделена от финальной Answer. Поиск может вернуть пустой текст или не найти источников, потому что такое состояние должно запускать расследование. У завершенного ответа требования строже: непустой текст и хотя бы один источник. В руководстве для авторов также описана проверка объявленных контрактов входа и выхода, а пути промежуточного состояния проверяются во время исполнения.

В тесте контракта было добавлено одно обязательное поле без изменения результата фикстуры:

schemaWorkflow.schemas.Answer.properties.resolutionCode = {
  type: 'string',
  minLength: 1,
};
schemaWorkflow.schemas.Answer.required.push('resolutionCode');

Ветка сброса пароля по-прежнему выполняла поиск справки и первое решение. Но на этапе завершения возникла ошибка WorkflowOutputInvalidError с кодом output_invalid, поскольку поле resolutionCode отсутствовало. Некорректный ответ наружу не попал. Именно так система и должна вести себя: остановиться на границе, а не выдать семантически правдоподобный объект за полностью соответствующий контракту результат.

У этой защиты есть четкий предел. Корректная строка text и корректный массив sources все равно могут содержать неверный ответ. Валидация схемы подтверждает, что потребляющий код сможет обработать значение, но не доказывает, что клиенту можно ему доверять. Дополнительный материал о маршрутизации обращений в поддержку с Jev разбирает именно этот уровень решений: даже вероятностям и типизированным результатам нужны размеченные примеры и запасной путь к человеку.

Возможность AgentRun workflow 2: ветвление ограничивает вызовы ИИ-агента

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

Каждый прямой запуск фикстуры завершился с документированным кодом. Сброс пароля, счет и неудачный платеж вернули код 0. Нерешенная проблема с платежом вернула код 2 и причину: после одного расследования ответ по-прежнему был недостаточным либо неопределенным. Во всех четырех случаях в stderr было записано ноль байт. Специализированный набор тестов поддержки из репозитория также прошел все 31 тест за 2.92 секунды, включая некорректные отправки, решения с низкой уверенностью, отмену и ошибки адаптеров.

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

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

Возможность 3: эскалация задана кодом, а не пожеланием в промпте

AgentRun превращает эскалацию в возвращаемое состояние исполнения с указанной причиной, а не в затерянную внутри промпта фразу. Проверенный workflow принимает ответ только тогда, когда решение равно yes, ответ соответствует контракту, а уверенность достигает 0.8. В противном случае он открывает очередь, допускающую от нуля до одного расследования, снова проверяет результат и эскалирует случай, если тот же порог опять не пройден.

Чтобы проверить, действительно ли число управляет поведением, порог в обоих сравнениях подняли с 0.8 до 0.98. Скриптовое решение в фикстуре сброса пароля осталось равным yes при 0.97. В исходном workflow этот случай немедленно завершался без вызова агента. В более строгом варианте он переходил к расследованию, получал тот же корректный ответ, снова возвращал yes при 0.97, а затем эскалировался после одного вызова агента и двух решений.

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

Эскалация также отделена от доставки. Среда исполнения возвращает complete или escalated, а хост решает, открыть ли обращение в поддержку, уведомить человека или ничего не делать. Такое разделение не позволяет документу workflow самому выдать себе разрешение связаться с клиентом или изменить его учетную запись.

Возможность 4: инспекция полезна, но интеграция остается вашей задачей

Инспекция AgentRun делает workflow понятным еще до исполнения кода, но не отменяет прикладную работу вокруг него. Для сгенерированного примера маршрутизации agentrun inspect вернул дайджест workflow, узлы judge, escalate и code, обязательный адаптер runJudge и значение executableCode: true. Команда validate вернула ok: true. Команда dry-run также вернула ok: true, явно указав, что синтетическая ветвь эскалации была пропущена.

Этот пропуск важен. Успешный пробный запуск подтверждает соединение компонентов, а не покрытие ветвей. Поведенческое доказательство дали четыре фикстуры поддержки, намеренно прошедшие через возврат, расследование и проверку человеком. Сохраняйте это различие в CI: инспекция проверяет структуру, валидация — контракты, а фиксированные сценарии — поведение.

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

Контрольная реализация обычной функцией делает компромисс особенно наглядным. Ее тело из 31 строки использовало те же скриптовые адаптеры и совпало с базовым вариантом по всем статусам и числу вызовов. Для единственного маршрута поддержки такую функцию проще читать и выпускать. Дополнительные 62 строки файла workflow в AgentRun дают переиспользуемый документ, универсальную инспекцию, общую семантику узлов, выходные контракты, структурированную эскалацию и поверхность, которую может генерировать агент-автор. Сокращения объема кода по умолчанию они не дают.

Та же граница лежит в основе более общего выбора между собственной разработкой и покупкой решения для внутренних агентных workflow: общая инфраструктура оправдана, когда объем повторяющейся операционной работы превышает стоимость ее поддержки.

Цена AgentRun beta: интерпретатор бесплатен, среда исполнения — нет

У AgentRun beta одна цена самого ПО: $0 за код под лицензией Apache-2.0. В beta.4 нет ни платного тарифа AgentRun, ни облачной среды исполнения AgentRun. Продукт состоит из npm-пакета, исходного кода, CLI, интерпретатора workflow и примеров. Parcha не включает в лицензию токены моделей, выполнение инструментов, хранилище, наблюдаемость или поддержку продакшена.

Jev — отдельная и необязательная статья расходов на модель принятия решений. Согласно проверенной актуальной странице моделей TypeSafe на 24 сентября 2026 года, Jev 1.13 стоит $0.042 за миллион входных токенов, а выходные токены бесплатны. При заявленном допущении в 500 входных токенов на решение одна проверка стоит $0.000021, две — $0.000042. Для 100,000 случаев такие вызовы модели принятия решений обойдутся соответственно в $2.10 или $4.20.

В этот расчет не входит расследование агентом. AgentRun может подключаться к любой агентной среде, предоставленной хостом, поэтому единой честной стоимости одного случая не существует. Профиль затрат обращения, завершенного после одной проверки Jev, отличается от случая с вызовом агента, инструментами, второй проверкой, хранилищем, логами и участием человека. В обзоре со скриптовыми ответами живые вызовы моделей не выполнялись, поэтому фактические расходы на инференс составили $0, а доказательность теста для оценки продакшен-затрат — столько же.

Temporal хорошо показывает, почему отказоустойчивый хостинг — отдельная покупка. Temporal Cloud сейчас стоит от $50 за миллион действий плюс хранение данных и включает $150 кредитов на 90 дней. AgentRun не берет такую платформенную плату, потому что не предоставляет сопоставимый облачный слой исполнения.

Реальные ограничения

Ограничения AgentRun достаточно серьезны, поэтому beta стоит внедрять через один ограниченный workflow, а не превращать в архитектуру по умолчанию.

1. Артефакты релиза по-разному указывают номер версии

Опубликованный манифест пакета указывает версию установленного пакета 0.1.0-beta.4, но вложенный README говорит Beta: 0.1.0-beta.3. Корневой README тега beta.4 также называет релиз beta.3, а в журнале изменений beta.4 помечена как невыпущенная. В текущей ветке main корневой README уже исправлен на beta.4, но пользователь, закрепивший опубликованный тег, увидит противоречивые сведения о статусе.

Интерпретатор от этого не ломается, но для системы workflow, где важна история версий, расхождение существенно. Закрепляйте версию npm, сохраняйте дайджест workflow и отдельно записывайте версии адаптеров и политик. Не пытайтесь восстанавливать продакшен-запуск по текстовому бейджу.

2. Нагрузка на хост — граница продукта

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

3. Хуки восстановления — не отказоустойчивое исполнение

Runtime предоставляет интерфейсы контрольных точек, memo, receipt и восстановления, но хранение и согласование реализует хост. Ключ идемпотентности помогает устранить дубликаты, но не гарантирует доставку exactly-once. Внешний эффект может завершиться уже после тайм-аута, поэтому перед повторной попыткой хост обязан проверить его окончательное состояние. Если главное требование — восстановление после сбоев, используйте Temporal. Если важнее персистентные графы агентов с состоянием, оцените LangGraph.js.

4. Доверенный JavaScript — жесткая граница безопасности

Узлы кода выполняют JavaScript с правами процесса, а валидация может запускать проверки. Флаг CLI --trusted лишь подтверждает риск, но не создает песочницу. Команда, принимающая workflow от пользователей, сгенерированные артефакты или данные из другой зоны доверия, должна изолировать их при помощи контролируемых хостом границ процессов, файловой системы, сети и учетных данных.

5. Типизированный результат все равно может оказаться уверенно неверным

Тест схемы завершился ошибкой именно так, как должен был, но он не способен обнаружить хорошо оформленный неверный ответ. Решение yes с высокой уверенностью все равно остается результатом модели. Workflow нужны размеченные примеры, пороги для конкретной задачи, продакшен-мониторинг и маршрут ручной проверки. Все 31 пройденный тест поддержки подтверждают только предоставленные сценарии, а не точность Jev на живых данных.

6. Выбор платформ и вариантов поддержки ограничен

Beta.4 — ESM-библиотека для Node.js с минимальной версией Node 22.19 и TypeScript 5.4 для пользователей TypeScript. Python, выполнение в браузере и облачная среда исполнения не поддерживаются. Для beta нет SLA продакшен-поддержки, а изменения API или исполнения между beta-релизами могут потребовать миграции.

7. Фиксированная функция неожиданно часто остается лучшей абстракцией

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

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

Вердикт: когда оркестрация ИИ-агентов с AgentRun оправдана

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

Но вердикт остается условным. Выбирайте AgentRun, только если верны все четыре утверждения: workflow повторяется; хотя бы одной модельной или агентной ветви нужен видимый предел; его должны инспектировать или генерировать несколько людей либо систем; хост способен взять на себя адаптеры, разрешения, восстановление, оценку и доставку. Если хотя бы одно условие не выполняется, начните с функции на TypeScript.

Используйте LangGraph.js, если продукт по своей сути является персистентным графом агента. Используйте Temporal, если в основе workflow лежит отказоустойчивый распределенный процесс. AgentRun занимает место между ними и обычной функцией: он уже каждой из этих сред исполнения, но структурированнее рукописного управляющего кода.

Практический следующий шаг прост. Возьмите одну существующую агентную задачу и отметьте каждый этап как детерминированный код, типизированное решение, расследование агента или ручную проверку. Если на диаграмме получилась одна прямая линия, оставьте функцию. Если есть повторяющаяся ветвь, где нужно контролировать расходы на агента или политику эскалации, перенесите в AgentRun именно ее, закрепите beta.4 и создайте четыре фикстуры до подключения живых моделей.

Частые вопросы об AgentRun