АГЕНТ · V

01  Постановка задачи

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

Эти требования несовместимы на уровне модели. Они разрешимы только на уровне архитектуры, в которую языковая модель встроена как один из компонентов, а не как самостоятельный исполнитель.

V — референсная реализация такой архитектуры. Не продукт, а исследовательский стенд, на котором институт проверяет инварианты, формализует политику и измеряет поведение в условиях продолжительной эксплуатации.

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

02  Прототип и программа

Программа V разделена на два уровня реализации, между которыми существует методологический мост.

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

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

Программа института формализует те же принципы через SMT-верификатор Z3 и аксиоматику на логике первого порядка. Формализация переводит архитектурную дисциплину из области инженерной практики в область доказуемых свойств, что делает её применимой к требованиям 187-ФЗ, 117-ФСТЭК, ГОСТ Р 57580 и аналогичных регуляторных контуров.

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

03  Принцип архитектуры

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

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

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

04  Четырёхэтажная защита

Архитектура V опирается на четыре независимых слоя проверки. Каждый закрывает своё пространство угроз. Слабость одного компенсируется другими. Путь одного действия через эти слои показан на схеме ниже.

4.1. Градиент необратимости R0–R5

Каждое действие в системе классифицировано по шкале необратимости от R0 (чтение, нулевое последствие) до R5 (деструктивное, невосстановимое). Класс действия определяет, какие проверки обязательны перед исполнением. Классификация формальна, фиксирована в коде и сопровождается тестами, ломающимися при нарушении. В текущей редакции R-таблица охватывает восемь классов критических операций.

Шкала R0–R5 — самостоятельный методологический вклад программы. Её преимущество перед двоичной моделью «разрешено / запрещено» в том, что она допускает постепенное усиление контроля по мере роста ущерба от ошибки. Это снижает ложноположительные блокировки на действиях низкой критичности и концентрирует ресурс верификации на действиях высокой.

4.2. Multi-Box Consensus

Каждое действие класса R3 и выше проходит независимую верификацию вторым языковым модулем, обученным на другом семействе. Первый модуль генерирует решение. Второй принимает решение в форме AGREE / DISAGREE / UNCERTAIN с обоснованием. Расхождение фиксируется как событие безопасности и блокирует исполнение до явного разрешения оператора.

Это эмпирическая верификация, не формальная. Её цель — снизить вероятность согласованной ошибки, возникающей из общих смещений одной модели. Метрики consensus rate и uncertainty rate измеряются. Архитектурное решение зафиксировано в ADR-0005.

4.3. Формальная верификация на SMT-решателе

Для класса R5 (деструктивные действия) разрабатывается формализация политики на языке логики первого порядка с проверкой через SMT-решатель Z3. Действие допускается тогда и только тогда, когда решатель подтверждает выводимость политики из контекстных фактов. При отклонении возвращается unsat core — минимальный набор условий, нарушение которых привело к отказу.

На дату публикации реализован пилотный фрагмент покрытия — один класс действий R5. Расширение покрытия на остальные классы R5 и затем на R4 — задача Фазы I программы. Полное покрытие R3–R5 — задача Фазы II.

4.4. Эпистемический контур

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

Уверенность пересматривается периодически, в режиме challenge pass: алгоритм отбирает записи высокой уверенности старше заданного возраста и пытается их опровергнуть на основе вновь поступившей информации. Найденные противоречия снижают уверенность; устоявшие записи её повышают.

Этот контур устраняет одну из главных уязвимостей LLM-агентов с долгой памятью — накопление устаревших или ошибочных «уверенных знаний», которые не подвергаются повторной проверке. Контур реализован в архитектуре; полная активация по слайсам памяти — задача Фазы I.

05  Архитектурные инварианты

Архитектура V сформулирована в форме инвариантов — утверждений о системе, нарушение которых считается дефектом, а не вариантом дизайна. Ключевые инварианты сопровождаются тестами, ломающимися при нарушении.

Провайдер-абстракция модели. Все вызовы языковых моделей проходят через единый интерфейс провайдера. Ядро не зависит от конкретной модели; добавление новой — адаптер плюс регистрация в конфигурации.

Политика — отдельный артефакт. Изменение политики не требует изменения core-кода и применяется горячей перезагрузкой без повторного развёртывания.

Действия класса R3+ проходят через verifier. Единая точка исполнения принимает только верифицированные действия; обход слоя верификации архитектурно невыразим.

