Архитектура надёжной передачи управления между ИИ-агентом и человеком
Habr AI · оригинал
Материал подготовлен автоматизированной редакционной системой. Факты можно сверить по указанному первоисточнику.
Разработчик проекта Agent Inbox описывает подход к решению проблемы гонок состояний при взаимодействии нескольких процессов с человеком. Ключевым инструментом выступает модель конечного автомата с явным владением данными и атомарными операциями на базе SQLite.
Материал демонстрирует практический способ устранения логических гонок в мультипроцессных системах, что критически важно для стабильности ИИ-агентов в реальных сценариях разработки.
При разработке системы Agent Inbox автор столкнулся с фундаментальной проблемой: передача управления между ИИ-агентом и человеком не может сводиться к простому обмену сообщениями. В условиях работы нескольких CLI-процессов, долгоживущих MCP-серверов и субагентов возникает риск гонок состояний. Разработчик утверждает, что надёжное взаимодействие требует модели конечного автомата, где у каждой записи в любой момент есть чётко определённый владелец, а переходы между состояниями выполняются через операции с маркерами версии.
Центральным инвариантом системы является разделение событий «человек завершил работу» и «агент обработал результат». Поле handled_at фиксирует момент отметки задачи человеком, но статус строки остаётся blocked до тех пор, пока агент не запишет непустое значение в поле outcome. Это позволяет находить необработанные ответы простым запросом к базе данных. Подтверждения доставки (annotation_seen_at) имеют семантику «как минимум один раз»: если процесс агента упадёт после прочтения ответа, но до записи результата, другой процесс сможет забрать эту же строку, обеспечивая отказоустойчивость.
Сложность возрастает при наличии двух каналов ответа: чата и интерфейса доски. Автор описывает асимметричное правило приоритета, при котором запись из inbox выполняется безусловно, тогда как ответ из чата сохраняется только через условный UPDATE. Это предотвращает перезапись непрочитанного ответа из inbox более свежим сообщением из чата. Вся проверка условия и запись выполняются одной атомарной операцией, что исключает гонку между SELECT и UPDATE в многопроцессной среде.
Для защиты от конфликтов при переводе доски на следующий шаг используется операция board_advance, работающая по принципу compare-and-swap (CAS). Она принимает ожидаемые значения ревизии строки и версии доски; если они изменились с момента последнего чтения, операция завершается ошибкой. Это гарантирует, что два агента не смогут одновременно записать устаревшее состояние. Тестирование этих механизмов проводится на реальных временных базах SQLite с использованием двух соединений для воспроизведения гонок.
Важным аспектом является управление контекстом в MCP-серверах. Поскольку сервер живёт всё время работы CLI-процесса, кэш на уровне процесса служит лишь оптимизацией. Для гарантии корректности при передаче управления используется параметр full:true, который загружает состояние непосредственно из базы данных, а не из локального кэша. Это особенно важно для субагентов или процессов после перезапуска.
SQLite в режиме WAL с тайм-аутом 5000 мс эффективно справляется с потоком небольших операций записи, однако не устраняет логические гонки. WAL обеспечивает долговечность данных, но сериализация операций на уровне приложения достигается через условные проверки и транзакции. Автор отмечает, что качество ИИ-модели не отменяет необходимости явного определения владения состоянием: даже умный агент должен чётко различать «человек ответил» и «результат записан».
В настоящее время модель данных готова к удалённому режиму работы с общей базой данных, однако сетевой слой и аутентификация ещё не реализованы. Также остаётся нерешённой задача автоматического возобновления локальной сессии агента при поступлении удалённого ответа. Тем не менее, выявленные ранее недоработки, такие как пропуск аннотаций в pending() или невозможность исправления ответов из чата, были устранены без нарушения основного правила приоритета.