Агенты поверх микросервисов: архитектурная революция или очередной хайп?

Что не так с текущим подходом?

Посмотрите на типичную AI-ERP сегодня. Это монстр с тремя головами:

• Монолитный агент, который пытается делать всё и сразу. Планирует закупки, ведет бухгалтерию, общается с клиентами. И в итоге ничего не делает хорошо.
• Разрозненные микросервисы, написанные десятью разными командами. У каждого свой API, свой формат ошибок, своя логика.
• Клей-код на Python, который должен это всё соединить. Тысячи строк скриптов, которые ломаются при любом изменении.

Концепция: не агенты ИЛИ микросервисы, а агенты НАД микросервисами

Забудьте про выбор между двумя подходами. Правильный ответ — использовать оба, но на разных уровнях абстракции.

Агенты думают на языке бизнеса. "Найди поставщика с лучшими условиями". "Спланируй производство на следующую неделю". Микросервисы выполняют конкретные технические задачи. "Получить данные из таблицы suppliers". "Рассчитать оптимальный маршрут".

Почему это работает там, где другие подходы падают?

Потому что мы разделяем ответственность:

• Агенты умеют думать, но плохо считают. LLM-модели отлично генерируют планы, но ужасно выполняют точные вычисления.
• Микросервисы умеют считать, но не думают. Они надежно обрабатывают данные, но не могут принять бизнес-решение.
• Семантический слой переводит между этими мирами. Это универсальный переводчик.

Вспомните статью про production-ready AI-агентов. Там мы говорили о важности надежности. Так вот, эта архитектура дает именно это.

1 Начинаем с графа знаний

Прежде чем строить что-либо, нужно понять, что строите. Граф знаний — это карта вашего бизнеса.

Не путайте с базой данных. База данных хранит факты. Граф знаний хранит смыслы.

Что должно быть в графе:

• Сущности: поставщик, заказ, товар, договор
• Отношения: поставщик_предлагает_товар, заказ_содержит_товар
• Бизнес-правила: минимальная сумма заказа, требуемые лицензии
• Метаданные: кто отвечает, SLA, приоритеты

2 Строим семантический слой (USDL)

Universal Semantic Data Layer — это не модное слово. Это необходимость.

Представьте: у вас 50 микросервисов. У каждого свой API, свои форматы данных, свои ошибки. Агент не должен знать все эти детали.

USDL делает две простые вещи:

1. Переводит бизнес-запросы на язык микросервисов
2. Унифицирует ответы от разных сервисов

Как это выглядит на практике:

# Вместо этого (плохо):
# Агент напрямую вызывает микросервис
response = requests.post(
    'http://procurement-service/v1/orders',
    json={"supplier_id": 123, "items": [...]}
)

# Делаем так (правильно):
# Агент работает с семантическим слоем
response = semantic_layer.execute(
    action="create_purchase_order",
    params={
        "supplier": "ООО Поставщик",
        "items": [{"product": "Болт М10", "quantity": 1000}],
        "urgency": "high"
    }
)

Семантический слой сам решает:

• Какой микросервис вызвать
• Как преобразовать данные
• Как обработать ошибки
• Как кэшировать результаты

3 Проектируем агентов как специалистов

Один большой агент — это катастрофа. Десять маленьких специализированных агентов — это решение.

Возьмите бизнес-процесс "управление закупками". Разбейте его на специалистов:

Каждый агент имеет:

• Четкую область ответственности
• Свой набор инструментов (через семантический слой)
• Свои метрики успеха
• Механизмы эскалации (когда не может решить сам)

4 Оркестрация: кто управляет агентами?

Самая сложная часть. Агенты не должны общаться напрямую. Это приводит к хаосу.

Вводим супервизора — специального агента, который:

1. Принимает задачу от пользователя или системы
2. Разбивает её на подзадачи
3. Назначает подзадачи специализированным агентам
4. Следит за выполнением
5. Собирает результаты
6. Принимает финальное решение

Супервизор — это тоже агент, но более высокого уровня. Он использует граф знаний, чтобы понимать, какие специалисты нужны для задачи.

