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

Аннотация

Один LLM-агент не справится со сложной корпоративной задачей. Он утонет в контексте, запутается в ролях и сломается под нагрузкой.

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

Паттерны роутинга, умная шина данных, event sourcing для агентов, семантический кэш, кошельки агентов, HITL как архитектурный элемент — без воды, с примерами и готовыми решениями.

Книга написана в соавторстве с ИИ (LLM-ассистентом): структура, редактура и шлифовка текста выполнены совместно человеком и моделью.

Это не просто книга об агентах — это книга, созданная с помощью агента.

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

Версия текста: 1.9

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

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

Автор использовал подход, описанный в книге: гибридная оркестрация человека и ИИ. 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.

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

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

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

Забудьте. Это мертвые стандарты для современных LLM-систем. Они создавались для маленьких логических агентов с жесткими правилами. Сегодня LLM-агенты общаются на естественном языке — им не нужны FIPA-спецификации и JADE. Вместо этого используют простые оркестраторы типа AutoGen или LangGraph. Тянуть классику в эпоху LLM — как управлять Tesla телеграфом. Прагматика побеждает: если агенты понимают друг друга через текст — протоколы не нужны.

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

Попытка натянуть академическую теорию 2000-х на современный оркестр LLM — это как пытаться заправить Теслу углем. Сегодняшний стандарт — это Schema Registry, семантический JSON и строгая валидация на выходе, а не многостраничные спецификации взаимодействий.

Но есть нюанс: микросервисы — это не про «больше — значит лучше».

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

В мире ИИ то же самое. Multi-Agent System — это мощный паттерн, но он не бесплатен. Каждый новый агент добавляет:

— точку отказа (агент упал — часть пайплайна встала)

— накладные расходы на контекст (передача состояния между агентами)

— риск «бесконечного уточнения» (агенты переспрашивают друг друга)

Поэтому прежде чем строить рой агентов, ответьте на вопрос: «А можно ли решить задачу проще?»

Именно здесь Anthropic сформулировал лестницу сложности — практический инструмент, который помогает не превратить ваш ИИ-проект в распределённый кошмар на пустом месте.

1.3.5. Лестница сложности: когда вам действительно нужен оркестр

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

Уровень 1: Промпт (Prompt)

Что это: Один запрос — один ответ. Без памяти, без инструментов, без циклов.

Когда использовать: Задача решается за один вызов LLM. Перевод текста, саммаризация, генерация письма по шаблону.

Живой пример: «Переведи этот договор на русский» — промпт, GPT-4o, готово. Не нужен агент. Не нужен оркестр. Не нужен Event Sourcing. Просто промпт.

Цена ошибки: Низкая. Если перевод кривой — перечитаете сами.

Уровень 2: Скилл (Skill)

Что это: Повторяющаяся задача, которая выполняется 3—5+ раз в месяц. Нужен стандарт, чтобы не переписывать промпт каждый раз.

Когда использовать: Вы ловите себя на том, что копируете один и тот же промпт из заметок. «Ага, вот этот промпт для анализа договоров — использую его каждую неделю.» Значит, пора завернуть его в функцию с параметрами.

Живой пример: Анализ договора на риски. Вы делаете это каждую неделю. Вместо того чтобы каждый раз вставлять промпт на 500 слов, вы создаёте функцию analyze_contract (text, risk_types) с фиксированным промптом внутри. Это скилл.

Цена ошибки: Средняя. Если скилл сломался — вы заметите на втором-третьем использовании.

Уровень 3: Воркфлоу (Workflow)

Что это: Несколько зависимых шагов, где выход одного — вход другого. Нужна надёжность, потому что ошибка на шаге 2 ломает шаг 3.

Когда использовать: Задача требует последовательности действий с проверками. «Сначала извлеки данные, потом проверь их, потом сгенерируй отчёт.»

Живой пример: Обработка заявки на возврат. Агент 1 извлекает номер заказа из письма. Агент 2 проверяет в базе, что заказ существует. Агент 3 рассчитывает сумму возврата. Агент 4 отправляет письмо клиенту. Если Агент 2 ошибся и сказал «заказа нет» — Агент 3 не должен считать сумму. Нужна валидация между шагами.

