Оркестр агентов: Архитектура, память и экономика мультиагентных систем

Оркестр агентов: Архитектура, память и экономика мультиагентных систем

ВАЖНОЕ ПРЕДУПРЕЖДЕНИЕ ДЛЯЧИТАТЕЛЯ

Версия текста книги 1.82

Информация в этой книге носит ознакомительный характер. Мультиагентные системы развиваются быстро – никто не гарантирует абсолютную точность расчётов, архитектурных рекомендаций и юридических советов.

Как создавалась книга

Автор использовал подход, описанный в книге: гибридная оркестрация человека и ИИ. LLM была агентом-редактором, генератором примеров и оппонентом. Автор – оркестратором: ставил задачи, отсекал галлюцинации, переписывал и решал, что оставить. Это живой эксперимент над тем самым роем агентов.

Об ответственности

Автор не гарантирует:

· точность Cost Per Task и CoF (глава 5);

· применимость паттернов (глава 1) к вашей системе;

· безопасность решений из главы 6 без реального юриста.

· Цифры меняются. API дорожают. Ваша задача уникальна.

Используйте на свой страх и риск

Автор не несёт ответственности за счета за API, бесконечные циклы агентов, судебные иски или потерю данных. Воспринимайте книгу как мнение архитектора, набившего шишки. Не как истину.

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

Осторожно: избыточное усложнение

В книге описана архитектура, рассчитанная на промышленные масштабы (миллионы запросов, десятки агентов, регуляторный комплаенс). Если вы делаете пилот на 1000 пользователей, вам не нужны 4 уровня памяти, графы знаний и Event Sourcing. Начинайте с общей памяти (Redis) и паттерна Supervisor. Усложняйте только когда начнёт болеть. Автор не несёт ответственности за перепроектирование и сгоревшие бюджеты.

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

ЮРИДИЧЕСКИЕ ПРЕДУПРЕЖДЕНИЯ (обязательны к прочтению перед внедрением)

1. Финансовые операции и лицензирование ЦБ РФ

Если ваш ИИ-агент инициирует переводы, списания, приём платежей или любые иные операции с денежными средствами, такая деятельность может требовать лицензии Центрального банка РФ (ст. 13 Федерального закона «О банках и банковской деятельности»). Автоматизация финансовых операций без лицензии – уголовно наказуемое деяние (ст. 172 УК РФ – незаконная банковская деятельность). Никогда не передавайте агенту полномочия по инициации платежей без встроенного HITL и отдельного модуля комплаенс, который проверяет каждую операцию на соответствие 115-ФЗ до её выполнения.

2. Персональные данные (152-ФЗ) и трансграничная передача

Обработка персональных данных граждан РФ (включая косвенные PII – IP-адрес, Device ID, историю диалогов) строго регулируется 152-ФЗ. Псевдонимизация («замена Иванова на Клиент 12345») не отменяет требования получать письменное согласие субъекта. Передача ПДн в зарубежные LLM API (OpenAI, Anthropic, Google, Mistral API и др.) является трансграничной передачей и допустима только при наличии письменного согласия и если страна получателя обеспечивает адекватную защиту данных. Для работы с ПДн граждан РФ рекомендуется использовать локальные модели (Qwen, LLaMA, GigaChat, YandexGPT), развёрнутые на серверах в РФ, либо API российских провайдеров, гарантирующих локализацию данных.

3. HITL и ответственность за решения агента

Утверждение о том, что HITL (человек в контуре) «переключает ответственность с интегратора на оператора», юридически неверно. HITL создаёт доказательство того, что человек имел возможность контролировать действие, но не снимает ответственность с разработчика/интегратора за опасные ошибки системы (например, непрозрачный интерфейс, скрытые галлюцинации, манипулятивные формулировки). Окончательное распределение ответственности определяется судом в каждом конкретном случае. Настоятельно рекомендуется страховать риски и заключать договоры с чётким разделением ответственности между оператором и интегратором.

4. Уголовная ответственность за реализацию описанных атак

