Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Вместо полной инструкции LLM-агенту стали выдавать рабочий процесс по одному шагу и фиксировать результат каждого действия. В нерецензированном препринте Amazon Web Services и University of the Bundeswehr Munich, где числа получили сами авторы, нижняя граница соблюдения процесса выросла с 76 до 95%. Такой подход делает поведение агента предсказуемее, но переносит ответственность за логику процесса с модели на внешний управляющий слой.
Сервер решает, какой шаг агент увидит следующим
Обычная схема помещает стандартную рабочую процедуру (SOP) целиком в системную инструкцию. Модель сама разбирает текст, выбирает следующий шаг, вызывает инструменты и решает, когда закончить. Даже правильный итог не доказывает, что агент выполнил обязательные проверки.
Авторы вынесли управление последовательностью на сервер через Model Context Protocol (MCP). Инструмент run_sop отдаёт агенту одну инструкцию. Модель выполняет её, возвращает структурированный step_output и только после этого получает следующий шаг.
Содержание процедуры в двух вариантах эксперимента совпадало. Менялся только способ доставки: полный текст в системной инструкции либо последовательная выдача сервером. Поэтому разницу связывают не с более подробной процедурой, а с тем, кто управляет переходами между шагами.
Агент сохраняет свободу внутри текущего действия: он выбирает параметры вызова, интерпретирует ответ инструмента и формирует результат шага. Но он не может переставлять будущие действия, заранее сопоставлять разные ветви или компенсировать ошибку, заметив противоречие дальше по процедуре.
У этого ограничения есть практический результат. Путь выполнения задан до запуска, а записи step_output образуют машиночитаемый журнал. По нему можно увидеть, на каком шаге агент отклонился, какой инструмент вызвал и какой вывод передал дальше, вместо того чтобы восстанавливать ход работы по финальному ответу.
Правильный ответ перестал скрывать пропущенную процедуру
Исследование проверило подход на 15 475 запусках в 13 областях SOP-Bench. В эксперимент вошли четыре открытые модели разного уровня: Ministral 3 8B, DeepSeek V3.2, GLM 5 и Kimi K2.5. Инструменты были имитациями с заранее подготовленными ответами, поэтому работа не охватывает сбои реальных API, задержки и изменение схем данных.
Главный эффект проявился не в обычной точности ответа, а в соблюдении процедуры. Нижняя граница доли запусков с выполнением нужных инструментов поднялась с 76 до 95%. Правильные ответы без подтверждённого прохождения процесса стали занимать не более 0,3% запусков.
Для самой лёгкой модели пошаговая схема прибавила 6,5 процентного пункта к обоснованной точности — доле правильных ответов, за которыми стоит выполнение процедуры. Модели не пришлось каждый раз восстанавливать порядок действий из длинного текста. У более способных моделей обычная точность, напротив, немного снизилась: они потеряли возможность заглядывать вперёд и самостоятельно исправлять ход работы.
Соблюдение процесса считали по названиям вызванных инструментов: запуск проходил порог, если агент использовал хотя бы половину ожидаемого набора. Метрика не проверяла порядок вызовов, параметры и использование полученных данных. Для анализа соблюдения процедуры взяли 12 областей: одну задачу с широким ветвлением исключили, потому что для неё этот порог давал ненадёжный результат.
Пошаговая схема особенно уязвима там, где решение требует сравнить несколько будущих ветвей. Она также последовательно исполняет плохую инструкцию: модель не видит процедуру целиком и хуже замечает её дефекты. Журнал шагов помогает найти такую ошибку после запуска, но не предотвращает её сам.
Планы стоит менять там, где важен доказуемый порядок действий
Работа не показывает, что любой агент нужно заменить жёстким конвейером. Она разделяет два класса систем. Для поиска, анализа и открытых задач полезна автономия: модель может перестроить план после новых данных. Для проверок клиентов, обработки обращений, классификации грузов и других регламентированных операций важнее заранее знать допустимый путь и доказать, что он действительно выполнен.
В таких продуктах процедуру стоит рассматривать как отдельный исполняемый компонент, а модель — как обработчик текущего шага. Управляющий слой выдаёт инструкции, принимает структурированный результат и хранит журнал. Тогда модель можно заменить без изменения самого процесса, а ошибку локализовать до конкретного перехода или вызова инструмента.
Перед таким переходом придётся точнее описать ветвления, входы, выходы и обработку пустых ответов. Пошаговая доставка не исправляет неоднозначную процедуру, а делает её дефекты повторяемыми. Команда меняет непредсказуемость агента на более понятный риск: качество системы теперь сильнее зависит от качества формализованного процесса.
Для прототипа, где важен только итог, эта архитектура добавит управляющий сервер и больше обменов с моделью без доказанной пользы. Для процесса, который проверяют аудиторы или владельцы операций, журнал шагов становится частью результата наравне с финальным решением.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
