Planner–Executor–Verifier: рабочая архитектура автономного инженерного workflow

Короткий ответ

Planner–Executor–Verifier: рабочая архитектура автономного инженерного workflow — это production-задача, а не демонстрационный prompt. Практический принцип: разделять планирование, выполнение и независимую проверку, чтобы один и тот же генеративный шаг не утверждал собственный результат. Ключевое решение: verifier должен опираться на отдельные правила, вычисления или evidence, иначе разделение ролей становится декоративным. В инженерной среде результат принимается по evidence, traceability и воспроизводимой проверке, а не по уверенности формулировки модели.

Граница системы и предмет контроля

Автономность — это свойство workflow, а не модели. Один и тот же LLM может работать как read-only помощник, как исполнитель после подтверждения или как агент, запускающий ограниченный цикл без участия человека. Уровень автономности задаётся допустимыми действиями, лимитами, средой выполнения, критериями остановки и тем, в каких точках требуется инженерное approval.

В production опаснее всего не отдельная ошибочная фраза, а неверное действие с побочным эффектом: перезапись файла, изменение записи PDM/ERP, массовая отправка, запуск неподходящего расчёта, неконтролируемая команда shell. Поэтому автономный контур обязан быть транзакционным там, где возможно, идемпотентным при повторных вызовах, наблюдаемым и способным остановиться при неизвестном состоянии.

Что должно быть определено до запуска

Артефакты и архитектурные границы

Контур автономности проектируют как конечный автомат с явными состояниями: queued, running, requires_approval, blocked, failed, completed и rolled_back. Переходы разрешает policy, а не свободный текст модели. Это особенно важно для длинных задач, где процесс переживает restart и должен продолжаться с checkpoint, не повторяя уже выполненный side effect.

Изменяющий tool должен иметь bounded scope: конкретный проект, объект, диапазон данных, число операций и срок действия полномочий. Дополнительно задаются budget по шагам/стоимости, network policy и stop conditions. При расхождении ожидаемого и фактического состояния выполнение прекращается до ручной классификации исключения.

Практический workflow

После каждого side effect состояние перечитывается и сравнивается с ожидаемым. Повторный запуск использует idempotency/checkpoint, поэтому не создаёт второй объект и не повторяет уже принятую операцию.

Инженерный сценарий

Автономность повышают ступенчато: read-only → draft → approval-gated write → bounded autonomous write. Каждый следующий уровень требует отдельного evidence о качестве и восстановлении после сбоя.

Что измерять

Чем выше автономность, тем важнее метрики side effects: rollback, duplicate action, policy violation, human rescue и незавершённые долгие задачи. Их нельзя прятать внутри общего task success.

Критерии приёмки

Failure modes и защитные меры

• planner включает запрещённое действие. Защитная мера: план без side effects; событие сохраняется как regression/incident case.
• executor импровизирует вне плана. Защитная мера: executor следует разрешённому плану; событие сохраняется как regression/incident case.
• verifier повторяет тот же LLM-вывод. Защитная мера: verifier не изменяет результат; событие сохраняется как regression/incident case.
• replan зацикливается. Защитная мера: replan после формальной ошибки; событие сохраняется как regression/incident case.
• успех шага принимается без postcondition. Защитная мера: лимит циклов; событие сохраняется как regression/incident case.

Как переводить из пилота в production

Пилот автономного workflow обязан иметь kill switch, лимит шагов, лимит стоимости, timeout, checkpoint и запрет на произвольное расширение scope. Сначала проверяется recovery path, затем happy path; иначе система умеет выполнять задачу, но не умеет безопасно останавливаться.

Расширение автономности оформляется как изменение класса допуска. Для нового уровня повторно проходят evals, security review и тест rollback. Массовые операции получают batch limit и canary batch, а не запускаются сразу на всём наборе объектов.

Traceability и эксплуатационная запись

Для автономного цикла сохраняют checkpoint ID, budget, step number, side-effect receipt, idempotency key, approvals, retries, rollback actions и reason code остановки. Без этого невозможно доказать, что повторный запуск безопасен.

Чек-лист перед production

Навигация по Wave AI R5 · часть 3 из 5