Автономные изменения инженерных данных: release gate, diff и конфигурационное управление

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

Автономные изменения инженерных данных: release gate, diff и конфигурационное управление — это production-задача, а не демонстрационный prompt. Практический принцип: разрешать агенту готовить изменение, но выпускать новую revision только через формальный release gate. Ключевое решение: автоматическая правка файла и выпуск утверждённой конфигурации — разные операции с разной ответственностью. В инженерной среде результат принимается по 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 и защитные меры

• агент перезаписывает baseline. Защитная мера: immutable baseline; событие сохраняется как regression/incident case.
• неполный diff скрывает связанные изменения. Защитная мера: полный diff; событие сохраняется как regression/incident case.
• release без теста. Защитная мера: verification before release; событие сохраняется как regression/incident case.
• неясно кто утвердил. Защитная мера: named approver; событие сохраняется как regression/incident case.
• rollback возвращает только часть конфигурации. Защитная мера: release transaction; событие сохраняется как 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