Ваш агент спит, пока мир меняется
Вы запускаете своего AI-агента на анализ кодовой базы из 200 файлов. Или на исследование рынка по 50 конкурентам. Что происходит дальше? Правильно — вы идете пить кофе, делать перекур, смотреть, как растет трава. Потому что ваш единственный агент сейчас уперся лбом в задачу, которая займет минимум час.
Блокировка — главная проблема любого фреймворка для агентов в 2026 году. Пока один агент копается в данных, остальная система замирает. Особенно обидно, когда у вас мощная инфраструктура — несколько GPU, распределенные сервера — а работает только один поток.
Вспомните исследование Stanford из нашей прошлой статьи. Да, параллельные агенты могут работать хуже. Но проблема не в параллельности как таковой, а в плохой координации. Deep Agents нашел способ это исправить.
Асинхронные под-агенты — не просто еще одна фича
В Deep Agents версии 3.8 (актуально на апрель 2026) появилась не просто новая функция, а архитектурный сдвиг. Теперь под-агенты могут работать полностью асинхронно, в фоне, не блокируя основной поток.
Что это дает на практике:
- Основной агент запускает под-агента и сразу возвращается к работе
- Под-агент работает где угодно — на том же сервере, в другом дата-центре, даже на вашем ноутбуке
- Состояние сохраняется автоматически, можно возобновить работу после сбоя
- Результаты под-агентов стекаются обратно, когда они готовы
Звучит как магия? Почти. Но под капотом — продуманная система очередей и stateful-контейнеров.
Stateful агенты: теперь они помнят все
Раньше под-агент был как одноразовый скрипт — запустили, получили результат, забыли. В новой архитектуре каждый под-агент — это полноценный stateful-процесс с собственной памятью.
Представьте агента, который анализирует научные статьи. Он скачал первую статью, начал читать — и тут отключили свет. В старой модели все потеряно. В новой — агент сохранил прогресс и продолжит с того же абзаца, когда питание вернется.
Гетерогенное развертывание: ваш агент везде
Самое интересное в обновлении — поддержка гетерогенных сред. Ваш основной агент может работать на дорогом инстансе с H100, а под-агенты — на более дешевых CPU-серверах, локальных машинах, даже на edge-устройствах.
| Тип развертывания | Когда использовать | Экономия |
|---|---|---|
| Локальный под-агент | Быстрая обработка небольших данных | 0$ за передачу данных |
| Удаленный CPU-сервер | Долгие вычисления без GPU | В 10 раз дешелее GPU |
| Специализированный инстанс | Обработка видео или 3D-графики | Не нужно покупать дорогое железо |
Как это работает технически? Каждый под-агент упаковывается в контейнер с указанием требований к ресурсам. Оркестратор Deep Agents сам решает, куда его отправить — на основе доступности, стоимости, задержки.
А чем это лучше обычных потоков?
Справедливый вопрос. Зачем городить сложную архитектуру с под-агентами, если можно запустить несколько потоков в Python?
Ответ простой: потоки — это про параллельность на одной машине. Асинхронные под-агенты — это про распределенную систему с отказоустойчивостью, балансировкой нагрузки и гетерогенными ресурсами.
Пять причин выбрать под-агентов:
- Если одна машина падает, задача автоматически переезжает на другую
- Можно комбинировать разные типы железа (GPU для ML, CPU для анализа текста)
- Платите только за реально использованные ресурсы
- Встроенный мониторинг — видите прогресс каждого под-агента в реальном времени
- Результаты кэшируются, можно переиспользовать без повторных вычислений
Если ваша задача умещается на одной машине и длится минуты — возможно, потоки хватит. Если речь про часы работы на разных инфраструктурах — без под-агентов не обойтись.
Пример из жизни: исследовательский агент
Представьте агента, который должен собрать информацию о 100 стартапах в сфере AI. Задача явно распараллеливается.
Как НЕ надо делать (старый подход):
Создать одного агента, который будет последовательно: 1) искать информацию о первом стартапе, 2) анализировать, 3) записывать результат, 4) переходить ко второму... И так 100 раз. Время выполнения — 5-6 часов.
Как делают сейчас:
Основной агент создает 10 под-агентов (stateful, удаленных). Каждому дает список из 10 стартапов. Под-агенты работают параллельно на разных серверах. Основной агент в это время может заниматься другими задачами или просто ждать, периодически проверяя статус.
Время выполнения сокращается до 30-40 минут. При этом если один под-агент упадет (например, из-за проблем с сетью), его задача автоматически перераспределится между остальными.
Эта архитектура напоминает принципы из статьи "Как правильно использовать суб-агентов", но выведенные на новый уровень. Здесь под-агенты не просто помощники, а самостоятельные рабочие единицы.
Код: как это выглядит на практике
Deep Agents сохраняет простой API даже для сложных функций. Вот как запустить асинхронного под-агента:
from deep_agents import AsyncSubAgent, RemoteDeployment
# Создаем под-агента с указанием ресурсов
sub_agent = AsyncSubAgent(
task="analyze_startup",
deployment=RemoteDeployment(
instance_type="cpu-large", # Тип инстанса
region="eu-west-1", # Регион
timeout_hours=2 # Максимальное время работы
),
stateful=True, # Сохранять состояние
callback=handle_results # Функция для обработки результатов
)
# Запускаем асинхронно - не блокируем основной поток
task_id = sub_agent.start_async({
"startup_name": "NeuroTech AI",
"analysis_depth": "deep"
})
# Основной агент может делать что-то еще
print(f"Запущен под-агент с ID: {task_id}")
print("Продолжаю работу, не жду...")
А вот как проверить статус и получить результаты:
# Проверяем статус без блокировки
status = sub_agent.get_status(task_id)
if status == "completed":
# Результаты готовы, забираем
results = sub_agent.get_results(task_id)
print(f"Результаты: {results}")
elif status == "failed":
# Что-то пошло не так, можно перезапустить
error = sub_agent.get_error(task_id)
print(f"Ошибка: {error}")
# Автоматический retry с сохранением прогресса
sub_agent.retry(task_id)
Обратите внимание на параметр stateful=True. Благодаря ему, даже если под-агент упадет на середине, при перезапуске он продолжит с последней успешной точки, а не начнет с нуля.
Когда это действительно нужно (а когда нет)
Асинхронные под-агенты — не серебряная пуля. Они добавляют сложности в архитектуру и имеют свои ограничения.
Используйте их, если:
- Задачи выполняются дольше 15-20 минут
- Нужно обрабатывать разные типы данных (текст, код, изображения)
- У вас доступны разнородные вычислительные ресурсы
- Требуется отказоустойчивость — задачи не должны теряться при сбоях
- Вы работаете с долгими экспериментами, которые идут часами или днями
Не используйте, если:
- Задачи выполняются за секунды или минуты
- Все данные и вычисления помещаются на одной машине
- У вас нет инфраструктуры для управления удаленными агентами
- Задачи требуют постоянной синхронной коммуникации между агентами
Помните про проблему координации из статьи про Stanford? Асинхронные под-агенты не решают ее автоматически. Если ваши под-агенты должны тесно взаимодействовать, возможно, лучше выбрать другую архитектуру — например, из нашей статьи об автономных агентах без роутинга.
Что будет дальше?
Асинхронные под-агенты в Deep Agents — это только начало. По слухам, в версии 4.0 добавят автоскейлинг под-агентов на основе нагрузки и интеллектуальный планировщик, который сам решает, сколько агентов запускать для конкретной задачи.
Но уже сейчас эта функциональность меняет подход к долгим задачам. Вместо "запустил и жди" получается "запустил и забудь" — система сама позаботится о выполнении, а вы получите уведомление, когда все будет готово.
Самое интересное — как эта технология сочетается с другими трендами 2026 года. Например, с continuous batching для роев агентов или специализированными моделями вроде Kilo Code. Представьте: под-агенты для анализа кода работают на оптимизированных под код моделях, а для анализа текста — на языковых. Все параллельно, все асинхронно.
Проблема уже не в том, как запустить много агентов. Проблема в том, как остановить их, когда они начнут слишком много успевать.