UML-диаграмма состояний AI-оркестратора

Поразмыслив над комментариями к предыдущему посту о декомпозиции AI-агента QA в связке с AI-агентом Code и оркестратором, решила описать внутреннюю логику работы Orchestrator (стейт-машины процесса автоматизации). Добавила префлайт-чеков (Token_PreFlight_Check) для закрытия критических архитектурных рисков AI-агентов: бесконечных автофиксов кода, неконтролируемых денежных трат. Схема детализирует требования к «самолечению» AI-системы.

Плюсы такой логики: ✔️ Защита от финансового выгорания (Token_Exceeded). Лимит в > 500k токенов на сессию — пороговое значение, предотвращающее перерасход бюджета при сложных багах. ✔️ Защита от бесконечного автофикса (Loop_Detected). Ограничение в > 5 итераций (Hard-cap) защищает систему от циклической генерации одного и того же нерабочего кода. ✔️ Безопасность репозитория (Atomic_Rollback). Использование Git_Reset при зацикливании гарантирует чистоту тестовой и рабочей среды. ✔️ Оптимизация контекста (Log_Condensation). Выделение только Stack Trace из логов перед отправкой AI-агенту Code — решение, экономящее до 80% входных токенов.

Есть ли минусы?

Исходник артефакта закоммитила на гитхаб в новую ветку tanyashipunova/ai_agents_costs/blob/v1600/stateDiagram_v1622

UML-диаграмма состояний AI-оркестратора | Сетка — социальная сеть от hh.ru UML-диаграмма состояний AI-оркестратора | Сетка — социальная сеть от hh.ru