把AI代理做稳：评估框架让自动化真可用

你可能已经见过这种场景：仓库主管对着一堆系统报表来回点筛选，想找“本月发货延迟超过48小时且客户投诉过的订单”，结果要翻三四个页面、切两个系统，五分钟过去了还没找到。更现实的是，很多一线同事根本不会写SQL，也不想学BI工具。

Pushpay 在他们的“自然语言搜索代理”项目里给了一个很实用的答案：让用户用一句话得到可执行的结果，同时用一套严谨的评估体系把准确率从 60–70% 拉到 95%+。虽然案例来自教会管理平台，但对“人工智能在物流与供应链”这条主线特别有参考意义——因为供应链数据同样复杂、字段同样多、工作流同样要求稳定可控。

下面这篇文章不重复源码细节，而是把它翻译成你能落地到物流与供应链的做法：怎么用AI语音助手/自然语言代理去自动化数据密集型任务，以及怎么用评估框架把它从Demo带到生产。

供应链的AI代理，难点不在“会说话”

结论先说：供应链场景里，AI代理最大的风险是“看起来对、实际错”。 语气自信但筛选条件错一位，轻则浪费人力，重则导致错发、错补货、错承诺。

在物流与供应链中，AI代理通常承担两类任务：

• 自然语言查询（NLQ）：把“人说的话”变成系统能执行的过滤条件、SQL或API参数，比如查询异常订单、滞留包裹、库龄过长SKU。
• 自动化工作流（Agentic Workflow）：不只是查，还会触发动作，比如创建工单、发通知、生成例外报告、触发补货建议。

Pushpay 的第一版方案其实是很多团队的起点：一个大而全的系统提示词（system prompt），把“有哪些筛选器、每个筛选器怎么用”全塞进去，让模型输出结构化 JSON。它能跑，但很快遇到三类典型天花板：

1. 准确率卡在 60–70%：字段越多、组合越复杂，越容易在边界条件翻车。
2. 人工评估太慢：靠人逐条看输出对不对，迭代周期会被拖成周。
3. 覆盖面越大越难调：上百个过滤器（供应链里可能是上千个字段/状态码/例外类型），靠“再改改提示词”很难突破。

这也是为什么我一直不太认同“先做个智能助手再说”的路线。没有评估体系的代理，只是一个不稳定的接口。

Pushpay 的关键做法：用“可度量”把代理拉到生产

结论：要把AI代理做可靠，你需要一套持续评估闭环，而不是一次性验收。 Pushpay 加入了一个自定义的生成式AI评估框架，核心由四部分组成，这四件事在供应链里完全可以复刻。

1) Golden Dataset：把真实问题变成可回归的测试集

Pushpay 建了一个 300+ 条的黄金数据集：每条包含“用户查询”以及“期望输出（expected output）”。这件事在物流里可以这样做：

• 从客服、仓库、运输调度、采购的真实问法里抽样（不要只用产品经理写的“标准句”）。
• 每条问法要配一个可执行的标准答案：例如结构化过滤条件、订单ID列表的规则、或触发动作的参数。
• 每周/每月把新出现的高频问法加入数据集，形成持续扩容。

可直接照抄的模板：

• Query：找出本周冷链订单中，温度异常>2次且目的地为华东的订单
• Expected output：{"filters":{"shipping_mode":"cold_chain","temp_anomaly_count":{"gt":2},"destination_region":"east_china","time_range":"this_week"}}

2) Evaluator：用“LLM as a Judge”做自动化判分

结论：让模型做裁判，比让人逐条看更快，但要有规则。 Pushpay 用了 LLM-as-a-judge 模式：把“代理输出”与“黄金答案”对齐比对，给出准确率、错误类型、以及日志（包括延迟）。

在供应链里，我建议把判分拆成更可操作的维度，而不是只给“对/错”：

• 字段选择是否正确（用了哪个筛选器/字段）
• 操作符是否正确（gt/lt/in/between）
• 边界条件是否正确（时区、自然周、含不含当天、库龄计算口径）
• 安全约束是否被遵守（是否越权查询、是否输出敏感信息）

这样做的好处是：你能很快知道问题到底在“理解意图”还是“字段映射”还是“口径”。

3) Domain Category：按“业务域”分桶，而不是只看总分

Pushpay 把用户查询分成不同 domain，并用 domain 维度看准确率和延迟，还引入了 95% Wilson 置信区间来避免“样本少导致的假高分”。这点特别关键。

供应链场景里，建议把 domain 分成更贴近职责边界的桶，例如：

• 运输异常（延误、滞留、签收失败）
• 仓储（库龄、拣货波次、盘点差异）
• 库存与补货（安全库存、缺货、周转天数）
• 订单与客服（取消、退款、投诉、承诺时效）
• 供应商与采购（到货偏差、交期、质量批次）

