Оптимизацию маршрута дописывают агентами под окна доставки, вместимость и ручные исключения

Нужен ли свой построитель маршрутов? На 8 октября 2026 года Яндекс Маршрутизация уже поддерживает временные окна и вместимость, а Poncy Go заявляет окна для каждой точки.

Но в примере из документации Яндекса закреплённые за машиной заказы дают перегруз. Маршрут построен, а статус задачи сообщает UNFEASIBLE: ограничения не выполнены.

Поэтому сначала загрузите свои заказы в готовый сервис. Разработку заказывают под оставшийся разрыв: особое правило отдела, обмен с учётной системой или проверку перед выпуском машины.

Если настройки уже покрывают ваши правила, начните с внедрения сервиса. Свой модуль имеет смысл заказывать, когда можете показать конкретный план, который отдел не разрешит выполнить.

Можно ли начать с таблицы адресов? Для развоза нужны ещё окна приёмки, груз и время обслуживания. Без них расчёт может выглядеть убедительно и расходиться с работой склада.

ИИ в логистике превращает заявку из почты в черновик полей, который диспетчер сверяет перед записью в учёт.

Пустой вес нельзя автоматически считать нулевым. Нулевой вес может быть настоящим значением; отсутствие сведений должно возвращаться в очередь уточнения с номером заказа.

Инженер ведёт машину агентов: агенты пишут загрузку и проверку полей, диспетчер подтверждает их смысл. Для разработки заранее задают границы доступа к данным клиентов.

На выходе загрузки нужен список принятых заказов и список отклонённых с причинами. Потерянная строка не должна превращаться в незаметное сокращение плана.

Достаточно ли написать «соблюдать окна»? В документации Яндекса жёсткое окно исключает нарушающий его заказ из обычного планирования; мягкое допускает нарушение со штрафом в расчёте.

Такой штраф помогает алгоритму сравнивать варианты. Он сам по себе не означает денежное взыскание с вашей компании и не превращает обязательное ограничение в пожелание.

Покупатель формулирует наблюдаемый результат: какой вход принять, какое нарушение показать. Такая постановка задачи агенту превращает правило отдела в код и проверку.

Если сервис уже умеет выразить правило, модуль передаёт нужную настройку. Если не умеет, инженер отдельно определяет, как искать допустимый план и что делать, когда проверка его отвергнет.

Что меняется, когда диспетчер закрепляет заказ за водителем? В документированном режиме Яндекса такие заказы нельзя исключить даже при нарушении вместимости или жёстких окон.

Возвращаемся к примеру с перегрузом. Диспетчер должен увидеть статус задачи и нарушенное ограничение; нарисованная линия маршрута ещё не основание выпускать машину.

После переноса заказа, смены автомобиля или обновления окна прежнее утверждение снимают. Вопрос ответственности за ошибки закрывают назначенным утверждающим и записью версии плана.

Проверка должна учитывать порядок погрузок и выгрузок: сумма всех заказов за день не равна одновременной загрузке. Утверждают конкретную версию плана после разбора отклонённых заказов.

Почему мы предлагаем такую разработку? На vibecoding.ru инженер ведёт машину агентов, которая пишет код и проверки; публичная карта проекта показывает устройство этой работы.

Наши поломки полезны здесь как примеры проверки данных. Поле терялось при записи, а оборванный ответ источника превращался в ноль: обе ошибки потребовали правил против повторения.

Это опыт разработки сайта. Клиентского кейса оптимизации доставки у нашей машины пока нет, поэтому мы не обещаем сокращение пробега или экономию рабочего времени диспетчера.

В курсе по агентной разработке есть урок «Одиннадцать шагов одной задачи». Он показывает предмет обучения; пригодность модуля для вашего развоза проверяют на ваших входах и ограничениях.

С чего начинается покупка? Возьмите обезличенную выгрузку и спорные планы, которые диспетчер правил вручную. По ним видно, чего не хватает готовому сервису и что должно остаться решением человека.

В разработке по подписке тариф «Один проект» стоит 250 000 ₽ в месяц: один продукт, один поток работы. Цена сверена 8 октября 2026 года; картографический сервис оценивается отдельно.

В таком проекте инженер ведёт машину агентов: пишет модуль ограничений и проверки плана, а диспетчер утверждает маршрут. Код уходит в вашу ветку вашего репозитория, как указано на странице услуги.

Для первого разговора подготовьте выгрузку, список правил и пример ручной правки. С ними можно обсудить задачу разработки и определить границу модуля до начала работы.

Как понять, что модуль окупается? Сначала сравните планы на одинаковых заказах, машинах и окнах. Сокращение пути за счёт исчезнувших доставок нельзя считать улучшением.

Затем сверяйте план с выполнением: опоздания, фактический пробег, время диспетчера и необъяснённые исключения. Период наблюдения и правила сравнения согласуйте до запуска.

Каждое новое исключение возвращайте инженеру: причина, затронутый заказ, решение диспетчера. Новое правило попадает в код и проверку, после чего отдел снова наблюдает результат.

Можно начать с режима, в котором модуль только сравнивает планы, а отдел работает прежним способом. К выпуску машин переходят после приёмки; подходящий момент определяют по данным вашего отдела.

1. Проверьте окна и вместимость в готовом сервисе. Заказывайте разработку под показанный разрыв, который настройками не закрывается.

2. Согласуйте обязательные поля. Неизвестный вес или окно возвращайте на уточнение, сохраняя номер заказа.

3. Превратите правила отдела в проверяемые условия. В приёмку включите планы с перегрузом, опозданием и ручным закреплением.

4. После правки перепроверяйте план. Диспетчер утверждает его актуальную версию вместе с решениями по отклонённым заказам.

5. Сверяйте расчёт с выполненными рейсами. Исключения возвращайте в разработку вместе с причиной и новой проверкой.