Цена ошибки: Высокая. Если воркфлоу сломался на шаге 3 — клиент получил неверную сумму возврата. Приходится откатывать всю цепочку.

Здесь появляется Event Sourcing (Глава 2.3) — чтобы откатывать состояние.

Уровень 4: Мульти-агент (Multi-Agent)

Что это: Шаги требуют полной изоляции друг от друга. Разные контексты, разные роли, разные модели. Агенты не знают о существовании друг друга — они общаются через шину данных.

Когда использовать: Задача настолько сложная, что один агент не может держать всё в голове без Context Pollution (Глава 1.1). Или когда разные части задачи требуют противоположных ролей (продавец vs юрист).

Живой пример: Департамент бизнес-аналитики. Агент-аналитик копается в данных (100 тысяч токенов SQL-запросов). Агент-юрист проверяет соответствие договору (50 тысяч токенов юридических текстов). Агент-писатель формулирует отчёт для директора (чистый контекст, только факты). Если скормить всё одному агенту — он утонет в контексте и начнёт галлюцинировать.

Цена ошибки: Критическая. Если агент-юрист пропустил пункт о неустойке — компания теряет миллионы. Нужен HITL (Глава 4.5), Circuit Breaker (Глава 3.4), полный Audit Trail (Глава 6.2).

Проблема: дорого или неработоспособно

На уровнях 3–4 у вас ровно два пути — и оба ведут в тупик:

1. GPT-4o/Claude Opus — надёжно, но невыносимо дорого. Воркфлоу из 10 шагов сжигает $5–10 за заявку. При 1000 заявок в день это $5000–10000 только на API. И вы платите эту цену вечно.

2. Дешёвые модели (Qwen2—7B, Llama-3-8B) — цена копеечная, но план из 10 шагов выполняется в 3–5% случаев. Они путают последовательность, игнорируют валидацию и проваливают критические проверки.

Классический выбор: либо бедные, но мёртвые, либо живые, но без денег.

Evoflux — это третий путь.

Как это связано с Evoflux

Evoflux — это эволюционный поиск во время инференса: агент генерирует план, пытается выполнить, получает обратную связь от инструментов и эволюционно правит план. Это не файн-тюнинг (который требует сотен примеров и ломается при изменении каталога инструментов). Это адаптация на лету. Для мультиагентной системы это значит: меньше падений, меньше перезапусков, меньше сожжённого бюджета.

Лестница говорит «когда», Evoflux говорит «как сделать дёшево на уровнях 3—4».

На уровнях 1—2 (промпт, скилл) вам не нужен Evoflux — задачи простые, дешёвые модели справляются.

На уровнях 3—4 (воркфлоу, мульти-агент) вы хотите использовать дешёвые модели (Qwen2—7B, Llama-3-8B), но они ломаются на сложных планах из 10+ шагов.

Классический подход: «Бери GPT-4o».

Evoflux говорит: «Подожди. Пусть дешёвая модель попробует, сломается, и эволюционно починит план на лету.»

Результат: выполнимость растёт с 3% до 24%, а цена остаётся на уровне дешёвой модели.

Вывод: Evoflux это техника, которая делает уровни 3—4 экономически доступными. Без неё воркфлоу и мульти-агент системы разоряют бюджет на тяжёлых моделях. С ней — вы можете использовать дешёвые модели там, где раньше нужен был GPT-4o.

Микросервисы и оркестр агентов строятся на одном принципе: «разделяй и властвуй». Но как именно собрать из кусочков работающую систему? Введём главное понятие этой главы — оркестрацию.

1.4. Что такое Оркестрация?

Оркестрация в ИИ — это не просто «запуск нескольких агентов подряд». Это управление потоком данных, состоянием и ответственностью.

Метафора: симфонический оркестр

Дирижёр (Orchestrator) — не играет ни на одном инструменте. Его задача — видеть партитуру целиком и указывать, кто вступает сейчас.

Скрипки (Specialists) — виртуозны в своём узком деле, но не знают, что делают трубы.

Партитура (Workflow/State) — жёсткий или гибкий план.

Роли в ИИ-оркестре

Router (Маршрутизатор) — принимает запрос и решает, какой агент (или последовательность агентов) должен его обработать.

Agents (Исполнители) — выполняют узкую задачу. Их промпты короткие и сфокусированные.