# Упрощенная логика супервизора
class ProcurementSupervisor:
    def handle_request(self, task: str):
        # Анализируем задачу
        analysis = self.analyze_task(task)
        
        # Определяем нужных специалистов
        needed_agents = self.identify_agents(analysis)
        
        # Создаем план выполнения
        plan = self.create_execution_plan(needed_agents)
        
        # Координируем выполнение
        results = []
        for step in plan:
            agent = self.get_agent(step.agent_type)
            result = agent.execute(step.task)
            
            # Проверяем результат
            if not self.validate_result(result):
                # План Б: пробуем другого агента или эскалируем
                result = self.handle_failure(step, result)
            
            results.append(result)
        
        # Принимаем финальное решение
        return self.make_final_decision(results)

Технические детали, которые все игнорируют (и потом плачут)

Мониторинг агентов — это не мониторинг серверов

Вы не можете просто смотреть на CPU и memory. Агенты — это когнитивные системы.

Что нужно мониторить:

• Качество решений: насколько решения агента соответствуют бизнес-правилам
• Стоимость выполнения: каждый вызов LLM стоит денег
• Время размышления: как долго агент "думает" перед действием
• Частота эскалаций: как часто агент просит помощи у человека
• Консистентность: дает ли агент одинаковые ответы на одинаковые вопросы

Безопасность в мире агентов

Агенты имеют доступ к данным. Много данных. И они могут принимать решения.

Три уровня защиты:

1. Контекстуальные ограничения: агент видит только те данные, которые нужны для его задачи
2. Проверка решений: прежде чем выполнить действие, оно проверяется на соответствие политикам
3. Аудит всех действий: полная запись кто, что, когда и почему сделал

Помните статью про архитекторов данных? Там мы говорили о важности governance. С агентами это в десять раз важнее.

Управление состоянием: помнит ли агент, что делал вчера?

Короткий ответ: должен помнить. Но не всё.

Два типа памяти:

• Краткосрочная: контекст текущей задачи. Хранится в Redis, очищается после завершения.
• Долгосрочная: извлеченные уроки, паттерны, предпочтения. Хранится в векторной БД с семантическим поиском.

Пошаговый план внедрения (без фанатизма)

Не пытайтесь перестроить всю компанию за неделю. Это путь к провалу.

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

Чего ждать в ближайшем будущем?

К 2027 году эта архитектура станет стандартом для корпоративных систем. Почему?

• Модели станут дешевле. Вызов Claude 3.7 сегодня стоит X, через год будет стоить X/3.
• Появятся специализированные модели для конкретных бизнес-задач. Уже сейчас есть модели, fine-tuned на финансовых отчетах или юридических документах.
• Инструменты оркестрации созреют. Сегодня нужно много кодить, завтра будет достаточно настроить.

Но главное изменение — в роли IT-отдела. Из "строителей систем" они превратятся в "тренеров агентов". Ваша задача будет не писать код, а учить AI понимать ваш бизнес.

FAQ: вопросы, которые вы постеснялись задать

Сколько это стоит?

Первый пилот — от $50к до $100к. Полномасштабное внедрение — от $500к. Но ROI при правильной реализации — 200-300% в год. Потому что сокращаются операционные затраты, ускоряются процессы, уменьшаются ошибки.

Какие команды нужны?

Не только разработчики. Нужны: бизнес-аналитики (понимают процессы), дата-сайентисты (настраивают модели), ML-инженеры (развертывают), security-специалисты (защищают). Плюс самое важное — subject matter experts из бизнеса, которые будут "обучать" агентов.

Что делать с существующими ERP?

Не выбрасывать. Агенты могут работать поверх SAP, Oracle, 1С. Семантический слой выступает как адаптер. Постепенно можно мигрировать функциональность в микросервисы, но это многолетний процесс.

Как избежать катастрофы, когда агент примет неправильное решение?

Три защиты: 1) Человек в петле для критических решений. 2) Система проверок перед исполнением. 3) Страховочный механизм отката. И да, будут ошибки. Но людей тоже ошибаются. Разница в том, что агента можно улучшить, и он не устает в 18:00.

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