ИИ-агенты могут вести себя непредсказуемо. Слой управления — нет.

Зачем оценивать взаимодействие агентов

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

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

Типичный пайплайн RAG можно представить так:

Запрос пользователя → поисковый модуль → найденный контекст (оценка) → генерация → сгенерированный ответ (оценка)

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

В мультиагентной системе эта схема расширяется:

Запрос пользователя → агент A → передача результата → агент B → общее состояние → агент C → проверка → итоговый ответ

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

Запись хода работы системы

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

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

Проверка тупиков и циклов

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

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

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

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

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

Оценка передачи данных между агентами

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

Передачу между агентами можно представить как небольшой информационный пайплайн:

Результат агента A → контекст, переданный агенту B → интерпретация агента B

Как и в RAG, нужно проверять качество поиска и генерации каждого агента. Кроме того, в мультиагентных системах требуется проверять интерфейсный контракт — договорённость о формате обмена данными между агентами.

Проверка передачи контекста

Сначала нужно выяснить, дошла ли до следующего агента нужная информация, созданная предыдущим.

Типичные вопросы:

На границе между агентами можно применять те же метрики качества контекста, что и при оценке RAG:

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

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

Типичные вопросы:

Здесь можно использовать принципы оценки качества генерации из RAG:

Для семантической оценки обычно используют LLM-as-a-judge: судья сравнивает результат предыдущего агента, контекст, полученный следующим агентом, и итог его работы.

Проверка целостности интерфейса

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

По возможности агентам следует передавать структурированные данные, даже если текст длинный, а не свободные ответы на естественном языке. Схемы JSON, модели Pydantic и другие контракты с типами позволяют детерминированно проверить часть передачи до запуска следующего агента.

Полезные метрики:

Так проверка передачи складывается из трёх взаимодополняющих уровней:

Результат агента A → качество контекста → целостность интерфейса → интерпретация агента B

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

Оценка общего состояния

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

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

Например, общее состояние системы поддержки клиентов SaaS может выглядеть так:

В исходнике объект состояния приведён не полностью: в нём указаны идентификатор клиента C1024, тариф Enterprise, проблема duplicate_charge, а также значения true для identity_verified и refund_eligible.

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

Детерминированные проверки применяют к свойствам, которые можно описать правилами:

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

Для оценки состояния можно использовать такие ключевые показатели:

Менеджер состояния работает подобно контрольной точке в дата-пайплайне:

Предыдущее состояние → работа агента → обновлённое состояние → проверка состояния → следующий агент

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

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

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

Проблема возникает не внутри отдельного агента, а из-за недостатка независимости между ними. Чтобы обнаружить однообразие моделей, нужно измерять, различаются ли рассуждения, фактические основания, решения и характер ошибок агентов.

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

От оценки к инженерному контролю

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

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

Контроль рабочего процесса. Слой оркестрации должен явно отслеживать запуски агентов, решения о маршрутизации, передачи данных, число итераций, время выполнения и конечные состояния. Для этого нужна детерминированная оркестрация. Фреймворки вроде LangGraph позволяют описывать рабочие процессы как графы с состоянием, явными узлами, рёбрами, ветвлениями и контрольными точками. Ограничения на число итераций, тайм-ауты и условия завершения предотвращают тупики и бесконечные циклы, не полагаясь только на решение LLM о том, когда остановиться. Затем ход выполнения можно записывать с помощью LangSmith и использовать для оценки процесса и диагностики нестандартного поведения.

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

Выполнение агентом задачи → менеджер состояния → обновление или очистка состояния → следующий агент

Менеджер состояния по детерминированным правилам следит за размером контекста и определяет, когда его нужно очистить. При достижении порога он запускает лёгкий агент для суммирования разговора. Затем менеджер состояния по заданным правилам заменяет старые сообщения кратким изложением, сохраняя недавний контекст. Получается гибридная схема: LLM суммирует смысл, а детерминированный код управляет тем, когда и как меняется состояние. Это помогает удерживать общий контекст компактным и не даёт ему расти бесконечно.

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

Например, в системе поддержки клиентов SaaS могут работать:

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

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

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