Перейти к содержимому

Рабочий цикл с агентом

Работа с агентом даёт стабильный результат, когда она устроена как процесс, а не как серия импровизаций. Базовый цикл выглядит так:

сформулировать → (для сложного) спланировать → выполнить → проверить → зафиксировать, и снова сначала.

flowchart LR
    F["Сформулировать"] --> P{"Сложная задача?"}
    P -->|"да"| PL["Спланировать"]
    P -->|"нет"| E["Выполнить"]
    PL --> E
    E --> V["Проверить"]
    V --> C["Зафиксировать (коммит)"]
    C --> F

Каждый проход цикла — это одна законченная, проверяемая порция работы. Ниже разобрано, что происходит на каждом шаге.

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

Спланировать: почему план до кода экономит часы

Заголовок раздела «Спланировать: почему план до кода экономит часы»

Для сложных задач (рефакторинг, новая подсистема, изменение, задевающее много мест) просите план до любых правок. Большинство харнесов имеют для этого отдельный режим планирования (plan mode), в котором агент читает код и предлагает подход, но ничего не меняет.

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

Хороший план агента содержит: шаги в порядке выполнения, список затронутых файлов, спорные места («предполагаю, что API можно менять, верно?»). Плохой план — пересказ вашей же задачи. Плохой план заворачивайте так же, как плохой код.

Выполнить: декомпозиция на проверяемые шаги

Заголовок раздела «Выполнить: декомпозиция на проверяемые шаги»

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

«Выполняй план по шагам. После каждого шага: прогони тесты, покажи краткий итог и остановись. Я посмотрю и скажу, продолжать ли».

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

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

Для кода фиксация — это коммит; для документов — сохранённая версия. Git превращает работу с агентом из рискованной в почти безопасную:

  • Отдельная ветка на задачу. Агент работает в ветке: что бы он ни натворил, основная ветка цела.
  • Частые мелкие коммиты. Коммит после каждого проверенного шага. Если шаг 5 пошёл не туда, вы откатываетесь к шагу 4 одной командой, а не разбираете клубок из пяти шагов.
  • Лёгкий откат вместо спора. Если агент запутался, часто быстрее сделать git checkout к последнему хорошему состоянию и поставить задачу заново с уточнением, чем просить «исправь то, что ты только что сломал».

Уровни доверия: что на автопилоте, а что под присмотром

Заголовок раздела «Уровни доверия: что на автопилоте, а что под присмотром»

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

  • Автопилот: чтение файлов, поиск по коду, запуск тестов и линтеров — действия, которые ничего не ломают.
  • С подтверждением: правка файлов на ранних этапах доверия, установка зависимостей, сетевые запросы, любые команды с побочными эффектами.
  • Только вручную (агенту не доверяется): git push в основную ветку, удаление данных, любые операции с продакшеном.

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

Автор учебника — Шахматов Алексей