Журнал решений с первого действия. Каждое решение verifier’а пишется в структурированный журнал. Формат журнала спроектирован под требования 17-го приказа ФСТЭК (см. раздел 06).

Тесты для архитектурных решений. Значимые архитектурные решения сопровождаются тестом, ломающимся при их нарушении.

Данные в юрисдикции РФ. Production-сборка не предполагает хранения, обработки или передачи пользовательских данных за пределы юрисдикции.

Готовность к ГОСТ-криптографии. Криптографические операции абстрагированы за интерфейс, допускающий замену провайдера без изменения вызывающего кода.

Полный перечень инвариантов с тестовым сопровождением фиксирован в архитектурной документации программы и доступен партнёрам под NDA.

06  Журнал решений

Каждое решение слоя верификации фиксируется в структурированном журнале. Текущая эксплуатация ведёт журнал в режиме append-only — записи добавляются и не модифицируются ретроактивно.

Референсная схема записи, спроектированная под требования 17-го приказа ФСТЭК, включает следующие поля:

timestamp · event_type · actor_id · action_type · target_resource · parameters · decision (allow / deny) · decision_reason · policy_version · agent_id · session_id

Эталонная схема предусматривает расширение журнала хеш-цепочкой записей для криптографического обнаружения ретроактивной модификации, а также подписи коммитов и журналирование на физически отдельный том — стандартные требования эксплуатации в КИИ-контуре. Эти элементы разворачиваются при аттестации на конкретном объекте; в текущем исследовательском стенде журнал ведётся append-only без криптоцепочки.

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

07  Состояние программы

Методологическая документация ведётся в формате архитектурных решений (ADR) и пронумерованной дорожной карты НИОКР. Наиболее значимые решения на момент публикации — классификатор эпистемической триажной обработки (ADR-014), Multi-Box Consensus критических действий (ADR-0005), Z3-верификация на пилотном классе действий (ADR-0039).

08  Дорожная карта Фазы I

Программа разделена на фазы. Фаза 0 — текущая, R&D-стенд. Фаза I — научная программа, под которую подаётся заявка о государственной поддержке. Фаза I содержит пять исследовательских milestone-ов, каждый сопровождается письменным артефактом (ADR / препринт) и тестовым покрытием.

Milestone 1. Schema-validation слой между выводом модели и executor’ом. Закрывает класс ошибок, связанных с malformed-параметрами критических действий.

Milestone 2. Внешняя политика как редактируемый артефакт: формат, версионирование, горячая перезагрузка, аттестация хешем.

Milestone 3. Расширение SMT-верификации с одного класса R5 на полное покрытие R5. Формализация политик, бенчмарк latency, состязательные кейсы.

Milestone 4. Активация эпистемического контура на slice-выборках долгосрочной памяти. Confidence-aware retrieval, метрики качества выборки.

Milestone 5. Challenge pass MVP. Автоматический пересмотр уверенности записей памяти на еженедельной основе, журналирование изменений уверенности.

Каждый milestone — самостоятельный научный результат. Совокупно они формируют первую в РФ публично документированную методологию формальной верификации действий мультиагентной системы. Фаза II — расширение покрытия и сертификация; содержание определяется по результатам Фазы I.

09  Открытость

Программа V придерживается раздельной модели публикации.

Публикуется открыто

Методология. Архитектурные инварианты. Референсная схема журнала. Шкала классов необратимости. Принцип Multi-Box Consensus. Дорожная карта фаз. Агрегированные метрики эксплуатации. Препринты по результатам каждого milestone.

Не публикуется

Конкретные политики на языке Z3. Системные промпты. Внутренняя структура агентов. Имена и параметры используемых языковых моделей. Топология инфраструктуры. Файлы конфигурации. Это закрыто как коммерческая тайна и интеллектуальная собственность института.

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

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

Программа V — один из исследовательских треков АНО «НИИ Системного Синтеза». Её результаты используются в методических материалах института по AI Governance и AI Safety, в публичной аналитической линии, в работе с партнёрами в финансовом секторе и государственных структурах. Архитектурные решения программы фиксируются в дисциплине ADR, описанной в Доктрине института.

Программа открыта для исследовательской коллаборации с академическими группами в области formal methods, AI safety и compliance-инженерии; регуляторного диалога с ФСТЭК, ЦБ РФ, Минцифры по вопросам сертификации мультиагентных систем; B2B-пилотов в банках, у операторов КИИ и в государственных структурах под NDA.

Контакт для всех типов запросов: info@isslab.ru. В теме письма указывается тип взаимодействия — академия, регулятор, пилот.