作品参考案例

先了解这两个案例

从一个具体问题开始，看看数据、插件和万智分别怎样参与。

生产调整案例关心“急单和设备故障后怎样安排生产”；元器件案例关心“订单物料够不够，缺多少、补多少”。两个案例都把工业 API 配置为万智插件，再在智能体应用中调用；需要精确计算时，配合技能脚本或代码解释器。

两个案例分别与 B（生产管理）、C（供应链与运营管理）方向相关。案例演示的是插件接入方式，参赛作品也可以使用自己的程序调用接口，不要求照搬案例的实现方式。

如果还不清楚插件如何获取数据，先阅读工业数据资源页的接入说明；已经接通插件，可以直接按下面的任务顺序设计和验证作品。

这些数据仅供选用，不强制使用；欢迎使用自己行业领域的数据，是否使用官方工业数据资源不影响评分。

案例用于参考，不绑定应用赛或创新赛，也不要求所有队伍完成全部任务。原资料中的测试数字用于解释实现过程，不是本届评分门槛。

案例一：急单与设备故障后的生产调整

生产管理方向参考；应用赛和创新赛均可选用。

本案例展示插件接入的一种做法，不要求所有作品采用相同技术方案。也可让万智完成同一项目中的独立配套任务，不强制打通Web；提交时提供Agent公开URL并说明实际分工。

要解决什么问题

模拟 PCB（印制电路板）工厂收到一张急单，同时关键设备发生故障。智能体需要查清生产现状，评估影响，比较重排方案，并在人工确认后执行允许的操作。完整主线是“状态诊断 → 急单确认 → 故障处置与方案比较 → 委外决策 → 核对结果”。

“排产”就是安排订单在哪台设备、什么时间生产；“委外”是把生产交给外部工厂完成。案例中的“扰动最小”方案，是尽量少改动已经排好的生产计划。

四项任务是参考案例的建议顺序，不是所有作品必须完成的清单。官方工业数据仍为可选资源；用自己的行业数据也可以，是否使用官方数据不影响评分。

它是怎样搭起来的

本届模拟工厂开放13个业务接口，另有1个随机生成订单的辅助接口。历史实现曾用过更多接口和自有工具，不能当作本届已开放能力。当前公开接口不支持修改设备、登记异常、删除或回滚；相关扩展需要在自己的测试环境实现，不能直接改动官方环境。

六个技能脚本分别做什么

这些脚本的名称和作用来自原样例，下载包未包含原案例技能包。它们是实现参考，不是已经随插件提供的功能。排产数字应由能保留计算过程的代码或工具产生，大模型负责理解任务和说明取舍。

任务1：查询工厂状态并识别交期风险

1. 输入：“请汇总工厂当前状态，说明哪些订单可能逾期。”
2. 调用订单、作业、资源、异常等只查询、不修改数据的接口，必要时结合工序路线和时间约束。
3. 汇总在制订单、设备可用性、当前作业与异常，并说明交期风险依据。
4. 用后台记录核对数量、状态和引用对象，保存 API 调用与输出。

原运行截图展示了 API 返回 total=340，但 rows 中当前页只有10条资源。复现时应按任务需要继续翻页或筛选，并在结论中说明已读取的范围；故障时间字段有值也不一定代表设备当前仍故障，要结合当前状态核对。

任务2：插入急单，先评估再确认

原案例中的情景：2层、50个、48小时内交付、销售金额3000元。历史运行记录使用了具体日期2026-10-08 17:45；复现时应换成测试环境中的有效交期。

1. 先查询现状，列出急单参数和可能影响，向用户确认。
2. 获得确认后调用新增订单接口；尚未确认时不创建，也不顺带执行排产或委外。
3. 创建后重新查询订单，取得真实ID并核对后台保存的字段，说明对既有订单的影响。

任务3：设备故障处置与重排方案比较

原案例中的情景：钻孔设备1故障，预计修复4小时。先评估哪些订单、工序和作业受影响，再提出处理方案。

1. 确认设备、故障开始时间、预计修复时长，以及异常需要关联的订单。
2. 先读取当前故障记录；如需模拟“设备故障4小时”，在自建测试环境或计算输入中设置240分钟。官方接口没有修改资源状态和新增异常的能力，不能直接按历史脚本写入官方后台。
3. 比较至少两种方案，例如交期优先与扰动最小；完整历史实现还包含急单优先策略和直接把急单插到前面的对照方案。
4. 计算交期、逾期订单数和对已有生产安排的影响，解释推荐理由；只提出建议，不擅自执行重排。
5. 执行前再次确认选用方案，执行后查询作业与订单，核对结果。

任务4：对仍会逾期的订单提出委外建议

1. 指出重排后仍不能按期完成的订单，并说明为什么建议委外。
2. 汇报要修改的订单和参数，获得人工确认后设置委外标记。
3. 记录确认过程和接口返回，再查询订单核对委外标记。官方没有新增异常接口，需要异常留痕时，在自己的应用日志中记录，不宣称已写入官方异常表。

这些测试结果说明了什么

介绍自己的作品时，可以说明这些内容

