安踏 × 火山引擎：三个 Agent 跑进全球电商，把「能回答」变成「能交差」

背景：一次大赛之后留下来的三个 Agent

企业智能体项目最常见的结局是停在演示环节：一场黑客松做出几十个原型，评审结束，代码留在仓库里。安踏这次的特殊之处在于，三个 Agent 都穿过了从原型到生产系统的那段路，其中一个已经进入企业生产系统并有了月度运行量。

路径本身不复杂。据中国商报网等报道，这些 Agent 来自一线业务的真实需求：业务团队通过火山杯智能体创新大赛提出问题，由 FDE（前向部署工程师）协助拆解流程与开发调试，再借助火山引擎的模型与智能体能力，把 Agent 放回实际工作中验证。安踏全球 IT 交付与支持部总监吴永良给出的判断标准也相当务实：判断一个智能体是否真正进入生产，不是看它回答得多聪明，而是看它能否替代完整流程中的某一环节——过去 AI 回答一个问题，未来 AI 完成一件事情，智能体竞争的终点不是聊天，而是工作流。

这句话可以被当作整篇复盘的主线。下面三个场景讲的都不是「模型说了什么」，而是「哪一段原本要人做的搬运被接走了」。

三个场景，三段被补上的断点

先把三个场景的结构摆在一起看，它们的形状高度相似。

场景	原本的断点在哪里	智能体接走的是哪一段	公开效果	成熟度
海外订货	每次订货处理四套模板，底层数据约 90% 重合，但货号、品类、翻译、公式与格式需人工逐项处理	用 ArkClaw 把四套模板封装成 Skill，自动完成货号转换、品类筛选、格式对齐	完整下单决策由半天缩短至 10 至 20 分钟；手工录入减少约 90%；准确率超过 99%	已覆盖鞋、服两条产品线
跨境退货	平台退货信息不能直接回到安踏系统，客服需把信息搬到 ERP 建退货单并逐单跟进	自动抓取平台退货数据，按 ERP 模板生成单据，并定期汇总状态与提示	TikTok 跨境业务每月自动创建超 1000 张退货单；人工建单与逐单跟进显著减少	已进入企业生产系统
带货视频	找热点、拆视频、生成提示词、发布到不同站点，多环节依赖人工重复操作	ArkClaw 采集热点与对标视频并完成拆解与提示词生成，Seedance 2.0 生成商品短片，衔接多站点发布	实习新人借助后半天即可独立产出合格视频；同等 token 消耗下每天多产约 15 条	东南亚电商业务在用

三点结构上的共性值得单独指出。其一，三者的价值都来自流程而非生成——订货看的是格式与公式对不对，退货看的是单据建得准不准，视频才是三者当中以生成为主的那个场景，而它给出的指标也刻意避开了「质量更好」，只说新人能上手与每天多产多少条。其二，三者都跨了至少两个系统：订货跨模板与品类体系，退货跨平台与 ERP，视频跨采集与多站点发布。其三，三者的输出都是可核验的——对不对、准不准、能不能用，业务人员一眼能判断，这正是可以放权的前提。

订货 Agent：90% 的重合与那 10% 的差异

海外订货这个场景的细节最值得拆。安踏国际事业部每次订货要处理四套不同模板，据商品规划人员王洁仪在报道中的说明，四套模板的底层数据约 90% 重合，但货号、品类、翻译、公式和格式仍需人工逐项处理。

这里藏着一个容易被忽略的判断：模板之间 90% 的数据重合，并不等于可以合并成一套模板。剩下的 10%——货号的编码规则、品类的划分口径、不同市场的翻译、公式与格式的差异——恰恰是这份工作真正的成本所在，也是它之所以没有被自动化掉的原因。把重合的 90% 自动化没有意义，因为那部分本来就可以用脚本处理；真正的门槛是那 10% 里隐含的业务规则。

安踏的解法是把这 10% 的规则显性化：用 ArkClaw 把四套模板封装成 Skill，让货号转换、品类筛选与格式对齐成为可被智能体调用的标准化能力。这一步的实质是把资深员工的隐性经验写成可执行的规则资产，而不是让模型去猜。报道中提到「商品规划中的 Excel 重复操作很多，技术方案可以复用」，指的正是这部分规则一旦被写成 Skill，就可以跨模板复用。

效果数字之外，有两个细节更能说明落地程度：这套 Agent 已覆盖鞋、服两条产品线，说明规则抽象到了能跨品类的程度；后续计划用于产品线规划、竞品价格带分析等场景，说明它的定位不是单点工具，而是在往规划侧延伸。不过这两个计划都属于规划表述，尚无交付时点。

退货 Agent：跨系统断点才是真场景

跨境退货是三个场景里最典型的一段「系统之间没有桥」的问题。电商平台上发生了退货，但这条信息不会自己回到安踏的系统；客服需要人工把它搬到 ERP 里创建退货单，之后还要逐单跟进状态。退货量一大，这段搬运就变成大量跨系统重复操作。