В главе 4.1 описаны потенциальные векторы атак (каскадная инъекция, отравление памяти, подмена идентичности). Эта информация приведена исключительно в образовательных целях – для понимания уязвимостей и их предотвращения при проектировании защищённых систем. Реализация описанных атак без разрешения владельца системы является преступлением, предусмотренным ст. 272, 273, 274.1 Уголовного кодекса РФ (неправомерный доступ к компьютерной информации, создание и распространение вредоносных программ, воздействие на критическую информационную инфраструктуру). Автор не несёт ответственности за использование знаний из этой книги в противоправных целях.

5. 115-ФЗ (ПОД/ФТ)

Если ИИ-агент участвует в финансовых операциях, он обязан соблюдать требования 115-ФЗ: идентификация клиента, фиксация операций, проверка на санкционные списки, информирование Росфинмониторинга. Неисполнение влечёт административную (ст. 15.27 КоАП РФ) и уголовную ответственность (ст. 174 УК РФ – легализация денежных средств). Разработчик и оператор могут быть признаны соучастниками.

Названия компаний и продуктов, упомянутые в этой книге, являются товарными знаками их соответствующих владельцев. Эта книга не одобрена, не спонсируется и не аффилирована с компанией Anthropic

Отдельное предупреждение о сфере применения

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

Упоминания конкретных LLM-моделей (GPT, Qwen, Claude, Llama) приведены в качестве примеров и не являются утверждениями о наличии у этих моделей системных недостатков, предвзятости или дефектов. Результаты работы каждой модели зависят от множества факторов, включая настройки, контекст и входные данные. Для получения объективной информации о характеристиках моделей обращайтесь к официальной документации провайдеров.

Неровности и пробелы

Странные переходы? Повторы? Места, где хочется подробностей? Так задумано. Книга побуждает задавать вопросы, а не даёт жёваные ответы.

Математика и схемы

Формул почти нет – вы подставите свои числа. Все схемы сгенерированы ИИ (Qwen). Стрелки могут врать. Цвета условны.

Связь с книгой «Инжинирия искусственного интеллекта»

Возможно, вы открыли сразу эту книгу – и не читали предыдущие. Это нормально. Каждая книга из серии «Инжинирия искусственного интеллекта» написана как самостоятельный текст. Но чтобы вы понимали, как они устроены и куда двигаться дальше, вот краткая карта.

Книга 1 – фундамент: как работает LLM, выбор модели, TCO, архитектурные ошибки.Книга 2 – продакшн: агентные системы, экономика проектов, компетенции.

Эта Книга (3) – не просто следующая глава. Это прямое продолжение всей серии. Она вбирает в себя основы первых двух книг и разворачивает их в сторону мультиагентных экосистем: оркестрация, память, наблюдаемость, экономика ошибок, право.

Вы можете читать книги по отдельности. Но если в главе 2 этой книги покажется, что про event sourcing рассказано слишком быстро или вы не понимаете, как агент принимает решение, – вернитесь к Книге 2. А если споткнётесь о внутреннем устройстве модели – откройте Книгу 1.

Информация в этой книге носит ознакомительный характер. Мультиагентные системы развиваются быстро - никто не гарантирует абсолютную точность расчётов, архитектурных рекомендаций и юридических советов.

ВВЕДЕНИЕ

«Один агент - это инструмент. Десять агентов - это команда. Сто агентов - это хаос, который нужно превратить в систему.»

В Книге 1 мы разобрали физику LLM (как работает трансформер). В Книге 2 мы научились строить продукты (агенты, RAG, TCO, внедрение).

Но что происходит, когда ваш пилотный проект взлетает? Когда один чат-бот превращается в отдел обслуживания клиентов? Когда один аналитик данных превращается в департамент бизнес-аналитики?

Вы сталкиваетесь с тремя проблемами, которых нет в учебниках по промпт-инжинирингу:

Масштаб

Один агент не справляется со сложной задачей. Ему нужны помощники. Но как заставить их не перессориться?

Надежность

Как понять, почему система из 50 агентов приняла странное решение, если каждый из них прав по-своему?

Ответственность

