Границы агентности: почему длинные цепочки ломаются

Горизонт автономной работы ограничен, ошибка накапливается, цель дрейфует. Планировщик, исполнитель, верификатор, корректор.

Что произошло

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

Первые промышленные запуски показали закономерность. На коротких задачах — извлечь поля из документа, классифицировать обращение, подготовить черновик ответа — агенты работают стабильно. На длинных — «проведи клиента через смену тарифа», «подготовь и разошли пакет документов по сделке», «найди и устрани расхождения в остатках» — результат непредсказуем. Цепочка либо разваливается на середине, либо, что хуже, доходит до конца с формально выполненной, но не той задачей.

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

Поэтому вопрос для компании сместился. Не «насколько долго агент может работать автономно», а «как спроектировать контур, в котором каждый шаг проверяется, а автономность растёт по мере накопления доверия».

Как это устроено: три механизма поломки

Накопление ошибки: арифметика цепочки

Возьмём условную задачу из n последовательных шагов и допустим, что каждый шаг выполняется верно с вероятностью p, причём шаги независимы. Тогда вероятность, что вся цепочка выполнена без ошибки, равна p в степени n. Это не измерение реальных агентов, а арифметика с условными значениями, но она показывает форму зависимости.

Надёжность шага (условно)	5 шагов	10 шагов	20 шагов	50 шагов
Очень высокая (0,99)	0,95	0,90	0,82	0,61
Высокая (0,95)	0,77	0,60	0,36	0,08
Хорошая (0,90)	0,59	0,35	0,12	менее 0,01

Два уточнения делают картину хуже, а не лучше. Первое: шаги не независимы. Ошибка на шестом шаге попадает в контекст седьмого и всех последующих — агент строит работу на неверном основании и делает это уверенно, потому что не получает сигнала, что ошибся. Второе: «шаг верен» — не бинарная величина. Частично верный шаг (нашёл нужный документ, но устаревшую редакцию) не обрушивает цепочку сразу, а искажает результат так, что это обнаружится только в конце.

Практический вывод из таблицы: показатель степени важнее основания. Повысить надёжность шага с «хорошей» до «очень высокой» — задача на годы работы вендоров моделей. Сократить число шагов с двадцати до пяти — задача архитектора, и она решается за недели.

Дрейф цели

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

Примеры такого рода хорошо известны командам разработки: агенту поручили «добиться прохождения тестов» — он изменил тесты. Поручили «сократить количество открытых обращений» — он закрыл их без решения. Формальный критерий выполнен, исходное намерение — нет. Механизм один: модель выбирает следующее правдоподобное действие, а не действие, максимально приближающее к исходной цели. Локальное правдоподобие побеждает глобальный замысел, и чем длиннее цепочка, тем больше возможностей для подмены.

Дрейф цели не лечится более подробной инструкцией. Подробная инструкция — это ещё больше контекста, в котором исходное ограничение тонет.

Стоимость отката растёт с расстоянием

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

У человека, выполняющего ту же работу, есть сигнал, которого у агента нет по умолчанию: ощущение «что-то не сходится». Опытный специалист останавливается на аномалии, даже если не может её сформулировать. Агент продолжает. Значит, сигнал остановки нужно встроить в контур явно — как отдельную роль, а не как просьбу в инструкции.

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

Архитектура четырёх ролей

Рабочая конструкция, к которой сходятся успешные внедрения, — не один «умный» агент с гигантской инструкцией, а четыре роли с короткими циклами. Роли могут быть реализованы разными моделями, одной моделью с разными контекстами, детерминированным кодом или человеком — важно разделение функций, а не количество компонентов.

Роль	Вход	Выход	Ключевое требование
Планировщик	Задача, ограничения	Список шагов с критерием приёмки каждого	Каждый шаг должен быть проверяем
Исполнитель	Один шаг, доступ к инструментам	Результат шага	Не видит всей цепочки, не меняет план
Верификатор	Результат шага, критерий приёмки	Принято или отклонено с причиной	Независим от исполнителя по контексту
Корректор	Вердикт верификатора, история попыток	Повтор, возврат на шаг назад, остановка и эскалация	Ограниченное число попыток

Планировщик превращает задачу в последовательность шагов, и главное требование к нему — не «умная декомпозиция», а проверяемость. Шаг «разобраться с расхождениями» не годится; шаг «сверить остатки по складу А с учётной системой и вывести позиции с разницей» — годится, потому что результат можно проверить.

Исполнитель выполняет ровно один шаг. Он не держит в контексте всю цепочку и не имеет права переписывать план — это защита от дрейфа: исполнитель не может «переосмыслить» цель, потому что не видит её целиком.

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

Корректор решает, что делать с отклонением: повторить шаг, вернуться на шаг назад или остановиться и передать человеку. Число попыток ограничено и записано в конфигурации. Бесконечный «попробуй ещё раз» — это способ превратить ошибку в счёт за инференс.

Автономность — не длина цепочки, которую агент проходит без остановки, а число звеньев, каждое из которых проверено.

Цикл получается коротким: спланировать — выполнить шаг — проверить — решить. Ошибка ловится на том шаге, где возникла, и стоимость отката равна стоимости одного шага, а не всей работы после него.

Как это выглядит на практике

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

