PCS — замкнутый цикл управления продуктом

Когда AI-агент получает доступ к рабочему продукту, проблема быстро перестаёт быть задачей промпта. Агент может прочитать логи, выбрать команду и выполнить её. Но кто проверит, что он видел актуальное состояние, не нарушил ограничение и действительно получил нужный результат?

Я описал для этого Product Control System (PCS) — методологию построения систем, в которых агент управляет изменениями продукта через замкнутый цикл. На вход приходит обращение пользователя, ошибка метрики, отказ интеграции или регламентная задача. На выходе должен остаться не только эффект, но и проверяемая запись о том, что произошло.

PCS — это не новый агент и не отдельный фреймворк. Методология не навязывает стек, платформу или структуру репозитория. Она задаёт обязанности системы и артефакты, без которых действие нельзя считать управляемым.

Почему одного агента недостаточно

Обычная схема выглядит примерно так: агент получает контекст, рассуждает, вызывает инструмент и сообщает, что всё готово. Для демонстрации этого хватает. В продуктивной среде появляются другие вопросы.

Актуален ли контекст? Агент мог прочитать старый документ. Достаточно ли данных? Пустой ответ API может означать «отклонений нет», а может — что API недоступен. Кто разрешил изменение? Подтверждение в чате не связывает человека с конкретным планом и его параметрами. Как проверить эффект? Сообщение команды «успешно» не доказывает постусловие.

PCS собирает эти вопросы в один цикл. Его логический порядок такой:

Model → Sense → Estimate → Decide → Authorize → Execute → Verify → Learn

Это не обязательно восемь микросервисов. В маленькой системе несколько обязанностей может выполнять один процесс. Важно, чтобы их можно было различить и восстановить по журналу.

Model: что система знает о продукте

Model — рабочее представление продукта, а не документация ради документации. В ней хранятся границы среды, компоненты и зависимости, цели, policy, safety invariants, известные режимы отказа и каталог допустимых действий.

Для важных утверждений нужны происхождение, время получения, срок актуальности и степень уверенности. Запись «провайдер повторяет webhook сутки» без источника — слабое основание для решения, даже если когда-то она была верной.

Model должна уметь устаревать. Если факт опровергнут, старую формулировку нельзя оставить рядом с новой и надеяться, что агент выберет правильную. PCS требует довести такое расхождение до зафиксированного исхода: исправить утверждение, сохранить историю и при необходимости создать задачу на улучшение наблюдаемости.

Sense и Estimate: факты отдельно от выводов

Sense собирает неизменённые свидетельства: метрики, логи, трассировки, проверки согласованности, события внешних систем и обращения людей. У каждого свидетельства должны быть источник, время, целевая среда, область измерения и состояние получения — success, partial или fail.

Это важная мелочь. Если сборщик логов прочитал только последние 200 тысяч строк, отчёт должен содержать partial. Нельзя выдавать неполную выборку за отсутствие событий.

Estimate отделяет исходные данные от оценки состояния. Здесь фиксируются факты, выводы, неизвестное и конкурирующие гипотезы. Воспроизведение проблемы на тестовом стенде показывает, что причина возможна, но не доказывает, что именно она вызвала случай в production.

Для серьёзных случаев оценку стоит проверять независимо. Проверяющий должен получить исходные требования и свидетельства, а не только готовый вывод агента.

Decide и Authorize: план важнее команды

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

План после авторизации должен быть неизменяемым. Если появились новые данные и план пришлось поменять, это уже другой план, которому нужна новая авторизация.

Authorize разрешает конкретное действие, а не агента вообще. Разрешение связывается с идентичностью исполнителя, хэшем плана, объектами воздействия, параметрами и сроком действия. Общий флаг вроде ALLOW_CHANGES=1 этой связи не создаёт.

Риск может менять способ авторизации. Перезапуск stateless-worker иногда можно заранее разрешить. Отправка уведомлений покупателям или изменение данных требует разрешения на конкретный набор объектов. Для критичных операций можно добавить dual control.

Execute и Verify: команда не равна результату

Execute выполняет типизированную операцию и записывает попытки и фактические эффекты. Для каждой операции заранее описываются область, обратимость, предусловия, лимит попыток, тайм-аут и правила частичного исполнения.

Verify проверяет результат независимым sensor. Отчёт самого actuator недостаточен: операция может вернуть 200, а постусловие в базе или внешнем сервисе не выполниться.

В демонстрационном примере PCS для магазина есть операция resync-payment-status. Она получает от одного до 500 идентификаторов заказов, сверяет статусы с платёжным провайдером и создаёт отгрузочные задания. После выполнения результат проверяется запросом к Postgres в режиме read-only. Повтор операции идемпотентен, число попыток ограничено тремя, а для частично обработанных заказов сохраняется список.

В том же примере проверка доставки уведомлений дала 34 из 35, а проверка склада завершилась not-checked из-за тайм-аута API. Случай нельзя было закрыть как успешный: один postcondition был нарушен, другой не проверен. Покупателя передали в поддержку, а проверку склада повторили после восстановления API.

Learn: закрытие случая меняет систему

Последняя фаза — Learn. Она не означает, что модель должна самостоятельно переписать себя после любого вывода. Нужно сохранить исход, обновить подтверждённые факты и создать задачи для обнаруженных пробелов.

В примере с магазином выяснилось, что провайдер повторяет webhook не 24 часа, как было записано в model, а три раза за 10 минут. Формулировку исправили, прежнее утверждение оставили в истории, а для нового режима отказа добавили стратегию повторной синхронизации статусов. Дополнительно появилась задача на sensor, который будет показывать время последнего обработанного webhook.

Так замыкается цикл: результат операции влияет на следующую версию model и на набор будущих проверок.

Что именно задаёт PCS

Методология фиксирует несколько границ.

Во-первых, safety invariants проверяются технически до и после действия. Подтверждение человека не должно превращаться в способ обойти ограничение, например запрет повторного списания.

Во-вторых, sensors и actuators инвентаризированы. Для каждого известны владелец, область данных и способ проверки работоспособности. Доступ к данным ограничен least privilege.

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

И наконец, сама PCS должна измерять себя: полную задержку цикла, долю успешных действий, частоту вмешательства человека и обращения к аварийному доступу. Иначе невозможно понять, стала ли система надёжнее.

Граница применимости

PCS не заменяет observability, CI/CD, IAM, поддержку или хранилище секретов. Она использует их как источники свидетельств и механизмы исполнения. Это методология для случаев, где агент может повлиять на работающий продукт и нужно доказуемо пройти путь от сигнала до проверенного результата.

Текущая версия — 2.4, статус проекта — проектирование основной методологии. В примере интернет-магазина техническое ядро цикла в основном проходит проверку, а периодические измерения, автоматическое обнаружение drift и часть аварийных процедур пока отмечены как partial. Для меня это важнее красивого статуса complete: матрица соответствия должна показывать, что ещё не сделано.

Репозиторий: github.com/IvanShishkin/pcs.