供应链与物流智能体

四种活儿共用这个名字，而只有一种是你的。

"物流智能体"被用来指四种几乎没有共同工程量的产品。开工之前先说清你在做哪一种，因为其中两种对语言模型来说根本就是错的。

• 网络规划与优化——路径、配载、货位分配、库存布点。这是运筹学，背后有几十年的求解器，而且目标函数是显式的。让 LLM 去选路径，严格劣于让求解器去选路径，而且它无法证明可行性。别做这个。
• 异常分诊与处置——一票货错过了中转、一个月台预约挪了、供应商确认缺量、一个箱子卡在码头。这才是那份活儿。它是在互不通话的系统之间、于信息不完整之下做判断，而这恰恰是这项技术擅长的，也恰恰是从来没人有足够人手做好的。
• 单证与报文处理——提单、装箱单、商业发票、格式坏掉的 EDI 报文。价值真实，主体上是一个抽取问题，而且把它建成一条独立的确定性流水线、而不是折进智能体循环里，会更划算。
• 状态问答——对内和对客的"我的货到哪了"。确实有用，但那是一个跑在物流数据上的客服智能体，它继承的是那本手册，不是这一本。

要紧的那道分界：让求解器去决定什么是最优解，让智能体去决定每天上千个偏差里哪一个值得占用一个人的注意力，以及该怎么说。把这两件事颠倒过来的团队，交付出的是一个能生成看似合理、却没人能对着承运商为之辩护的路径方案的智能体。

每个事实都带着一个快门时刻，而工具契约必须把它写出来。

这是整个领域赖以转动的那项设计决策。在多数智能体应用里，检索到的文档此刻与它被写下时同样为真。在物流里，没有一样东西是这样。物理世界在连续地动，而关于它的数据是以离散、延迟、有时乱序的批次到达的——所以一个没有时间戳的工具结果不是事实，而是一条套着自信 schema 的传闻。

给每个读工具的响应加上必填的 as_of 与 source，并把你的数据按三个陈旧度等级分开，各用各的规则：

• 秒到分钟级——车载定位回传、堆场扫描、WMS 事务落库即读。可以直接据以推理。
• 小时级——承运商状态事件、码头闸口动作、合作方确认。它们成批到达且经常乱序，所以"没有事件"意味着"没有事件被上报"，绝不等于"什么都没发生"。一个因为最后一次扫描是六小时前就断定货物卡住的智能体，会在每一家四小时一轮推送的承运商身上报出误报。
• 天级——在手库存、提前期、主数据、成本表。当成估计值。绝不能让智能体仅凭一个库存数字就承诺可供量；那是拿一个你没读过误差棒的数字做出的一项承诺。

然后把它落在外壳层强制执行，而不是在提示词里提要求：一个按字段设定的最大年龄，在代码里检查，让超龄的读取变成一次带具名理由的拒绝行动。模型不擅长自发注意到"一个时间戳让一个原本完美的答案失去了资格"，而这是本领域单项价值最高的护栏。这个问题的一般形式在知识截止与时间里；在这里它不是边缘情况，而是主线情况。

异常分类法就是产品本身。

把一个智能体放到事件流上、告诉它"去找问题"，它每天会找出一组不同的问题，而且没有一组是可计数的。让这件事可交付的，是一份封闭的、具名的异常类型清单——现实的量级是八到十五种——而且在任何一种上线之前，每一种都要挂上四样东西：

• 一条检测规则，能确定性就确定性。"承诺日期有风险"是一次日期比较，不是一次主观判断；模型的活儿从触发之后才开始。
• 一个对应到真实后果的严重度——产线断料、错失的客户承诺、已经开始计时的滞期费。严重度要从涉及的金钱或承诺推导出来，绝不能从"这个事件听上去有多吓人"推导。
• 一位具名的责任人。每一种异常类型都要路由到一个真能把它处置掉的角色。没有责任人的异常就只是一条通知，而没有责任人的通知会被静音。
• 一条显式的"不动"分支。大多数偏差会自行消解——晚了九十分钟的卡车会到。智能体必须能得出"这个会自行解决，盯到 14:00"，并把它记成一项决定，而不是沉默。

让分类法保持封闭，并用结构化输出强制智能体归类到其中，同时留一个显式的 unclassified 桶。未分类率是你最好的单项健康指标：它上升，就意味着世界变了而你的分类法没变；而那队未分类事件，就是你下一个版本的需求说明。

每一次写入，都是与一个能说"不"的人订的契约。