Bus (Шина данных) — место, где агенты оставляют результаты.

Важно: они передают не просто текст, а структурированные данные.

Например, JSON (JavaScript Object Notation — текстовый формат, похожий на словарь с ключами и значениями, понятный любому языку программирования).

Supervisor (Координатор) — проверяет результат перед выдачей пользователю. Может отправить задачу на доработку.

Пример работы оркестратора

Пользователь пишет: «Найди в моей переписке все упоминания слова договор и отправь юристу краткое резюме».

Router видит слово «найди» (поиск) и «отправь юристу» (доставка) — решает, что сначала нужен Поисковый Агент, потом Агент-Составитель резюме.

Agents выполняют: первый ищет письма (возвращает JSON со списком), второй пишет резюме.

Bus — временное хранилище, где первый агент оставляет найденные письма.

Supervisor перед отправкой проверяет: «А есть ли там что-то конфиденциальное?» — если да, то не отправляет, а просит пользователя подтвердить.

Оркестратор не знает, как именно искать письма или писать резюме. Он только знает порядок шагов и правила перехода.

1.5. Паттерны оркестрации

Паттерн (от англ. pattern — образец) — это проверенная схема взаимодействия между агентами. Не изобретайте велосипед: в 90% задач работает один из трёх шаблонов, описанных ниже.

Паттерн А: Последовательная цепочка (Sequential Chain)

Схема: User Query -> Agent A (Извлечение) -> Agent B (Анализ)

— > Agent C (Отчёт) -> User

Когда использовать

Линейные процессы (ETL — извлечение, преобразование, загрузка; перевод текста и последующее форматирование).

Плюсы: просто отлаживать.

Минусы: нет возможности вернуться назад. Если Agent B ошибётся, Agent C сделает красивый отчёт на основе лжи.

Реальный пример

Взять Excel-файл с продажами (Агент А — извлечь данные), найти аномалии (Агент Б — статистический анализ), отправить отчёт в Telegram (Агент В — отправитель). Если Агент Б ошибётся и назовёт нормальные продажи аномалией, Агент В отправит ложную тревогу — и никто не вернётся назад.

Паттерн Б: Звезда с Центром (Supervisor / Hub-and-Spoke)

Центральный агент (Supervisor) держит состояние задачи. Он вызывает других агентов по мере необходимости, получает результаты и принимает решение о следующем шаге.

Когда использовать

Сложные творческие или аналитические задачи, где нужен цикл обратной связи (написал проверил исправил).

Плюсы: гибкость. Supervisor может менять план на лету.

Минусы: Supervisor становится «узким горлышком». Он должен быть очень умной (и дорогой) моделью.

Пример

Написать ответ на сложную жалобу клиента. Supervisor вызывает:

• агента «Эмпатия» (сгенерировать извинение),

• потом агента «Компенсация» (рассчитать скидку),

• потом агента «Юрист» (проверить, не нарушает ли это оферту).

Если юрист говорит «нарушает», Supervisor может отменить компенсацию и вызвать агента «Стандартный ответ».

Паттерн В: Рой (Swarm / Decentralized)

Нет главного агента. Агенты общаются друг с другом напрямую через общую шину сообщений. Каждый агент реагирует на события.

Когда использовать

Системы реального времени, мониторинг, трейдинг.

Плюсы: масштабируемость.

Минусы: хаос. Очень сложно отлаживать. Непонятно, кто виноват, если система приняла странное решение.

Паттерн Г: Агентские торги (Bidding)

Жесткий роутинг (Router -> Агент А) хорош, но не всегда экономичен. Что, если Агент А сейчас перегружен, а Агент Б свободен и стоит в два раза дешевле?

Как это работает

Оркестратор не назначает задачу, а «бросает клич» в шину данных. Специализированные агенты делают «ставку» (bid), указывая два параметра:

• Свою цену за выполнение (в токенах или условных единицах).

• Свой Confidence Score (уверенность в успехе, от 0 до 1).

Оркестратор выступает в роли аукциониста: он выбирает не обязательно «самого умного» агента, а того, кто предлагает лучший баланс цены и уверенности для этой конкретной задачи.

Когда использовать

Высоконагруженные системы, где критически важна оптимизация Cost Per Task.

