Процесс и обратная связь
Эта глава описывает процесс совместной работы человека с coding/knowledge agent: discovery, решения, исполнение, review и handoff. Это не control loop production runtime; его состояния, budgets и terminal reasons разобраны в agent loop and state и durable execution.
Надёжная operator work строится как последовательность проверяемых переходов состояния. Код или документ часто создаётся быстро; основное время уходит на обнаружение реального состояния, снятие неоднозначности и доказательство правильности результата.
Базовый процесс
explore → decide → plan → execute → verify → review → handoff
Это не обязательные церемонии и не waterfall. У каждого этапа отдельный вопрос:
| Этап | Главный вопрос | Артефакт |
|---|---|---|
| Explore | Что происходит на самом деле? | Карта, baseline, evidence |
| Decide | Какой подход и trade-off выбираем? | Decision record |
| Plan | В каком порядке безопасно менять состояние? | Проверяемые шаги |
| Execute | Какое минимальное изменение приближает outcome? | Изменённый артефакт |
| Verify | Что механически подтверждено? | Результаты checks/evals |
| Review | Решена ли правильная проблема правильным способом? | Findings и corrections |
| Handoff | Что должен знать следующий исполнитель? | Сжатое текущее состояние |
1. Explore: сначала факты
Discovery нужен, когда среда неизвестна или сообщение пользователя описывает симптом, а не причину.
Хороший explore:
- читает локальные инструкции и источник истины;
- воспроизводит текущий результат;
- находит затронутые компоненты и их потребителей;
- отделяет факт от гипотезы;
- не меняет состояние раньше, чем это разрешено задачей.
Для бага дисциплина выглядит так:
reproduce → localize → hypothesize → falsify → fix
Правка до воспроизведения часто лечит правдоподобную историю, а не реальную причину.
2. Decide: вернуть человеку значимый выбор
Не каждый выбор требует диалога. Агент может самостоятельно выбрать имя локальной переменной в рамках соглашений. Но решение нужно согласовать, если варианты отличаются:
- пользовательским поведением;
- публичным API или форматом данных;
- стоимостью и vendor dependency;
- объёмом миграции;
- обратимостью;
- уровнем риска или полномочий.
Хорошее предложение содержит 2–3 реальных варианта: что получаем, чем платим и когда вариант плох. Слабый вариант не нужно добавлять только ради количества.
3. Plan: порядок — часть решения
План полезен, если изменение затрагивает несколько артефактов или требует совместимости. Он должен отвечать:
- что изменяется и где;
- от какого шага это зависит;
- какая проверка выполняется сразу после;
- как сохранить старое поведение;
- что делать, если гипотеза оказалась неверной.
План не высечен в камне. Новое evidence может потребовать ревизии, но менять согласованный подход скрытно нельзя: это уже новое решение.
4. Execute: маленькие проверяемые переходы
Вместо большого изменения и проверки в конце:
- Зафиксировать старое поведение тестом или baseline.
- Создать один ожидаемо failing check.
- Внести минимальное изменение.
- Получить green.
- Упростить структуру, не меняя поведения.
- Перейти к следующему контракту.
Это TDD-модель RED → GREEN → REFACTOR. Для конфигурации и чистой документации отдельный unit test часто не нужен, но наблюдаемое поведение всё равно должно быть защищено build/smoke/visual checks.
5. Verify: несколько разных петель
Одна проверка не отвечает на все вопросы.
Механическая
Компилируется ли, проходят ли тесты, существуют ли routes, валиден ли формат? Она быстрая и воспроизводимая.
Поведенческая
Получает ли пользователь ожидаемый результат в реальном сценарии? Здесь полезны integration, browser и eval cases.
Семантическая
Сохранился ли intent? Не оптимизировали ли метрику ценой смысла? Не добавили ли ненужную связанность?
Операционная
Что происходит после публикации: latency, ошибки, стоимость, неожиданные действия, возможность отката?
Исследования и практические руководства по agent evals подчёркивают, что многошаговые системы требуют комбинации оценок и анализа траекторий, а не одной итоговой метрики: Demystifying evals for AI agents.
6. Review: проверка не только исполнения
Self-review задаёт вопросы, которые tests обычно не задают:
- решён ли исходный outcome;
- сохранены ли non-goals и инварианты;
- не подменён ли контракт более удобной задачей;
- нет ли хрупкого workaround;
- синхронны ли код, конфигурация и документация;
- можно ли объяснить решение без чтения всего diff.
Для рискованного плана полезна независимая критика до реализации. Автор плана склонен защищать собственные предположения.
7. Handoff: передать состояние
Хороший handoff отвечает:
- какой outcome и что уже считается решённым;
- какие решения приняты и почему;
- какие файлы или внешние объекты изменились;
- какие проверки реально запускались;
- какие риски остались;
- какой следующий шаг безопасен.
Фраза «почти готово, осталось немного» бесполезна без конкретного состояния.
Как масштабировать процесс
| Размер задачи | Что можно объединить | Что нельзя терять |
|---|---|---|
| Локальная обратимая правка | explore + decide; plan в 2–3 пункта | воспроизведение и проверка |
| Новая feature в одном сервисе | короткий brainstorm, план группами | контракт, TDD, review |
| Cross-cutting изменение | отдельные решения и deployment order | compatibility, consumers, rollback |
| Внешняя операция | исполнение может быть коротким | authority, preview, confirmation/evidence |
Процесс должен быть пропорционален не числу строк, а неопределённости и цене ошибки.
Progress report и evidence
Статус:
Я обновил зависимости, всё работает.
Evidence:
- Docusaurus: 3.8.1 → 3.10.2
- clean install: exit 0
- typecheck: exit 0
- production build: 86 routes
- legacy route diff: 78/78 сохранены
- audit: 53 → 24, remaining upstream-only
Status помогает следить за процессом. Evidence позволяет проверить утверждение.
Feedback без микроменеджмента
Полезный checkpoint возникает после завершённого логического перехода:
- discovery нашёл неожиданную архитектуру;
- выбран подход;
- контракт стал green;
- обнаружен новый риск;
- требуется расширить authority;
- внешнее состояние изменилось.
Не нужно требовать сообщения после каждого чтения файла. Нужно требовать видимости там, где изменился план, риск или доказательство.
Два примера
Малый: исправить ссылку
- Воспроизвести generated
href. - Добавить smoke assertion, который падает на relative URL.
- Исправить root-relative link.
- Build + assertion.
- Проверить страницу браузером.
Большой: изменить API между клиентом и сервером
- Найти всех producers/consumers и deployment constraints.
- Сначала определить новый контракт и compatibility window.
- Проверить план независимым review.
- Выпустить backward-compatible server.
- Мигрировать clients с contract tests.
- Наблюдать usage старой версии.
- Удалить compatibility layer отдельным изменением.
Одинаковый цикл масштабируется, но checkpoints и доказательства различаются.
Типичные сбои
- Endless planning — план не уменьшает неопределённость и никогда не переходит в проверяемое действие.
- Implementation drift — агент обнаружил новое, но молча реализовал другой подход.
- Verification theater — перечислены проверки, которые фактически не запускались.
- Green but wrong — tests проходят, но проверяют не исходный outcome.
- No stop — повторяется одна гипотеза без нового evidence.
- Conversation as storage — решения существуют только в длинной истории сообщений.
Checklist процесса
- Discovery завершился картой и evidence, а не впечатлением.
- Значимые trade-offs решены явно.
- План содержит проверку после каждого логического блока.
- Поведение меняется через failing check там, где это применимо.
- Механическая и семантическая проверки различены.
- Progress reports содержат evidence.
- Новый риск или scope change возвращает работу к decision gate.
- Handoff позволяет продолжить без чтения всей переписки.