Кто платит, если автономная система нарушила закон, удалила базу данных или обидела клиента?

Эта книга - про переход от «игрушечных демо» к «скучным, надежным энтерпрайз-системам». Здесь нет магии. Есть архитектура, шины данных, юридические риски и инженерия доверия.

Поехали.

ГЛАВА 1. ПОЧЕМУ ОДИН АГЕНТ НЕ МОЖЕТ ВСЁ

«Дайте мне точку опоры, и я переверну мир». Но если точка опоры - это одна большая языковая модель (LLM), а мир - это корпоративная ERP-система, то вы не перевернете мир. Вы сломаете спину модели.

Под "агентом" в этой книге понимается:

LLM + набор инструментов (вызов API, SQL, чтение файлов) + инструкция (промпт), которая определяет его роль. Агент не просто "отвечает", а выполняет действия.

Если у вас работает один LLM-агент и вы довольны - эта глава для вас.

Потому что через 3–6 месяцев вы упрётесь в четыре стены:

· Агент начнет "тупить" на длинных задачах.

· Счёт за API вырастет в 10 раз без роста качества.

· Вы не сможете добавить новую роль (например, "проверка договора"), не сломав старые.

· Ошибка в одном месте обрушит всё.

Эта глава - не про теорию. Это про боль, которая придёт к вам неизбежно.

1.1. Крах монолитного агента

В главе 6 Книги 1 мы говорили о том, что будущее за оркестром, а не за монолитом. Давайте посмотрим, почему это не просто модное слово, а суровая необходимость.

Представьте, что вы нанимаете одного сотрудника на должность:

· Генерального директора;

· Главного бухгалтера;

· Старшего разработчика;

· Юриста;

· И уборщика.

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

Что сделает этот «универсальный солдат»?

Он начнет генерировать SQL-код. Ошибется в синтаксисе. Потратит 50% контекстного окна на отладку ошибки. Забудет, зачем он вообще начал этот запрос - это называется Drift of Intent (дрейф цели). Сгенерирует красивое, но юридически ничтожное письмо, потому что его «внимание» рассеяно между кодом, налоговым кодексом и стилем общения.

Это называется Context Pollution - загрязнение контекста, когда в одном окне смешаны взаимоисключающие роли. Это не просто «много информации». Это системный эффект, где шум, конфликт приоритетов и затухание релевантности работают вместе.

Но есть пример и пострашнее (и смешнее).

Попросили монолитного агента: «Найди в логах ошибки 500. Если их больше 10 - отправь в Slack предупреждение молнией, если меньше - просто запиши в файл». Что сделал агент? Он увидел первую ошибку, написал про нее поэму в духе Шекспира, потом забыл про условие, начал анализировать лог как литературное произведение, открыл 15 вложенных друг в друга тегов «think», сгенерировал JSON, который сам же не смог распарсить, и финальным действием отправил в Slack самоуничтожающееся сообщение с капчей. Потому что его «внимание» пыталось быть одновременно сисадмином, поэтом и маркетологом.

Монолитный агент обречен, потому что вы не можете одновременно:

· Убрать шум (нужны и код, и письма, и законы);

· Согласовать приоритеты (аудитор и оптимизатор несовместимы);

· Удержать релевантность через длинный разнородный контекст.

У любой LLM есть предел эффективного внимания. Даже если технически окно поддерживает 1 миллион токенов, модель начинает «терять нить», если в контексте смешаны системные инструкции («Ты - строгий аудитор»), код на Python, таблицы с данными и черновики писем.

Результат

Модель выбирает усредненный, посредственный вариант, который не удовлетворяет ни одну из ролей.

А теперь - про цену ошибки

В монолитном агенте нельзя откатить одну роль. Если он ошибся в налоговом кодексе - вы не можете исправить только юриста, не трогая разработчика. Вы перезапускаете всего агента заново, теряя прогресс по коду и письму. Это не просто «медленно» - это дорого. В оркестре вы перевызываете одного налогового агента за 0.2 секунды.

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

