AWS Infinity: как снизить стоимость ожидания AI-агентов

23 октября 2026 года AWS Open Source и UC Berkeley представили Infinity в рамках проекта Hydro. Это ранний исследовательский open-source runtime для процессов, в которых одновременно работают многие AI-агенты. Его основная идея касается времени ожидания: агент вызвал инструмент, сохранил историю разговора и освободил исполняющий процесс. Когда ответ придёт, runtime восстановит состояние и продолжит работу.

Для бизнеса это знакомая ситуация. Агент собрал заявку, отправил её руководителю и ждёт решения. Или запросил данные из CRM, а внешняя система ответит позже. Весь период ожидания держать для него отдельный запущенный процесс затратно, особенно если таких заявок много. Infinity предлагает архитектуру, в которой вычисления запускаются по событию. Насколько она выгодна конкретной компании, покажут нагрузка, стоимость хранения и очереди, а также результаты пилота.

Что выпустили AWS и UC Berkeley 23 октября

Авторы опубликовали Infinity под лицензией Apache 2.0. В репозитории проекта он описан как runtime и протокол инструментов для конкурентной работы агентов. AWS прямо называет релиз ранним исследовательским. Это важная граница: публикация кода и лабораторный тест ещё не подтверждают пригодность для любой корпоративной системы.

Runtime делит работу каждого агента на короткие шаги, которые авторы называют execution slices. В ходе шага система загружает сохранённую историю, получает одно завершение модели, сохраняет результат и при необходимости отправляет вызов инструмента. Шаг заканчивается, пока инструмент выполняет свою работу. Ответ инструмента приходит отдельным сообщением и запускает следующий шаг.

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

Что именно измерили авторы

В публикации AWS приведён лабораторный бенчмарк с 80 000 агентами и 3,2 млн завершений модели. При использовании симулированной модели и хранилищ в памяти состояние простаивающего агента занимало около 100 КБ. По расчёту авторов, примерно 75 000 таких агентов помещаются в 8 ГБ памяти Raspberry Pi 5.

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

Почему ожидание стоит денег

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

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

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

Как это выглядит в бизнес-процессе

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

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

У такого сценария есть вопросы, которые Infinity сам за компанию не решит. Кто может согласовать счёт? Сколько действует решение? Что делать, если сумма поменялась во время ожидания? Как поступить при повторном webhook? Ответы нужны в правилах процесса до запуска пилота.

Что проверить перед пилотом

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

Затем проверьте технический контур:

1. Состояние. Где хранится история агента, кто может её читать, как долго она нужна и что происходит при удалении данных.
2. Очередь. Как событие попадает в нужный поток, что происходит при задержке доставки и как команда видит сообщения, требующие повторной обработки.
3. Повторы. По какому ключу система узнаёт уже обработанное событие. Повторная доставка не должна создавать второй платёж или дубль заявки.
4. Права. Какие инструменты агент может вызвать самостоятельно, а какие действия требуют утверждения сотрудником.
5. Наблюдаемость. Какие записи позволят восстановить путь: идентификатор потока, входное событие, вызванный инструмент, его результат и решение человека.
6. Возврат к ручной работе. Кто получает задачу, если интеграция недоступна или агент не может уверенно продолжить процесс.

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

Для пилота с собственными воркерами, очередью и длительными агентными задачами можно рассмотреть инфраструктуру Timeweb Cloud. На официальной странице своего решения с OpenClaw провайдер заявляет доступ к популярным моделям и оплату российской банковской картой, включая «Мир»; это предложение провайдера, а не готовое подтверждение совместимости Infinity с его сервисами. Развёртывание runtime, мониторинг, резервные копии и ручной маршрут при сбое потребуется проверить и настроить отдельно.

Как оценить экономику без обещаний

Сравнивайте пилот с тем способом, которым компания уже обрабатывает тот же процесс. Запишите число поступивших задач, длительность полезных вычислений, время ожидания, стоимость вызовов модели, хранение истории, работу очереди и поддержку системы. Показатель «сколько агентов создано» мало объясняет: один агент может ждать сутки, другой непрерывно вызывать инструменты.

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

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

Какие исключения показать на пилоте

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

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

Где уместен мультиагентный контур

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

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

Для работы с несколькими агентными ролями можно изучить HERMES. По этой ссылке заявлены $15 на подписку HERMES. Перед применением к рабочим данным проверьте условия сервиса, права инструментов и маршрут человеческого подтверждения. Выбор агентного инструмента и выбор runtime для исполнения процессов решают разные задачи; совместимость конкретной связки следует испытывать отдельно.

План руководителя на ближайшую неделю

1. Найдите процесс, в котором ожидание внешнего события заметно длиннее активной обработки. Попросите команду показать реальные задачи и таймкоды, а не оценку по памяти.
2. Нарисуйте состояния процесса: получено, проверяется, ждёт решения, подтверждено, отклонено, ошибка. Укажите, какое событие переводит задачу между состояниями.
3. Назначьте владельца каждого перехода. Отдельно отметьте операции, которые агенту разрешено выполнять без человека.
4. Проверьте повторную доставку, задержку события и потерю доступа к внешнему сервису. Для каждого случая нужен понятный исход задачи.
5. Запустите пилот на ограниченной очереди. Сравните стоимость инфраструктуры, срок обработки, ручные касания и ошибки с текущим порядком работы.

После пилота принимайте решение по результату своего процесса. Infinity показывает, как долгоживущий агент может освобождать вычисления между событиями. Ранний статус проекта требует проверки под вашу нагрузку и ваши требования к данным. Самая полезная отправная точка здесь - процесс с долгим ожиданием и ясным событием возврата.

Источники

• AWS Open Source: Introducing Infinity, 23 октября 2026 года
• Репозиторий Hydro Project: Infinity
• AWS News Feed: обзор релиза Infinity, 23 октября 2026 года

Если хочешь внедрить ИИ агентов в свой бизнес, но не знаешь с чего начать, пиши мне в телеграм t.me/berdoff, я проведу бесплатную консультацию, поделюсь своим опытом.