Агент затупил: как найти причину и починить ИИ-агента

Что значит «агент затупил» простыми словами

Машина заглохла. Дальше - два типа людей. Первый бьёт по капоту, кричит «ну давай же!» и в десятый раз крутит ключ в надежде, что «само заведётся». Второй открывает капот, светит фонариком - а там просто бензин кончился.

С ИИ-агентом ровно та же история. Он «затупил» - зациклился, ходит по кругу, спорит или несёт чушь. Новичок бьёт по капоту: переспрашивает то же самое чуть другими словами, злится и в финале сносит весь проект. А вайбкодер открывает капот: снимает диагноз, находит причину и лечит именно её. Разница - часы времени и куча сожжённых токенов.

Зачем учиться диагностике ИИ-агента

Затем, что агент будет тупить. Это так же неизбежно, как пробки в пятницу вечером. Вопрос один: что ты делаешь в этот момент - паникуешь или чинишь?

• Нет навыка диагностики - ты жжёшь токены (а значит, деньги) на бесполезных переспросах.
• Ты теряешь часы, споря с ИИ, хотя причину можно найти за минуту.
• В панике ты способен снести рабочий код, хотя поломка была на копейку.

Этот урок - твоя «аптечка». В скилле ECC ECC (Engineering-Centric Coding) - набор продвинутых рабочих приёмов для работы с агентами. agent-introspection-debugging - это «скилл самодиагностики»: учит агента разбирать свои сбои по шагам, прежде чем сдаваться. он называется agent-introspection-debugging - структурный разбор сбоя вместо слепых повторов. Сейчас разложим его на простые шаги.

Как починить агента: 4 шага вместо паники

Запомни одно правило: не повторяй одно и то же три раза, меняя пару слов. Это и есть самый частый антипаттерн. Хочешь результат - пройди по четырём фазам. Каждая занимает пару минут, а вместе они экономят часы.

Шаг 1. Зафиксируй сбой - сделай фото места аварии

Прежде чем что-то трогать - запиши, что вообще случилось. Не в голове, а словами:

• Что агент пытался сделать в момент поломки?
• Какая ошибка вылезла (точный текст, если есть)?
• Какой был последний удачный шаг?
• Какое действие повторяется по кругу?
• Что агент считает правдой про мир - где он думает, что находится (папка, ветка, какие файлы есть)?

Шаг 2. Найди причину - поставь диагноз

Теперь сопоставь симптом с типовой причиной. Их немного, и каждую легко узнать в лицо:

А вот четыре вопроса-фильтра - они отсекают лишнее и называют тип поломки:

• Это логика (агент неправильно думает), состояние (мир не такой, как он думает), окружение (что-то снаружи не работает) или правило (ему не дали инструкцию)?
• Не потерял ли он цель и не полирует ли не ту задачу?
• Сбой постоянный или случайный - мигнул и прошёл?
• Какое самое маленькое действие подтвердит, что я угадал причину?

Шаг 3. Лечи маленьким действием

Никаких «переписать всё заново». Бери самое маленькое действие, которое меняет картину:

Шаг 4. Короткий отчёт, чтобы не наступить на грабли снова

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

Когда тупит не модель, а обёртка (харнесс)

Бывает хитрее. Сама модель умная - ты гонял её «вживую», и всё ок. А внутри твоего приложения она тупит. Значит, виноват не повар, а кухня вокруг него - обёртка, она же харнесс. В ECC это разбирает скилл agent-architecture-audit.

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

Харнесс Харнесс (обёртка) - вся обвязка вокруг модели: инструменты, память, правила, формат вывода. Модель одна на всех, а обёртка у каждого приложения своя - и именно она чаще всего виновата в «ступоре». ломается несколькими типовыми способами:

Держи быстрые вопросы-индикаторы. Хоть на один ответ «да» - копай туда:

• Агент может пропустить обязательный инструмент и всё равно ответить? То есть правило живёт только в тексте, а не в коде.
• В новых разговорах всплывает старое содержимое? Память загрязнилась.
• Одно и то же лежит сразу в промпте, и в памяти, и в истории? Дублирование забивает стол.
• Ответ отличается между «внутри» и «на экране»? Что-то портит вывод по дороге.

Пример из жизни: агент чинит здоровую ногу

Ты делаешь телеграм-бота. Просишь агента «почини отправку сообщений». Он бодро правит код, рапортует «готово!». Проверяешь - тишина. Просишь снова - а он лезет в то же самое место и переписывает его другими словами. И ещё раз. И ещё. Токены тают, бот молчит, ты на грани.

А правда вот в чём: бот не запускался, потому что не был включён сам сервер (помнишь причину «отказ соединения»?). Агент чинил код, которому и так было хорошо, - лечил здоровую ногу, потому что ни разу не проверил реальность.

Вот как направить его по верному пути с первого захода:

Стоп. Не переписывай код заново. Сначала сделай диагностику по шагам:

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

Частые ошибки при отладке агента

• Бить по капоту. Повторять то же самое разными словами - главный антипаттерн. Сначала диагноз.
• Чинить не ту болезнь. Агент правит код, а проблема - в выключенном сервере. Проверяй реальность.
• Верить памяти агента. Он «помнит» файл, которого нет. Смотри, что реально на диске.
• Сразу сносить всё. Маленькое действие почти всегда выигрывает у «перепишем заново».
• Винить модель первой. Работало в playground, а у тебя нет - копай обёртку, а не модель.
• Молча радоваться «починил». Без короткого отчёта те же грабли прилетят тебе в лоб через час.