Самое опасное место в агентном workflow - проверка успеха

Pactum вырос из той же линии работы. ⠀ Это рабочий repo, где мы проверяем практическую часть прежней рамки: цель -> contract -> execution -> gate -> review. ⠀ Там проверяется не “может ли агент написать код”, а более скучная вещь: кто заранее фиксирует критерий, по которому этот код будет считаться рабочим. ⠀ Если эту проверку пишет тот же агент, который должен пройти gate, у него появляется слишком простой обход: не решить задачу, а сделать проверку слабее. ⠀ В Pactum это вынесли в отдельное правило для plan-DAG: ⠀ 1. validation живет в approved contract; ⠀ 2. executor может запускать ее, но не должен менять; ⠀ 3. проверка должна цепляться за expected files; ⠀ 4. где возможно, она должна падать на pre-change tree. ⠀ Например: task чинит CSV export для пустых optional fields. \go test ./…\ может быть зеленым еще до изменения. Узкий regression test по export, который сначала падает на старом дереве, уже проверяет сам риск задачи. ⠀ Вот здесь связь с основной рамкой становится прямой: business goal -> contract -> bounded execution -> verification -> decision. Pactum проверяет один тяжелый участок этой линии до того, как считать его product truth. ⠀ Pactum пока не sandbox и не готовая платформа. Но как execution-lab он хорошо показывает, где агентный workflow ломается еще до review: в слабой, поздней или изменяемой проверке. ⠀ Ограничение такое: frozen validation не заменяет человека и не делает запуск безопасным. Она только закрывает один неприятный обход - возможность переписать критерий успеха по дороге. ⠀ В терминах Goalrail это тот же маршрут, просто здесь проверяется execution-lab слой рядом с core рамкой. ⠀ Хороший финал такой задачи - не зеленая строка в отчете, а проверка, которую executor не мог переписать по дороге.

Самое опасное место в агентном workflow - проверка успеха | Сетка — социальная сеть от hh.ru