Агент-инженер по репозиторию · Модуль 4 · Урок 4.3
План и декомпозиция задачи перед записью
Зачем (какую проблему чиним)
Агент, который бросается править код по первому импульсу, делает разрозненные изменения, ломает несвязанное и теряет нить. Инженеры сначала планируют: разбивают задачу на шаги, намечают, какие файлы тронуть. Тот же приём резко повышает надёжность агента и делает его действия предсказуемыми и ревьюабельными.
Решение и альтернативы
Решение: перед записью агент формирует план — упорядоченный список шагов с целевыми файлами и критерием готовности (какие тесты должны позеленеть). План — это структура в состоянии задачи, по которой агент идёт и которую отмечает. Это включает фазу «понять» (retrieval из версии v2) до фазы «менять».
Альтернативы: без плана, чистый ReAct — работает на мелочи, плывёт на многошаговых задачах; жёсткий план без права пересмотра — ломается о реальность (тест вскрыл другое). Берём plan-and-execute с возможностью ревизии плана по ходу.
DIFF
Добавляем структуру Plan/PlanStep в состояние задачи и системную инструкцию: сначала план, потом правки; план можно ревизовать.
⚠ Безопасность
План — это и точка контроля: на версии v4 он попадёт в описание MR (что и зачем). Явный план облегчает человеку оценку намерения агента до одобрения изменений. Декомпозиция держит каждый шаг маленьким — маленькие шаги легче откатывать (урок 4.4).
Проверка
На задаче «добавить валидацию и тест к функции X» агент сначала выдаёт план из 2–3 шагов с файлами и критерием готовности, затем исполняет их по очереди; в логе видно соответствие правок шагам плана.
Глубже
Паттерны рассуждения (ReAct, plan-and-execute, рефлексия) как осознанный выбор — курс «Продакшн-разработка», Модуль 3 (гл. 5–6).
+package main
+
+// PlanStep — один шаг плана с целевыми файлами и критерием готовности.
+type PlanStep struct {
+ Goal string // что сделать
+ Files []string // какие файлы предполагается тронуть
+ Done bool
+}
+
+// Plan — упорядоченные шаги; агент идёт по ним и может ревизовать при новой
+// информации (например, тест вскрыл другую причину).
+type Plan struct {
+ Steps []PlanStep
+ DoneWhen string // критерий готовности: какие проверки должны пройти
+}Anti-patterns
| Грабля | Почему плохо | Как правильно |
|---|---|---|
| Править код без плана, по первому импульсу | Разрозненные правки, поломка несвязанного, потеря нити на многошаговой задаче | Сначала план (шаги, файлы, критерий готовности), потом правки |
| Жёсткий план без права пересмотра | Реальность (упавший тест, иная причина) ломает план, агент упирается | Plan-and-execute с ревизией плана по новой информации |
Практическое задание (RA-v3)
- Ввести
Plan/PlanStepв состояние задачи; системно требовать план до правок. - Разрешить ревизию плана при новой информации (упавший тест и т.п.).
- Закоммитить:
git commit -m "v3: plan-and-execute decomposition".
Проверка знаний
Зачем агенту-инженеру строить явный план до внесения правок?
Верный ответ: B
B. План структурирует многошаговую работу, удерживает шаги маленькими и обратимыми и делает намерение агента явным — это пригодится в описании MR и человеческом ревью. План не заменяет тесты (C).