Автоматизация логистики с ИИ: как устроен Shipment Exception Commander

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

Shipment Exception Commander — эталонное приложение с открытым исходным кодом на базе Claude Managed Agents для принятия решений в таких ситуациях. Оно анализирует одно синтетическое исключение, по формальным правилам оценивает все варианты восстановления, поручает независимому проверяющему оценить риски и оспорить рекомендацию, показывает оператору точное действие и только после штатного подтверждения человеком разрешает одно идемпотентное изменение в песочнице.

Автоматизация логистики начинается с детерминированной оценки

Координатор не выдумывает тарифы и не принимает текстовое описание за политику. Серверный инструмент shipment_intelligence, работающий только на чтение, предоставляет три синтетических сценария и рассчитывает оценки вариантов по фиксированной формуле: 50 баллов за соблюдение обещанного срока, 20 за покрытие запасами, 20 за экономическую эффективность относительно абсолютного лимита и 10 за уверенность. У каждого варианта указаны версия и срок действия предложения, расчётное время прибытия, число защищённых единиц товара и дополнительные затраты в USD.

В главном демонстрационном сценарии SCX-2026-071 сравнивались три реалистичных варианта решения: недорогая доставка морем, которая не укладывалась в обещанный срок; полная авиаперевозка, превышавшая абсолютный лимит расходов; и ускоренная авиадоставка с разделением партии, защищавшая все 240 подтверждённых единиц за $4,200. Последний вариант набрал 91 балл и остался в пределах операторского лимита $5,000. Благодаря оценке рекомендацию можно воспроизвести; задача Claude — собрать доказательства, оспорить допущения и объяснить компромисс.

Недоверенные данные не могут разрешать операцию

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

У координатора также нет доступной для записи межсессионной памяти, хранилища секретов, интеграции MCP или исходящего сетевого доступа. Узкими автоматически разрешёнными исключениями служат read, glob и grep. Bash и запись итоговых файлов работают в режиме always_ask, а редактирование, веб-запросы и веб-поиск отключены. Единственное каноническое изменение состояния выполняется командой execute адаптера.

Проверяющий оспаривает рекомендацию

До любого запроса на выполнение координатор Opus передаёт предложенный вариант восстановления узкопрофильному проверяющему Haiku. В демонстрационном запуске он вернул NEEDS_CHANGES: ему не удалось установить, сохраняло ли силу предложение Q-071-v4 и были ли окончательными данные о доступной ёмкости и доплатах. Координатор не проигнорировал замечание, а вызвал детерминированный валидатор предложения. Тот повторно проверил синтетические часы, срок действия предложения, версию политики, уровень согласования расходов и ожидаемую версию состояния. Только достоверный результат ready_for_human_approval изменил итоговый статус на готовый.

Затем в карточке согласования были раскрыты идентификаторы сценария и варианта, точная сумма $4,200, прежнее и новое расчётное время прибытия, влияние на обещанный клиенту срок, 240 защищённых единиц, срок действия предложения, версии политики и состояния, оценка, история проверки, отклонённые альтернативы, стабильный ключ идемпотентности, ожидаемые поля квитанции и поведение при отказе или сбое.

Отказ означает отсутствие изменений

Первую штатную карточку согласования намеренно отклонили. Ни одна команда, меняющая состояние, не запускалась: оно осталось detected с версией 3, квитанция не появилась, а ключ идемпотентности не был использован. Агент не стал переключаться на другие инструменты, менять команду или создавать новый ключ.

По явному запросу оператора то же каноническое действие показали повторно. На этот раз его разрешили. На границе изменения адаптер ещё раз проверил версию состояния 3, актуальность предложения, политику, уровень согласования и абсолютный лимит $10,000. Операция выполнилась ровно один раз: сценарий перешёл из состояния detected версии 3 в resolved версии 4, а система вернула квитанцию rcpt_37105a2da411aee0391c с номером бронирования SBX-56DFC3291972.

Безопасный повтор и честно обозначенные границы

Синтетический адаптер отвечает за стабильный ключ SCX-2026-071:OPT-071-B:v3, блокировку на уровне ОС, проверку канонического состояния и реестр квитанций. Повторные вызовы с тем же намерением возвращают уже существующую квитанцию; конфликтующее намерение с тем же ключом приводит к ошибке; при устаревшей версии, параллельном выполнении или возможной частичной записи необходимо сначала проверить состояние, а не слепо повторять запрос.