Итак, монолитный агент задыхается в собственном контексте. Но это - только вершина айсберга. Даже если вы каким-то чудом решите проблему перегрузки, вас ждут еще три способа, которыми монолит развалится на части:

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

О них - в следующих разделах.

1.2. Три смерти монолита

У подхода «одна модель на всё» есть три фатальных слабости. Назовём их тремя смертями монолита.

Смерть первая: Конфликт ролей (Role Conflict)

LLM (Large Language Model, большая языковая модель та самая, на которой работают ChatGPT и аналоги) очень чувствительны к системному промпту - инструкции, которую вы даёте перед началом диалога.

Если вы напишете:

«Ты - креативный маркетолог, который хочет продать любой ценой. Но также ты - строгий юрист, который минимизирует риски».

модель войдёт в ступор. Стиль ответа будет шизофреничным. Она начнёт фразу с «Срочно купите!» и закончит «но мы не гарантируем законность этой сделки».

Гипотетический пример

Агента попросили одновременно написать продающий пост и отметить в нём все возможные нарушения закона о рекламе.

Он написал:

«Купите наш чудо-порошок - он стирает всё! Данное утверждение не проверено и может быть незаконным».

Ни продать, ни обезопасить. Каша.

В реальных задачах роли действительно противоречат друг другу:

· Продавец хочет максимизировать конверсию.

· Служба безопасности хочет заблокировать всё подозрительное.

Один агент не может одновременно оптимизировать две противоположные метрики.

Почему это смерть?

Модель не ищет компромисс - она выдаёт кашу. Вы получаете ответ, который не годится ни для продажи, ни для юриста. Вы перезапускаете агента с новым промптом - он снова путается. Бесконечный цикл.

Смерть вторая: Отсутствие изоляции ошибок (No Fault Isolation)

В монолитной системе ошибка на шаге 1 заражает весь процесс.

Пример (без кода, жизненный). Агент должен:

· Прочитать PDF со счётом.

· Вытащить дату платежа.

· Сверить с календарём.

· Отправить напоминание, если просрочка.

Агент неправильно распарсил (то есть извлёк и интерпретировал) дату: увидел «10.02» и решил, что это 10 февраля, хотя на самом деле это 2 октября (формат перепутан). Дальше он:

· Сверяет с календарём 10 февраля (это прошедшая дата);

· Пишет «вы просрочили платёж на 3 месяца»;

· Отправляет агрессивное письмо директору.

Всё потому, что нет санитарного кордона. Монолит сам же себя проверяет - а значит, с высокой вероятностью не заметит ошибку. Нет модуля, который сказал бы: «Стоп. Твой коллега-аналитик прислал бред. Не используй эти данные».

Представьте масштаб

Если эта ошибка происходит в системе, которая обрабатывает 10 000 счетов в день, то каждый следующий шаг (сверка с календарём, отправка писем, начисление пеней) будет множить ложь. В монолите вы даже не узнаете, где именно пошёл сбой, - потому что нет отдельного модуля-валидатора, который закричал бы: «Стоп! Дата из второго шага - прошедшая, проверьте парсер (модуль, который извлекает дату из документа)».

В оркестре изоляция есть: агент-парсер даты отправляет результат в отдельный валидатор. Если дата выглядит подозрительно (например, прошедшая или вне разумного диапазона), валидатор бьёт тревогу, и процесс останавливается. Ошибка одного не убивает всю цепочку.

Почему это смерть?

В монолите вы не можете «откатить только парсер». Вы правите одну строчку в промпте - перезапускаете всего агента. Ошибка тихо размножается, как вирус.

Смерть третья: Экономическая неэффективность (Token Waste)

Запускать GPT-4o (или аналог) для задачи «переведи текст с английского на русский» - это как вызывать вертолёт, чтобы перевезти соседа через дорогу. Дорого, медленно, избыточно.

Конкретная арифметика

Возьмём простую задачу: из 10 000 сообщений поддержки найти те, где есть слово «не работает», и переслать их в отдел разработки.

Монолитный агент на GPT-4o

