供应链出现异常时，团队与 AI Agent 如何共同复核

简要回答

在异常复核中，Agent 负责核对和整理源资料。一个 Agent 把供应商通知与采购订单逐项比对，另一个根据团队提供的数据，列出可能受影响的订单行。两者给出的结果属于初步结果。来源之间的矛盾由团队成员处理，每项决定交给有相应权限的成员作出。

复核的产出是一份复核包，记录各项来源及其时间、矛盾、缺失项、假设、候选方案和已作出的决定。复核包不能代替企业正式的业务记录。联系供应商、修改订单这类动作，在各自所属的系统里由有权限的成员完成，执行结果也在那里核对。

本文示例为虚构，描述的是一种建议的工作方式，既非客户案例，也未用真实数据测试。示例没有连接任何系统，其中的数字也不是测量结果。

示例中的延期出货通知

这家虚构的分销商有三名成员参与复核。采购负责人在自身授权范围内跟进供应商；计划员维护计划数据，以及由此形成的正式记录；在这个虚构团队中，客服负责人获授权确认对客户的交付承诺。

团队安排了两个 Agent，各自承担一项独立的核对。通知核对 Agent 把供应商邮件与采购订单行逐项比对；影响清单 Agent 读取计划员提供的计划系统导出文件，列出可能依赖这批延期供货的订单行。两个 Agent 均不连接企业资源计划（ERP）系统或计划系统，也不联系供应商或客户。

团队把资料限定在获准查看该客户与订单数据的成员和 Agent 范围内。邮件和导出文件放在一个私密空间里，由三名成员和两个专用 Agent 共享。文件存放的位置是一道边界；Agent 运行所在的电脑，以及存放在那里的凭据，构成另一道边界，团队需要单独核对。

出货、到货与客户交付是三个不同的日期

供应商邮件给出的是新的出货日期。出货推迟一周，本身并不意味着控制板晚一周到货，更不意味着用到这批控制板的每一笔客户订单会随之延误。从出货到客户交付，中间还隔着运输时间、收货时间和现有库存。

复核时把三个日期分开记录。出货日期指货物离开供应商的时间，到货日期指货物抵达分销商仓库的时间，客户日期指某一订单行计划交付的时间。示例中的邮件给出了新的出货日期，没有给出预计到货时间。在取得到货估计之前，到货日期记为未知。

计划软件对供应延迟有自己的定义。Oracle Fusion Cloud Supply Planning 25D 版本的文档描述了一类名为 Late Replenishment for Sales Order 的异常，当某一销售订单行的供应晚于该行计划日期时产生。同一页面说明，在有约束的供应计划中，这类基于订单的异常需要配置为用户自定义异常。仅凭一封供应商邮件，还不能判定销售订单行符合这项定义；判断需要供需之间的关联数据和相关日期。

哪些已确认，哪些有出入，哪些缺失

开始分析之前，团队先把资料并排摆开。下表使用虚构数值，展示一项事实所处的三种状态。

导出文件取数早于邮件到达，因此无法反映新日期，其中的数量也停留在周一傍晚的状态。复核时，每一个取自导出文件的数字旁边，注明这个取数时间。

两个 Agent，两项初步核对

两项核对使用不同的资料，能够并行开展。规模如此的复核，由一个 Agent 按顺序完成两个步骤同样合适。团队选择两个 Agent，原因在于两项核对的输入和输出各不相同。

通知核对 Agent 读取邮件和采购订单行，列出邮件写明的每一个字段，标出与订单一致的字段，并指出存在出入或缺失的字段。在示例中，它报告了新的出货日期、出货数量与订单数量的差异，以及缺失的预计到货时间。订单 500 块、本批出货 400 块，如果属于分批出货，两个数字同时成立。因此 Agent 提出的问题是，这份通知覆盖哪些货物，剩余 100 块作何安排。

影响清单 Agent 读取计划系统导出文件。对每一条候选订单行，它报告零件、供应行、关联的需求行或销售订单行、带单位的数量、相关日期，以及取数时间。使用同一零件或同一周交货、却没有关联记录的订单行，另列一份待核清单。Agent 不把自己的结果表述为受影响订单的完整名单。

两份结果同属初步结果。它们依据同一批文件，彼此一致并不构成相互独立的证实。延期范围确认之前，影响清单保持附条件的状态。团队如需按「400 块受影响」和「500 块全部受影响」分别推演，每个版本把范围标为假设，并写明仍需补充的分配数据。

处理来源之间的矛盾

采购负责人向供应商确认，400 块究竟属于分批出货、总量变更还是笔误，新日期适用于本批货物还是整张订单，剩余数量现处于何种状态。供应商的答复、答复时间和接收答复的成员，记入复核记录。在此之前，受影响的数量在复核中保持未定。

较新的邮件与较早的导出文件在出货日期上也不一致。邮件时间更近，导出文件则反映截至周一的正式记录，复核需要分别核实两份资料。复核时分别注明两个版本的来源、时间、状态和负责人，再由计划员与采购负责人核实当前状态。