Плюсы: Динамическая балансировка нагрузки и реальная экономия бюджета.

Минусы: Требует сложной логики оркестратора и задержку на «торги» (доли секунды).

Приведем теперь итоговую схему — инструмент для принятия решений

Используйте эту схему как чек-лист при проектировании: ответьте на три вопроса (линейность, взаимозависимость, критичность реального времени) — и получите готовый паттерн.

Задача линейная (ETL, перевод)? -> Sequential Chain

Нужен контроль и ветвление? -> Supervisor

Асинхронные события, высокая параллельность? -> Swarm

Важное предупреждение

Рой хорош для систем мониторинга — тысячи датчиков шлют события, каждый агент сам решает, реагировать или нет. В этом сценарии асинхронность и децентрализация — преимущества: датчики не ждут друг друга, и общая производительность системы выше. Но представьте, что в чате поддержки 50 агентов начинают отвечать клиенту одновременно, перебивая друг друга, — и никто не может объяснить, почему клиенту начислили три скидки. Такая нескоординированная активность не только путает клиента, но и создаёт хаос в бэкенде: дублирующиеся операции, конфликтующие обновления базы и полная потеря аудита того, какое решение стало финальным. Для 90% бизнес-задач начинайте с Supervisor или цепочки. Они дают предсказуемый поток управления, единую точку принятия решений и возможность отследить каждый шаг, что критично для финансовых, юридических и клиентских сценариев, где цена ошибки высока.

Сквозной слой: Критик как архитектурный фильтр

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

Поэтому поверх любого паттерна должен быть надстроен сквозной слой Критика. На каждый запрос (или каждые 3–5 шагов сложного процесса) оркестратор вызывает не только Исполнителя, но и независимого Критика. Критик проверяет результат по трём осям: соответствие контексту (grounding), безопасность (toxicity/safety), логическая непротиворечивость. Если оценка Критика ниже порога — ответ блокируется до отправки в шину данных или пользователю.

Блокировка — не финал, а триггер для эволюционного цикла: оркестратор запускает повторную попытку Исполнителя с подсказкой «ты ошибся, критик указал на следующее». (Подробнее о том, как работает эволюционный цикл, — в Главе 3, раздел 3.4.2) После 2–3 неудач задача эскалируется на HITL. Это превращает Критика из «инструмента тестирования» (LLM-as-a-Judge в офлайн-режиме) в архитектурный элемент рантайма, который обеспечивает активную самозащиту системы.

Инженерный смысл

Для роя из 10+ агентов этот слой — единственный способ предотвратить эмерджентное безумие (коллективные галлюцинации) до того, как они попадут в шину данных или к пользователю. Затраты на дешёвого Критика (Qwen2–7B) для дорогого Исполнителя (GPT-4o) в 3–5 раз ниже стоимости исправления последствий ошибки в продакшене. Паттерн Bidding (агентские торги) может учитывать «стоимость Критика» как дополнительный параметр при выборе исполнителя: агент, который требует меньше проверок, получает приоритет.

Промпт-инженерия для оркестратора: как не убить супервайзера

Супервайзер — самый уязвимый агент в системе. Он получает запрос, анализирует, принимает решения о вызове других агентов, собирает результаты. Если его промпт не оптимизирован, он деградирует после 5–10 вызовов: начинает путать агентов, терять контекст, принимать противоречивые решения. Вот три правила, которые работают в промышленных оркестрах:

Правило 1: Жёсткое разделение ролей.

Промпт супервайзера должен состоять из трёх чётких секций: (1) «Твоя задача — только маршрутизация. Ты не генерируешь контент», (2) «Список доступных агентов с их описанием и ограничениями», (3) «Формат ответа: JSON с полями agent_id, reasoning, confidence». Без этого супервайзер начинает «творить» вместо того, чтобы направлять.

Правило 2: Явный fallback.

Добавьте в промпт: «Если ни один агент не подходит для задачи с уверенностью> 0.7 — верни fallback: true и передай задачу человеку». Это предотвращает ситуацию, когда супервайзер отправляет сложный запрос неподходящему агенту, просто чтобы «что-то сделать».

Правило 3: Ограничение истории.