物流里的写操作不是数据库更新。改订一个箱子、加急一票货、更改送达预约、释放一张采购订单——每一个都在花钱、在挪动一项承诺，或者在消耗一份对方可能已经卖给别人的运力。由此得出三条规则，而第三条是团队用惨痛代价学到的那条。

• 按可逆性与代价给动作分级，并据此设闸。免费且可逆的——加一条备注、把一票货标记为盯防、起草一封消息——无人值守直接跑。可逆但有代价的，比如在同一时间窗内挪动一个月台预约，无人值守跑但要有上限和日报。任何花钱的、改变对客日期的、或者要通知外部方的，都要附上证据提请人工确认；这个审批界面就是整个设计的重心，而审批与确认 UX 讲的正是怎样把它做得足够快，快到能在早上七点的控制塔里活下来。
• 提交时重读。从智能体形成意图到写入落地，几分钟过去了，世界动了——而且常常正是因为同一场扰动。就在写入之前重新拉取那条记录，发现状态已变就中止，而不是覆盖它。这与旅行与预订手册对一份运价报价所用的是同一套纪律，理由也一模一样：你报价的那个东西，不是你即将买下的那个东西。
• 绝不盲目重试一次物流写入。合作方 API 与 EDI 通道经常在成功的同时超时，于是一次重试就订下了第二个箱子。每一次写入都带幂等键，每一个含糊的结果都靠对账收场——回读并确认——而不是再试一次。完整的论证在幂等与重试；在这个领域，那个重复项不是一行坏数据，而是一条实船上的一个实体集装箱。

集成层是这活儿的大半，而它不属于提示词。

人人都低估它，而工期正是在这儿丢的。你要把一个 WMS、一个 TMS、一个 ERP、若干承运商 API，以及一批各自对标准略有不同解读的合作方 EDI 流拼到一起——而这些连接处的脏，在智能体跨着它们推理之前是看不见的。

• 实体识别与归一。同一个地点，在 WMS 里是一个 DC 代码，在 ERP 里是一个 ship-to，从承运商那儿来是一串 SCAC 加设施编号，在 ASN 上则是一段自由文本地址。用确定性代码加一张可审计的映射表来解决它。靠推断来对齐实体的智能体，会悄悄把同城的两个设施合并成一个，而你会从一次送货中得知这件事。
• 单位与数量。件、箱、托盘、层；公斤与磅；毛重与净重。在工具边界处归一，返回一个规范单位并把原值并排附上。别指望模型在四十步里把单位换算一路捋清——它多半会成功，而"多半"对一个会变成实货的数量来说是错的标准。
• 合作方方言漂移。承运商会改状态码语义、会加字段，而且不告诉你；一个开始以不同形态到达的 EDI 段，是一次没有提交、也没有报错的行为变更。给契约做快照、把它的版本打在每条 trace 上，并在门面层吸收变化——正是第三方工具漂移里的那个模式。
• 工具粒度胜过工具数量。抵住"每个系统的每个端点配一个工具"的冲动；那样你会得到六十个互相重叠的工具，以及一堆看起来像推理失败的选择错误。做一小组按领域塑形的工具——get_shipment_status、get_inventory_position、propose_appointment_change——每一个在底下向多个系统扇出。见面向智能体的工具设计。

去测它没有报出来的那个异常。

已报异常的精确率好测、好看，而且近乎无关紧要。真正让你付代价的失败，是智能体从未浮出水面的那些：那次抵达了产线的缺料、那笔累计了三天的滞期费、那个比你更早知道的客户。它们从不出现在复核队列里，因为队列里根本没有东西可复核。

• 对着已了结的历史做回测。取上个季度真实发生过的扰动——那些在某人账上挂着成本的——按事件当时实际到达的样子回放这条流，然后问：智能体会不会把每一个都报出来，以及比人早报了多少小时。"提前小时数"才是那个在商业上有意义的指标，也是该端到一位运营总监面前的那个数字。
• 对沉默做抽样。每周随机抽取一批被智能体判为"不动"的货，交给一位计划员复核。这是唯一能找出系统性盲区的机制，而且它必须是一项常设仪式，而不是出事之后才开的一次调查。
• 把未分类率与推翻率放在一起看。未分类率上升，说明分类法陈旧了。某一种异常类型上的推翻率上升，说明那一类的处置预案是错的，而且它精确地点出了要修什么。
• 在难例上给轨迹打分。一个靠读了一条陈旧记录而做对的判断，是一次掷得好的硬币，规模化之后它一定会掷坏——这正是新鲜度纪律需要轨迹评估、而不只是结果打分的原因。

延伸阅读：采购与寻源智能体，同一张网络的上游那一半；数据分析智能体，紧挨着它的那层报表；以及人在环中，计划员该站在哪里。