Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Рабочая программа для повторяющейся GUI-задачи начинает экономить токены лишь после нескольких последующих запусков, причём неудачные попытки её собрать могут стоить дороже успешных. В нерецензированном препринте, где все числа получили сами авторы, команда City University of Hong Kong описала PACE: у успешно скомпилированных программ окупаемость составила от 2 до 16 повторных использований. Для продукта это превращает автоматическую компиляцию из обязательного этапа в решение, которое стоит принимать по истории запросов и накопленному бюджету.
Почему дешёвый запуск ещё не означает экономию
Компиляцией здесь называют превращение завершённых трасс GUI-агента в параметризованную программу. При следующем похожем запросе модель один раз извлекает из задания значения полей, после чего программа выполняет знакомую последовательность действий без новых обращений к модели.
Такой запуск расходует мало токенов, но сначала нужно оплатить генерацию кода, проверку и исправления. Попытка может закончиться без пригодной программы, а при изменении интерфейса уже созданный сценарий перестанет работать. Поэтому стоимость одного программного запуска сама по себе ничего не говорит об окупаемости.
PACE разделяет эти расходы. Система записывает стоимость успешных и неудачных попыток компиляции, а затем сравнивает агента и программу на одинаковых входных данных. Расход считают во взвешенных токенах: кешированные входные и выходные токены приводят к стоимости обычного входного токена с учётом относительных цен.
Окупаемость равна стоимости компиляции, разделённой на экономию при одном повторном запуске. Диапазон от 2 до 16 использований относится только к успешным попыткам и не включает получение исходных трасс, предыдущие неудачи и будущую замену программы после изменения GUI. Это нижняя оценка для полного потока задач, а не универсальный порог для запуска компиляции.
Цена неудачи может менять решение сильнее, чем стоимость рабочей программы. В полных записях DeepSeek медианная неудачная попытка стоила в 6,57 раза дороже успешной при сравнении разных семейств задач. Такое межсемейное сравнение не доказывает, что ошибка сама вызывает перерасход, но показывает, почему нельзя считать только удачные сборки.
Как PACE принимает решение по уже пришедшим задачам
После каждого запроса PACE оценивает, сколько похожих задач ещё может прийти и какова вероятность получить рабочую программу. Ожидаемая стоимость компиляции включает будущие неудачные попытки, а ожидаемая экономия уменьшается из-за сбоев программы и возможного изменения интерфейса.
Система сначала обслуживает текущую задачу и только затем решает, компилировать ли процедуру для следующих запусков. Это исключает экономию задним числом: только уже обработанные запросы дают системе наблюдения и бюджет.
Одной оценки будущего недостаточно. PACE отдельно проверяет, укладывается ли возможная стоимость действия в накопленный лимит. Предполагаемые будущие задачи могут обосновать компиляцию, но не пополняют бюджет, пока действительно не придут.
В основной настройке допустимый перерасход составляет 25% относительно варианта, где все задания выполняет обычный агент. При заданных в работе границах стоимости PACE сохраняет этот предел после каждого входящего задания, даже если прогноз повторного использования ошибся или несколько попыток компиляции подряд провалились.
Это математическая гарантия для принятой модели расходов, а не гарантия успешного выполнения задачи. Она требует заранее ограничить цену каждого действия, обнаруживать сбои программы и бесплатно убирать её из списка доступных сценариев. Если инфраструктура не умеет надёжно фиксировать ошибки и возврат к агенту, переносить предел перерасхода в продукт напрямую нельзя.
Командам нужен учёт расходов, а не новый обязательный слой
В симуляциях на записанных последовательностях запросов PACE сократил расход токенов на 17,3–24,9% относительно ReAct и адаптированных правил принятия решений из AutoRPA и ToolPro. Результат показывает пользу отложенной компиляции, но не подтверждает, что тот же диапазон сохранится на другом интерфейсе или потоке задач.
Проверка охватила семь семейств задач из AndroidWorld, LibreOffice в контейнере OSWorld и приложения Reddit из WebArena. Использовались три модели: GLM 5.3 Flash, DeepSeek Flash и Qwen 3.8 Flash. Созданные программы запускали на 30 свежих заданиях, а политику выбора проверяли главным образом в симуляциях с измеренными профилями расходов и записанными последовательностями запросов.
Работа не требует менять архитектуру продукта ради PACE как отдельного компонента. Практический вывод — собирать четыре показателя для каждого повторяющегося процесса: стоимость агента, стоимость программного запуска с извлечением параметров, расходы успешной и неудачной компиляции, а также цену возврата к агенту после сбоя.
Компилировать сразу имеет смысл только для устойчивых и часто повторяющихся процедур. При редких запросах, нестабильном GUI или дорогих исправлениях безопаснее ждать, пока история запусков покроет возможную неудачу. Порог из статьи нельзя переносить как константу: его нужно пересчитать по собственным моделям, интерфейсам и механизму проверки результата.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