智能体接走的是完整的三段：从电商平台抓取退货数据、按 ERP 模板生成单据、定期汇总状态并提示。注意这里的第二段——按 ERP 模板生成单据，意味着它不是简单地转发信息，而是要做一次结构转换，与订货场景里的模板转换是同一类问题。

这个案例最有价值的信息其实是它的运行状态：已进入企业生产系统，在安踏品牌的 TikTok 跨境业务中每月自动创建超 1000 张退货单。这是三个场景里仅有的给出月度运行量的一个，也是其中明确进入生产系统的那个。对判断一个智能体项目是否真的落地，这类运行量数字比任何效率百分比都更有说服力。

内容 Agent：把产出量与 token 解耦

带货视频场景的链条是三段式：ArkClaw 采集热点与对标视频并完成拆解与提示词生成，Seedance 2.0 生成商品短片，再衔接多站点发布。东南亚电商部短视频运营李晗在报道中提到，东南亚站点每天上新商品特别多，人工剪辑完全跟不上备货节奏。

效果给了两个指标：实习新人借助后半天即可独立产出合格视频；同等 token 消耗下每天还能多产出约 15 条。后一个指标的表述方式值得留意——它把产出增量挂在「同等 token 消耗」这个前提下，而不是只说「效率提升三倍」。这说明在内容生成类场景里，成本已经被当作与产出并列的约束条件写进了评估口径，这在企业智能体落地中是一个比较成熟的信号。

同时也应注意到，这个场景是三者中效果最难客观衡量的：「合格的带货视频」没有公开的判定标准，「每天多产 15 条」的基线也未说明。合理读法是把它当作方向性指标，而不是可复用的 ROI 数字。

三笔账的读法

三笔账放在一起，各自的口径强度并不一样，需要分开看。

数字	可反推的含义	口径强度	建议补充什么
下单决策：半天 → 10 至 20 分钟	按半天计 4 小时，压缩幅度约 12 至 24 倍	中：区间表述、基线明确，但未说明是单次订货还是一批	每次订货的模板数量与 SKU 量级
手工录入减少约 90%	剩余 10% 大概率是异常与例外处理	中：比例清晰，但「录入」的计数字段未定义	以字段数还是以操作次数计
数据准确率超过 99%	按每月千余张单据量级，意味着每月个位数错误	中：未说明核验方式与核验覆盖率	是全量复核还是抽样，错误如何被发现
每月自动创建超 1000 张退货单	按月均 22 个工作日计，约每日 45 张以上	较强：有明确运行量与时间单位	该业务的退货总量，以便算出覆盖率
同等 token 下每天多产约 15 条视频	产出增量，但基线未给	弱：无基线、无质量判定标准	原人工日均产量与合格判定标准

需要说明的是，上述所有数字均来自报道中的企业方陈述，未见第三方审计或独立核验，具体效果可能因业务场景而异。相关智能体的可用范围、接入方式与功能细节，应以安踏与火山引擎官方的当前信息为准。这不影响它们作为落地路径样本的参考价值，但影响它们作为 ROI 基准的可迁移性。

另外一个缺失的口径是成本侧。三笔账都只给了效率与产出，没有给运行成本，也没有给投入工时。对想复用这条路径的团队来说，最需要的恰恰是这一栏：一个场景从提出到进入生产，需要多少 FDE 人天、多少业务人员配合、运行起来每月多少 token 与调用费用。这部分目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。

组织机制：业务出题、FDE 拆解、业务验收

如果只能从这个案例里带走一样东西，值得带走的不是那三个 Agent，而是把它们送进生产的这套机制。它有三段。

业务出题，而不是 IT 出题。三个场景都来自一线：商品规划团队的模板搬运、客服的退货单搬运、短视频运营的剪辑压力。这些痛点的共同特征是当事人说得出「哪一步最烦」，而 IT 部门通常说不出。用大赛作为收集机制的好处是它给了一线一个正式的表达通道，坏处是原型质量参差，需要下游有能力筛。

FDE 拆解，而不是交给供应商做需求。FDE 这个角色的价值在于他既懂技术又能坐在业务旁边把流程拆开。报道中明确写了 FDE 协助拆解流程与开发调试——注意顺序：先拆流程，再开发调试。这与「先把需求写成文档再外包」的传统路径相反，也正是原型能活下来的关键。

业务验收，而不是技术验收。三个 Agent 的效果指标全部是业务口径：下单决策时间、退货单数量、每天多产几条视频。没有一项是模型侧的准确率或召回率。这决定了验收权在业务手里，也就决定了它不会因为「技术指标达标但没人用」而停在半路。

这套三段机制还有一个隐含优点：它天然带有筛选功能。规则写不清楚的流程，在 FDE 拆解那一步就会卡住；业务不认的场景，在验收那一步就会被淘汰。安踏能留下三个，说明前面被筛掉的应该更多——报道未披露这个数字，但从机制设计上看，高淘汰率是它正常工作的表现，而不是失败的证据。

三个指标：人、流程、区域

