Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Оптимизационный агент научился вести одну задачу через последовательность запросов: менять данные, ограничения и цели, сохраняя ранее принятые решения. В препринте Harbin Institute of Technology, который не прошёл рецензирование и содержит собственные замеры авторов, MAPLE завершил все проверочные последовательности и сохранил высокое качество планов. Для продуктовой команды это архитектурный шаблон агента с состоянием, а не доказательство готовности системы к эксплуатации.
Исполняемая модель становится частью памяти
Обычный LLM-агент получает описание задачи, пишет модель или код для решателя и возвращает план. При следующем запросе ему приходится восстанавливать контекст из диалога: какие ограничения уже добавили, какой план приняли и что именно означают ссылки вроде «оставить прежнюю машину для этого клиента».
MAPLE хранит не только переписку. Его состояние включает входные таблицы, исполняемую программу Workbench, принятый план, журнал обновлений и набор найденных решений. Если очередная правка не проходит проверки, агент откатывается к последнему зафиксированному состоянию, а ошибочное изменение не попадает в историю.
На старте LLM пишет функции, которые читают данные, объявляют переменные решения и оценивают план. Переменные имеют заданные типы: бинарные значения, категории, целые и вещественные числа, перестановки или назначения. Тип связывает переменную с заранее написанными операциями создания, скрещивания, изменения и исправления кандидатов.
Такое разделение уменьшает поверхность кода, за которую отвечает модель. Она задаёт смысл задачи, а среда следит, чтобы перестановка не потеряла элементы, назначение использовало допустимые ресурсы, а значение осталось в заданных границах.
Способ поиска зависит от формулировки. Линейные задачи выполняет математический решатель, нелинейные и комбинаторные — генетический алгоритм, а задачи с несколькими конкурирующими целями — NSGA-II. В последнем случае результатом становится не один план, а набор компромиссов, например между расстоянием, опозданиями и выбросами.
Каждое обновление проходит через локальную правку и откат
Получив новый запрос, MAPLE сначала определяет, что изменилось. Новая цена может затронуть только таблицу, дополнительное ограничение потребует изменить функцию оценки, а появление другого типа решения — структуру пространства поиска. Остальные функции редактор оставляет без изменений.
Затем агент разрешает ссылки на прошлые решения. Если пользователь просит сохранить назначение ранее упомянутого заказа, MAPLE находит заказ в журнале, извлекает ресурс из принятого плана и превращает эту связь в обязательное условие следующего поиска. Для набора компромиссных планов система хранит весь набор, но исторические ссылки привязывает к одному сохранённому представителю.
После правки программа компилируется, проверяет интерфейсы и выполняется на небольшом примере. На исправление кода отведено до трёх попыток. Затем решатель строит планы, а среда проверяет структуру результата; только после успешной проверки новая программа, данные и история заменяют прежнее состояние.
Отдельный переключатель решает, использовать ли старые результаты поиска. В режиме Warm система переносит подходящих кандидатов в новую задачу, исправляет их и дополняет свежими. Режим Full начинает поиск заново. LLM предлагает режим и объясняет причину, но фиксированный код сверяет объяснение с реальными изменениями: например, действительно ли заменились заказы или поменялась структура переменных.
Результат поддерживает архитектуру, но пока не выбор продукта
Для проверки авторы собрали NLDO: 15 последовательностей и 180 обновлений для отбора, расписаний, смен, маршрутов и размещения облачных ресурсов. Там встречаются задачи с одной целью, набором конкурирующих целей и резкими заменами входных данных ближе к концу последовательности.
MAPLE прошёл все последовательности. Нормированное онлайн-качество для задач с одной целью составило 0,951: показатель учитывает качество плана на каждом шаге и обнуляет продолжение после первого сбоя протокола. Для нескольких целей отношение гиперобъёма достигло 0,875; эта метрика показывает, насколько найденный набор компромиссов покрывает эталонную область решений.
Основные запуски использовали DeepSeek-V4-Pro Preview. Один и тот же набор сгенерированных программ проверяли с десятью случайными запусками численного поиска, поэтому повторения измеряют устойчивость решателя, а не разброс ответов LLM. Сравнение охватывает ReAct, Persistent ReAct и несколько агентов для математической оптимизации, но сам NLDO остаётся контролируемым бенчмарком, а не журналом производственной эксплуатации.
Работа меняет планы команды, если та собиралась хранить только диалог и каждый раз заново генерировать модель. MAPLE показывает более надёжную границу компонентов: LLM локально редактирует смысл задачи, а типы, проверки, фиксацию состояния и откат реализует обычный код.
Менять выбранный решатель или LLM только из-за этих результатов рано. Практический вывод уже применим: живой агент планирования должен версионировать исполняемую задачу и принятые решения так же явно, как бизнес-система версионирует данные. Иначе ссылка на прошлый план остаётся текстом, который модель каждый раз толкует заново.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
