顺丰供应链Agent落地实践：供应链AI从工具走向全域智能操作系统

分享嘉宾｜高磊顺丰集团 数智供应链解决方案运筹优化算法 总工程师

编辑整理｜何均泽

内容校对｜韩珊珊

出品社区｜DataFun

搭建一个 Agent Demo 已经很容易：Prompt、模型 API、Tools，再加一套框架，很快就能跑起来。但生产环境考验的不是“能不能回答”，而是能不能长期、稳定、安全地工作。业务语义和数据契约、安全与合规、持久运行、凭证管理、沙箱隔离、全链路 Trace、版本和评测，都是 Demo 之外必须补齐的部分。

供应链场景中 Agent 落地的 5 大断点

从 2024 年开始做供应链智能体后，团队把生产中的问题归纳为五类。第一是“语义乱”：同一个“订单”在 OMS、WMS、TMS 中可能分别指客户订单、出库单和运单，同一个字段又可能存在不同命名；供应链链路长、系统多，烟囱式建设让数据和语义更难打通。第二是“不敢做”：查数容易，真正让 Agent 做决策、执行动作，业务首先要确认风险是否可控。第三是“重复建”：按系统分别做 Agent，最终又形成新的智能体烟囱。第四是“算不对”：预测、优化等复杂问题不能直接交给大模型计算。第五是“学不会”：运行中的成功经验和失败教训如果不能回流，Agent 上线后也难以持续变好。

FZ Agent OS：角色化 Agent 共享统一能力底座

对应五个断点，FZ Agent OS 用 Ontology Engine、Agent Studio、Skill Hub、Evolver、Skill Evolver 分别处理理解、行动、复用、求解和进化问题，并以 Identity、Policy、Sandbox、HITL、Trace、Eval、Version 等治理能力贯穿全程。架构上还有一个重要原则：Agent 不按系统构建，而按真实业务角色构建。需求计划、产销协同、订单履约、生产排程、库存管理、运输等角色 Agent 可以跨越多个系统，上层角色复用同一套能力底座。能力交付侧由 Agent Studio 和 Evolver 承接，共享引擎侧由 Ontology Engine 和 Skill Evolver 支撑；再通过 Data Gateway、API Gateway 与 ERP、OMS、MES、WMS、TMS 等企业系统和数据源连接，把真实资源访问与 Agent 运行环境隔开。

先把业务讲清楚：FZ Ontology Engine 统一企业语义

Ontology Engine 的目标是让 Agent 先理解业务，再查询、决策和行动。企业里虽然已经有 Schema、业务文档、API 文档和知识库，但这些材料并不天然等于 Agent 可用的业务语义。团队早期尝试把业务文档直接放进 RAG，结果会召回大量无关信息，噪音反而影响判断。因此，FZ Ontology Engine 把业务对象、对象关系、规则计算、动作边界、指标口径等沉淀成企业级语义中心，并按业务域组织，而不是做一张覆盖所有业务的超级大图。

图谱建设也尽量由 Agent 完成。业务文档、PRD、API 文档和访谈记录进入建模流程，Agent 抽取概念、关系和规则，人负责审核，结果再进入版本管理。运行时则反过来按需取 Context：先做语义搜索和 Top-K 召回，再根据当前问题沿相邻节点逐层扩展，只把真正相关的信息放进 Agent Context，避免一次性塞入大量材料。

语义中心把资产分成四类：Entity 描述业务对象、属性、关系、约束和状态；Function 负责无副作用的计算与分析；Action 对应会改变业务状态的动作；Indicator 描述业务指标。四类对象形成“理解—决策—执行—度量”的闭环，也支持从指标异常反向追到业务对象、计算方案和执行动作。

演示中，一款 A 类 SKU 在佛山区域仓的库存健康度降至 62%，缺口 320 件。Agent 先通过 Ontology 理解“库存健康度”“可调库存”“执行调拨”等含义，再查询实时库存和需求、调用源仓匹配能力。候选仓比较后，广州区域仓综合得分 92，距离 48 公里、4 小时可达、成本 380 元；方案建议调拨 320 件。因为生成调拨单会改变业务状态，流程在执行前暂停，由计划员确认数量、时效和成本，确认后再生成调拨单，直到入库完成并记录全过程。

让 Agent 敢于执行：把权限、凭证和风险关进治理边界

统一语义之后，下一步是让 Agent 可控地运行。Agent Studio 将治理、执行、资源访问拆成三个平面：Agent Control Plane 负责身份、项目、权限和逻辑资源的上下文组装；Core / Execution Plane 使用这些逻辑资源执行任务；Secure Resource Access Plane 在信任边界内解析真实端点与凭证，并完成策略和审计。

这里的关键设计是让 Agent 只持有“逻辑资源”。真实 API 地址、数据库地址和 Credential 不进入 Agent，上游只拿到经过转换的逻辑资源，访问时再由 Secure Data Gateway 和 Secure API Gateway 解析。数据侧可以控制表、列、行级范围并拦截不安全 SQL；API 侧负责鉴权、审计、前置参数校验、限流、熔断和配额。真正高风险的动作进入 HITL，必须人工确认后才能继续。

能力复用通过 Skill Hub 完成。团队把 Skill 视为业务能力的主要扩展方式，并分成三个层级：系统级 Skill 与 Ontology 中的 Function、Action 等资产绑定，全公司共享且严格治理；组织级 Skill 由个人能力发布、经组织审核后共享；个人级 Skill 可以从日常任务中快速产生，只对本人可见。系统还会依据对话难度、API 调用次数和业务价值生成 Skill 候选，但候选进入 Skill Hub 前仍要人工审批。这样既保留统一企业底座，又允许不同岗位和个人在同一治理框架下形成自己的能力组合。