Каждое сообщение он прогоняет через полную модель (с её «интеллектом», рефлексией, веером рассуждений). Стоимость - $30 за тысячу сообщений. Итог: $300.

Узкий агент на маленькой модели (например, GPT-3.5-turbo или даже локальная BERT-подобная): стоит $0.50 за тысячу сообщений. Итог: $5.

Разница в 60 раз. И большую часть времени «умная» модель просто спит на рабочем месте.

При 100 000 запросов в день разница превращается в $30 000 в день на монолите против $500 на оркестре. За месяц - почти миллион долларов разницы. При масштабировании монолит разоряет бюджет.

В монолите вы вынуждены гонять тяжёлую LLM даже для тривиальных действий, потому что «агент один и он должен всё уметь». В оркестре вы даёте дорогой модели только сложные задачи (написать договор, проанализировать конфликт юрисдикций), а фильтрацию, извлечение дат, перевод шаблонных фраз отдаёте дешёвым специалистам.

Знакомый запах?

Конфликт ролей, отсутствие изоляции, перерасход токенов. Если вы из мира разработки, вы уже слышали эту песню. Лет пятнадцать назад её пели про монолитные бэкенды. Те же три смерти: один сервис пытался быть и базой данных, и веб-сервером, и очередью сообщений. Всё кончилось переходом на микросервисы.

Теперь история повторяется. Только вместо серверов - агенты. Вместо API - промпты. А решение всё то же: оркестр узких, независимых, экономичных ролей.

Как именно - читайте дальше.

1.3. Аналогия с микросервисами

Если вы работали в разработке ПО, вы знаете историю перехода от монолита к микросервисам. Если нет - кратко расскажу, потому что это ровно та же боль, которую сейчас лечат в мире ИИ.

Что было раньше: Монолит

Одна огромная программа, которая делает всё. Сервер, база данных, очередь сообщений, обработка платежей - всё в одном бинарном файле.

Живой пример (из реальной жизни)

Интернет-магазин. Модуль «отправка e-mail» лежит в той же программе, что и модуль «приём заказов». Если случилась ошибка в email (например, закончилось место для логов писем), то лежит весь сайт. Клиент не может даже оформить заказ, потому что монолит упал целиком. Ошибка в одной неважной функции убила всё.

Другая проблема: вы не можете написать модуль e-mail на Python, а модуль расчёта скидок - на Go. В монолите один язык, одна версия библиотек, один график релизов. Релиз раз в месяц. Фикс критической ошибки - через две недели.

Что пришло на смену: Микросервисы

Набор маленьких независимых программ (сервисов). Каждый делает одно дело и делает его хорошо. Сервис e-mail - только отправляет письма. Сервис заказов - только принимает заказы. Они общаются по сети, но не знают внутренностей соседа.

Преимущества

Изоляция отказов: упал сервис e-mail - магазин продолжает принимать заказы. Клиент даже не заметил.

Независимость технологий: можно писать каждый сервис на своём языке. E-mail на Python, расчёты на Rust, база - отдельно.

Независимый деплой (развёртывание): поправил один сервис - залил его один. Не ждёшь общего релиза.

В мире ИИ происходит ровно тот же переход.

Монолит в ИИ - одна большая модель (One Big Model), которая делает всё. Мы уже разобрали, почему это плохо: когнитивная перегрузка, конфликт ролей, отсутствие изоляции, экономическое безумие.

Микросервисы в ИИ - это Multi-Agent System (система множества агентов). Набор узких специалистов. Один умеет только писать SQL. Второй - проверять налоги. Третий - составлять письма.

Переходим от One Big Model к Multi-Agent System.

От JADE к JSON: почему классика умерла

Если вы учились на классических курсах по распределенным системам, вы сейчас вспомните про BDI-модели (Belief-Desire-Intention), протоколы FIPA и платформу JADE.

Забудьте. Это мертвые стандарты для современных LLM-систем.

Классические агенты общались через жесткие онтологии и строгие контракты. Современные LLM-агенты работают с вероятностной природой текста. Они не «понимают» FIPA-сообщения. Они понимают ваш промпт и JSON-схему.