## 物流延误日报 {.case data-case-id="063"} | 字段 | 值 | | --- | --- | | 案例编号 | `063` | | 行业 / 部门 | 零售 / 供应链 | | 角色 | 物流专员 | | 难度 | `入门` | | 调用来源 | `schedule`（定时由获授权 Agent 经 App/Extension 读取物流轨迹） | 在途订单延误了，往往是客户先来问、客服才发现。目标：每日定时让获授权 Agent 读取在途订单的物流轨迹，汇总出延误订单清单，交物流专员确认后再通知相关仓与客服；轨迹时间戳缺失的订单不硬判，走独立的"待确认"分支单独发清单，不并入延误或正常。指标：从取数到专员收到日报的中位数 < 10 分钟；轨迹时间戳齐全的延误订单 100% 进入清单；数据源不可达时 0 例被当作"全部正常"。 - **覆盖**：定时读取物流轨迹、按轨迹时间戳判定延误、延误清单经物流专员确认后通知相关仓与客服、时间戳缺失单列"待确认"独立分支、零结果与取数失败回执。 - **不覆盖**：自动改派或重发、自动通知客户、自动向承运商发起索赔、延误责任判定。 - **假设**：有一个经授权能读取物流轨迹并在读取侧脱敏的 Agent（通过 App/Extension）；订单号与收件信息脱敏后进入通知，收件人姓名、电话、地址不外带。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：每日定时由获授权的物流 Agent 经 App/Extension 读取在途订单的物流轨迹，App/Extension 在读取侧即完成脱敏，Agent 只接收订单号尾号、线路要点、承诺时效与轨迹时间戳等白名单字段，收件人姓名、电话、地址不进入 Agent 消息与运行记录；按轨迹时间戳判定是否延误（承诺时效与最新轨迹时间比较），汇总成延误日报。订单号与收件信息脱敏：通知只含订单号尾号与线路要点，不带收件人姓名、电话、地址。 触发：定时（计划）发起调用，调用时带入物流频道、物流 Agent 和审批人（物流专员）。 结果分四类处理： 有延误（轨迹时间戳齐全且判定为延误）：延误清单交物流专员确认（仅含订单号尾号、线路、延误时长、时间戳依据），确认后通知相关仓与客服，留审计时间戳与操作人；驳回则本次失败结束、留审计，不自动通知。 时间戳缺失·待确认（轨迹时间戳缺失或矛盾、无法判定）：这是独立的分支而非附注——不硬判为延误或正常，单独发"待确认"清单给物流专员人工核实并留时间戳，不并入延误、也不并入本期无延误。 本期无延误（时间戳齐全且全部按时）：发一条"本期无延误"汇总回执并留时间戳，不要静默结束。 取数失败（物流数据源不可达或轨迹数据陈旧）：告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道；不当作"本期无延误"，也不当作待确认。 审批：延误清单通知相关仓与客服前须经物流专员确认；审批为二值确认或驳回，不设自动超时，无默认通过/否决。 异常：物流 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容供人工补发。 完成：确认通知、待确认清单、零结果回执、取数失败升级各自留审计时间戳后结束。 ``` ![案例 063 物流延误日报：每日定时让获授权 Agent 读取物流轨迹并按时间戳判定延误；回传不合结构停在原等待点。有延误交物流专员确认后通知相关仓与客服，时间戳缺失走独立待确认分支单独发清单不并入延误或正常，本期无延误发零结果回执，数据源不可达按取数失败告警留审计重试升级，不当作全部正常](../../../media/cases/fig-case-063-01-flow.svg){#fig-case-063-01 width=94%} 如上图所示，正常路径、人工决策与异常同时可见： 1. **定时触发**：计划到点（每日）发起一次调用，带入物流频道、物流 Agent 与审批人（物流专员）。 2. **读取轨迹**：获授权 Agent 经 App/Extension 读取在途订单的物流轨迹，App 在读取侧完成脱敏，Agent 只接收白名单字段，回传延误判断（依据承诺时效与最新轨迹时间戳）；回传结构不合要求时停在原等待点，等其重新提交，不自动重跑。 3. **四路分流**： - **有延误**：延误清单（仅含订单号尾号、线路、延误时长、时间戳依据）交物流专员确认，确认后通知相关仓与客服并留审计时间戳与操作人；驳回则本次失败结束、留审计，不自动通知。 - **时间戳缺失·待确认**：轨迹时间戳缺失或矛盾的订单不硬判，单独发"待确认"清单给物流专员人工核实并留时间戳——独立分支，不并入延误，也不并入本期无延误。 - **本期无延误**：发一条汇总回执并留时间戳，不静默结束。 - **取数失败**：物流数据源不可达或轨迹数据陈旧，告警失败并留审计时间戳，按重试上限重试，仍失败则升级到值班频道，不当作"全部正常"。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"定时取数 + 四路分流"流程——它知道"读轨迹判延误"需要一个发消息并等待回调的 Agent 环节、"分四类结果"需要一个条件路由、"专员确认"需要一个审批环节、"通知与回执"各需要一个发消息环节。AI 还会在后台校验流程结构是否完整，你不必关心这些技术细节。 - **物流数据源不可达或轨迹数据陈旧**：不当作"本期无延误"或静默结束，而是告警失败、留审计时间戳，按重试上限重试；仍失败则升级到值班频道由人工确认。 - **轨迹时间戳缺失或矛盾**：Agent 不硬判为延误或正常，走独立"待确认"分支单独发清单由物流专员人工核实，不并入延误或本期无延误；核实时效用的字段仍以轨迹时间戳为准，缺失就写"待确认"，不猜。 - **专员驳回通知**：本次失败结束并留审计；要重新通知就再发起一次确认，没有"AI 自动改判"。 - **通知发送失败**：按重试上限重试投递；超过上限则升级到值班频道，并保留待发内容供人工补发。 - **本期无延误（结果为 0）**：仍发一条汇总回执并留时间戳，让"没消息"变成可核验的记录，而不是无声结束。 - **物流 Agent 回传不合结构**：本次完成请求被拒绝，停在等待点等其修正后重新提交，不自动重跑。 - **长时间无人审批**：审批本身不设自动超时，流程停在等待状态。若业务需要响应时限，由另一条定时检查的 Workflow（或值班人员）扫出未确认的日报并提醒专员。 延误清单在通知相关仓与客服之前须经物流专员确认，避免把承运商系统的偶发时间戳异常当成延误广播出去。确认时专员能看到每单的订单号尾号、线路、延误时长与时间戳依据，是"有依据的快速决策"；时间戳缺失的订单走待确认分支另行核实，不混进审批清单。审批为二值确认或驳回，不设自动超时，无默认通过/否决；驳回即本次失败结束并留审计，不自动改判；催办属于另一条定时编排。 本工作流的轨迹读取由获授权 Agent 通过 App/Extension 完成，工作流本身不直接调用物流或承运商系统。物流频道作为调用输入提供；数据源访问凭据用 `` 占位，由 Agent 运行时从密钥引用。数据源不可达或轨迹陈旧属于取数失败，走失败回执与升级，不当作"本期无延误"。对仓与客服的通知只含脱敏后的订单号尾号与延误要点，收件人姓名、电话、地址不进入工作流，按客户信息最小披露执行。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段以白名单为准（仅令牌化/白名单字段，原值不进入以上任何一层），收件信息在源头即被脱敏，并按 10% 抽查四层实际记录。 - **回放集与基准**：取最近 300 单在途订单轨迹（含正常、延误、时间戳缺失样本）回放，人工基准答案为按承诺时效判定的延误清单；轨迹时间戳齐全样本的延误判定准确率 ≥ 95%。 - **待确认口径**：时间戳缺失或矛盾样本 100% 走独立"待确认"分支并单独发清单，0 例被硬判为延误或正常，也不并入"本期无延误"。 - **数据源防线**：数据源不可达样本 100% 出取数失败回执并升级，0 例被当作"本期无延误"。 - **脱敏口径**：通知内容 100% 不含收件人姓名、电话、地址，只含订单号尾号，按 10% 抽样核对。 - **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（仅令牌化/白名单字段，原值不进入以上任何一层），收件人姓名、电话、地址出现 0 次，按 10% 抽查四层实际记录。 - **结果可见**：确认通知、待确认清单、本期无延误、取数失败四类结果 100% 各有可见回执，不出现静默成功；从取数到专员收到日报的中位数 < 10 分钟。 - **分母与口径**：准确率分母为轨迹时间戳齐全的回放样本数；每次运行记录取数、确认与通知时间戳。 ### 复用与变体 - **同构迁移**：供应商到货延迟日报、门店补货在途日报、退件回流时效日报。 - **分级路由**：延误超过 48 小时或影响大促订单的单独标高优先级并提醒物流主管，在提示词里写明。 - **写回系统**：确认后再加一个 Agent 环节，由它通过 App/Extension 把延误标签写回订单系统，便于客服侧直接看到；写回须是获授权 Agent 经 App/Extension 的幂等动作（幂等键=订单号+延误周期），响应未知先查后写、按重试上限有限重试、失败升级值班并置"待处理"保留补偿，全程留审计。若不需要写侧能力，改为只读汇总或仅留 Loop 回执更安全。