Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Повторяющиеся задачи ИИ-агента можно переводить в сценарий с фиксированным поведением и не заставлять модель заново придумывать план при каждом запуске. В препринте Pheo Inc, который не рецензирован и содержит числа, полученные самими авторами, такой сценарий всегда повторял свой результат, а исходные агенты часто расходились сами с собой. Для продукта это даёт проверяемость и экономию токенов, но переносит главный риск в механизм выбора запросов для ускоренного маршрута.
Как повтор превращается в исполняемый навык
Агент сохраняет историю выполнения задачи и ищет в ней устойчивую последовательность действий. Из неё он собирает кандидата на роль «привычки»: сценарий, который вызывает инструменты и формирует результат без нового рассуждения модели.
Кандидат не заменяет исходный агент. Он объявляет область входных данных, которую умеет обслуживать, а отдельный механизм проверяет каждый новый запрос. Знакомый случай получает сценарий, всё остальное уходит исходному агенту, который продолжает работать и остаётся готовым принять трафик после отката.
Так появляется линия исполняемых версий одного навыка. Предыдущие версии не перезаписываются, поэтому отмена новой версии сводится к смене активного указателя, а не к восстановлению модели, подсказки и инструментов из резервной копии.
Перед подключением кандидата система последовательно проверяет, работает ли путь отката, сохранил ли сценарий обязательные запреты, совпадает ли его маршрут с эталонным и не ухудшает ли он результат на реальном трафике. Последний этап начинается с теневого запуска: старая и новая версии выполняют запрос параллельно, но ответ пользователю отдаёт только действующая версия. После сравнения кандидат требует человеческого одобрения.
Маршрут проверяют по трассе выполнения. Она фиксирует вызовы инструментов, типы аргументов, срабатывания запретов, отказы и переходы к человеку, но отбрасывает свободный текст и конкретные значения. Значимые действия должны совпасть точно, а допустимое различие остальных шагов система выводит из того, насколько исходный агент расходится сам с собой при повторных запусках.
Повторяемость окупается только на частых запросах
В задаче перевода вопросов на естественном языке в SQL сценарий воспроизвёл собственный результат во всех 456 повторных запусках. Исходные агенты на тех же вопросах регулярно выдавали разные ответы, хотя условия задачи не менялись. При проверке качества сценарий оказался не хуже каждого заменённого им варианта в пределах заранее заданного допуска.
На обслуженном запросе расход токенов снизился на 14–56%. Однако сначала системе нужно добыть трассы, построить кандидата и проверить его, поэтому накопленная экономия перекрывала эти затраты после 7–53 повторных использований. Подход имеет экономический смысл для устойчивых и частых операций, но не для длинного хвоста редких запросов.
Повторяемость здесь означает не только одинаковый итоговый текст. Система может показать, какой сценарий работал, какие инструменты он вызвал и через какие проверки прошёл. Это полезнее обычной оценки ответа там, где результат приходится воспроизводить для аудита или разбирать после ошибки.
Планы меняет не сценарий, а контроль его границ
Работу проверяли на 42 повторяющихся вопросах к базе данных и на отдельной задаче выбора маршрута в каталоге поиска. Это подтверждает идею на двух типах операций, но не работу длинных линий версий в производственном масштабе.
Главная проблема возникает до запуска сценария. Механизм выбора пропустил неподходящие запросы среди 2,6% естественных перефразировок и среди 26% примеров рядом с границей заявленной области. После такого решения рассуждающая модель уже не запускается, поэтому правдоподобная ошибка может пройти незаметно и затем повторяться точно.
Проверка трассы часто не помогает: вызов нужного инструмента с неправильным значением аргумента выглядит так же, как правильный вызов, поскольку трасса хранит схему аргументов, а не их содержимое. Безопасный при прежнем составе каталога сценарий также может стать неоднозначным после добавления похожего соседа. Значит, кандидата нужно проверять заново при изменении каталога, а не только при первом подключении.
Для команд, которые уже строят агентов, работа предлагает не замену модели, а слой исполнения над ней. Начинать стоит с операций с неизменным планом, большим числом повторов и проверяемым результатом: запросов к данным, подготовки стандартных документов или вызова устойчивой цепочки внутренних сервисов.
При этом исходный агент должен оставаться рабочим, механизм выбора — уметь отказываться от ускоренного маршрута, а часть сэкономленных ресурсов придётся тратить на теневые запуски. Автоматически превращать всю историю агента в библиотеку сценариев рано: плохая привычка воспроизводится столь же надёжно, как хорошая.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
