AI-агенты в логистике: как маршруты строят без диспетчера

Классическая задача построения маршрутов — VRP, vehicle routing problem — десятилетиями решалась математическими солверами: Google OR-Tools, jsprit, коммерческие движки вроде Routific. Вы описываете ограничения (окна доставки, вместимость машины, время работы водителя), солвер выдаёт оптимальный порядок точек. В 2024–2025 годах в отрасли появился второй слой: поверх этих солверов ставят LLM-агента, который принимает решения на естественном языке, сам дёргает нужные API и переигрывает план, когда реальность ломает расчёт. Это не замена оптимизатору, а надстройка над ним — и именно в этом суть перемены.

Ниже — как такая связка работает на практике, чем она отличается от чистого солвера и от чистого чат-бота, и в каких случаях агент реально экономит деньги, а в каких добавляет расходов на токены без пользы.

Что именно поменялось

Раньше диспетчер утром запускал расчёт, получал маршрутные листы и до конца дня жил с ними. Если в 11:00 клиент перенёс окно доставки, а на трассе встала фура — диспетчер вручную звонил водителям и перекраивал план в голове или в Excel.

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

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

Из чего собирается связка

Типовая архитектура, которую сейчас собирают команды в логистике, выглядит так:

• Оркестратор-агент на базе LLM (GPT-4-класса или Claude-класса модели) — принимает события и решает, какой инструмент вызвать.
• Инструмент-солвер — OR-Tools или коммерческий движок, считает собственно оптимальный маршрут по жёстким ограничениям.
• Инструменты-источники: карты и пробки, погода, API склада и остатков, статусы водителей, окна клиентов из CRM.
• Слой памяти: история решений и предпочтений клиентов, чтобы агент не переспрашивал одно и то же.

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

Агент против чистого солвера против ручного диспетчера

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

Кому это пригодится и кому нет

Пригодится

• Курьерская доставка по городу с плотным потоком изменений: клиенты переносят окна, курьеры выпадают, точки закрываются. Здесь ценность именно в динамическом перепланировании.
• Компании со сложными «мягкими» правилами: «этому клиенту не звонить после 18:00», «на эту точку не ставить нового водителя». Такие условия трудно загнать в жёсткие ограничения солвера, но легко описать текстом для агента.
• Диспетчерские с высокой нагрузкой на людей: агент снимает поток однотипных решений и оставляет человеку сложные случаи.

Не пригодится

• Стабильные регулярные маршруты: развоз по одним и тем же 20 точкам каждый день. Пересчитать один раз солвером и ездить — агент тут лишняя прослойка и лишние расходы.
• Малый парк — две-три машины: диспетчер справляется в уме дешевле, чем стоит интеграция и токены.
• Жёсткая регуляторика, где нужна детерминированность: если решение должно быть воспроизводимым и проверяемым до цифры, вероятностная LLM в контуре принятия решения — риск.

Где грабли

Главная опасность — доверить агенту то, что должен считать солвер. Если попросить LLM самостоятельно выстроить порядок из 40 точек, она выдаст маршрут, который выглядит разумно, но проигрывает оптимальному по километражу на десятки процентов. Проверять такой результат глазом невозможно.

Второе — стоимость и латентность. Агентный цикл с несколькими вызовами инструментов занимает секунды и стоит денег; для события «водитель опоздал на 5 минут» это оправдано не всегда.

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

¹ Агент с доступом к инструментам (tool use / function calling) — языковая модель, которой разрешено не просто отвечать текстом, а вызывать внешние функции и API: посчитать маршрут, запросить погоду, обновить запись в базе. Модель сама решает, какой инструмент и с какими параметрами вызвать, а результат вызова возвращается ей в контекст для следующего шага.