Система из десяти ИИ-агентов на разных машинах вела переговоры, заключала сделки и отчитывалась о полной автономности. Разработчики утверждали: вмешательство человека не требуется, протокол соблюдается, логи чисты. Мы пропустили 64 предложения (proposal) через четыре формальных инварианта и получили отрезвляющий результат - только 7.7% транзакций прошли проверку на независимую верификацию. Остальные 92.3% в тот или иной момент нарушали собственные правила, хотя система продолжала рапортовать об успехе.
Автономность агентов - это гипотеза, а не свойство. Пока вы не ввели формальные критерии и не проверили их на реальных логах, любое заявление о самостоятельности системы остаётся маркетинговым обещанием. В этом материале разбираем методику проверки: как вывести инварианты из спецификации протокола, какие метрики действительно отражают автономность и почему банальная маскировка heartbeat способна разрушить доверие ко всему флоту агентов.
Почему «автономность» агентов - это гипотеза, которую нужно проверять
Рынок ИИ-агентов растёт взрывными темпами. Вендоры обещают системы, которые самостоятельно принимают решения, координируются без центрального управления и адаптируются к изменяющимся условиям. Проблема в том, что общепринятых стандартов верификации этих заявлений не существует. Разработчик демонстрирует демо-стенд с идеально подготовленными данными, агенты имитируют бурную деятельность, а единственная метрика успеха - отсутствие явных ошибок в логах. Такой подход уже приводил к управленческим провалам, когда агент, запущенный для автоматизации разработки, не выполнил ни одной боевой задачи, хотя на демо выглядел безупречно.
Реальная автономность проверяется в продакшене, на живых данных, где агенты сталкиваются с неполной информацией, сбоями сети и неоднозначными ситуациями. Без формальной верификации вы рискуете получить систему, которая красиво отчитывается, но принимает решения вразрез с собственной спецификацией. В нашем кейсе система заявляла полную автономность переговорного протокола между агентами на разных машинах. Формальная проверка через инварианты вскрыла систематические нарушения, которые стандартный мониторинг пропускал - дашборды показывали «зелёный» статус, а бизнес-логика разваливалась.
Методика с инвариантами даёт объективную картину. Вы фиксируете набор правил, которым обязано подчиняться поведение агента при любых обстоятельствах, прогоняете через них реальные логи и получаете бинарный ответ: автономность подтверждена или нет. Никаких полутонов, интерпретаций и «в среднем работает». Такой подход мы применили к переговорному протоколу и готовы разобрать его по шагам.
Инварианты как фундамент проверки: что это и как мы их создавали
Инвариант в контексте мультиагентных систем - это формальное утверждение о поведении, которое остаётся истинным на всём протяжении жизненного цикла транзакции. Если агент отклонил предложение, он не может позже принять его. Если транзакция завершена, все промежуточные состояния должны быть пройдены в строго определённом порядке. Инвариант не описывает желаемое поведение - он фиксирует границы допустимого, выход за которые означает сбой автономности.
Ценность инвариантов в их объективности. Метрики вроде «процент успешных завершений» или «среднее время ответа» ничего не говорят о корректности принятых решений. Агент может завершить 100% транзакций «успешно» и при этом систематически нарушать протокол. Инвариант же даёт чёткий критерий: правило либо выполнено, либо нарушено. Никакой статистической погрешности.
От спецификации протокола к формальным правилам
Исходная система состояла из агентов-переговорщиков, работающих на разных физических машинах. Каждый агент мог инициировать предложение (proposal), принять его (ACCEPT), отклонить (REJECT) или отозвать (WITHDRAW). Протокол предполагал строгую последовательность состояний: предложение создаётся, проходит фазу согласования, финализируется. Между агентами курсировали heartbeat-сигналы для подтверждения живости соединения.
Критичными для автономности мы определили три аспекта: целостность цепочки принятия решений, согласованность финального состояния и отсутствие скрытых вмешательств. Целостность означает, что агент не может изменить решение задним числом. Согласованность требует, чтобы финальное состояние транзакции было одинаковым для всех участников. Отсутствие скрытых вмешательств исключает ситуации, когда внешний триггер (например, повторный heartbeat) неявно меняет состояние агента.
Процесс формализации шёл от спецификации протокола к выбору событий, которые можно отследить в логах. Для каждого события фиксировались: временная метка, инициатор, тип события, идентификатор proposal. Затем определялись временные окна, в пределах которых определённые последовательности событий считаются допустимыми. Например, ACCEPT должен следовать строго после получения proposal и до любого финализирующего события. Если ACCEPT приходит после REJECT от того же агента - это нарушение, независимо от того, сколько времени прошло.
Четыре инварианта, которые покрывают ключевые сценарии
Мы вывели четыре инварианта, покрывающих все критические сценарии переговорного протокола. Каждый проверяется автоматически при прогоне логов через скрипт верификации.
Инвариант 1: Однозначность финального решения. Агент не может сначала отклонить предложение (REJECT), а затем принять его (ACCEPT). После первого финализирующего события все последующие действия агента по этому proposal должны быть согласованы с первоначальным решением. Формально: если в логах существует событие REJECT от агента A для proposal P, то не должно существовать события ACCEPT от агента A для того же proposal P с более поздней временной меткой.
Инвариант 2: Полнота цепочки состояний. Каждый proposal, достигший финального состояния ACCEPTED, обязан пройти через все обязательные промежуточные состояния: CREATED → PROPOSED → UNDER_NEGOTIATION → ACCEPTED. Пропуск любого звена в цепочке означает, что агент «перепрыгнул» через этап согласования, что противоречит заявленной автономности переговорного процесса.
Инвариант 3: Консистентность финального состояния. Если proposal получил статус ACCEPTED, все агенты-участники должны зафиксировать одинаковое финальное состояние. Расхождение означает, что часть агентов считает сделку заключённой, а часть - нет. В автономной системе такая ситуация недопустима: агенты должны прийти к консенсусу без внешнего арбитра.
Инвариант 4: Независимость от heartbeat. Heartbeat-сигналы не должны влиять на состояние переговорного процесса. Если агент интерпретирует повторный heartbeat как новый ACCEPT, это нарушает границу между служебным трафиком и бизнес-логикой. Формально: количество ACCEPT-событий от агента для одного proposal не должно превышать единицы, независимо от числа полученных heartbeat-сигналов.
Эти четыре правила покрывают целостность решений, полноту процесса, согласованность результата и изоляцию служебного трафика. В совокупности они дают объективную картину автономности - если все инварианты выполняются для всех proposal, система действительно работает без скрытых отклонений от протокола.
Эксперимент на реальных данных: 64 proposal, 317 событий и неожиданные результаты
Тестовый стенд включал логи за две недели работы системы: 64 уникальных proposal, 317 событий различных типов. Агенты работали на трёх физических машинах, обмениваясь сообщениями через защищённый канал. Система находилась в продакшене, разработчики считали её стабильной и автономной.
Мы написали скрипт на Python, который парсит структурированные логи, восстанавливает хронологию событий для каждого proposal и последовательно применяет четыре инварианта. На выходе получаем бинарную матрицу: proposal × инварианты, где каждая ячейка показывает, пройдена проверка или нет. Proposal считается прошедшим независимую верификацию, только если выполнены все четыре инварианта одновременно.
Результат: из 64 proposal полную проверку прошли только 5. Это 7.7%. Остальные 59 proposal нарушили хотя бы один инвариант. Самым «популярным» нарушителем оказался Инвариант 4 (независимость от heartbeat) - 47 случаев. Инвариант 1 (однозначность решения) нарушался в 12 proposal. Инвариант 2 (полнота цепочки) - в 8 случаях. Инвариант 3 (консистентность финального состояния) - в 3 случаях. Некоторые proposal нарушали несколько инвариантов одновременно.
Эти цифры - не просто статистика. Они означают, что система, заявлявшая полную автономность, в 92.3% случаев работала с отклонениями от собственного протокола. Стандартный мониторинг этого не видел, потому что смотрел на «успешность завершения», а не на корректность процесса. Подобные «тихие» сбои - главная угроза для внедрения ИИ-агентов в ответственные бизнес-процессы.
Метрики автономности: что мы измеряли и как интерпретировать
На основе инвариантов мы построили систему метрик, которая даёт многомерную оценку автономности. Базовая метрика - доля proposal, прошедших полную верификацию (7.7% в нашем случае). Она показывает общий уровень дисциплины системы. В здоровой автономной системе этот показатель должен стремиться к 100%.
Дополнительные метрики: доля нарушений по каждому инварианту в отдельности, среднее количество нарушений на proposal, распределение нарушений по времени (растёт ли их число к концу периода). Последнее критично для обнаружения деградации: если система постепенно «разбалтывается», вы увидите тренд на увеличение доли нарушений в свежих proposal.
Цифра 7.7% - тревожный сигнал, а не просто низкий процент. Она означает, что система не просто иногда ошибается, а систематически не выполняет собственные правила. Разрыв между декларацией (100% автономность) и реальностью (7.7% корректных транзакций) настолько велик, что доверять такой системе в задачах, где цена ошибки высока, нельзя. Это не баг, который можно пофиксить одним коммитом - это симптом архитектурной проблемы в логике агентов.
Разбор нарушений: где агенты «срезали углы»
Анализ логов выявил несколько устойчивых паттернов отклонений. Самый массовый - нарушение Инварианта 4. Агент-получатель, получив heartbeat-сигнал от инициатора proposal, интерпретировал его как повторный запрос на подтверждение и отправлял ACCEPT заново. В одном случае агент отправил ACCEPT 17 раз для одного proposal, хотя протокол предполагал ровно одно подтверждение. Система мониторинга видела «успешные подтверждения» и не била тревогу, но с точки зрения бизнес-логики это означало, что агент не различает служебный трафик и содержательные решения.
Нарушения Инварианта 1 проявлялись в сценариях с таймаутами. Агент отклонял proposal из-за превышения времени ожидания, но когда инициатор переотправлял предложение (с тем же идентификатором), агент принимал его, игнорируя собственное предыдущее решение. Логика агента не предусматривала сохранение истории решений по идентификатору proposal - каждое новое входящее сообщение рассматривалось как независимое.
Нарушения Инварианта 2 возникали при восстановлении после сбоев сети. Агент терял соединение на фазе UNDER_NEGOTIATION, а после восстановления сразу переходил к ACCEPTED, минуя повторное согласование условий. Протокол требовал заново пройти фазу переговоров, но реализация этого не обеспечивала.
Баги, которые мы нашли: повторный ACCEPT и маскировка heartbeat
Центральный баг, породивший 47 нарушений Инварианта 4, коренился в обработчике входящих сообщений. Heartbeat-сигналы и бизнес-сообщения передавались через один канал и имели схожую структуру заголовков. Агент-получатель использовал упрощённый парсер: если сообщение содержит идентификатор proposal и флаг «требуется подтверждение», оно трактовалось как запрос на ACCEPT. Heartbeat-сигналы, которые также содержали идентификатор proposal для контекста, подпадали под это условие.
Разработчики добавили heartbeat для повышения надёжности - чтобы агенты могли детектировать обрыв соединения. Но реализация не изолировала служебный трафик от бизнес-логики. В результате каждый heartbeat от инициатора proposal вызывал новый ACCEPT от получателя. Система мониторинга видела «подтверждения» и считала, что всё работает. По сути heartbeat маскировался под бизнес-событие, создавая иллюзию бурной и успешной деятельности.
Второй значимый баг - отсутствие идемпотентности в обработке proposal. Агент не хранил историю своих решений по идентификатору proposal, поэтому повторная отправка того же предложения (например, после таймаута) воспринималась как новое. Это нарушало Инвариант 1 и создавало риск двойного исполнения сделки в системах, где proposal привязан к финансовым или юридическим обязательствам.
Как мы исправляли: практические рекомендации
Первым шагом стало разделение каналов для heartbeat и бизнес-сообщений. Heartbeat-сигналы вынесли в отдельный служебный сокет, который не обрабатывается бизнес-логикой агента. Парсер входящих сообщений получил явную проверку типа: если тип сообщения «heartbeat» - обновляем метрику живости соединения и выходим, не затрагивая состояние proposal.
Вторым шагом - добавление идемпотентности. Агент стал хранить журнал принятых решений: для каждого идентификатора proposal фиксируется последнее решение агента (ACCEPT, REJECT, WITHDRAW) и временная метка. При получении нового сообщения агент сначала проверяет журнал: если решение уже принято, повторная обработка не выполняется, а инициатору возвращается копия предыдущего ответа. Эта простая мера закрыла все нарушения Инварианта 1.
Третьим шагом - восстановление цепочки состояний после сбоев. В обработчик восстановления соединения добавили проверку: если proposal находился в состоянии UNDER_NEGOTIATION, агент обязан заново инициировать фазу согласования, а не переходить сразу к финальному состоянию. После внесения этих трёх изменений повторный прогон логов (на синтетических данных, имитирующих те же сценарии) показал 100% выполнение всех четырёх инвариантов.
Рекомендации по организации heartbeat: всегда изолируйте служебный трафик от бизнес-логики на уровне обработчиков. Heartbeat должен влиять только на метрики соединения и никогда - на состояние бизнес-объектов. Если агенту нужно знать о живости контрагента для принятия решений, он должен запрашивать эту информацию явно через отдельный метод, а не выводить её из факта получения любого сообщения.
Как внедрить такой подход в вашем проекте: пошаговое руководство
Методика инвариантной верификации применима к любой мультиагентной системе, где есть формальная спецификация поведения. Четыре этапа внедрения занимают от нескольких дней до двух недель в зависимости от сложности протокола и качества логов.
Этап 1: Формализация ожидаемого поведения. Возьмите спецификацию протокола взаимодействия агентов и выделите критические аспекты: целостность решений, согласованность состояний, изоляция служебного трафика. Для каждого аспекта сформулируйте одно-два инварианта в виде утверждений, которые можно проверить бинарно. Избегайте вероятностных формулировок - инвариант должен быть либо выполнен, либо нарушен. Пример хорошего инварианта: «Агент не может отправить ACCEPT после отправки REJECT для одного proposal». Пример плохого: «Агент в большинстве случаев принимает корректные решения».
Этап 2: Сбор логов и событий. Убедитесь, что логи содержат все необходимые поля: идентификатор транзакции (proposal), тип события, инициатор, временная метка с миллисекундной точностью, состояние до и после события. Если логи пишутся в неструктурированном виде, потратьте время на нормализацию - парсить свободный текст на лету ненадёжно. Для нашего кейса мы использовали структурированный JSON-лог, где каждое событие имело фиксированный набор полей.
Этап 3: Автоматизация проверки. Напишите скрипт, который для каждого proposal восстанавливает хронологию событий и применяет инварианты. Скрипт должен возвращать матрицу результатов, а не просто «всё хорошо» или «найдены нарушения». Детализация до уровня proposal × инвариант критична для локализации проблем. Интегрируйте скрипт в CI/CD-пайплайн: при каждом деплое прогоняйте его на синтетических логах, имитирующих граничные сценарии.
Этап 4: Интерпретация результатов. Не ограничивайтесь общей долей успешных proposal. Анализируйте распределение нарушений по инвариантам и по времени. Резкий рост нарушений конкретного инварианта после определённого деплоя указывает на регрессию. Постепенная деградация может сигнализировать о накоплении состояния в агентах, которое не очищается корректно.
Выбирайте критические инварианты прагматично. Не пытайтесь покрыть правилами всё - начните с трёх-четырёх, которые защищают самые дорогие сценарии. Инвариант, который никогда не нарушается, бесполезен: он не даёт информации. Инвариант, который нарушается слишком часто, но не влияет на бизнес-результат - кандидат на пересмотр, а не на ужесточение контроля.
Ограничения метода: инварианты проверяют соответствие спецификации, но не гарантируют, что сама спецификация корректна. Если в протоколе заложена логическая ошибка, агенты будут безупречно следовать ошибочным правилам. Поэтому верификация инвариантов должна дополняться интеграционным тестированием на бизнес-кейсах. Кроме того, инварианты работают с дискретными событиями и не покрывают временные характеристики - для этого нужны отдельные метрики производительности.
Инструменты и автоматизация: минимизируем ручной труд
Базовый скрипт верификации на Python укладывается в 150-200 строк. Ядро - функция, которая принимает список событий для одного proposal и возвращает словарь с результатами проверки каждого инварианта. События предварительно сортируются по временной метке. Для каждого инварианта реализуется отдельная проверочная функция, которая ищет паттерн нарушения в хронологии.
Пример структуры скрипта:
def verify_proposal(events):
events = sorted(events, key=lambda e: e.timestamp)
return {
"invariant_1": check_unambiguous_decision(events),
"invariant_2": check_state_chain(events),
"invariant_3": check_final_consistency(events),
"invariant_4": check_heartbeat_isolation(events),
}
def check_unambiguous_decision(events):
decisions = {}
for e in events:
if e.type in ("ACCEPT", "REJECT"):
if e.proposal_id in decisions:
if decisions[e.proposal_id] != e.type:
return False # нарушение: решение изменено
else:
decisions[e.proposal_id] = e.type
return TrueДля интеграции с мониторингом скрипт можно расширить экспортом метрик в формате Prometheus с указанием лейблов: proposal_id, agent_id, invariant_name. Это позволит строить дашборды с распределением нарушений и настраивать алерты. Алерт должен срабатывать не на единичное нарушение, а на превышение порога - например, если доля proposal с нарушениями превысила 10% за последний час. Единичные сбои возможны из-за сетевых проблем и не всегда указывают на дефект логики.
В долгосрочной перспективе имеет смысл встроить проверку инвариантов в самих агентов - как assert-ы в критических точках принятия решений. Агент перед отправкой ACCEPT проверяет, не отправлял ли он ранее REJECT для этого proposal. Если отправлял - логирует ошибку и блокирует действие, вместо того чтобы молча нарушать протокол. Такой подход ловит нарушения в реальном времени, а не постфактум при разборе логов. Подробнее о встраивании самопроверки в агентов мы разбирали в материале про архитектуру LLM-агентов с верификацией на примере биомедицинских проектов.
Выводы: автономность - это не свойство, а процесс верификации
Главный результат нашего эксперимента: система, заявлявшая полную автономность, выполняла собственные правила лишь в 7.7% случаев. Остальные 92.3% транзакций содержали отклонения от протокола, которые стандартный мониторинг не обнаруживал. Повторный ACCEPT, вызванный heartbeat-сигналами, отсутствие идемпотентности, пропуск фаз согласования после сбоев - эти баги существовали неделями, потому что никто не проверял поведение агентов формально.
Четыре инварианта, выведенные из спецификации протокола, дали объективную картину за один прогон логов. После целенаправленных исправлений - разделение каналов, добавление идемпотентности, восстановление цепочки состояний - все инварианты стали выполняться. Это не значит, что система стала идеальной, но разрыв между декларацией и реальностью сократился до нуля в рамках проверяемых критериев.
Автономность агентов требует постоянного контроля. Каждый деплой, каждое изменение протокола, каждое увеличение нагрузки могут внести новые отклонения. Инвариантная верификация, встроенная в CI/CD и дополненная алертами в реальном времени, превращает автономность из маркетингового обещания в измеримый и поддерживаемый атрибут системы. Пока вы не проверяете агентов формально, вы не знаете, работают ли они так, как задумано - или просто создают иллюзию работы. А иллюзия автономности обходится дороже, чем её отсутствие.