AI 是最简单的部分：供应链中的前向部署工程师究竟是什么？

什么因素真正造就了一名前向部署工程师（Forward Deployed Engineer）——这个科技行业最炙手可热的职位，通过一个供应链项目来讲述。

2026年8月3日

14分钟阅读

2012年，《哈佛商业评论》将数据科学家称为“21世纪最性感的职业”。

每家公司突然都想拥有这样的人才。

十多年后，现在所有人都在追逐的职位是前向部署工程师。

这名工程师深入嵌入公司的运营中，使AI模型或优化算法在混乱的现实世界中真正发挥作用。

不幸的是，没有比供应链更混乱的运营场景了。

当我成为一名供应链数据科学家时，我深有体会。

例如，想象从米兰仓库发出的一批奢侈包，经过卡车、机场和清关，最终抵达上海的商店。

时尚零售公司的分销链 –（图片由Samir Saci提供）

这条链涉及多个国家的多个团队，他们使用不同的系统（ERP、WMS、TMS），而这些系统并非为提供统一数据而设计。

例如，我曾参与过一个项目，仅为了构建一个管道来比较两个日期（请求交货日期和实际交货日期）以衡量准时交货，就花了18个月。

你的供应链中多个系统相互交互 –（图片由Samir Saci提供）

因此，在大多数AI供应链项目中，最大的挑战是在这种混乱的环境中实施智能体。

这在过去对于商业智能和数据科学来说是如此，现在对于生成式AI更是如此。

为什么公司现在愿意花大价钱让前向部署工程师为供应链运营实施AI？

在本文中，我将通过我为一家时尚零售商开展的项目来回答这个问题，说明FDE在此环境中面临的挑战以及他们需要具备的品质。

这是一个AI驱动的分销链监控工具的部署，帮助规划人员找到门店延迟交货的根本原因。

这个AI智能体帮助规划人员了解为什么发货被延迟 –（图片由Samir Saci提供）

我在米兰一家零售商的物流部门实施了这种智能体编排。

他们的问题是，在检测和分析分销链故障方面的能力有限。

物流总监：“超过35%的延迟交货没有解释。”

他们希望有一个智能体仅从数据中进行根本原因分析，不带偏见，就像下面的分析一样。

Claude比较仪表板测量的根本原因与实际 –（图片由Samir Saci提供）

这个实施的有趣之处不在于智能体编排本身，而是我围绕它构建的一切。

我将用这个例子来阐述这份工作真正需要什么：

• 读取没有文档的系统
• 让团队就定义达成一致
• 在信任工具之前让用户测试它

没有一项是技术性的，而这些都是前向部署工程师的工作。

如果你是一名数据科学家，正在寻找目前薪资最高的职位，这就是这个职位背后的工作，以及你需要具备的技能。

部署连接到供应链系统的Claude智能体

这一切始于物流总监的一个请求：“我希望AI帮助我的规划人员找到分销链故障的根本原因。”

涉及空运的国际物流链 –（图片由Samir Saci提供）

他们有一个由12名规划人员组成的团队，负责管理门店库存。

他们向仓库发送订单，每个订单都有请求交货日期，并监控发货直到货物到达门店。

从订单创建到门店交货的所有步骤都记录在系统中 –（图片由Samir Saci提供）

由于仓库的延迟、路线变更或海关滞留，超过25%的订单延迟到达。

门店经理向总监投诉，因为延迟交货意味着销售损失。

使用时间戳监控发货

幸运的是，每个步骤都记录在系统中：

• 仓库运营团队使用仓库管理系统（WMS）准备和装载货物到卡车
• 运输团队使用运输管理系统（TMS）组织仓库提货、空运和最后一英里配送

这些系统生成用于跟踪整个分销链中订单的时间戳。

从订单创建到门店交货的所有步骤 –（图片由Samir Saci提供）

规划人员手动在Excel中处理数据，以解释过去的延迟并标记未来的延迟。

由我进行的传输和拣货包装前置时间分析示例 –（图片由Samir Saci提供）

然而，这既慢又低效。

分析通常来得太晚，运营团队没有足够的时间来查明根本原因。

于是讨论变成了争吵，每个团队都指责对方。

绩效评估期间冲突的图解 –（图片由Samir Saci提供）

正如我喜欢说的，供应链管理中最复杂的任务是与人打交道。

聘请Claude作为超级分析师

这就是为什么我们构建了一个Claude智能体，通过MCP服务器连接到他们的数据，定期运行此分析并帮助分析师采取行动。

智能体可以查询数据，以自然语言回答任何请求，帮助规划人员找到分销链故障的根本原因。

Claude为高层管理层生成的视觉 –（图片由Samir Saci提供）

规划人员可以在几秒钟内生成带有交互式视觉的报告，如上所示，无需编写一行代码。

