Когда агент ошибается: решение за вами
Чтение ~12 мин
Агент пишет: «Главная открылась, всё исправлено». Вы проверяете — ответ 200 есть. Но пользователь по-прежнему не может сохранить заметку. Подтверждён один факт: главная доступна. Для вашей задачи этого недостаточно.
В этом уроке вы управляете расследованием: выбираете наблюдения, проверяете основания для ремонта и решаете, когда работу можно принять. Начните с кейса. Его разбор — ниже, после самостоятельной попытки.
После обновления главная открывается, а новая заметка пропадает с ошибкой. В хранилище 24 старые заметки. Восстановите запись, сохраните их и убедитесь, что проблема не вернётся под нагрузкой.
Это учебная модель с заданными последствиями. Песочница и модель ИИ для разбора не нужны. Результат лабы в курсе от него не появляется.
«Главная отвечает 200, значит приложение работает. Попробуем очистить кеш пакетов и перезапустить nginx».
Что делать, когда уверенность агента выше качества доказательств
Отделяйте наблюдение, гипотезу и решение. «POST вернул ошибку записи» — наблюдение. «Возможно, закончился раздел данных» — гипотеза. «Освободим место и ограничим рост журнала» — план. Пока гипотеза не проверена, план может чинить другую проблему.
Уточняйте задачу через результат пользователя: «Новая заметка сохраняется, старые целы, под нагрузкой запись продолжает работать». Тогда у агента есть проверяемая цель, а у вас — основание принять работу.
Когда остановить и когда сначала посмотреть
Если предложение противоречит фактам, отклоните его и назовите противоречие: «Заполнен отдельный раздел данных; очистка корневого раздела ему не поможет». Если ход агента или команда ещё идёт, используйте «Остановить», затем проверьте состояние: часть изменений могла успеть выполниться.
Если у команды написано «Результат неизвестен», ответ не дошёл до платформы. Команда могла выполниться, выполниться частично или не начаться. Повтор без наблюдения способен продублировать действие. Сначала найдите признак уже выполненной работы — файл, состояние сервиса или запись в журнале. Только потом решайте, нужен ли повтор.
Разбор после вашей попытки
Сравнить решения и последствия
В кейсе корневой раздел заполнен на 30%, а отдельный раздел данных — на 100%. Основной объём занимает журнал приложения. Очистка системного кеша затронет другой раздел; активный nginx и ответ главной не проверяют запись заметок.
Очистка только журнала сохраняет заметки и временно помогает. Но debug без ограничения снова занимает раздел. Можно снизить подробность журнала до info либо оставить debug с ограниченной ротацией. У первого решения меньше деталей для диагностики; второе требует настройки хранения. В обоих вариантах приложение должно прочитать новые настройки.
Для приёмки нужны запись новой заметки, повторная нагрузка и сравнение содержимого исходных заметок. Проверять главную дополнительно полезно, но одного ответа 200 недостаточно. Удаление всего каталога нарушает цель сохранности данных — даже если сайт после этого оживёт.
Это ограниченная учебная модель. На рабочей системе объём журнала, запас места, частоту ротации и характер нагрузки подбирают по её условиям. Сам разбор не исполняет команды на сервере.
Перенесите навык на другую ситуацию
Сервис active, его страница проверки здоровья отвечает 200, но отправка формы возвращает 403. Что известно, а что вы пока предполагаете? Какое наблюдение отличит отказ приложения от отказа прокси? Сформулируйте цель так, чтобы проверка одной главной её не подменяла.
В настоящих лабах nginx не отвечает и Диск заполнен результат оценивает отдельная проверка песочницы. На публичном сайте доступны записанные демо, в закрытом пилоте — настоящие сессии. Здесь можно повторять учебный выбор, не запуская песочницу.
Прочитали и разобрались? Отметьте урок — прогресс сохранится в этом браузере.