Экосистема AI Vibe
Агенту нужен не ещё один retry, а контракт эскалации
У coding-агента в соло-workflow четыре честных выхода, когда цикл застрял: повторить в рамках бюджета, отдать специалисту, запросить у человека узкое решение или остановиться. Без такого контракта сильная модель и длинные rules в IDE не спасают от бесконечных «починю ещё раз» и размытых вопросов вроде «можно продолжать?». Автор miruky называет подход Escalation Engineering и выкладывает исполняемый Python-референс, который можно прогнать локально без API-ключа.
Четыре режима вместо одного «ещё разок»
Retry, delegate, scoped decision, stop: четыре именованных режима, не бесконечный цикл ремонта.
Сниппет и развёрнутый текст miruky сходятся на одном практическом контракте. Обычный retry оставляет того же владельца и тот же план исполнения. Эскалация меняет владельца, модель, инструмент, источник доказательств, уполномоченного решателя или вводит терминальную остановку. Для release-агента размытый human-in-the-loop не подходит: вместо «Can I continue?» нужен проверяемый вопрос, можно ли опубликовать текущий артефакт в конкретный destination до дедлайна. Ревьюер одобряет или отклоняет действие, а не «продолжай работу вообще».
Полная диагностика у debugging specialist идёт отдельным маршрутом.
Публикация остаётся своим шагом с собственным approval, даже после успешного ремонта.
Capability сильной модели не заменяет authority на publish: опыт «починить сборку» не равен праву выкатить релиз без решения владельца артефакта.
| Ситуация | Маршрут |
|---|---|
| Та же проверка совместимости падает после трёх попыток ремонта (иллюстративный лимит в примере) | Эскалация к debugging specialist |
| Рутинный transient-сбой | Bounded retry в рамках бюджета |
| Запрещённая операция | Stop |
| Нет права на publish | Scoped release decision у уполномоченного reviewer |
| Reviewer недоступен для consequential action | Пауза до deadline; timeout policy может закрыть запрос |
Лимиты не должны обнуляться сменой task id.
Учитываются max repair attempts, глубина делегирования, elapsed time и spending budget. Эскалировать стоит при смене expertise, разрешённого действия, evidence или decision owner, а не на каждый мелкий edit. Иначе human attention сгорает быстрее, чем токены.
Trusted host: где живут credentials и digest
Модель предлагает операцию и аргументы; доверенный хост подставляет revision и evidence и пропускает dispatch только для ещё актуального одобренного запроса. Для артефактов в proposal фиксируется content digest, а adapter при dispatch сравнивает одобренный digest с хешем фактических байтов. Иначе approval на старую версию файла остаётся «бумажным».
В комментариях к публикации miruky уточняет: для expiry controller опирается на host clock, а не на «время модели».
В соло-практике rules и промпты задают наблюдаемые триггеры: exit status, повторяющаяся сигнатура ошибки, конфликт источников, превышение бюджета. Не «модель на 95% уверена» без калибровки по исходам. Четыре свойства, которые автор выделяет явно (capability, authority, autonomy, accountability), напоминают: назначение LLM не снимает организационную ответственность с человека.
Офлайн-референс: проверить policy без облачного ключа
Репозиторий miruky/escalation-engineering: типизированный Python-пакет, настраиваемая policy, долговечный SQLite controller и локальные примеры. Демо release использует детерминированных actors, чтобы решения контроллера были видны без выбора провайдера модели; proposer и specialist можно заменить, сохраняя host policy и границу dispatch.
Требуется Python 3.10+.
Минимальный прогон по шагам автора:
git clone https://github.com/miruky/escalation-engineering
cd escalation-engineering
python3 -m venv .venv
source .venv/bin/activate
pip install -e .
escalate demo
Для соло-разработчика это способ отладить пакеты approval (goal, operation, artifact, digest, required reviewer roles, resume condition) до того, как те же правила попадут в agent graph. LangGraph (interrupts и resume с перезапуском узла), RouteLLM и guidance Anthropic по agent design miruky приводит как внешние опоры: не обязательный стек, а контекст, где пауза и повторный dispatch без reconciliation опасны для payment и release.
Resume condition «человек ответил» слабая.
Нужно валидное решение от authorized identity на текущий request, action, arguments, evidence и state revision. Смена artifact после approval аннулирует покрытие; то же правило стоит закрепить в Cursor rules или system prompt для агента с mutation tools.
Формальных SLA у miruky нет: что крутить руками
Числовых KPI latency, cost или human-in-the-loop SLA автор не фиксирует. Зато есть операционные рычаги: бюджеты попыток, времени и денег, инспекция связи triggers → resolved outcomes при настройке policy. Повтор одного и того же failure у specialist сигнализирует чинить return condition или packet; stale approvals лечатся snapshot binding; повтор uncertain external effect требует reconciliation, а не слепого repeat.
Текст сопровождается пометкой AI assistance и independently verified against linked sources.
Сверяйте контракт с собственным host policy, а не копируйте формулировки в production вслепую.
Практический вывод для vibe coding: до очередного «улучшим промпт» зафиксируйте четыре исхода, пакет scoped approval на publish и offline demo. Иначе агент останется автономным там, где нужна accountability.
Источники
- miruky, «Your AI Agent Needs an Escalation Path: Introducing Escalation Engineering» (Dev.to, опубликовано 2026-09-26): Dev.to
- Репозиторий reference implementation: https://github.com/miruky/escalation-engineering