规划人员现在比以前生产更多的根本原因分析，并且这些分析及时到达，以便他们采取行动。

分析师使用Claude工作流生成的闪报示例 –（图片由Samir Saci提供）

分析师现在可以自动向每个团队（仓库、公路货运、空运）安排闪报，在不到5分钟内进行深入的根本原因分析，并将智能体作为绩效副驾驶使用。

然而，这并非易事。

这里最大的挑战不是设计，而是实施。

本文的其余部分是关于我们为此付出的努力，因为部署才是困难的部分。

如果你想了解解决方案本身的细节，我在这个短视频中解释了所有内容：

但现在，是时候回顾我在这种混乱环境中尝试实施Claude时遇到的最大障碍和挑战了。

这将让你了解供应链中FDE所需的技能和专业知识。

像许多分析项目一样，第一个问题是获取干净、统一的数据。

干净的表是输出，而不是输入

下面的视觉是Claude通过MCP实施用于回答分析师问题所使用的数据集样本。

通过MCP工具连接到Claude的数据集 –（图片由Samir Saci提供）

在一个单表中，我们有覆盖从订单创建到门店交货整个分销链的所有时间戳，数据来自多个系统。

每个字段都在MCP实施中向Claude描述，包含运营上下文，以便它可以查询数据来回答任何问题。

例如，如果卡车在截止时间之后到达机场，则为FALSE。

当我开始这个项目时，没有任何连接。

时间戳由各个系统创建 –（图片由Samir Saci提供）

事实上，这三个系统有自己的架构、字段定义和格式。

作为前向部署工程师，我的职责是理解如何提取正确的信息、清理它并将其存储在一个统一的表中。

让我分享两个例子。

示例1：没有明确的字段来提取正确的信息

在理想世界中，你连接到Snowflake表并根据字段名称选择正确的字段。

我的现实并非如此。

当我询问IT基础设施经理在哪里找到订单创建日期时，他指给我看这张表。

用于提取订单创建日期的规划工具表 –（图片由Samir Saci提供）

字段名称并不明确。

最后两列来自一位四年前离职的工程师进行的自定义开发。

• 是规划工具中的订单号
• 是一个定义订单是由人还是自动创建的属性
• 和 是我们需要获取订单创建日期和时间的两个字段

在这种情况下，最好的做法是让用户和基础设施团队坐到同一张桌子旁。

我的问题：我应该取哪个字段？

不幸的是，没有人能给我一个完整的答案。

我使用了多个订单的示例，并将规划人员在屏幕上的内容与表中的数据进行了比较。

通过这种方式，我发现 是一个依赖于 的公式

ORDER_CREATION_TS = HEUR_DTS   when CRIND = 'A'
                    MANU_DTS   when CRIND = 'M'

这一点都不明确，而且没有文档，确认这个公式花了好几天时间。

这种调查至关重要：它是使工具可靠并赢得用户信任的关键。

这是这份工作要求的第一个技能：深入系统，并让运营用户与你一起参与。

每天运行流程的人知道这些字段的含义，即使没有人写下来。

示例2：五个研讨会来定义一个布尔值

第二个例子展示了你将如何将运营现实与系统中可用的数据进行协调。

在规划人员创建订单后，它们被发送到仓库。

一旦仓库团队准备好，它们就被装载到卡车上。

订单装载到卡车的出库月台 –（图片由Samir Saci提供）

有时卡车没有准时装载，延迟会级联到后续的每一步。

例如：如果卡车晚出发两小时，它可能会错过机场的航班。

延迟装载有两种情况：

• 卡车已到，但托盘未准备好，因此仓库负责
• 托盘已准备好，但卡车未到，因此运输负责

这是仓库经理告诉我的。

经验告诉我，物流中从来没有这么简单的事，所以我和运输经理进行了双重确认。

他给了我一个没有人提到过的第三种情况。

运输经理：“如果卡车是由货运代理派出的，那么准时装载不是我的责任。”

在这个阶段，我必须权衡所有边缘情况，从WMS和TMS中提取正确的信息。

用于创建正确公式的可用数据 –（图片由Samir Saci提供）

在与两个团队进行了五次研讨会后，我们达成了一个让所有人都满意并尽可能准确地反映运营现实的公式。

LOAD_ONTIME = LOAD_END <= 19:00        # 里程碑事实，两种场景相同

# 责任归属，仅在LOAD_ONTIME为False时：
if CTRL == 'SHP':                       # 场景1：我们自己的卡车总是在那里
    CAUSE = 'WAREHOUSE'                 # 仓库负责准备和装载
elif CTRL == 'FWD':                     # 场景2：货运代理提货
    if PACK_END <= PU_ETA:              # 货物在预定时段内已准备好
        CAUSE = 'FORWARDER'            # 卡车来晚了，仓库是级联受害者
    else:
        CAUSE = 'WAREHOUSE'            # 货物未及时包装

