Распределённые агенты: когда ИИ живёт на разных машинах

За последний год мультиагентные фреймворки — LangGraph, Microsoft AutoGen, CrewAI — обзавелись механизмами, которые разносят агентов по разным процессам, серверам и даже устройствам. AutoGen выпустил слой AutoGen Core с асинхронной передачей сообщений между агентами, которые не обязаны жить в одном интерпретаторе Python. LangGraph получил LangGraph Platform с развёртыванием графов как отдельных сервисов. Идея одна: агент — это не функция внутри вашего скрипта, а сетевой узел, который можно масштабировать, перезапускать и держать за файрволом отдельно от остальных.

Это меняет то, как вы проектируете систему из нескольких ИИ-агентов. Раньше «мультиагентность» чаще всего означала цикл в одном процессе: планировщик вызывает исполнителя, тот вызывает критика, всё в одной памяти. Распределённая схема разносит роли по разным адресам в сети — и приносит с собой все радости распределённых систем: задержки, частичные отказы, необходимость сериализовать состояние.

Что значит «распределённый агент»

Под распределёнными агентами понимают систему, где отдельные агенты — автономные компоненты, которые сами решают, какой инструмент вызвать и что сделать дальше — общаются не через вызовы функций в общей памяти, а через сеть: очередь сообщений, gRPC, HTTP или брокер вроде Redis и RabbitMQ.

Практических конфигураций несколько:

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

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

Зачем вообще разносить агентов

Держать всё в одном процессе проще. Распределение оправдано, когда упирается что-то конкретное.

Масштабирование по нагрузке

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

Изоляция и безопасность

Агент с доступом к продакшн-базе или платёжному API опасно держать в том же процессе, что и агент, обрабатывающий пользовательский ввод. Prompt injection¹ через пользовательский текст может заставить агента вызвать инструмент, который вы не планировали. Сетевая граница с явным протоколом сообщений ограничивает, что один агент вообще может попросить у другого.

Данные, которые нельзя вывозить

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

Распределённая архитектура — это не про то, чтобы система стала умнее. Это про то, чтобы отказ одного агента не ронял всю систему, а чувствительные данные не покидали контур.

Как это делают основные фреймворки

Подходы отличаются радикально: от полноценного слоя сообщений до «просто запусти граф как сервис».

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

Общий узкий момент — состояние

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

Кому это пригодится, а кому нет

Распределение — не бесплатное улучшение. Оно добавляет сетевые задержки, точки отказа и сложность отладки. Стоит оно того не всегда.

Пригодится

• Продуктовым командам с реальной нагрузкой. Если один тип агента получает на порядок больше запросов, чем другие, отдельное масштабирование экономит деньги на GPU и API.
• Компаниям с закрытым контуром. Когда часть данных физически не может уйти в облако, локальный агент рядом с данными — не роскошь, а требование.
• Системам с опасными инструментами. Разнести агента, который пишет в базу, и агента, который читает ненадёжный ввод, — разумная мера против инъекций.

Не пригодится

• Прототипам и демо. Пока вы проверяете, работает ли идея вообще, распределение только замедлит итерации. Один процесс, один файл — и вперёд.
• Задачам без узкого места. Если система обрабатывает десятки запросов в день и всё влезает в один сервер, сеть между агентами добавит задержку и ничего не даст взамен.
• Командам без опыта эксплуатации распределённых систем. Отладка гонок, потерянных сообщений и рассинхрона состояния — отдельная дисциплина. Без неё распределённая архитектура превратится в источник плавающих багов.

Что учесть перед переходом

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

¹ Prompt injection — атака, при которой во входные данные встраивают текст-инструкцию, заставляющую агента отклониться от задачи: раскрыть данные или вызвать нежелательный инструмент. Для агентов с доступом к реальным действиям это основной класс рисков.