Как сделать AI-агента надёжным: пошаговый план от измерений до автономной работы

Почему агент ненадёжен, даже если модель сильная

Надёжность агента — свойство всей системы, а не модели. Длинная задача состоит из десятков шагов, и ошибки накапливаются: при 95% правильных шагов цепочку из десяти без единой ошибки проходит около 60% прогонов (0.95^10 ≈ 0.60), а из пятидесяти — меньше 10%. Поднять точность модели вы не можете, а вот ловить ошибку на том же шаге и делать её дешёвой — можете. Этим и занимается харнес: инструкции, инструменты, среда, состояние и обратная связь вокруг модели.

Ниже — план, который ведёт от «вайба» к измеримой надёжности и дальше к автономной работе. Шаги идут в порядке отдачи: каждый следующий опирается на предыдущий.

Шаг 1. Перестаньте оценивать «по ощущениям»

Один инженер уверен, что новый промпт всё изменил, другой не видит разницы, а метрик не считал никто. Начните с журнала провалов: каждый раз, когда агент застрял, сломал что-то или отчитался о неработающей фиче, записывайте одну строку.

| дата  | задача           | что случилось                  | подсистема     |
|-------|------------------|--------------------------------|----------------|
| 10.10 | скидки в корзине | «готово», e2e не запускал      | обратная связь |
| 10.10 | вебхук оплаты    | не смог поднять БД             | среда          |
| 11.10 | рефакторинг API  | повторил отвергнутое решение   | состояние      |

Колонка «подсистема» — главное. Через неделю станет видно, где горлышко, и чинить вы будете его, а не всё подряд. Считать надёжность по успешным прогонам — ошибка: именно журнал затыков показывает, где агент падает.

Шаг 2. Введите две метрики: MTBF и MTTR

Надёжность — это два числа. MTBF (среднее время между отказами) для агента — сколько шагов он проходит до затыка. MTTR (среднее время восстановления) — сколько уходит на возврат в рабочее состояние после сбоя. Доступность растёт и от роста первого, и от снижения второго.

Гонка за агентом, который вообще не ошибается, бесконечна. Снизить MTTR обычно можно за день. Поэтому начинайте со второго числа.

Шаг 3. Сделайте ошибку дешёвой

Автономность допустима не тогда, когда агент перестал ошибаться, а когда цена ошибки упала почти до нуля. Для этого нужно три вещи:

• Чистые небольшие коммиты — откат любой правки одной командой.
• Изоляция — агент работает в отдельной ветке или рабочей копии, например через git worktree, и в песочнице без доступа к продакшену.
• Скрипт сброса окружения — база, зависимости и сервисы возвращаются в исходное состояние одной командой.

git worktree add ../shop-agent -b agent/discount
cd ../shop-agent
make reset   # пересоздать БД, применить миграции, загрузить фикстуры

Проверьте секундомером, сколько занимает полный возврат к рабочему состоянию. Это и есть ваш MTTR. Заодно ограничьте радиус поражения: лимит на размер диффа одной задачи и запрет на правку файлов вне её области.

Шаг 4. Замкните петлю обратной связи

Без проверок агент — сам себе единственный судья, и он искренне считает работу выполненной. Дайте ему команды, которыми он проверяет себя, и сделайте их обязательными.

• Fail-fast: проверка падает на первой ошибке с понятным сообщением, а не выдаёт сто строк шума.
• Быстрые проверки после каждой правки: линтер и типизация через хук агента.
• Избыточность: вторая независимая проверка того же свойства — E2E-сценарий поверх юнит-тестов. Зелёные юнит-тесты не доказывают, что фича работает у пользователя.

Критерий «готово» записывайте как проверяемое условие: «E2E-сценарий оформления заказа с промокодом проходит», а не «реализована скидка».

Шаг 5. Вынесите память в файлы

Агент не помнит прошлую сессию. Всё, что нужно для продолжения работы, должно жить в репозитории: цель, сделанное и как проверено, решения с причинами, тупики, следующий шаг. Хороший признак — новая сессия, получив только репозиторий и слово «продолжай», сразу начинает полезную работу.