没有必要深入公式的细节。

重要的是，我们花了一周时间才达成一致！

真正的瓶颈

我原本期望工作重点是引入更好的算法。

最终，我站在这里是为了构建算法存在所需的定义。

这是这份工作要求的第二个技能：不要接受你得到的第一个定义。

向每个团队问同一个运营问题，直到他们都给出相同的答案，然后写下来。

定义就是可交付成果。

一旦这些定义存在，真正的问题是如何让智能体以一种规划人员会真正信任的方式来使用它们。

将定义转化为工具

一旦公式存在，AI部分几乎就简单了。

我将Claude Opus 4.8连接到一组工具，用于查询包含交易数据的表。

使用Claude Opus的MCP实施 –（图片由Samir Saci提供）

客户不希望向Claude提供太多信息，只提供理解数据所需的最低限度。

物流总监：“我们希望智能体提供公正的根本原因分析，并评估每个团队的绩效。”

我们没有为每个场景构建仪表板，而是给了智能体访问工具来查询一个数据集，该数据集包含标志和前置时间，并让它自己组合分析。

通过MCP工具连接到Claude的数据集 –（图片由Samir Saci提供）

在MCP实施中，我们提供了工具返回内容的通俗语言描述以及底层运营规则的含义。

作为第一次测试，我们让Claude解释它手头的工具。

Claude使用MCP工具描述解释布尔标志的定义 –（图片由Samir Saci提供）

它正确解释了每个标志，我无需解释任何一个。

智能体理解了数据，因为前向部署工程师最终与两个团队坐下来，决定了数据的含义。

第二次测试更难：它将如何使用这些标志来评估绩效？

智能体提出的根本原因分析方法论 –（图片由Samir Saci提供）

它提出将基于标志的归因与实际持续时间进行比较，这正是使得开头的结果成为可能的区别。

那一刻我知道这个方法会奏效。

剩下的是将其交到团队手中。

用户验收测试：确保工具会被使用

我不想演示这个工具。演示只是证明构建它的人能让它工作。

所以我向规划团队提出了另一个要求：带着你们每周已经做的分析，我们和智能体一起运行它们。

分析师评估Claude对他们过去分析过的案例的结论 –（图片由Samir Saci提供）

这是在这个阶段唯一重要的测试。

这些规划人员花了数月时间手动在Excel中制作同样的重复报告。

在智能体说任何话之前，他们就知道答案应该是什么样子。

如果它偏离了、编造了数字、或者遗漏了他们总是检查的细微差别，他们会立即发现。

这就是为什么他们比我是更好的测试者：我可以验证工具返回了正确的行，但只有他们能告诉我答案是否有用。

一次实践测试

一位规划人员要求进行他每周一都会做的分析：

请为我准备一份上周范围内的航班时间延迟分析。

首先要检查的是智能体是否回答了规划人员实际想问的问题。

（图片由Samir Saci提供）

这个请求很模糊，智能体很容易回答些无关的内容。

但它理解了规划人员指的是上周交付的订单，并且它区分了那些导致一天延迟的航班和那些没有延迟的。

模型证明了它可以理解上下文、质疑请求，并给规划人员他实际需要的东西。

这正是物流总监所要求的。

每个重复报告都是一个单元测试

在传统的IT项目中，你编写规格说明、按规格构建、然后测试构建是否与规格匹配。

但这里没有规格说明，因为没有人能在看到工具实际运作之前编写它。

他们有的是多年的重复分析，而这些分析最终成为比我事先能指定的任何测试套件都更好的测试。

如何成为一名优秀的供应链FDE？

回顾这个项目，我们可以将我的贡献分为两部分。

一部分是数据科学家或AI工程师的工作：构建一个MCP服务器，配备一组工具来查询和描述数据，并带有文档字符串。

这部分花了不到5天时间。

而另一部分是确保我们有一个工具被部署并可供团队使用——这花了数周时间、十几次简短会议和长时间的工作会议。

这看起来更像是我以前作为持续改进工程师的工作，而不是部署智能体工作流的AI工程师。

作为软件工程师或数据科学家如何培养这些技能？

我的观点不是说一种工作取代了另一种。在这个环境中，你需要两者兼备。

如果你想培养这些技能，我会通过这个博客上的案例研究来介绍一种方法论：

关于我

在LinkedIn和Twitter上与我联系；我是一名供应链工程师，使用数据分析来改善物流运营并降低成本。

作者

Samir Saci

查看更多来自Samir Saci的文章

分享本文

• 在Facebook上分享
• 在LinkedIn上分享
• 在X上分享

Towards Data Science是一个社区出版物。提交你的见解，触及我们的全球受众，并通过TDS作者支付计划获得收益。