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

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

Возьмём учебный станок со сменой 08:00–16:00. Перерывы и другие участки в этом расчёте не учитываем. На оснастке X заказ А занимает 180 минут, Б ещё 120. Срочный заказ В требует оснастки Y, занимает 90 минут и должен закончить эту операцию к 14:00. А уже начали, прерывать его нельзя.

Работы всего 390 минут при доступных 480. Но переход с X на Y занимает 45 минут, обратно 30. Если оставить очередь А, Б, В, срочный заказ закончится в 15:15. Если после А поставить В, а затем Б, операция В закончится в 13:15. Для этого придётся вернуться на X, и весь график станет длиннее.

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

Одной средней нормы переналадки на заказ мало. После одинаковой оснастки переход может не понадобиться, после другой потребуются подготовка и проверка. В таблице исходных данных нужна длительность конкретного перехода и состояние станка в начале расчёта. Документация PyJobShop показывает именно такую зависимость времени от соседних операций.

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

Базовая модель производственного расписания в документации Google OR-Tools запрещает пересечение работ на одной машине и сохраняет порядок операций. В своём модуле этот принцип нужно распространить на действительно общие ресурсы. Если программа видит только станки, она сможет нарисовать график, в котором один наладчик занят в разных местах в одно время.

Неизвестную длительность нельзя молча заменить догадкой модели. Модуль должен показать, какие данные отсутствуют, и остановить расчёт затронутой части графика либо явно пометить согласованное допущение. Иначе точные часы на экране скроют неточную норму в основании.

Формулировка «оптимизация производства» не задаёт, какие решения разрешены. В файле правил нужно записать: начатые операции сохраняем; недоступные ресурсы исключаем; очередь подтверждённого участка меняем только с разрешения; при невыполнимом сроке показываем конфликт. Такой документ и есть основа постановки задачи агенту.

Здесь важно разделить разработку и ежедневный расчёт. Агент пишет и исправляет программу. Сама программа получает структурированные данные и рассчитывает варианты по заданным ограничениям. Производственный график не должен зависеть от того, как чат в этот раз пересказал список заказов. Правила для ИИ-агента описывают также доступ к данным и условия приёмки кода.

Первую версию можно строить на согласованной выгрузке из действующей системы. Тогда проще проверить, что одинаково поняты номера операций, единицы времени, статусы и календарь. Для разработки подходят обезличенные примеры. Передачу рабочих данных и права подключения к MES согласуют отдельно; полный доступ агенту не является условием пересчёта.

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

В демонстрации легко показать красивую очередь, где все заказы помещаются. Принимать модуль нужно на ситуациях, из-за которых его заказывают: срочная работа, сломанный станок, занятый наладчик и отсутствующая норма. Для каждой ситуации диспетчер заранее описывает допустимый результат.

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

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

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

Наш опыт здесь относится к разработке. На карте нашей машины видны код, документация и правила, по которым инженер ведёт агентов. Этот опыт объясняет, как вести доработку, но не доказывает снижение простоя станков. Производственный эффект придётся измерить на вашем участке.

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

В курсе агентной разработки есть урок «Файл правил целиком». Для планировщика его практический смысл такой: правило «переналадка зависит от пары операций» должно попасть и в описание, и в расчёт, и в проверку. Исправление только подписи на экране не устранит пропущенный переход.

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

Начните с участка, где конфликт уже можно показать на заказах и календаре. На первом этапе модуль получает копию данных и считает рядом с действующим графиком. Диспетчер сравнивает варианты; автоматическая запись в рабочую систему пока не нужна. Это позволяет отделить ошибку расчёта от ошибки интеграции.

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

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

На странице разработки по подписке тариф «Один проект» стоит 250 000 ₽ в месяц, проверено 8 октября 2026. Это поток разработки, а не обещание готового планировщика за эту сумму или за месяц. Для обсуждения первой задачи подготовьте пример сорванной очереди, выгрузку и список запретов. С ними можно обсудить задачу планировщика.

1. Задайте цель пересчёта: срок нужной операции, допустимые сдвиги и цену дополнительной переналадки.

2. Запишите переходы оснастки, общие ресурсы, календарь и уже начатые работы; неизвестные нормы пометьте отдельно.

3. Принимайте модуль на конфликтах и невыполнимых сроках, проверяйте последствия для всей затронутой очереди.

4. Начните рядом с действующим графиком; диспетчер утверждает вариант перед передачей в рабочую систему.

5. Возвращайте фактические задержки и ручные изменения в правила и проверки следующей версии.