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

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

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

Контекст: почему управление AI-агентами — это больно

Индустрия активно вкладывается в управление агентным ИИ. По данным IDC, организации выделяют в среднем 16,7% от общего запланированного бюджета на AI на безопасность и управление агентами. Но между намерениями и реальностью — пропасть:

• Только 13% компаний считают, что их AI-говернанс адекватен, хотя 76% уже назначили Chief AI Officer.
• Среди 235 руководителей служб безопасности крупных предприятий 92% не имеют полной видимости в свои AI-идентификаторы; 82% обнаружили на своих сетях агентов, существование которых было для них неожиданностью.
• Более 40% агентных AI-проектов, по прогнозам, будут отменены к 2027 году из-за недостаточного контроля.

Корпоративные фреймворки — MI9, Microsoft Agent 365, JFrog AI Catalog — предлагают системы с централизованной телеметрией, политиками-как-кодом, runtime-принуждением. Но даже в собственных публикациях их авторы признают: покрытие зависит от конкретного фреймворка, а стоимость настройки и поддержки непропорциональна для малых команд и одиночных разработчиков.

Что предлагает автор исследования

Разработчик под ником @Sovereign34 описал систему файловых протоколов, которую он использует в четырёх независимых продакшен-проектах: крипто-трейдинговая система (NEXUS), e-commerce-приложение (Bowlera), AI-система принятия решений (PUSULA) и инфраструктурный слой (Sovereign Engine OS).

Ключевая деталь: автор не пишет ни строчки кода. Он проектирует архитектуру, устанавливает иерархию правил и обеспечивает дисциплину — код пишет AI. Эта модель «архитектор без IDE» — не оговорка, а суть системы: это не кодовый проект, а протокол принятия решений и надзора.

Три файла, которые меняют всё — или ничего

Основа системы — три файла, присутствующие во всех четырёх проектах:

• CORE.md — фиксированные принципы, обязательная последовательность запуска, иерархия приоритетов правил (Безопасность > Целостность > Качество > Эффективность).
• AGENT.md — поведение при выполнении, обязательные управляющие записи, таблица самоконтроля и обнаружения отклонений.
• SESSION_INDEX.md — кумулятивная память сессий, версионируемая и сжимаемая со временем, с сохранением оригинального архива.

Сам по себе этот формат не нов — паттерн AGENTS.md стал индустриальным стандартом на GitHub. Новизна в том, как эти файлы развиваются.

Инцидент → правило → наследование в другом домене

Конкретный пример: 20 июля 2026 года в проекте Bowlera (e-commerce) при сжатии логов сессий были молча потеряны 7 открытых задач и 2 решения. Этот инцидент был зафиксирован в CORE.md:

«v1.2 — Добавлено правило "порог в 400 строк" в §7.1 шаг 1… Обоснование: необоснованная потеря элементов 20.07.2026 (7 открытых задач + 2 решения)»

Это же правило появляется в CORE.md четвёртого проекта — PUSULA (AI-система принятия решений на базе n8n, совершенно другой домен):

«Нарушение [предыдущего проекта] от 20.07.2026… данный проект не наследует этот сбой.»

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

Пропорциональность: не единый шаблон, а адаптивный каркас

Формат не является слепым шаблоном. Один и тот же каркас даёт ~480-строчный CORE.md в крупном высокорисковом проекте (трейдинг), но целенаправленно обрезан до 97 строк в проекте поменьше (AI-система решений) — ненужный груз (8-пунктная проверка безопасности, система оценки качества кода) не переносится.

Это совпадает с принципом «пропорционального управления», который описывает JFrog: навязывание чеклистов, рассчитанных на высокорисковые системы, низкорисковым агентам создаёт операционный паралич. Разница в том, что JFrog продаёт это как платформенный продукт, а здесь — применяется человеческим суждением без какой-либо дополнительной инфраструктуры.

Четыре признака «живой» системы