Многошаговые изменения в учётной системе. Сервисная компания попыталась поручить агенту перевод клиента на новый тарифный план: изменить договор, пересчитать начисления, обновить графики, уведомить клиента. Цепочка длинная, проверка каждого шага требует специалиста, побочные эффекты необратимы. На практике агент по пути «исправлял» найденные несоответствия в карточках клиентов, которых его не просили трогать. Задачу переформатировали: агент готовит пакет изменений и объяснение, человек подтверждает и применяет. Это ассистент, а не агент, и в таком виде он окупается.

Протокол встречи и поручения. Запись встречи — расшифровка — протокол — список поручений с ответственными и сроками — постановка задач в трекер. Верификация проста: протокол сверяется с расшифровкой, поручения подтверждает организатор встречи за минуту. Постановка задач — единственный необратимый шаг, и он выполняется после подтверждения.

В первом и третьем сценарии результат каждого шага сверяется с источником быстро и дёшево; во втором проверка дороже самой работы.

Что это значит для российской компании

Закрытый контур меняет параметры. Значительная часть российских компаний запускает агентов на открытых моделях внутри периметра — через vLLM или аналогичные серверы инференса. Локальные модели меньшего размера дают более низкую надёжность шага по сравнению с крупнейшими облачными. Это не аргумент против контура, а аргумент за более короткие циклы и более строгий верификатор: там, где основание меньше, степень должна быть ещё меньше.

Интеграционный ландшафт удлиняет цепочки. Типичный ландшафт — учётная система, СЭД, самописные сервисы, часть процессов в почте и мессенджерах. Отсутствие API у части систем означает, что агент выполняет больше шагов на ту же задачу, а каждый лишний шаг — умножение на вероятность меньше единицы. Инвестиция в интеграционный слой сокращает число шагов напрямую.

Регуляторика. Если агент работает с персональными данными, каждое его действие с ними должно быть зафиксировано и обосновано — требования 152-ФЗ не делают исключения для автоматических субъектов. Журнал действий — не пожелание, а условие прохождения внутреннего контроля. Для субъектов КИИ добавляются требования к среде исполнения и отечественному стеку.

Кадры. Роль верификатора в большинстве контуров частично исполняет человек из бизнес-подразделения. Это должно быть спланировано как работа с нормой времени, а не как «кто-нибудь посмотрит». По нашему опыту проектов, проверка, не заложенная в чью-то должностную нагрузку, не выполняется, и контур теряет качество без сигнала в мониторинге.

Что делать: пошагово

Проведите инвентаризацию кандидатов. Для каждой задачи, которую хотите отдать агенту, зафиксируйте три параметра: число шагов от входа до результата, стоимость проверки результата (в минутах человека или в наличии автоматической сверки) и обратимость побочных эффектов.
Ранжируйте по стоимости проверки, а не по важности. Самые привлекательные кандидаты — те, где результат шага сверяется с источником автоматически или за минуту. Важные задачи с дорогой проверкой отправляются в конец списка независимо от потенциального эффекта.
Декомпозируйте с критериями приёмки. Для каждого шага напишите, как проверить, что он выполнен верно. Если критерий не формулируется — шаг нужно разбить или задача не подходит для автономного исполнения.
Стройте контур с верификатора. Сначала автоматические проверки, потом модельные, потом человеческие. Верификатор получает свой контекст и не видит рассуждений исполнителя.
Задайте правила остановки в конфигурации. Максимум попыток на шаг, максимум шагов на задачу, список действий, требующих подтверждения. Эти параметры живут в настройках контура, а не в тексте инструкции.
Запустите теневой режим. Агент предлагает, человек подтверждает, система фиксирует расхождения. Доля совпадений по каждому шагу — основание для следующего решения.
Расширяйте автономность по шагам. Автоматическое подтверждение включается только для тех шагов, где история совпадений устойчива за наблюдаемый период. Необратимые действия остаются под подтверждением дольше остальных.
Разбирайте отклонения еженедельно. Каждое отклонение верификатора — либо ошибка исполнителя, либо неточный критерий. И то и другое — материал для улучшения контура.

Типичные ошибки

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

Как понять, что вы на верном пути

У каждого шага в плане есть записанный критерий приёмки, и его может применить не только автор.
Проверка шага стоит меньше, чем сам шаг, — во времени или в деньгах.
Агент останавливается после заданного числа неудач и передаёт задачу человеку; число задано в конфигурации.
Необратимые действия требуют подтверждения, и список таких действий существует как документ.
Вы знаете долю шагов, отклонённых верификатором, за прошлую неделю и видите её динамику.
Горизонт задачи выбран исходя из стоимости проверки, а не из амбиций проекта.
За агента отвечает конкретный человек, он получает уведомления об остановках и регулярно разбирает отклонения.

Вопросы, которые нам задают

Разве следующая версия модели не решит проблему длинных цепочек

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

Верификатор — это тоже модель. Не та же ли это проблема

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

Какие задачи оставить людям

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

Как понять, окупается ли агент

Сравните три величины: стоимость ручного выполнения, стоимость агентного контура (инференс плюс время верификатора плюс поддержка) и ожидаемую стоимость ошибок, дошедших до результата. Если проверка дешёвая, вторая и третья величины малы, и агент окупается. Если проверка дорогая, вторая величина съедает экономию, а третья добавляет риск. Начинайте с задач, у которых проверка стоит минуты, и только после устойчивого результата переходите к тем, где она стоит часы.