Об этом проекте

Production Orchestrator — инструмент планирования производства на основе агентов, ориентированный на небольшие вышивальные цеха и цеха по декорированию одежды. Подан как кандидат на хакатон «Agents for Humans» в треке профессиональных агентов; локально протестирован против Amazon Bedrock и развёрнут в Bedrock AgentCore Runtime. Создан на базе Strands Agents framework и предназначен для инспекции состояния цеха, выявления препятствий, предложения расписания с доказательной базой, вывода ключевых решений на утверждение человеку и применения только того плана, который человек проверил. Проблема Малые производственные цеха одновременно координируют сроки, утверждения клиентов, наличие материалов, совместимость оборудования, мощность операторов и коммуникацию с клиентами. Один срочный заказ может потребовать серии связанных решений, и цена упущенного — переделка, просрочка или необратимая эскалация с клиентом. Цель проекта — инспектировать реальное состояние цеха, детерминированно обнаруживать препятствия, создавать версионированное предложение, черновик соответствующих коммуникаций, останавливаться перед записью и сохранять полную аудит-цепочку. Сборка агента В модуле workflow один агент координирует приём, чтение состояния цеха, детерминированный анализ, создание предложения, черновик коммуникаций и этап с gated применением. Экспонируется восемь инструментов: intake_customer_request, list_active_orders, get_inventory, get_machine_capacity, analyze_shop_blockers, propose_schedule, draft_communications, apply_production_plan. Хук BeforeToolCallEvent — ProductionPlanApprovalHook — перехватывает apply_production_plan до выполнения и вызывает approval interrupt, чтобы рецензент принял или отклонил предложение с привязкой по точному хэшу. FileSessionManager сохраняет сессию Strands и ожидание, позволяя воркеру завершиться между предложением и решением; новый процесс восстанавливает сессию и отправляет официальный ответ на interrupt. README подчёркивает разделённость ответственности: модель выбирает и выстраивает последовательность инструментов, а детерминированный код проверяет все извлечённые факты о цехе, вычисляет препятствия и объёмы, привязывает утверждение к каноническому содержанию предложения и обеспечивает write gate. Намерение — сохранить полезность agent reasoning, не требуя от модели самостоятельно контролировать свои права. Локальный демо для жюри После uv sync --locked команда запуска демонстрации открывает локальный интерфейс на 127.0.0.1:8765, который прогоняет полный восьмитульный workflow и останавливается перед реальным Strands interrupt. Страница отображает activity feed записанных вызовов инструментов, доску производства до/после, читаемые черновики сообщений и точные последствия решения. Выбор «Keep current schedule» или «Approve coordinated plan» вызывает новый процесс, который восстанавливает сохранённую сессию и продолжает официальный interrupt. Доступны три синтетических сценария: срочный заказ с конфликтом мощности и нехваткой ниток; заказ командных футболок, вытесняющий две мелкие задачи; партия металлических монограмм при дефиците материалов. Раздел Technical proof показывает неизменяемый хэш предложения, факты о модели и провайдере, различные start и resume process IDs и аудит-цепочку. Демо управляется детерминированной локальной tool-calling моделью, поэтому не требует платных вызовов моделей; при этом каждый факт о цехе всё равно получается через реальный вызов инструмента. Привязка только к localhost, транзитивный SQLite и состояние сессии хранятся в игнорируемом demo-runtime пути, коммуникации готовятся как неотправленные черновики, производство аутентификация, мульти-тенантность и внешние интеграции отсутствуют. Пути у провайдеров и доказательства n Полные восемь путей отклонения и подтверждения были проведены через Amazon Bedrock с моделью amazon.nova-lite-v1:0 в us-east-1, отчёты зафиксированы в директории evidence. По данным README, отклонение сохранило revision 1 без plan-applied события, а точное подтверждение атомарно перевело расписание и задачу закупок в revision 2, и единственный применённый хэш совпал с пересмотренным на interrupt предложением. Неизменяемые предложения сохраняются в SQLite по каноническому хэшу содержания. Запуски отторжения и подтверждения с нового процесса описаны как доказательство того, что новый интерпретатор Python способен восстановить того же агента и сессию, восстановить pending interrupt и отправить официальный ответ. Тот же workflow развёрнут в Amazon Bedrock AgentCore Runtime как production_orchestrator-3S24euH1Cz. Пары live start и decide над эндпоинтом воспроизводят оба исхода в разных внутриконтейнерных процессах: отторжение не применяет планов, подтверждение — ровно один раз применяет пересмотренный хэш. Существует локальный путь модели для демонстрации независимости governance layer от провайдера: interrupt, привязка хэша, checkpoint verification и fail-closed resume — один и тот же код для каждого провайдера. README сообщает, что этот путь был прогнан с gemma4:e4b полностью на одном NVIDIA RTX 3060 через Ollama, с вызовом всех восьми инструментов в требуемой последовательности и восстановлением сохранённого interrupt в новом процессе. Эти прогоны прямо помечены как development evidence, а два latency наблюдения описываются как две точки данных, а не контролируемый benchmark; решения и длины ответов различаются, а latency провайдера исключает время выполнения инструментов и задержку оператора. Ollama host считается частью trusted provider configuration чекпоинта, поэтому восстановление против другого host fail-closes так же, как замена AWS профиля. Разработка и инструментарий Прerequisites: Python 3.11+, uv, локальная модель с поддержкой tools для fallback воспроизведения и именованный least-privilege AWS профиль с явным region и Bedrock model access для judged пути. Начальная настройка: uv sync, pytest, ruff check. Отдельные CLI entry points запускают полный intake workflow и более узкий two-phase restart proof (start, затем resume с решением). README рекомендует использовать неиспользуемую runtime директорию на каждое решение, указывает, что runtime базы и session файлы игнорируются, а в git не должны попадать учётные данные AWS, клиентская информация и состояние runtime. Документация и управление Описанные документы включают architecture document с диаграммами системы и cross-process approval плюс таблицу маппинга каждой гарантии на тест или зафиксированное evidence; shot-by-shot video script; AgentCore deployment runbook, описывающий deployed Runtime contract, process-boundary model и limits; development contract, определяющий границы реализации и конкурса. README содержит disclosure contest-period и prior-work: команда ранее изучала приложение управления вышивальным цехом под Apache-2.0 и использовала этот опыт только как domain research; исходный код, промпты, UI, ассеты, схема, клиентские данные, fixtures или реализация не были включены. Весь представленный product code, инструменты, поведение агента, интерфейс, синтетические данные, тесты, документация и материалы демо созданы в период подачи. Статус Репозиторий сам описывается как submission candidate. Локальное демо исключает production аутентификацию, мульти-тенантность и внешние интеграции; черновик коммуникаций остаётся неотправленным. Результаты локальной модели представлены исключительно как development evidence, а прогоны Bedrock — как judged-provider evidence.