Цикл работы агента
«Напиши мне в сваггере три метода», попросил я как-то агента, который вел документацию по апи. Получил в ответ три разных файла сваггера, по одному на метод. Формально задача выполнена, каждый метод описан корректно, только смысла в трех отдельных файлах не было никакого: я ждал один документ с тремя эндпоинтами внутри. Агент не переспросил и не сверился с тем, как уже была устроена документация в проекте, просто взял и сделал. Это живая иллюстрация того, что происходит, когда цикл, о котором дальше пойдет речь, где-то ломается.
Цикл называется «perception-planning-action-verification» («восприятие - планирование - действие - проверка»), и крутится на каждом шаге, пока задача не закрыта:
Восприятие (perception): агент смотрит, что у него есть прямо сейчас: содержимое файла, ответ API, вывод команды в терминале, актуальное состояние мира на этом шаге.
Планирование (planning): модель каждый раз заново решает, что делать дальше, исходя из того, что увидела на предыдущем шаге.
Действие (action): вызов инструмента, правка файла, запрос в API, команда в консоли. Единственный шаг, где агент реально меняет что-то во внешнем мире.
Проверка (verification): агент смотрит на результат своего же действия. Файл сохранился? Тест прошел? Апи ответил ошибкой? Это переход к следующему восприятию, цикл замкнулся.
В моей истории со сваггером сломалось на планировании: агент воспринял «три метода» буквально как «три отдельных файла», ни разу не сверившись с тем, что уже лежит в проекте, и проверка на выходе прошла формально: файлы-то валидные.
Кстати, для аналитика тут есть прямая параллель. Этот цикл почти дословно повторяет то, что ты описываешь в постановке для любого процесса с обратной связью: получили событие, приняли решение по бизнес-правилам, выполнили действие, зафиксировали результат и проверили, нужно ли что-то компенсировать.
Зачем это знать? Когда агент выдает не то, что ты просил, эта схема дает конкретную точку, куда смотреть: агент не увидел нужный контекст на восприятии, неправильно спланировал следующий шаг или проверка на выходе прошла формально. Вместо того чтобы переписывать промпт наугад и надеяться на удачу со второй попытки, можно понять, какой именно шаг цикла не сработал, и поправить именно его: добавить контекст, уточнить условие или заложить более строгую проверку результата.
«Напиши мне в сваггере три метода», попросил я как-то агента, который вел документацию по апи. Получил в ответ три разных файла сваггера, по одному на метод. Формально задача выполнена, каждый метод описан корректно, только смысла в трех отдельных файлах не было никакого: я ждал один документ с тремя эндпоинтами внутри. Агент не переспросил и не сверился с тем, как уже была устроена документация в проекте, просто взял и сделал. Это живая иллюстрация того, что происходит, когда цикл, о котором дальше пойдет речь, где-то ломается.
Цикл называется «perception-planning-action-verification» («восприятие - планирование - действие - проверка»), и крутится на каждом шаге, пока задача не закрыта:
Восприятие (perception): агент смотрит, что у него есть прямо сейчас: содержимое файла, ответ API, вывод команды в терминале, актуальное состояние мира на этом шаге.
Планирование (planning): модель каждый раз заново решает, что делать дальше, исходя из того, что увидела на предыдущем шаге.
Действие (action): вызов инструмента, правка файла, запрос в API, команда в консоли. Единственный шаг, где агент реально меняет что-то во внешнем мире.
Проверка (verification): агент смотрит на результат своего же действия. Файл сохранился? Тест прошел? Апи ответил ошибкой? Это переход к следующему восприятию, цикл замкнулся.
В моей истории со сваггером сломалось на планировании: агент воспринял «три метода» буквально как «три отдельных файла», ни разу не сверившись с тем, что уже лежит в проекте, и проверка на выходе прошла формально: файлы-то валидные.
Кстати, для аналитика тут есть прямая параллель. Этот цикл почти дословно повторяет то, что ты описываешь в постановке для любого процесса с обратной связью: получили событие, приняли решение по бизнес-правилам, выполнили действие, зафиксировали результат и проверили, нужно ли что-то компенсировать.
Зачем это знать? Когда агент выдает не то, что ты просил, эта схема дает конкретную точку, куда смотреть: агент не увидел нужный контекст на восприятии, неправильно спланировал следующий шаг или проверка на выходе прошла формально. Вместо того чтобы переписывать промпт наугад и надеяться на удачу со второй попытки, можно понять, какой именно шаг цикла не сработал, и поправить именно его: добавить контекст, уточнить условие или заложить более строгую проверку результата.