Корпоративный энтузиазм вокруг автономных агентов строится на предположении, что модели способны выполнять многоэтапные рабочие процессы с минимальным контролем. Стандартные бенчмарки поставщиков подкрепляют эту иллюзию стерильными циклами выполнения, однако внедрение агентов в реальные бизнес-процессы быстро вскрывает пограничные случаи, которые скрыты за маркетинговыми демо. Как описал венчурный инвестор Томаш Тунгуз по итогам трех месяцев эксплуатации r2 — собственного агентного каркаса в рабочей среде, — настоящая автономия требует жестких архитектурных ограничений, а не слепого доверия.
Переосмысление очередей задач и человеческий контроль
Отказ от специализированных таск-менеджеров стал первым прагматичным решением. Тунгуз перенес очередь задач своего агента из Asana напрямую в Gmail: единый интерфейс входящих сообщений сделал зависшую работу слишком заметной, чтобы ее игнорировать. В такой схеме агент r2 обрабатывает задачи, пока цепочки писем архивируются со служебным ярлыком. Письмо возвращается в папку «Входящие» только после завершения действия или когда процессу явно требуется решение человека.
Поскольку агент не может похоронить переписку навсегда, почтовый ящик выступает жесткой системой эскалации. Ранее 24 цепочки писем незаметно зависали в статусе ошибок внутри Asana, не отправляя никаких уведомлений. Привязка исполнения к электронной почте гарантирует, что каждая застрявшая задача снова всплывет с пояснением в одну строку. Это не позволяет автоматизированным процессам бесследно исчезать в неконтролируемом бэклоге.
Парадокс самовосстановления и гибридная маршрутизация
Внедрение отказоустойчивости в агентные процессы неизбежно выявляет скрытые сбои до того, как система стабилизируется. Первые шесть недель работы r2 показатель ошибок оставался на идеальном нулевом уровне — обманчивая цифра была вызвана тем, что система молча поглощала сбои. Как только заработали автоматический трекинг и механизмы самовосстановления, зафиксированная доля ошибок подскочила до 15%, а затем достигла пика в 34%.
До появления системного мониторинга 21 цепочка оставалась в сломанном состоянии до 18 дней, что потребовало 112 ручных вмешательств через прямые SQL-запросы. Обновленная архитектура фиксирует сбои мгновенно: она повторяет неудачные операции четыре раза со случайной задержкой, а затем отправляет их в очередь недоставленных сообщений.
«Самовосстановление работает, но оно хрупкое: прежде чем число ошибок снизится, система вскроет их гораздо больше».
Как отметил Тунгуз, вывод этих сбоев наружу позволил каркасу автоматически откатить 65 некорректных развертываний (включая 42 из-за непройденных модульных тестов), перехватывая сломанный код до его попадания в продакшн. Однако у автоматического восстановления есть жесткие эксплуатационные границы: истекшие токены авторизации, нехватка памяти и случаи, когда модель выдает пространный текст вместо структурированного выполнения, по-прежнему требуют немедленного вмешательства человека.
Одновременная оптимизация расходов на вычисления и задержек потребовала создания явного уровня маршрутизации. Локальные открытые модели выполняют задачу за 4–6 минут с околонулевыми предельными издержками, тогда как коммерческие облачные модели справляются за 39 секунд с заметно более высокой точностью. Маршрутизатор r2 динамически распределяет уровни на основе приоритета задачи и ведет журнал решений, предотвращая зацикливание при переключении между моделями.
Структурное разделение и роль координатора
Для надежной работы r2 пришлось отказаться от монолитных промптов в пользу структурированных направленных ациклических графов (DAG). Вместо произвольных операций записи языковая модель генерирует строго валидированный JSON, где указаны действие, домен, обоснование и уровень уверенности. За выполнение отвечает детерминированный код приложения, после чего изолированный узел верификации проверяет изменение состояния. Это гарантирует, что модель никогда не проверяет собственную работу.
Автоматизация графа выполнения избавляет от операционной рутины, но не вытесняет техническое руководство. Устойчивая окупаемость инвестиций возникает не от ожидания полной автономии, а от отношения к агенту как к младшему сотруднику, чья работа контролируется строгими порогами маршрутизации, правилами автоматического отката и эскалацией сложных случаев на человека.