• 所选任务的输入、约束、使用的 API 和计算方法。
• 万智如何理解任务、选择工具、处理结果，以及何时请用户确认。
• 操作前后记录是否一致，错误、拒绝、恢复与人工介入是否可追溯。
• 哪些功能来自已有插件或脚本，哪些由自己实现；实际完成范围与已知限制。

这四项任务演示了从查询到处理问题的完整过程。应用赛和创新赛都可以参考，也可以只选择其中一个任务开发作品，不要求全部完成。测试时请保留接口返回结果，方便核对。

案例二：销售订单缺料诊断与智能补货

供应链与运营方向参考；应用赛和创新赛均可选用。

本案例展示插件接入的一种做法，不要求所有作品采用相同技术方案。也可让万智完成同一项目中的独立配套任务，不强制打通Web；提交时提供Agent公开URL并说明实际分工。

要解决什么问题

采购员拿到一张销售订单，问：“这张订单的料够不够？”智能体读取订单明细，核对库存，计算缺口，再给出供应商、补货数量与费用建议。原样例名称为“芯链管家·元器件供应链助手”，处理顺序是“诊断 → 测算 → 建议”。

“最小起订量（MOQ）”是供应商要求一次至少购买的数量；“阶梯价”是购买数量不同对应不同单价；“在途”是已经采购、还没有到货的物料。

本案例按“订单缺料诊断 → 缺口与补货测算 → 供应商建议 → 汇总与在途核对”展开。下文是实现参考，不要求参赛作品全部照做。

当前元器件接口统一使用 X-Api-Key，值为本队伍编码；万智插件和自己的程序都按这个方式调用。Cookie 只用于网页后台登录，不用于当前 API 调用。历史截图展示的是参考应用，不代表每支队伍已经拥有同一个应用。

步骤1：找到销售订单，读取完整明细

先查询销售订单列表，找到要分析的订单，再读取订单详情，取得每一行商品标识和需求量。不能只根据列表摘要回答是否缺料。示例提问：“请分析指定销售订单的缺料情况，并给出补货建议。”

步骤2：查询库存、价格和供应商信息

按商品ID或准确型号匹配每一行物料，读取库存、最小起订量（MOQ）和阶梯价。需要考虑在途物料时，再查询采购单状态、采购数量和已到货数量；通过供应商接口核对关联信息。缺少交期、供货能力或替代料兼容性信息时，列为待确认条件。

步骤3：用代码计算缺口与补货数量

将接口返回的结构化数据交给代码解释器执行 Python。先说清哪些数量要算进去，再开始计算：是否只看当前库存，是否计入在途、其他订单占用或安全库存。下面是一种便于开始测试的简化算法，不是所有企业的统一库存规则。

缺口数量 = max(需求数量 - 可用库存, 0)
有缺口时，建议补货量至少满足缺口与MOQ
单项金额 = 补货数量 × 对应数量档位的单价
补货总额 = 各项金额之和

同一物料在多行订单中出现时应先按同一套规则合并需求数量，避免重复计算库存。数量跨过价格档位时重新匹配单价；金额的舍入规则也要保持一致。大模型负责解释，应保留计算过程，让其他人能重新计算并核对。

供应商选择：先比较缺口金额，再说明理由

将缺料项按缺口金额从高到低排序，结合查询到的供应商资料、历史采购信息与自己的约束给出建议。区分“缺口金额”和考虑MOQ、阶梯价后的“建议采购金额”。加量采购要比较总支出和多买的库存，不能为了凑价格档位机械加量。

场景设定为约1500种商品、6家供应商，但技术文档记录的一个测试队伍当时没有供应商和采购单。请以本队伍实际数据为准；缺少供应商时标明“暂不能推荐”，在途记录为空时如实说明查询结果，有疑问请联系赛事群里的技术人员楼亮。

核对在途采购，避免重复补货

查询相关采购单及明细，核对状态、采购量和已到货数量，判断是否已有在途物料覆盖缺口。只有确认可用于本订单且到货时间满足要求的数量，才按自己的计算规则计入；缺少交期或分配信息时说明假设，不直接扣减全部在途量。

汇总订单与建议，便于逐项核对

当前元器件接口文档没有提供采购单创建接口，因此这个流程的输出是“补货建议”，不能宣称已经自动下采购单。若用自有工具继续执行采购，应说明新增工具、权限和执行证据。

汇总应包括订单号、明细行数、缺料项数、缺口总金额、建议采购量与金额，以及在途采购是否覆盖部分缺口。逐行列出计算依据，便于回到后台核对。

原样例的运行结果

建议再测试这些变化

• 库存不足或物料查询不到时，能否区分真实缺口与缺失数据。
• 订单有多行相同物料、采购量跨价格档位时，能否重新计算。
• 采购单未全部到货时，能否区分已到货与在途数量。
• 接口失败或字段缺失时，是否停止无依据的结论并说明下一步。

原样例提到订单状态和库存会随时间更新；当前接口文档说明手工创建销售订单不会自动扣库存，也不会自动推进状态。测算和演示要按实际环境的规则，不要把旧案例的变化规律直接套用到当前系统。

相关资料

以上案例依据《赛例文档》和《零一万物agent赛题样例》整合；插件操作依据《万智插件配置说明文档》。完整配置步骤、两个案例及资料范围已合并进同一份手册。