Не передавайте супервайзеру всю историю диалога. Передавайте только: (1) текущий запрос, (2) последние 3 решения, (3) сжатое резюме (Rolling Summary). Иначе через 20 шагов он утонет в собственном контексте и начнёт галлюцинировать.

Живой пример плохого промпта (не делайте так): «Ты — умный ассистент, который управляет другими агентами. Решай, что делать.» Хороший промпт (делайте так): «Ты — диспетчер. У тебя есть 5 агентов: [список]. Твоя задача — выбрать одного из них. Не генерируй ответ пользователю. Верни JSON. Если не уверен — верни fallback.»

Паттерн выбран, агенты запущены. Но есть один нюанс, который убивает 80% оркестров на старте. Агенты не умеют читать мысли друг друга. И если они общаются текстом — жди беды.

1.6. Главная проблема оркестрации: Шина данных (The Data Bus)

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

Плохой пример

Агент А пишет: «Ну, продажи выросли примерно на 10%, вроде бы неплохо, но в феврале был провал.»

Агент Б читает это и думает:

10% — это мало или много?

Какой именно февраль?

«Провал» — это на сколько процентов?

Агент Б галлюцинирует (придумывает несуществующие факты), пытаясь угадать контекст.

Хороший пример (Структурированная шина): Agent A возвращает JSON:

json

{

«metric»: «sales_growth»,

«value»: 0.10,

«period»: «2024-Q1»,

«anomalies»: [

{«month»: «February», «deviation»: -0.15, «reason»: «holiday_shortage»}

],

«confidence»: 0.95

}

Agent B получает этот JSON. Он точно знает значения. Он не гадает.

Правило номер 1 оркестрации

Агенты общаются на языке структур (JSON, XML, Pydantic-модели), а люди общаются с системой на языке текста.

JSON — это уже хорошо, но этого мало. В реальном проекте агенты пересылают гигабайты логов, истории диалогов, промежуточные выкладки. Контекст снова загрязняется. Нужна шина, которая умнее, чем просто «возьми и передай всё».

1.7. Умная шина: Передача только необходимого (Selective Context Loading)

В наивной архитектуре агенты пересылают друг другу полные истории диалогов. Это дорого и шумно.

Решение: Шина как источник истины (Single Source of Truth)

Вместо передачи значений, мы передаем ссылки или запросы на данные.

Агент-Производитель

Сохраняет результат в Шину (Kafka Topic / Redis Key).

В Шину летит не только payload (сами данные), но и metadata (данные о данных: кто, когда, краткое содержание):

json

{

«message_id»: «msg_555»,

«payload_summary»: {

«has_transaction_details»: true,

«risk_level»: «high»

},

«data_pointer»: «kafka_topic_finance_results/partition_1/offset_999»

}

Агент-Потребитель

Получает сообщение. Смотрит на payload_summary.

Если ему нужно только risk_level, он берет его из заголовка. Токенов потрачено: ~10.

Если нужен полный анализ, он использует data_pointer, чтобы подтянуть полный payload из Шины только в этот момент.

Реализация на практике (пример для Kafka + Redis)

1. Агент-производитель пишет payload в Redis (TTL = 24 часа).

2. В Kafka отправляет только:

{

«topic»: «task_results»,

«key»: «session_123»,

«data_pointer»: «redis://cache/task_555»,

«payload_summary»: {«risk_level»: «high»}

}

3. Агент-потребитель:

— Если нужен только risk_level берёт из заголовка Kafka (0 токенов).

— Если нужны детали делает GET redis://cache/task_555.

Схематично

[Агент А] -> сохраняет полные данные -> Redis (хранилище) [Агент А] -> отправляет короткий указатель -> Kafka -> [Агент Б] [Агент Б] -> если нужно детали -> GET Redis

Давайте соберём все компоненты вместе и проследим путь одного запроса от пользователя до финального ответа.

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

Экономия токенов

Агент загружает в свой контекст только релевантные фрагменты.

Чистота контекста

Нет шума от предыдущих шагов.

Асинхронность

Агент-потребитель может начать работу, как только появятся критические данные.

Соберём всё, что мы узнали о монолите, оркестрации и шине данных, в короткий список выводов. А затем посмотрим, куда ведёт эта дорога — к проблемам памяти и состояния.

Резюме главы 1

Один агент не справится со сложной задачей. Он утонет в собственном контексте и запутается в ролях.

