Узнайте, как отличить граничные ограничения от рабочих в ИИ-агентах. Практические советы по настройке воркфлоу для Python-разработчиков.
Недавно я наблюдал, как кодинг-агент отказался начинать одобренную реализацию. В плане работ было написано approved, но агент запросил одобрение снова, потому что ожидал поле Implementation Approval.Status. Суть не изменилась, но ярлык был не тот. Агент следовал воркфлоу, который я создал для проведения изменений через требования, дизайн, ревью, планирование и реализацию. Я месяцами добавлял поля статусов, контракты передачи, контрольные точки, правила повторов и эскалации. Каждое дополнение решало реальную проблему, но вместе они сделали воркфлоу настолько хрупким, что он останавливался на заголовке.
Я строил систему вокруг старого вопроса: как не дать модели потерять путь? Модель теперь могла следовать пути, но мой путь стал проблемой.
Инцидент с одобрением выявил различие, которое я упускал.
Граничное ограничение уменьшает пространство решений:
Рабочее ограничение создаёт обязательства:
Оба типа выглядят как защита, но ведут себя по-разному, когда модель способна их выполнять. Граничные ограничения говорят агенту, где можно действовать. Рабочие ограничения читаются как запрошенная работа. Надёжный агент будет надёжно создавать лишние артефакты, тесты, абстракции и условия остановки, которые они подразумевают.
Это дало мне принцип, который я теперь использую при изменении воркфлоу агентов: будь строг к границам и доказательствам, но гибок к пути между ними.
Сдвиг в возможностях реален, хотя публичные измерения часто отстают от используемых моделей. Горизонт времени выполнения задач METR показывает сильный исторический рост сложности задач, которые агенты могут выполнить. METR также предупреждает, что бенчмарк покрывает хорошо определённые задачи, возможности остаются неравномерными, а новые релизы могут оставаться неизмеренными неделями или пропускаться. По состоянию на 2 августа публичная страница всё ещё была датирована 8 мая, а список недавно неизмеренных моделей не догнал последние релизы.
Реальное использование также сместилось к более длительному выполнению. Анализ примерно 400 000 сессий кодинг-агентов выявил разделение труда: люди принимали большинство решений по планированию, а агенты — большинство решений по выполнению. Авторы описывают это как «люди решают, что строить, а агент решает, как строить».
Ни один из этих источников не доказывает, как сегодняшние модели ведут себя в моём воркфлоу. Семейства моделей, участвовавшие в описанных сбоях, вышли после измерений и бенчмарков, которые я нашёл. Я не нашёл публичного повторного прогона на этих релизах.
Это особенно важно для FixedBench. В мае 2026 года исследователи протестировали пять тогдашних кодинг-моделей на 200 задачах, где код уже был исправлен. Агенты всё равно вносили нежелательные изменения в 35–65% случаев. Это полезное доказательство того, что в том поколении существовал перекос к действию. Но это не текущий уровень отказов.
Более интересный результат — что произошло, когда исследователи изменили инструкцию. Приказ агентам сначала проверять и считать воздержание успехом сократил правки уже корректного кода. На частично исправленном коде та же инструкция заставила их воздерживаться, когда требовалась дополнительная работа. Промпт-инжиниринг обменял перекос к действию на пассивность.
Это ровно та ловушка, которую я создал в своём воркфлоу. Модель однажды ошиблась, и я закодировал противоположное поведение как универсальное правило. Когда модель или задача менялись, компенсация оставалась.
Самое сильное доказательство здесь — история сбоев этого воркфлоу на текущих моделях, которые я использую. Исследования объясняют, почему эти сбои правдоподобны и почему простые исправления промптов деградируют. Они не заменяют наблюдение за самой системой.
Строгое поле одобрения было лишь самым заметным сбоем.
В другом прогоне воркфлоу остановился перед реализацией, потому что не мог найти внешние бухгалтерские доказательства, документы об одобрении, точную команду релиза и подробные предположения об окружении E2E. Репозиторий, локальные сервисы и тестовые инструменты были доступны. Большая часть реализации могла бы продолжиться. Воркфлоу превратил полезный контекст планирования в обязательные шлюзы готовности, а затем обработал каждый отсутствующий шлюз как решение пользователя.
Документы тоже разрослись. Требования к продукту и дизайн-доки начали собирать одобрения стейкхолдеров, доступ к живым сервисам, процедуры релиза, дашборды и операционные доказательства. План работ по изменению экспорта данных включал настройку аккаунта и проблемы продакшена, хотя запрошенный результат заканчивался реализацией.
Ревью усугубило расширение. Во время того же планирования ревьюер запросил детерминированное доказательство на 20 000 строк. Планировщик принял замечание, не спросив, какое решение изменит это доказательство или достаточно ли более дешёвой проверки границы. Ревьюер затем обнаружил, что предложенные данные противоречат существующему контракту агрегации, что вызвало новую ревизию. Каждый шаг был технически защитим. Сам цикл не имел экономического суждения.
Я сделал ревьюера авторитетным, а автора послушным. «Ревью до одобрения» превратилось в «добавляй работу, пока у ревьюера не кончатся идеи».
Это не сходимость. Это храповик.
Я не решил проблему удалением всех правил. Я изменил, где воркфлоу строг.
Запрос пользователя больше не принимается как автоматически валидный объём реализации. Перед дизайном воркфлоу записывает:
Оценка стоимости остаётся грубой, потому что это работа по требованиям, а не детальная оценка. Её задача — сделать плохой трейдофф видимым, пока объём ещё дёшево сократить.
«Без изменений» и «используй существующее» — валидные выводы, но ни один не является по умолчанию. Агент должен изучить достаточно доказательств, чтобы решить, удовлетворён ли результат, частично удовлетворён или требует реализации. Это избегает превращения перекоса к действию FixedBench в его зеркальное отражение.
Это также меняет то, что пользователям нужно сообщать. Полезный запрос содержит границу текущего результата, а не только список желаемых функций. «Расширь существующий путь аутентификации без изменения контракта публичного ответа» ценнее, чем длинный список правил реализации. Он указывает и результат, и точку, где дизайн нужно пересмотреть.
Старый воркфлоу описывал полные маршруты: запусти одного агента, заполни все поля, запусти другого, остановись на любом отсутствующем вводе, повторяй, пока не появится сериализованное состояние.
Теперь я стараюсь давать каждой фазе четыре вещи:
«Запусти все тестовые прогоны» предсказывает маршрут. «Используй самый узкий тест, который наблюдает требуемую границу» даёт критерий решения. Точные схемы по-прежнему важны там, где программное обеспечение парсит ответ. Человекочитаемый план работ не должен падать, потому что два заголовка выражают одно и то же одобренное состояние. Я изменил проверку одобрения, чтобы она принимала семантически эквивалентные доказательства вместо требования одного заголовка.
Главный агент также владеет лёгким разрешением конфликтов. Он может интерпретировать семантически эквивалентные состояния, разрешать локальную неоднозначность репозитория, повторять с новыми доказательствами и продолжать незатронутую работу. Эскалация пользователю зарезервирована для решений, принадлежащих пользователю: изменённый результат продукта, новое требование, крупное одобренное изменение дизайна, недоступные полномочия или необратимое внешнее действие.
Получатель ревью теперь имеет три варианта:
Отклонение включает доказательства и возвращается ревьюеру. Ревьюер может сохранить замечание, если доказательства всё ещё оставляют результат некорректным или непроверяемым. Повторение того же предпочтения без новых доказательств не блокирует воркфлоу.
Полезный процесс ревью сохраняет базовый инженерный навык: решать не реализовывать технически разумное предложение.
Удаление правил может быть столь же небрежным, как и добавление. Я доказал это во время переписывания.
Планировщик генерировал скелеты интеграционных и сквозных тестов, чтобы первый вертикальный срез мог доказать критерий приёмки через реальную границу как можно раньше.
После упрощения передачи планировщик стал рассматривать сгенерированный скелет теста как несвязанный файл и запланировал новый сквозной тест позже в проекте. Артефакт всё ещё существовал, поэтому воркфлоу выглядел полным. Но причина его существования исчезла.
Я восстановил цель скелета в планировщике: потреблять точный сгенерированный файл в самой ранней задаче, которая может сделать его границу исполняемой. Общая инфраструктура может идти первой только тогда, когда ни один критерий приёмки не может работать без неё, и только инфраструктура, необходимая для этого первого среза, должна там быть.
Это граничное ограничение, которое стоит сохранить. Оно связывает запланированную реализацию с наблюдаемым доказательством и предотвращает откладывание интеграционного риска до тех пор, пока не будут построены все компоненты. Его удаление сделало воркфлоу меньше и менее надёжным.
Несколько контролей всё ещё оправдывают свою стоимость:
Для опасных операций песочницы, ограниченные учётные данные, изолированные файловые системы и сетевые контроли сильнее длинных инструкций в промпте. Они ограничивают радиус взрыва, даже когда суждение несовершенно. Повторные запросы одобрения — более слабая замена: один отчёт о реализации описывает высокие показатели одобрения и снижающееся внимание и отвечает использованием автоматизированного суждения для сокращения рутинных запросов.
То же разделение применяется ко всему воркфлоу. Обеспечивай прочную границу механически, где возможно. Позволь модели выбирать среди обратимых действий внутри неё. Описание среды, ориентированной на агентов, использует похожий принцип: относись к инструкциям верхнего уровня как к оглавлению, а не как к энциклопедии.
Я использую четыре вопроса при пересмотре существующего правила:
Начни с аудита вашего текущего воркфлоу для ИИ-агентов. Пройдись по каждому правилу и спроси: это граница или работа? Удали правила, которые создают артефакты без влияния на решение. Замени предписанные маршруты критериями решений. Добавь механизм отклонения замечаний ревью. И всегда проверяй, что раннее вертикальное доказательство остаётся в плане.
Сделай это сегодня, и ваш агент перестанет останавливаться на ярлыках и начнёт приносить пользу.
Хочешь закрепить знания на практике?
Решай задачи на Algolit — интерактивная платформа для обучения
Начать бесплатно →