Длинная сжатая история диалога создаёт ощущение непрерывности, но теряет самое дорогое — причины отвергнутых решений. Осознанный сброс сессии с полным письменным состоянием обычно дешевле.

Шаг 6. Одна задача за раз

Закон Литтла: число задач в работе равно интенсивности поступления, умноженной на время задачи в системе. При фиксированной пропускной способности параллельные задачи не ускоряют работу, а только растягивают каждую. Для агента это ещё жёстче: три фичи — это три модели предметной области в одном окне контекста.

• Держите WIP=1: одна фича до проверенного результата.
• Режьте задачи по размеру: одна проверяемая пользовательская способность, 1–3 файла, проверка быстрее минуты.
• Заведите BACKLOG.md — клапан для «заодно». Заметил соседний недостаток — одна строка в бэклог, а не самовольная правка.

Шаг 7. Разведите исполнителя и проверяющего

Самооценка агента — слабый тормоз: та же сессия, которая писала код, склонна считать его правильным. Пусть результат оценивает отдельный сабагент или отдельная сессия, которая получает только требование, дифф и результаты проверок — без рассуждений исполнителя. Вердикт оценщика опирается на машинные проверки, а не на «выглядит нормально».

Шаг 8. Отпустите агента в автономный цикл

Харнес делает надёжным один прогон, цикл делает автономной серию прогонов. Цикл поверх плохого харнеса лишь быстрее множит ошибки, поэтому этот шаг — последний. Простейший цикл описывается тремя строками:

Цель:        e2e-сценарий оплаты с промокодом проходит
Проверка:    make lint && make test && make e2e
Остановка:   цель достигнута ИЛИ 15 попыток ИЛИ 2 часа → позвать человека

Выберите тип цикла по задаче. Если у работы есть финишная черта, нужен цикл по цели: память о прогрессе, независимый оценщик и бюджет шагов. Если конца нет (утренняя проверка CI, разбор новых ошибок) — цикл по расписанию. Частая ошибка — запускать по расписанию задачу, у которой есть конец: каждый запуск начинает её с нуля.

Правила безопасной автономии

• Условие остановки — только машинно проверяемое, плюс лимит попыток и бюджета.
• Эскалация: заранее перечислите, что циклу не доверяется (миграции продакшена, деньги, удаление данных).
• Если задача буксует, прогресс не растёт по существу — это сигнал передать её человеку, а не крутить дальше.
• Читайте диффы. Скорость цикла не должна превышать скорость вашего чтения, иначе вы перестаёте понимать собственную кодовую базу.

Частые ошибки на этом пути

Начинать с переписывания инструкций

Самый популярный ответ на сбой агента — дописать правило в AGENTS.md. Через пару месяцев файл разрастается до сотен строк, и важные правила в нём теряются. Если журнал провалов показывает, что агент не запускал проверки, лечить нужно обратную связь: команду проверки и хук, а не ещё один абзац текста.

Чинить всё сразу

Пять подсистем харнеса хочется улучшить одновременно. Но тогда непонятно, что именно помогло. Оцените каждую подсистему по шкале от 1 до 5, потратьте полчаса на самую слабую и прогоните один и тот же набор из пяти типовых задач до и после. Разница в журнале провалов покажет, был ли эффект.

Путать «тесты зелёные» и «фича работает»

Агент может написать тест, который проверяет его собственную реализацию, а не требование. Такой тест зелёный всегда. Защита — проверка на уровне пользователя (E2E-сценарий), написанная до реализации или независимым проверяющим, и правило, что агент не правит тест, чтобы он прошёл.

Выключать проверку ради скорости

Медленные проверки соблазняют пропустить их «в этот раз». Лучше разделить их: быстрые линтер и типизация — после каждой правки, полный набор тестов и E2E — перед словом «готово». Так петля обратной связи остаётся короткой и не мешает работе.

Считать абляцию первым шагом

Можно по очереди отключать подсистемы харнеса и смотреть, насколько падает качество. Это полезная проверка, но дорогая и не первая: сначала журнал провалов укажет на горлышко, а абляция лишь подтвердит гипотезу. Нулевая просадка при отключении компонента не значит, что он не нужен, — возможно, его просто не задействовал выбранный набор задач.

Лестница зрелости

Итог

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