ИИ не должен управлять исполнением. Заметки о детерминированном FSM-рантайме для агентов
Большинство рантаймов для ИИ-агентов сейчас работают по одному простому паттерну: LLM -> вызов инструмента -> рантайм выполняет сайд-эффект.
Для read-only задач это работает вполне сносно. Но как только агенты начинают мутировать внешнее состояние (платежи, базы данных, инфраструктуру, персональные данные), такая модель исполнения становится слишком сложной для операционного контроля и прогнозирования.
В процессе подготовки части наших внутренних агентов к деплою, мы пришли к необходимости полностью разделить процессы «рассуждения» (reasoning) и право на исполнение (execution authority).
Мы написали nano-vm — детерминированный FSM-рантайм (конечный автомат), в котором:
модель лишь предлагает действия;
рантайм жестко контролирует переходы состояний и сайд-эффекты.
Рантайм принудительно обеспечивает:
конечные графы исполнения;
строгий порядок шагов, зафиксированный при компиляции (compile-time ordering);
capability-gating для инструментов (жестко изолированные доступы);
границы идемпотентности и защиту от replay-атак;
append-only историю аудита.
Одно из архитектурных решений, которое оказалось критически важным: слой политик намеренно сделан менее выразительным, чем Python.
Мы полностью отказались от eval-подобного исполнения и ограничили политики небольшим детерминированным подмножеством AST:
только простые операторы;
никаких циклов;
никаких системных вызовов.
Это ограничение радикально упростило аудит и исключило целые классы рантайм-поведения, которые мы не хотели видеть в финансовых воркфлоу.
Sabotage Mode и семантика отказов
Чтобы протестировать семантику отказов, мы добавили в демо-стенд «Sabotage Mode» с несколькими векторами атак:
неавторизованная инъекция инструментов (tool injection);
попытки повторного выполнения (replay-атаки);
подделка хешей (hash corruption);
пропуск шагов пайплайна (skipped transitions).
С точки зрения эксплуатации самым полезным свойством пока оказались именно детерминированные границы повторного воспроизведения вокруг сайд-эффектов.
Нам также пришлось решать крайне неудобную compliance-проблему: как сохранить неизменяемые цепочки аудита (immutable audit chains) и при этом выполнить требования 152-ФЗ / GDPR об уничтожении данных. Наш текущий подход заменяет ссылки в хранилище на маркеры-надгробия (tombstones), полностью сохраняя криптографическую непрерывность хешей и ссылочную целостность графа.
В основном мне интересно, как другие инженеры решают проблему права на исполнение в stateful-агентах. Вы позволяете модели напрямую управлять сайд-эффектами или встраиваете детерминированный слой контроля между ними?
Core runtime: github.com/Ale007XD/nano_vm
MCP layer: github.com/Ale007XD/nano-vm-mcp
Live Sabotage Demo: demo.bannerbot.ru:8843
