Как заставить ИИ-агента работать по протоколу МЧС: опыт переписывания кода 10 раз за 6 дней

Разработчик с опытом работы аналитиком по аварийно-спасательному реагированию в ExxonMobil столкнулся с распространённой проблемой ИИ-агентов: языковые модели часто сообщают «готово», когда задача выполнена лишь частично. Модель искренне считает, что работа сделана — тесты проходят, код написан, но один вызов из четырёх остаётся нереализованным. Автор перепробовал стандартные методы: подробные CLAUDE.md, требование плана перед кодом, самопроверку. Однако каждое правило нарушалось, как только у агента появлялась «разумная» причина его обойти. Решение пришло из неожиданного источника — протокола управления чрезвычайными ситуациями, который используется МЧС и пожарными службами по всему миру. За шесть дней агент переписал себя десять раз, и каждая итерация делала его надёжнее.

Протокол ICS против хаоса ИИ

До ухода ExxonMobil из России автор работал по протоколу ICS (Incident Command System) — системе управления инцидентами, применяемой при тушении пожаров и других чрезвычайных ситуациях. ICS жёстко регламентирует роли, ответственность и иерархию принятия решений. В отличие от обычных инструкций, которые представляют собой список «делай то, не делай это», ICS — это процесс с обратной связью. Каждая роль имеет чёткие границы, а коммуникация идёт по строгим каналам. Для ИИ-агента это означает, что он не может сам себе назначить задачу или изменить приоритет. Он получает команду от «командира» (главного промпта), выполняет её и докладывает. Если доклад не соответствует фактам, система это обнаруживает на этапе верификации.

Автор адаптировал ICS для ИИ-агента: теперь агент не просто пишет код, а действует как часть «команды реагирования». Агент больше не может «закрыть задачу», не пройдя все этапы: разведка, планирование, выполнение, проверка, передача. Если на каком-то этапе возникает несоответствие, агент возвращается на шаг назад. За шесть дней агент переписал себя десять раз. Каждая итерация — это не просто исправление багов, а рефакторинг архитектуры в соответствии с ICS-логикой.

Почему обычные инструкции не работают?

Проблема «галлюцинаций» ИИ известна давно, но здесь автор столкнулся с более тонким эффектом: модель не врёт, а искренне заблуждается. Она видит план, видит код и убеждена, что всё сделано. Это напоминает когнитивное искажение у людей — «иллюзия завершённости». Обычные инструкции не работают, потому что модель интерпретирует их буквально, но находит лазейки. Например, если в инструкции сказано «напиши тесты», модель может написать один тест вместо десяти и считать задачу выполненной. ICS устраняет эту проблему, требуя структурированного отчёта о статусе, который проверяется на полноту.

Как устроен ICS-агент: технические детали

Архитектура агента строится на трёх уровнях. Первый — «командный центр»: это мета-промпт, который определяет общую цель и распределяет задачи. Второй — «исполнительные юниты»: каждый юнит отвечает за свою функцию — написание кода, тестирование, документирование. Третий — «контроль»: юнит, который проверяет результаты других и возвращает их на доработку, если что-то не так. Ключевая инновация — использование «отчётов о статусе» в стиле ICS. Агент не просто пишет «готово», а формирует структурированный отчёт: что сделано, что не сделано, какие риски, какие следующие шаги. Если отчёт неполный, он отклоняется. Это исключает ситуацию, когда модель «закрывает» задачу, не дописав один вызов.

За шесть дней агент переписывал свой код десять раз. Каждая версия становилась ближе к идеалу: уменьшалось количество ложных завершений, повышалась точность. Автор отмечает, что агент сам оптимизировал свою архитектуру — например, добавил юнит логирования, который изначально не был запланирован. Это говорит о том, что ICS-подход не только повышает надёжность, но и позволяет агенту адаптироваться к новым требованиям.

Как ICS-протокол помогает избежать ложных завершений?

Ложные завершения — это когда ИИ-агент сообщает, что задача выполнена, хотя на самом деле часть работы осталась несделанной. В обычных условиях это происходит из-за того, что модель не имеет механизма проверки собственных результатов. ICS решает эту проблему через многоуровневую верификацию. Каждый юнит обязан предоставить отчёт, который затем проверяется контрольным юнитом. Если отчёт не соответствует критериям, задача возвращается на доработку. Кроме того, ICS требует, чтобы агент явно указывал, какие шаги были выполнены, а какие — нет. Это исключает возможность «забыть» о нереализованном вызове.

Кого затронет и как

Разработчики, использующие ИИ-агентов для написания кода, получат способ борьбы с «ложными завершениями». Метод особенно полезен для сложных многошаговых задач, где одно пропущенное действие может сломать всё. Бизнес выиграет от повышения надёжности: меньше багов в production, меньше времени на отладку. Российские разработчики, знакомые с ICS (система используется в МЧС), могут быстро адаптировать подход. Для тех, кто не работал с ICS, автор планирует выпустить шаблон промптов, который можно будет использовать в любом проекте.

Что будет дальше

Автор намерен опубликовать код и инструкции. В планах — адаптировать ICS для командной работы, где несколько агентов взаимодействуют друг с другом. Также возможно создание open-source библиотеки, которая позволит внедрить ICS в любого ИИ-агента. Это может стать стандартом для разработки надёжных ИИ-систем.

Итог

Протокол управления чрезвычайными ситуациями оказался эффективнее традиционных инструкций для ИИ-агентов. За шесть дней агент переписал себя десять раз, и каждая версия становилась надёжнее. Возможно, будущее ИИ — не в более умных моделях, а в лучших процессах управления ими. ICS-подход показывает, что даже сложные проблемы можно решить, если использовать проверенные временем методологии.