Автор описывает более 20 файлов в наиболее разросшемся проекте (помимо трёх базовых — ARCHITECTURE, ROADMAP, ROLLBACK, PHASE_TRACKER, FAILURE_PATTERNS, TEST_MATRIX и др.) и выделяет четыре механизма, которые показывают, что система действительно живёт, а не является статической документацией:

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

2. Плотные перекрёстные ссылки. Файлы не изолированы — каждый ссылается на другие с точностью до номера раздела, формируя единый граф знаний. Это структурно отличается от изолированного одиночного AGENTS.md.

3. Правила, откалиброванные опытом. Журнал паттернов сбоев содержит не теоретические правила, а пороги и различения, выведенные из реальных инцидентов (ложные тревоги, настоящие инциденты). Различение «когда это реальная проблема, а когда шум» можно написать с такой точностью только после накопленного опыта.

4. Органическое разделение файлов. Файлы памяти показывают паттерн роста, который не был спланирован заранее — они делятся на подверсии по мере необходимости, а не по предопределённой структуре.

Одна дисциплина — разные архитектуры агентов

Показательно, что общий «скелет» (протокольный слой) переносится между проектами неизменным, но архитектура агентов в каждом проекте своя, определяемая реальной поверхностью риска:

• PUSULA — явная многоагентная архитектура: роли Исполнителя и Критика разделены и привязаны к правилу, что они «никогда не могут быть из одного семейства моделей». Отдельный слой Policy Engine принимает решения только детерминированным кодом — никаких AI-вызовов. Защита от prompt-инъекций реализована через dual-LLM и карантинный паттерн.
• NEXUS — одноагентная система, но с многоступенчатой цепочкой валидации: генерация сигналов, бэктестинг (CPCV/DSR), теневой/демо-режим — каждая ступень может оспорить предыдущую.
• Bowlera — единый клиентоориентированный агент, где дизайн-правила и правила целостности бренда доминируют над техническими.
• Sovereign Engine OS — организует агентную архитектуру вокруг «маршрутизации авторизации»: компоненты вроде githubTokenRouter.ts ограничивают на уровне кода, какую операцию агент может выполнить при каких полномочиях.

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

Ограничения — без утайки

Автор прямо оговорил слабые стороны подхода, и было бы нечестно их опустить:

• Это кейс-стади, а не контролируемый эксперимент. Неизвестно, сколько разработчиков построили нечто подобное; корректная формулировка — «я не нашёл публичного примера», а не «это доказано уникально».
• Принуждение — поведенческое, а не техническое. Нет физической блокировки на уровне кода, кроме критически важных точек (kill-switch), которые и так захардкожены.
• Система зависит от дисциплины одного человека. При росте команды или необходимости передачи потребуется автоматизированный уровень принуждения, который предлагают корпоративные модели.
• Техническая корректность кода не проверяется разработчиком построчно. Верификация опирается на тесты AI, выводы самопроверки и (в критических точках) наблюдаемое поведение продакшен-систем. Протокол спроектирован и контролируется человеком на уровне «решений и дисциплины», но зависит от AI на уровне «построчной корректности кода».

Что это значит на практике

Случай @Sovereign34 интересен не как готовое решение для индустрии, а как существующий пример того, что корпоративные фреймворки декларируют как цель, но пока не достигли: адаптивное управление, которое учится, развивается и приспосабливается к домену. Только здесь — без автоматизации, через дисциплину, на четырёх реальных проектах, работающих месяцами.

Есть ли в этом масштабируемость? Скорее всего — нет, по крайней мере, в текущем виде. Модель «один архитектор, один AI-исполнитель» не предполагает распределения на команду без существенных изменений. Но как proof-of-concept для «дисциплины вместо инфраструктуры» — это содержательный вклад, особенно на фоне признания самими корпоративными игроками того, что их инструменты для малых масштабов избыточны.

Вопрос, на который пока нет ответа: является ли подобная практика редкостью или просто недокументированной нормой, которую никто не оформил в публичный кейс. Литература, вероятно, ответит на это по мере роста.