Agent Studio 本身更多采用配置而不是写大量底层代码：模型、System Prompt、Memory、Skill、Tool、Ontology、Resource 等可以组合配置，再经过 Draft、Staging 到 Production Endpoint。调试时，业务方通过 Workspace、Conversation Flow、Inspector/Logs 和 Trace 查看 Run、Tool、Data、API、Policy、Approval、Model、Hook 等全过程，失败不再是黑盒，而是一条可以定位、介入和恢复的工作流。

大模型不直接算：把复杂业务问题交给可验证的求解器

供应链里还有大量预测和优化问题，核心不是让大模型直接“算答案”，而是把业务问题交付成可运行、可验证的求解器资产。过去算法建模依赖专家经验，经验留在个人脑中；业务不断变化，又会带来持续调参与运维成本。FZ Evolver 的思路是让 Agent 承担部分“算法工程师”工作：AI 辅助理解问题、设计方案和迭代，专家聚焦目标、约束等关键确认，建模方法再沉淀为可复用的 Workflow 和 Skill。

为避免 Agent 从零生成不可控的算法，平台仍由成熟算法库和求解器提供确定性计算，并用一整套 Pipeline / Harness 管理测试、评测、Gate、Artifact 和版本。大模型更多负责理解业务、辅助方案设计与迭代，小模型或求解器负责确定性计算。当前主要覆盖运输路径优化、仓网规划、库存优化、需求预测四类问题，统一经历“理解—设计—实现—验收—优化—发布”的交付链。演示中的工作台类似 IDE：业务数据进入后，Agent 会先反问目标和约束，确认问题后再进入求解器设计、分阶段实现、试跑、验收和性能优化。

这套体系形成三层优化：第一层，算法模型或求解器优化业务结果；第二层，FZ Evolver 持续优化算法模型和求解器；第三层，FZ Skill Evolver 再优化 Evolver 所依赖的 Skill。业务、模型和研发能力分别处在不同层级，但都通过可验证结果向上反馈。

经验不能只留在 Trace 里：让每次运行推动 Skill 进化

Agent Studio 中的 Trace、反馈信号，以及 FZ Evolver 产生的 Trace、Artifact、Score、Benchmark，会进入 Skill Evolver，成为下一版 Skill 的证据。整个进化流程不是“让模型自己改自己”，而是受治理的版本管线：先 Freeze 还原 Trace、上下文和 Skill 版本，再跑 Baseline；Analyze 定位问题，Synthesize 聚类共性问题，Mutate 生成候选版本，Review 检查预算和反特化，随后进入 Gate，最后由 Learn 更新知识与版本谱系。

其中有两条硬约束。第一，没有行为证据，不允许修改 Skill，避免模型为了高分编造优化理由；第二，没有确定性 Gate，不允许晋级版本。候选版本必须从质量、成本、延迟和安全等维度评估，只有通过 Gate 才能发布。这样一来，一次业务运行既完成当前任务，也留下下一次能力进化所需的证据，形成“业务闭环”和“能力闭环”两条循环。

总结：语义先于行动，工程边界承载智能，证据驱动进化

高磊把 FZ Agent OS 的设计理念收敛为三个坚持：语义先于行动，先把业务对象、规则和口径讲清楚；工程边界承载智能，把凭证、权限、沙箱、HITL、Trace、版本和评测留在可治理的系统里；证据驱动进化，让能力更新建立在真实运行结果之上。

Q&A

Q1：您提到让 Agent 自己建立语义关系、由人来测评和审核。对于 Agent 自动建出来的这套关系，具体怎么验证？有没有一套比较明确的验证方法或方法论？

A：验证很难完全让 Agent 代替人，因为 Agent 不承担最终责任，质量 Gate 还是要由人把关。我们的思路不是取消人工，而是把人的精力从“生产”转到“审核”。我们会用一整套 Skill 告诉 Agent 如何从业务文档、API 文档、访谈记录中抽取概念和建立关系，尽量提高准确率，再由人做最终把关。甚至人对语义图谱的修改也没有单独做编辑页面，而是继续通过对话让 Agent 修改。

Q2：统一语义和本体需要被不同业务使用，但图谱建模可以很粗，也可以很细。面对不同应用需求，Ontology 的建模粒度怎么权衡，才能既统一又可用？

A：第一，要承认不同业务域本身就存在差异，所以并不是一整张超级大图，而是按业务域区分，只是一个业务域会打穿相关系统。第二，颗粒度跟着业务实际走。一个概念如果在业务文档中经常出现，通常就是比较合适的建模粒度。

Q3：我们的实验平台每天会跑几十万次实验，数据量达到 PB 级。您现在主要构建的是语义图谱，有没有考虑进一步加入具体 Trace、Event、Decision Tree，或者一些启发式经验，形成介于语义概念和数据实例之间、可以复用的实例化层？

A：这个问题内部讨论过很久：只做语义层，还是把数据实例对象也纳入进来。当前选择是只做语义层，不做业务实体的实例化图谱。一个原因是技术难度，以顺丰的数据量，PB 级甚至更大的实例图谱挑战很大；另一个原因是不同场景的数据 Ready 程度不一样。现阶段的判断是，仅语义层在很多场景里已经足够。