Границы этих гарантий описаны без преувеличений: блокировка, состояние и реестр квитанций хранятся в локальных файлах одной сессии песочницы Managed Agents. Распределённой гарантии для промышленной эксплуатации они не дают. Настоящему адаптеру перевозчика или TMS понадобились бы общее транзакционное хранилище и поддержка идемпотентности на стороне следующей системы.

Оценщик результата проверил доказательства

В ходе сессии в каталоге /mnt/session/outputs/ появились три артефакта: понятный человеку пакет восстановления, структурированная аудиторская запись и исходная квитанция о выполнении. Механизм оценки результата Managed Agents независимо сопоставил эти файлы с каталогом, исходным кодом адаптера, каноническим состоянием, историей согласований и реестром квитанций. До выдачи результата satisfied он потребовал доработать сведения о сроке действия предложения, явно описать поведение при сбоях, добавить манифест итоговых файлов и указать ограничение локальной сессией.

После этого пакет восстановления скачали через файловый прокси приложения. Его SHA-256: 30c8ad1d0d13cf7ad4b7070e67370ea270562c5e4ef44dfa503e3124180bd40b. Сессия возможностей — sesn_01CcQjCVoWvNQ7VJLFbuDJxh, результат — outc_01GoD4rsLMh93iQNfAUw63KW.

Рабочий запуск оценки выявил и пробел в интерфейсе: дочерние потоки оценщика могут запрашивать согласование, пока родительская сессия простаивает. Теперь релиз восстанавливает ожидающие карточки согласования как из родительских событий requires_action, так и из событий дочерних потоков evaluated_permission: ask, убирает их после подтверждения или получения результата и не позволяет повторному воспроизведению воскрешать уже закрытые запросы. Кроме того, система передаёт session_thread_id оценщика через узкий список разрешённых браузерных параметров и, прежде чем перенаправить решение, сверяет маршрут с тем самым событием инструмента, от которого поступил запрос.

Исправленный путь проверили в отдельной настроенной сессии Sonnet sesn_01BvSf33BLBbN86w5oDb3BkQ. Перенаправленное событие инструмента оценщика sevt_013VnmofY8ytk6QwgDtNSYoq содержало поток sthr_018HMgpidoN86Qp4iGLZt1q3; интерфейс сформировал подтверждение sevt_016ZFv5TdBPKNyEPThzGT36Q с теми же идентификаторами инструмента и потока, сервер принял его, после чего оценщик продолжил работу и запросил следующую проверку. Узкую проверочную сессию затем намеренно прервали, чтобы не платить за лишние итерации; основной результат по доставке сохранил статус satisfied.

Opus в основной роли, Sonnet для проверок, Haiku как независимый контролёр

Предварительно настроенным координатором остаётся claude-opus-5. Чтобы снизить стоимость повторяемых платных проверок, в локальных сессиях можно явно заменить только модель координатора на claude-sonnet-5; любые другие переопределения отклоняются по принципу fail-closed. Независимый проверяющий работает на claude-haiku-4-5. В оплаченной smoke-сессии sesn_01RTs3wLV41odV9p92eWtrHV использовался Sonnet, вернувший точный ответ SMOKE OK.

Промышленный набор тестов намеренно изолирован от учётных данных, даже если у разработчика настроен файл .env.local. Тесты доказывают, что в свежем развёртывании нет браузерного поля для ключа, трафик к Anthropic отсутствует, система сообщает configured: false, а маршруты биллинга отвечают кодом 503.

Публичный эталон с безопасным отказом

В публичном эталонном развёртывании на Vercel нет ни ключа Anthropic, ни идентификаторов ресурсов Managed Agents. Посадочная страница и /api/agent/health остаются доступными, но создание сессии отклоняется по принципу fail-closed. Пользователи развёртывают агента и окружение в собственной учётной записи Anthropic; любой настроенный экземпляр необходимо закрыть контролем доступа, прежде чем предоставлять его другим.

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

Материалы релиза

• Репозиторий: dvnc-labs/shipment-exception-commander
• Релиз: v0.1.0
• CI: успешный релизный запуск
• Коммит: 1db0329
• Развёртывание: shipment-exception-commander.vercel.app
• Состояние: проверка агента с безопасным отказом

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