Оркестрация — это разделение труда. Переход от монолита к микросервисам.

Есть три главных паттерна: Цепочка (для простых процессов), Supervisor (для сложных задач), Рой (для асинхронных событий). Начните с Supervisor.

Общайтесь структурами, а не текстом. Шина данных должна передавать JSON/объекты.

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

Но разделить задачи между агентами — полдела. Главная боль начинается, когда агентам нужно:

• Помнить, о чём говорили 10 шагов назад.

• Передать эстафету другому агенту без потери смысла.

• Не запутаться в 50 разных историях диалогов.

Именно этим — памяти и состоянию экосистемы — посвящена следующая глава.

ГЛАВА 2. ПАМЯТЬ ЭКОСИСТЕМЫ: ОТ KV CACHE ДО КОРПОРАТИВНОЙ ДОЛГОСРОЧНОЙ ПАМЯТИ

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

В Книге 2 мы говорили о краткосрочной и долгосрочной памяти одного агента. В Книге 3 мы говорим о памяти системы.

2.1. Иерархия памяти в распределенной системе

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

У каждого типа памяти своя скорость, своя цена и свой срок годности. Мы выделяем четыре уровня. У каждого — свой SLA (Service Level Agreement — договорённость о том, как быстро и надёжно данные будут доставлены) и своя стоимость.

Уровень 1: Горячая память (KV Cache & Session Store)

Почему «горячая», а не просто «оперативная»?

В классических серверах RAM — это общий пул быстрой памяти. В нашей иерархии «горячая память» — это два специализированных подвида:- KV Cache (в VRAM GPU), который хранит внутренние представления текущего диалога и привязан к конкретному инстансу модели.- Session Store (например, Redis) — общая оперативная память для текущих сессий агентов. Их объединяет скорость (наносекунды — микросекунды) и недолговечность (данные исчезают при перезапуске). Этим они отличаются от «тёплой» памяти (PostgreSQL, дни-недели) и «холодной» (S3, годы).

Где живёт: VRAM (видеопамять GPU — та самая, где модель держит текущий диалог), Redis (быстрое хранилище «ключ-значение» в оперативной памяти сервера). Оба этих хранилища мы называем «горячей» памятью, потому что они обеспечивают максимальную скорость доступа, но их содержимое не переживает перезапуск агента или сервиса.

Время жизни: миллисекунды — часы.

Что хранит: текущий диалог, промежуточные вычисления (например, «на втором шаге я получил сумму 1500 рублей»), активные инструменты (какие функции сейчас доступны агенту).

Цена доступа: почти нулевая — если данные уже в кэше (временном буфере), модель читает их мгновенно.

Риск: теряется при рестарте инстанса (если сервер перезагрузили — всё, горячая память пуста).

Инженерный совет (человеческим языком):

Никогда не храните в горячей памяти важные факты, которые жалко потерять. Это рабочий стол, а не архив. Если вы положили договор на рабочий стол и выключили компьютер — договор исчез.

Почему нельзя хранить память агента только в горячей памяти (КV Cache)?

Три причины, почему это ловушка:

Привязанность к конкретному инстансу

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

Замедление при длинных диалогах

Горячая память линейно растёт с каждым новым сообщением. При 100 тысячах токенов (примерно 150 страниц текста) инференс — то есть процесс генерации ответа — замедляется в 3–5 раз. Вы будете ждать ответа по 30 секунд вместо 5.

Агенты не видят горячую память друг друга

Агент А «запомнил», что клиент Иван обещал оплатить завтра. Агент Б об этом не знает — потому что его горячая память отдельная. В мультиагентной системе это катастрофа.

Живой пример

Два агента: Планировщик (составляет график) и Отправитель (шлёт напоминания). Планировщик запомнил: «Встреча перенесена на 15:00». Он перезапустился через минуту — и забыл. Отправитель напоминает клиенту о встрече в 12:00, как в старом расписании. Клиент приезжает рано, злится. А виновата горячая память.

Вывод

горячая память (KV Cache) годится только для текущего шага рассуждения — например, чтобы помнить, что вы только что сказали внутри одного вызова модели. Для передачи состояния между агентами она не годится.

Уровень 2: Тёплая память (Operational State)

