production-orchestrator

Production Orchestrator 是一种基于代理的生产排程工具，面向小型刺绣和装饰服装店。它被提交为黑客马拉松 "Agents for Humans" 专业代理轨道的候选作品，在本地验证后针对 Amazon Bedrock 进行测试，并部署到 Bedrock AgentCore Runtime。该工具使用 Strands Agents 框架构建，旨在检查店铺状态，识别阻塞点，提出有据可依的排程，将需要后果的决策呈现给人工审批，并且仅应用人工审核的确切计划。 问题目标 小型生产店铺需要同时处理交期、客户批准、材料可用性、机器兼容性、操作员产能和客户沟通。一次紧急订单可能牵连多个相关决策，遗漏任何一项都可能导致返工、延迟交付或可避免的客户升级。项目的明确目标是：检查真实店铺状态，确定性地检测阻塞点，生成版本化的提案，起草相关沟通，在执行任何后果性写入之前停止，并保留完整的审计链。 代理的组装方式 工作流模块中的一个代理协调摄入、店铺读取、确定性分析、提案创建、沟通起草以及受控应用步骤。暴露了八个工具函数：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 执行前拦截并引发审批中断，使审查者能够接受或拒绝确切的哈希地址提案。FileSessionManager 持久化 Strands 会话和待处理中断，使工作进程在提案与决策之间可以死亡；新进程重建会话并提交正式的中断响应。 README 强调了责任的明确划分：模型负责选择和排序工具，而确定性代码验证所有提取的店铺事实，计算阻塞点和数量，将审批绑定到规范提案内容，并强制写入门限。其目标是在不要求模型自行执行权限的前提下，保持代理推理的实用性。 面向评委的本地演示 执行 uv sync --locked 后，运行演示命令会在 127.0.0.1:8765 启动一个本地界面，演示完整的八工具工作流，并在真正的 Strands 中断处停止，以免发生后果性写入。页面将记录的工具轨迹呈现为活动馈送、生产看板的前后对比、可读的消息草稿以及确切的决策后果。选择 "保持当前排程" 或 "批准协调排程" 会导致新进程重建持久化会话并恢复正式中断。 可选择的三种合成场景：具有产能冲突和线材短缺的紧急订单；替换两个较小工作的团队球衣订单；以及存在材料短缺的金属刺绣批次。"技术证明" 展开展示了不可变提案哈希、模型和提供方事实、不同的启动与恢复进程 ID，以及审计链。 演示使用确定性的本地工具调用模型驱动工作流，因此不需要付费模型调用；README 说明每项店铺事实仍然来源于真实工具调用。它仅绑定到 localhost，将临时 SQLite 和会话状态存储在被忽略的 demo-runtime 路径下，将通信准备为未发送的草稿，且不提供生产认证、多租户或外部集成。 提供方路径与证据 完整的八工具拒绝与批准路径在美国东部（us-east-1）的 Amazon Bedrock 上使用 amazon.nova-lite-v1:0 模型进行了验证，相关报告提交至 evidence 目录。根据 README，拒绝保留了修订版 1 且未出现计划应用事件；而精确批准则原子地将排程和采购任务推进到修订版 2，且唯一应用的哈希与中断处审查的提案完全匹配。 不可变提案按照规范内容哈希持久化到 SQLite。新进程的拒绝与批准运行被描述为证明：全新的 Python 解释器能够重建相同的代理和会话，恢复待处理中断，并提交正式的中断响应。错误的中断 ID、被篡改的会话、提案或提供方绑定、过期状态以及重放都被报告为失败关闭。 相同的工作流已部署到 Amazon Bedrock AgentCore Runtime，名称为 production_orchestrator-3S24euH1Cz。针对该端点的实时启动与决策对被称作能够在不同的容器内进程中复现两种结果：拒绝不应用任何计划，批准仅应用一次被审查的确切哈希。 存在一种本地模型路径，以展示治理层与提供方无关：中断、哈希绑定、检查点验证以及失败关闭恢复的代码对所有提供方均相同。README 报告该路径曾在单块 NVIDIA RTX 3060 上通过 Ollama 运行的 gemma4:e4b 模型上得到验证，调用了所有八个工具并按照要求顺序在新进程中恢复了持久化中断。这些运行被明确标记为开发证据而非评委提供方证明，并将两次延迟观察描述为两个数据点而非受控基准，指出决策和响应长度有所不同，且提供方延迟不包含工具执行和操作员延迟。Ollama 主机被视为检查点可信提供方配置的一部分，因此针对不同主机的恢复会像更换 AWS 配置文件一样失败关闭。 开发与工具 先决条件列出：Python 3.11+、uv、用于后备复现的具备工具能力的本地模型，以及具备显式区域和 Bedrock 模型访问权限的命名最小权限 AWS 配置文件。初始设置使用 uv sync、pytest 和 ruff check。独立的 CLI 入口点分别驱动完整的摄入工作流以及较窄的两阶段重启证明（启动，然后带决策恢复）。README 建议为每个决策使用未使用的运行时目录，并说明运行时数据库和会话文件被忽略，且 AWS 凭证、客户信息或运行时状态不应提交到 git。 文档与治理 引用的文档包括：包含系统与跨进程审批图表的架构文档，以及一张将每项保证与证明它的测试或提交证据对应的表格；逐镜头视频脚本；AgentCore 部署手册，描述已部署 Runtime 合约、进程边界模型及限制；以及定义实现与竞赛边界的开发契约。 README 中包含参赛期间及先前工作的披露：团队曾研究过一个 Apache-2.0 的刺绣店管理应用，仅将其用作领域研究，未纳入任何源代码、提示、UI、资源、模式、客户数据、夹具或实现。所有提交的产品代码、工具、代理行为、界面、合成数据、测试、文档和演示材料均声明是在提交期间创建的。项目采用 Apache License 2.0 许可，并附带通知及第三方通知文件。 状态警示 仓库自描述为提交候选作品。其自身的框架限制了它：本地演示省略了生产认证、多租户和外部集成，且通信起草仅停留在未发送的草稿阶段。本地模型结果仅被呈现为开发证据，而 Bedrock 运行则是评委提供方的证据。