吴永良在报道中给出了三个衡量智能体建设进展的指标，这个框架本身比具体数字更可迁移。

维度	指标	衡量的是什么	为什么比 ROI 更早可用
人的维度	有多少业务每天离不开智能体	依赖度，而非使用率	使用率可以靠行政手段推高，离不开不能
流程维度	有多少业务流程已默认智能体参与	流程重构程度	只有流程改了，效率收益才不会抵消在返工里
区域维度	有多少智能体开始跨国家复制	可复用性	复制是验证抽象层次是否足够高的硬指标

把这三个指标套回本案例，可以给出一个更清醒的进度判断：在人的维度上，三个场景的相关岗位已经形成依赖；在流程维度上，退货场景明确「已进入生产系统」，说明流程已改；在区域维度上，报道提到东南亚电商与 TikTok 跨境业务，且退货流程计划开放给斐乐及其他品牌的 TikTok 团队——跨品牌复制刚刚起步，跨国家复制尚未见到公开数据。换句话说，这套建设目前处于前两个指标有进展、第三个指标刚开始的阶段。

这也提示了一个容易被误读的地方：多品牌集团做智能体，跨品牌复制的难度往往大于跨国家复制。斐乐与安踏的商品结构、ERP 模板、目标市场语种都可能不同，退货流程要复用，很可能要重做模板映射那一层。报道只说「下一步计划开放」,未给出时间表，宜按规划而非既成事实来读。

六步打法与三条红线

把上述内容抽象成可迁移的打法，大致是六步。

步骤一，找跨系统断点，而不是找可以被自动化的岗位。三个场景全部是「A 系统的信息到不了 B 系统」。这类断点的特征是：当事人每天在做、说得出步骤、做错了能被发现。它比「做一个客服智能体」这种按职能划分的起点更容易落地。

第二步，把差异部分的规则显性化。订货场景里那 10% 的差异是价值所在。做之前先问：这段流程的规则能不能写成明确的映射表？写不出来的，说明流程本身还没理顺，先理流程再做智能体。

第三步，用大赛或类似机制收集一线诉求。关键是给一线正式的表达通道，并允许他们提出「这一段最烦」这种颗粒度的诉求，而不是要求他们写需求文档。

第四步，用 FDE 做流程拆解。先把流程拆成步骤、判断与例外，再谈开发。拆完如果发现规则不足，回到第二步。

第五步，用业务口径验收。指标要落在时间、数量、准确率这些业务人员自己会算的数上，不要落在模型指标上。

第六步，单点跑稳后再复制。安踏的顺序是先安踏品牌的 TikTok 业务，再谈斐乐。复制时优先复用规则资产（Skill、模板映射），而不是复用代码。

三条红线：

• 写操作保留人工确认。退货单据与 ERP 写入都属于对外或对内产生实际后果的动作，自动化的应当是生成与汇总，最终的确认环节应保留在业务侧。报道中提到的准确率超过 99%，其核验方式未披露，更说明这一步不能省。
• 规则不清的流程不要先做智能体。如果一段流程连当事人都说不清规则，那么模型只会把混乱固化下来，并且难以排查。
• 不要把效率数字直接当 ROI。本案例的三笔账都缺成本栏，也缺投入工时栏。在补齐这两栏之前，任何「提效多少倍」的说法都不能进入财务口径。

局限与冷静判断

• 全部数字为企业方陈述：效率、准确率与产出数据均来自报道中的企业方口径，未见第三方审计或独立核验，效果可能因业务场景而异。
• 成本栏缺失：三笔账都没有给出运行成本与投入工时，无法计算投入产出比，只能作为效率改善的方向性参考。
• 基线口径不完整：「半天」是否等于四个小时、下单决策是单次还是批量、「合格视频」的判定标准，报道均未说明。
• 退货单量缺覆盖率：每月 1000 余张是绝对量，但不知道占该业务退货总量的比例，无法判断智能体承担了多大比重。
• 跨品牌复制仍属计划：斐乐及其他品牌的开放是下一步安排，未见时间表，且不同品牌的商品结构与模板映射差异可能构成实质门槛。
• 供应商视角的信息不对称：本案例的主要信源与火山引擎的技术能力展示相关，未能看到独立第三方对同一项目的观察。
• 可迁移性受行业约束：这三个场景都具备「规则可写清、结果可核验、量大、出错代价可控」的特征。对规则模糊、结果需要主观判断或出错代价高的流程，这条路径未必适用。

总体来看，这个案例的价值不在于数字有多亮眼，而在于它把一个完整路径跑通了：从一线提出「这段最烦」，到 FDE 把它拆成可执行的规则，到业务用它自己的口径验收，再到有月度运行量地待在生产系统里。这条路径没有依赖模型能力的突破，依赖的是选场景的克制与拆流程的耐心——三个场景都选在跨系统搬运这种不性感但规则清晰的地方，这恰恰是它们能活下来的原因。对正在推进智能体落地的团队，可复制的是这条路径与那三个指标，而不是那三笔账。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。