新日期和数量确认之后，计划员在计划系统中更新正式记录，复核随后从已确认的状态继续推进。以这种方式了结的矛盾，会在两处留下记录。复核包说明矛盾如何解决，正式记录保存当前的数字。

候选方案与各自的决定人

复核以一组候选方案收尾。每个方案写明前提条件和决定人，均不由 Agent 执行。

采购负责人的决定，不能代替属于其他成员的审批。例如，启用备选货源之前，可能需要先取得质量或成本方面的签核。对客户的承诺仍由客服负责人负责。

各项动作随后在各自的系统中完成。采购负责人通过企业惯用的渠道联系供应商，客服负责人在与客户沟通的渠道中更新交付信息。每项动作的结果，在其发生的系统里核对。

复核包包含什么

复核包把整次复核集中记录在一处，包括以下内容。

• 每一项来源，以及收到或取数的时间。
• 按已确认、有出入、缺失三类归档的事实。
• 明确标注为假设的假设。
• 候选订单行，每行附上支撑它的关联关系和日期，以及仍待核实的订单行。
• 各个方案及其前提条件。
• 每项决定的决定人、其授权范围和决定内容。
• 尚待执行的动作、各自的负责人，以及确认执行仍需的证据。

复核包里记下的决定，不等于动作已经完成。团队批准了一项方案、尚无成员执行时，任务不应显示订单已经修改。跟踪订单修改的任务保持打开，写明负责人和下一步动作，直到执行证据核对完毕。单纯用于复核的任务，在复核包通过验收后即可关闭，后续动作另建任务，分别写明负责人。

复核包服务于复核，不能代替企业的正式记录。订单状态、数量和日期维护在企业的正式业务系统中；来源有出入时，按前文步骤核实并更新。

结束复核前的核对清单

以下问题概括了示例中的做法，团队可在把一次异常复核标记为完成之前逐项核对。

• 出货、到货和客户日期是否分开记录，未知的日期是否标为未知？
• 每一条候选订单行，是否附有支撑它的关联关系和日期？
• 没有关联记录的订单行，是否列入待核清单？
• 来源之间的每一处矛盾，是否记下来源、时间、状态和负责人？
• 已确认的变更，是否录入正式记录？
• 每项决定是否写明决定人及其授权范围？
• 尚未完成的动作，是否有负责人，并写明确认执行所需的证据？

Syfo 在其中的位置

本文由 Syfo 发布。文中提及的功能依据 Syfo 文档描述，示例并未在产品中运行。

Syfo 的任务记录负责人、状态、下一步动作和交付物，适合从初步核对推进到决定与后续跟进的异常复核。Syfo 文档说明交付物需要明确标记，团队因此把定稿的复核包标记在对应任务上。其文件文档建议把敏感文件放进私有频道或受控任务；其安全说明区分了频道附件与 Agent 工作文件，后者留在 Agent 运行所在的电脑上。

本文所依据的 Syfo 文档，没有提到 Syfo 与 ERP、仓储或运输系统之间的连接，示例也不依赖任何此类连接。Syfo 的安全说明把付款、合同相关动作和对外承诺列为不应由 Agent 直接自动执行的动作，示例中的这些动作同样交由获授权的团队成员处理。

FAQ（问题与回答）

示例中的 Agent 能直接修改订单或库存吗？

示例中的 Agent 读取团队提供的文件，不连接也不写入任何业务系统。Agent 在获得其他访问权限后能做什么，不在本文讨论范围内，这取决于企业在自身系统中授予的权限。

异常复核需要不止一个 Agent 吗？

规模如此的复核，由一个 Agent 按步骤完成即可。示例使用两个 Agent，是因为通知核对和影响清单的输入与输出各不相同。增加 Agent 并不会让它们的结果彼此独立。

邮件与系统记录不一致时，团队该怎么办？

分别记下两个版本的来源、时间、状态和负责人，并与负责的业务成员核实当前状态。确认之后更新正式记录，再从那里继续推进。较新的邮件与较早的导出文件，可能各自部分正确。

资料不足以确定受影响订单时怎么办？

列出候选订单行及其支撑关联，列出仍待核实的事项，并写明缺少哪些资料。一份附条件、带待决问题的清单，比一份靠猜测填满的名单更能为决定人提供依据。

资料来源

Late Replenishment for Sales Order 异常的定义，以及它在有约束供应计划中作为用户自定义异常配置的说明，引自 Oracle 文档 Configure Order-Based Exceptions for Constrained Supply Plans（Oracle Fusion Cloud Supply Planning 25D 版本）。

任务字段参见 Syfo 文档《任务》，交付物标记与敏感文件的存放参见《文件与交付物》。频道附件与工作文件的区别、需要成员确认的动作，参见《安全与权限》。以上页面均于 2026 年 10 月 20 日读取。