Где живёт

PostgreSQL (обычная реляционная база данных), MongoDB (документо-ориентированная БД), Vector DB в горячем слое (о векторных БД — чуть позже).

Время жизни: дни — недели.

Что хранит

Историю текущей сделки (шаги, кто одобрил, когда отправлено письмо), статус заявки («в обработке», «отправлено юристу»), последние 10 взаимодействий с клиентом.

Цена доступа: низкая — миллисекунды.

Риск

Может рассинхронизироваться, если агенты пишут в разные таблицы без согласования. Один агент обновил статус заявки на «закрыта», а второй всё ещё считает её «активной».

Инженерный совет

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

Расшифровка

Транзакционная база — это как банковская проводка: либо деньги переведены и у вас и у получателя всё сошлось, либо операция отменена целиком, без «половинчатых» состояний. Для статусов заявок это критично.

Уровень 3: Холодная память (Long-Term Semantic Memory)

Где живёт

Векторная база данных в холодном слое (например, Pinecone, Qdrant, или просто S3-хранилище с индексами), графовые базы данных (о них — на следующем уровне), S3 (облачное объектное хранилище, как Яндекс Облако или AWS S3) с отдельной индексацией.

Время жизни: годы.

Что хранит

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

Цена доступа

Высокая — сотни миллисекунд на поиск плюс генерация эмбеддинга (числового вектора, который позволяет искать похожий смысл, а не точные слова). Это в сотни раз медленнее, чем чтение из Redis.

Риск

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

Инженерный совет (человеческим языком)

Нужна стратегия «забывания» (Eviction Policy — правило, по которому мы удаляем старые данные). Например: удаляйте всё, что не запрашивалось более года. Или архивируйте в медленное хранилище, оставляя только индекс.

Живой пример

Вы храните историю заказов клиента за 5 лет. Клиент заказал 100 одинаковых товаров. Холодная память возвращает агенту 100 записей. Агент задыхается. Правильная стратегия: хранить агрегат («заказывал 100 раз товар X»), а не каждую накладную.

Уровень 4: Мета-память (Knowledge Graph)

Где живёт

Графовые базы данных — Neo4j, TigerGraph, Azure Cosmos DB для Gremlin (Gremlin — язык запросов к графам).

Что хранит

Связи между сущностями. Не просто «документ А похож на документ Б» (это векторная БД), а строгие отношения:

• «Документ А подписан Клиентом Б через Договор В».

• «Клиент Б работает в Компании Г, у которой есть Юридический адрес Д».

• «Товар Е входит в категорию Ж, которая требует лицензии».

Зачем нужна

Векторный поиск хорош для семантики («найди документы про кофе» — он найдёт и «эспрессо», и «арабика», и «растворимый напиток»). Граф хорош для связей и многошаговых вопросов.

Пример сложного запроса, где граф побеждает вектор

«Найди всех сотрудников компании X, которые подписывали договоры с поставщиками кофе в 2023 году, и у которых есть неподписанный акт сверки за последний квартал.»

Векторная БД просто найдёт документы со словами «кофе», «договор», «акт сверки» — и выдаст кучу мусора. Граф пройдёт по связям:

• Компания X её сотрудники (кто подписывает);

• Сотрудники договоры с поставщиками (фильтр по году и по товару «кофе»);

• Договоры акты сверки (проверка, подписан ли).

Инженерный совет

Для сложных корпоративных систем RAG без графа знаний вы уткнётесь в потолок на сложных запросах. RAG (Retrieval-Augmented Generation — генерация с подкреплением от поиска) — это когда модель сначала ищет документы, а потом отвечает на их основе. Если запрос требует 2—3 логических шагов, простая векторная БД начнёт галлюцинировать.

А теперь — главная боль

Четыре уровня памяти — это хорошо. Но даже если вы всё правильно разложили по полочкам, остаётся одна неприятная проблема: как передать эстафету от одного агента к другому, когда контекст уже переполнен?

Агент А накопил 50 тысяч токенов диалога (пусть даже часть из них — в тёплой памяти, но контекст вызова всё равно толстый). Агенту Б нужно всего три факта: дата, сумма и риск-уровень. Если скормить Б всё подряд — он утонет в шуме, замедлится и начнёт галлюцинировать.