一句话：总准确率没有意义，能指导迭代的准确率才有意义。

4) Dashboard：把工程迭代变成“分钟级反馈”

Pushpay 的看板不仅展示按 domain 的准确率，还展示 p50–p90 延迟分布，用于找性能瓶颈。

在物流场景，延迟不是“体验问题”这么简单：

• 调度现场需要秒级响应，否则就会绕开系统用人工经验。
• 仓库作业节拍固定，响应慢会导致波次计划无法落地。

把延迟按 domain 拆开，你会很快发现：某些域慢，通常不是模型慢，而是上下文拼装太大、检索召回太多或工具链调用太多。

让语音助手真正可用：动态提示词 + 过滤器语义检索

结论：当字段/筛选器非常多时，“把所有说明写进提示词”是死路。 Pushpay 后来引入了动态提示词构造器（Dynamic Prompt Constructor, DPC），用语义检索只把“与当前问题相关的过滤器清单”塞给模型。

这对供应链系统简直是刚需，因为你的字段库可能包括：承运商、线路、波次、库区、批次、温控、税则、箱规、异常码……把全量字典塞进提示词，成本高、延迟高、还更容易让模型选错。

我实践下来，DPC 在供应链落地时要抓住三类上下文：

1. 问题上下文：问的是运输还是仓库？是查订单还是查SKU？
2. 角色上下文：客服看到的字段通常比财务/仓库少；越权会造成数据泄露。
3. 租户/站点上下文：不同国家、不同仓、不同承运商字段可能不一致（跨境物流尤其明显）。

把“过滤器库存（field inventory）”从静态提示词变成动态装配，你会同时得到三件事：更准、更快、更便宜。

供应链落地的一套可复制路线（含可执行动作）

结论：先用“可控域”上线，再用评估闭环扩域，这是最稳的打法。 Pushpay 的策略是：通过 domain 评估发现弱项后，先抑制（suppress）低表现域，只开放高表现域，从而在整体上达到 95% 的可用水平。

把它翻译成物流与供应链的项目计划，可以这么做：

第一步：选一个“高价值、低歧义”的域

优先选这些：

• 延误与滞留订单查询（字段明确、口径清晰）
• 库龄与呆滞SKU（口径可定义）
• 异常工单生成（动作固定）

先别从“智能补货策略”这种强策略域开始，歧义太多，争议太大。

第二步：建立黄金数据集与回归评估

把 100 条做扎实，比 1000 条空洞更有用。每条都要能回归、能复现。

第三步：上线“域级开关”与灰度策略

把每个 domain 当成一个功能模块：

• 高分域：直接开放给更多人
• 低分域：隐藏入口、提示“该能力正在优化中”、或转人工流程

这并不丢人。相反，这是对业务负责。

第四步：把语音入口接进来（但别跳过评估）

语音助手在一线场景特别吃香：司机、仓管、巡检人员腾不出手打字。

做法很简单：语音只是输入层，后面仍然走同样的代理与评估体系。你要额外加两类测试样本：

• ASR 误识别（同音字、口音、噪声）
• 口语化表达（“最近”“差不多”“上次那批”）

然后评估里多一个维度：语音转写后的意图保持率。

你可以把“语音助手”当成加速器，但别把它当成遮羞布。底层不可靠，语音只会放大问题。

你该关注的三个指标：准确率、覆盖率、可解释性

结论：生产环境不只看准确率，还要看“能处理多少”和“错了能不能定位”。 结合 Pushpay 的经验，我建议供应链代理最少盯三项：

1. 域级准确率（含置信区间）：别被小样本骗。
2. 覆盖率（Coverage）：用户问题里有多少能被分到已开放域。
3. 可解释性日志：至少记录意图识别、召回的字段清单、最终选择的过滤器、以及拒答/转人工原因。

当这三项都能稳定跑起来，代理才会从“有趣功能”变成“自动化工作流的基础设施”。

下一步：把“查询代理”升级成“自动化工作流代理”

Pushpay 的案例本质是“自然语言到结构化过滤条件”。在物流与供应链里，一旦这层稳定了，你可以很自然地往工作流走：

• 查到“高风险延误订单”后，自动创建异常工单并@责任人
• 查到“库龄>180天且周转低”的SKU后，生成清仓建议并推送采购
• 查到“供应商交期偏差连续三次”的批次后，触发供应商评分更新

我会建议你用同一套评估框架扩展到“动作正确性”：不仅判查询对不对，还要判该不该做动作、做什么动作、参数是否正确。

你准备把第一个可控域选在哪：运输异常、仓储库龄，还是库存补货？