Клиент изменил шкаф. Что передать в цех?

Одна фраза меняет несколько документов

Представим мебельную мастерскую. В заказе М-014 согласован шкаф шириной 600 мм с двумя полками. Клиент пишет менеджеру: «Давайте 720 мм и ещё одну полку». В переписке уже новая договорённость, а у технолога может остаться прежняя спецификация.

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

Шаг 1. Зафиксировать изменение без догадок

Агент находит заказ и его последнюю согласованную версию. Из сообщения он готовит список: ширина 600 → 720 мм, количество полок 2 → 3. Рядом сохраняет ссылку на исходное сообщение. Если «шире» означает размер ниши, а не внешний размер изделия, агент формулирует уточнение для менеджера.

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

Шаг 2. Собрать последствия для заказа

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

Конкретный способ обмена выбирается после обследования: доступный API, согласованный формат выгрузки или подготовка файла для ручного импорта. Наличие агента не гарантирует, что установленная версия САПР поддерживает автоматический обмен.

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

По материалам: Anthropic — Building effective agents ↗

Шаг 3. Передать технологу версию 02

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

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

По материалам: LangChain — LangGraph overview ↗

С чего начать проверку в мастерской

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

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

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