百丽十二年数智化复盘：先把企业工程化，再让AI 读懂它丨2026 ITValue Summit 前瞻：AI系统落地系列直播③

在所有人都在谈论大模型参数、算力集群和智能体（Agent）的时候，百丽时尚集团副总裁、科技中心总经理季燕利写了一篇数万字的长文（《百丽时尚：企业 AI 应用建设落地实践——从协同在线到 AI 原生》），里面几乎没出现这些热词。

这不是故作清高，也不是不懂技术。百丽自己买了近二十张A800和A100，系统里跑着四十多种模型，每周消耗的Token超过三百亿——这些数字他都有，只是从不拿它们当成绩。在他看来，模型和算力只是底座，真正值得花十二年去做的，是另一件事：先把自己工程化，再让AI读懂企业。

百丽时尚集团做的是鞋服行业，在300多个城市拥有近8000家直营门店。“品牌+直营”的模式，让百丽对系统的要求与只做加盟的品牌完全不在一个量级。2014年，百丽开始自建业务ERP系统；2020年，启动数字化体系建设；2023年，正式进入智能化阶段。十二年过去，季燕利把这段历程概括为一句话：信息化是采集，数字化是治理，智能化是应用。 没有第一层，就不可能有第二层；没有前两层的积累，第三层更是空中楼阁。

这个逻辑听起来朴素，甚至有些“反潮流”。当整个行业都在追逐“AI原生”的时候，百丽选择了一条更笨的路：先把业务在线化，再把判断标准化，最后让标准连成网络。季燕利管这叫“四个在线”，而第一步"业务在线化"，在百丽被拆得更细：业务、沟通、组织、权限，四个都要在线并串联起来，季燕利管这叫“协同在线”。而承载这一切的，不是某个炫酷的AI界面，而是每个员工每天都在用的工作群。

补货、审批、销售跟进、任务分解……这些原本要在复杂系统界面里反复找配置、查权限的操作，被百丽做成了H5卡片，直接发在群里。员工打开卡片，系统就知道他是谁、管哪个地区、有什么权限，填完数字自动流转。业务人员几乎无感地从“打开系统操作”变成了“在群里点开通知操作”。季燕利说，对ToB大型企业来说，AI不是在界面上的AI，而是群里的AI。

这场对话，我们聊的正是这套工程化体系是如何一点点长出来的。从门店店长的一天如何被重构，到“本体”和“FDE”到底在真实业务里意味着什么；从为什么能诊断出“虚假繁荣”，到AI的决策和人的决策发生冲突时该怎么办。季燕利的回答里没有太多宏大叙事，更多的是一个干了十几年IT、又做过业务的人，对”智能化到底该怎么落地”的务实思考。

在钛媒体2026 ITValue Summit前瞻之AI系统落地系列直播中，钛媒体集团联合创始人刘湘明与百丽时尚集团副总裁、科技中心总经理季燕利围绕企业AI系统落地的痛点话题展开了讨论。

以下为对话实录。

十二年，从 信息化到 数字化到 智能化

刘湘明：百丽智能化建设的历程是怎样的？

季燕利：百丽时尚集团做的是鞋服行业，跟很多同行最大的区别在于我们是“品牌+直营”模式，在 300 多个城市拥有近 8000 家直营门店。直营对系统的要求，和只做加盟完全是两个量级。

2014 年我们开始自建业务ERP系统，2020 年开始做数字化体系，2023 年开始做智能化体系，到现在已经接近 12 年了。智能化是一个持续建设的过程，我们一直强调，这不是项目叠加，而是工程化的一套体系。

我们的逻辑是三层递进的：信息化是采集，数字化是治理，智能化是应用。没有信息化，数字化就不可能；没有信息化和数字化，智能化也不可能。

当年推动数字化，其实是为了解决信息化阶段的一个核心痛点。因为我们的系统是自研的，业务用着用着就觉得“不好使”。

“不好使”的原因，每个做自研系统的企业都会遇到，主要来自两方面：一是规模膨胀带来的配置复杂化。公司越做越大，不同部门对系统的操作规则各不相同，系统要承接这么多规则，配置就越来越臃肿；二是系统叠加带来的操作门槛升高。同一个流程上叠了无数个部门的规则，操作人员不仅要理解部门之间的关系，还得去不同的系统里查配置、找入口。

所以业务说系统不好使，往往不是流程本身出了问题，而是"配置选择、找准确数据、找操作点"这些体验层面的问题。

刘湘明：怎么用工作群来解决信息化这套难题？

季燕利：拿补货举例。补货在鞋服行业是高频操作，每周一次，补货人员分布在各个城市，体系庞大。

原来的流程是总部用邮件发布开放款，每个人看邮件的时间不一样，打开系统的时间不一样，操作节点也不一样。

后来我们改成在群里通知，同时把消息做成H5卡片。员工打开这个卡片，系统就知道是谁、管哪个地区、什么职位、有什么权限。员工不用再去做配置，直接填数量、下补货单，填完卡片自动流转给你的上级审批，再汇总到总部。

一个群解决了什么？解决了原来系统界面里配置多、找不准的问题。业务人员无感地就从“打开界面操作”变成了“在群里打开通知操作”，操作完数据自动回到总部。我们后面又把销售跟进数据也做进来，销售业绩在群里也能体现。

这么做有几个好处。第一，把线下业务线上化；第二，API 接口标准化，为后面搭建AI 体系打好了基础。 工作群在数字化时代是载体，到智能化时代这个载体越来越突出。对 ToB 大型企业来说，你的 AI 不是在界面上的 AI，而是群里的 AI。

刘湘明：过去哪些工作是有用的，哪些是弯路？

季燕利：我们整个过程不是设计出来的，而是为了解决一个个具体问题，一步步迭代出来的。

做数字化，核心点除了刚才说的这套体系，还有把分散的数据集中到数仓里。这是一个大工程，本质上也是一次数据治理的过程。

要说弯路，我们真没走太多，只是建设周期拉得比较长，因为一直在解决过去积累下来的问题。具体手段上，用 H5 解决界面问题，用数仓解决数据标准不统一的问题，都是一点点迭代出来的，不是设计出来的。

还有一点很关键：我们是站在企业整体的角度思考，而不是站在某个部门。信息化系统往往是按部门流程建的，最大的问题是断点，部门与部门之间靠开会、打电话沟通。而数字化是建立在企业整体运营体系之上的，这正是数字化和信息化最大的区别。

到了智能化阶段，恰恰是去应用这套体系。因为有了标准化的数据、标准化的流程，AI 应用起来才更容易。

刘湘明：为什么文章里几乎不提模型和算力这两个热词？

季燕利：我们认为模型和算力是底座。

企业首先应该谈的是业务如何运营、如何管理。你把业务标准化，把数据标准化、统一化，体系做出来之后，模型和算力其实只是底座。

这不是说我们不做底座。我们从2023年就在做，不同场景、不同业务流用的是不同的模型。算力也一样，我们自己买了接近20张A800 和 A100，还有A40。

我们每周消耗的Token大概300多亿，每周花销约 7 万元人民币，其中一半是 IT 在用，另一半是业务在消耗。

刘湘明：你文章里说“别人忙着让AI读懂企业的混乱，我们先把自己工程化”。企业缺三样东西，业务没在线、判断没标准、判断连不成网。你们是在哪个场景第一次意识到这个问题？

季燕利：在信息化阶段就有这个问题。业务没在线，谁怎么操作界面你不知道；判断没标准，怎么判断业务对错你不知道，大家靠开会沟通。

还是回到补货场景。当时投诉量很大，我把各地区的货品操作人员拉进一个群，把他们的改进意见也放进去，让大家自己互相解释、互相看哪个是共性问题。

结果发现，80%提“系统不好使”的其实是个性化问题，不是系统本身不好使；剩下20%里，有一半是权限问题；真正说系统功能没做好的只有10%。

在线化以后，基本上就没人再提“系统不好使”了。即使偶尔有人这么说，群里大部分人也会告诉他：“你的操作方式不对。”

因为IT人员也在群里，哪个功能到底好不好使，我们自己就知道，不需要等业务人员再提。个性化的问题慢慢统一，标准也就慢慢形成了。

网络也是这样。原来谁在什么时间做了什么动作，大家都不知道；现在通过H5，任何一个动作都有记录。比如补货单，原来周一下发、周三收，后来变成周二就能收。因为大家都能看到彼此的下单时间，就会有人说：“你凭什么周二晚上才下？”大家互相看得见，就一起把节奏往前推。谁的订货准确度高、谁的效率高，全群都能看见。

这种网络化不是AI做出来的，而是工作群本身就已经把前面这些问题解决了。

刘湘明：流程已经这么顺了，AI还能做什么？

季燕利：AI能做的是把最后的动作也省掉。

原来我还需要打开H5、自己去下单，以后可以让AI直接帮我把这个任务完成。

刘湘明：能不能用一个门店店长的日常，讲讲“四个在线”如何运转？

季燕利：我们门店每天都有工作任务安排，早上店长到店后，就会查看昨日销售额、月度累计销售额，以及当前距离任务目标还差多少，这些数据都是实时在线的，在工作群里都能找到——这就是“业务在线”。

如果店长查看后发现需要追赶任务进度，就会重新做任务分解，所有操作直接在线上卡片里就能完成。做好任务分解的卡片，可以直接发到主管群或者门店群，两个群是互通互联的。

主管群能查看相关内容，这就实现了“组织在线”，能清晰明确你的直属上级是谁。不同层级能查看对应权限的数据，也就是“权限在线”，比如你是S级店长，可以查看同级别门店的数据，但无法查看其他城市所有门店的数据。

“沟通在线”就更好理解了：任务下发后，如果主管觉得你制定的任务目标太激进，直接在卡片底部的备注栏标注即可，不用专门打电话沟通；门店员工也可以在群里反馈任务分配是否合理。到约定的时间点店长会上报进度，截至当日中午12点的任务完成情况，发到群里后，主管群和门店群都能同步看到。

这套体系在门店运营中已经非常成熟完善。过去主管想要和店长沟通，得先打电话再查数据，现在只要通过自己的权限打开那张H5卡片，所有信息一目了然，协同自然就能顺畅开展了。

刘湘明：店长效率提升后，释放出来的管理者时间流向了哪里？

季燕利：原来店长需要打开电脑查数，现在我们给店长开发了一款前端工具，可以直接查看数据；AI应用之后，直接就能查询数据，问一句“我今天卖了多少钱，任务完成得怎么样”，答案就能直接出来。

关键变化在于，原来是人找数，店长需要花精力思考“怎么找数”；现在找数的思考过程被释放了出来，店长可以把精力放到对具体业务的思考上，比如怎么卖货、怎么服务、怎么给店员做培训。因为店铺本身人员就不多，人效要求很高，以前他们要花很多时间在内部管理、查数这类非服务性工作上，现在这类工作的时间占比越来越低，一线人员可以把更多时间放在顾客服务上。

以前工作是满足上级的管理要求，现在是聚焦创造实际业务价值。

刘湘明：门店达成率很高，数字很漂亮，为什么还能诊断出是“虚假繁荣”？

季燕利：首先我们是大型组织，不是小型门店。门店本身有业绩任务压力，在追逐任务达成的过程中，很容易产生逐短期利益的冲动，靠做促销、赶活动来冲业绩完成任务。但站在全盘来看，选什么货、满足什么要求、怎么做才规范合理、如何统筹整体规划，单店是很难做到这点的。

总部的货品总控人员确实更容易统筹把控，但他们也存在局限：这么多门店都在开展业绩冲刺，人的精力和视野都是有限的，没办法覆盖管控到每一家门店。当门店为了冲业绩参加活动，短期把某一类商品的销量做上去了，反而会造成商品结构性失衡。短期来看业绩数据确实很好看，但如果没能及时发现这次促销带来的商品结构问题，后续货品结构的合理性就再也调整不回来了。

这其实是任何经营模式都会遇到的短期利益和长期发展的矛盾：短期看着发展向好，如果没能及时发现短期增长带来的结构性问题，后期调整又跟不上，长期发展就一定会出问题。

（编者补注：他在文章里给出过这一步的做法：一个门店 600 多个指标和维度让AI跑一遍，主导链是商品结构长尾，放大链是月底深度打折，因果作用的周期和强度都标出来。传统模式下缺的不是时间，是触发点——达成率好看，报表上没有任何东西提示你该去查，只能等下一季订货或者季尾清货被动暴露，中间隔一个季度到半年。现在它在当期就能被看到。）

刘湘明：“本体是给业务节点造一个数字孪生”。在你看来，本体到底是什么？

季燕利 ：本体说白了就是，明确你要研究的对象是什么，你的具体业务是什么。一家门店是一个本体，这家门店的销售是一个本体，某一件商品也是一个本体。本体本身会关联很多内容，但核心逻辑是：在某个具体时间点处理某件具体事务时，我们要分析的核心主体是什么。

那为什么本体很重要？因为AI的底层是0和1，它没办法用人类的思维方式思考。人类已经自带这套主体认知和逻辑框架了，但AI没有。你要让AI理解我们现实中要解决的问题，就必须告诉它“哪个是核心主体”“主体和主体之间是什么关系”。而主体之间的关系背后对应着具体行动，行动背后就是业务规则和业务策略。只有把这些关系完整梳理清楚提供给AI，AI才能在动态的业务流程中，找准这个时间点需要解决的问题，定位出核心主体。

所以构建本体，本质就是把我们日常的业务认知整理成一套AI能读懂的知识。我们把它归纳出六个操作维度，包括实体、事件、状态、时间、因果、动作等等，再把这些维度映射到实际数据上，如果只整理知识不做数据映射，AI没办法落地应用。本体最大的作用，就是把核心主体和它相关的各类主体连接起来。

刘湘明：FDE和我们原来谈的实施服务有什么不一样？

季燕利：本体和FDE（Forward Deployed Engineer，前沿部署工程师）都是智能化产物，最早由Palantir提出，核心目标都是让智能化落地到具体业务中运行。未来的软件必然要具备这项能力：传统软件更多围绕功能逻辑构建，而智能化围绕应用逻辑构建。我一直强调，智能化是“落地应用”，信息化核心是“数据采集”，数字化核心是“数据治理”，智能化必须和具体业务深度绑定。FDE这套体系，核心要求就是真正理解业务、支撑保障业务运行。

现在国内大多数软件公司是怎么做FDE的？大多是把原来派驻甲方的驻场工程师转岗做定制化开发，但团队思维还停留在传统信息化理念里，是从“软件应用”的角度解读FDE。而想要真正理解FDE，必须从业务运营的视角出发，从真实业务场景切入梳理业务流程、理解业务数据、理清对接系统逻辑、调试优化模型，让模型读懂真实业务，最终把业务操作抽象成AI可识别的逻辑，让AI能够自主完成具体业务操作。

这对软件公司提出了非常高的要求：不仅要理解单个企业的单一业务动作，还要把全链路业务流程梳理透彻。FDE远不是一件简单的工作，它要求从业者具备跨界能力：只懂软件远远不够，必须深度理解业务。所以我一直认为，当下市场里绝大多数软件公司、多数主流IT从业者，还是在用信息化的旧逻辑谈论智能化。我们本身是企业内部IT团队，一直服务于自身业务，所以我们的整套系统都是围绕业务逻辑、业务场景、业务规则搭建的，从业务主体出发构建，而非从软件功能出发。

刘湘明：你怎么看未来的企业软件？很多人都在看衰它们。

季燕利：走到智能化应用这套体系的阶段，如果不从业务本身出发去做智能化，只想靠着智能化解决数字化、信息化的问题，这条路是走不长远的，单点的功能无法解决整体的问题。想要搭建数据应用体系，必须先理解信息化和数字化的价值。没有数字化、信息化做基础，做上层应用也很难做起来。

刘湘明：你文中提到"请业务专家参与本体建设"，但强因果关系没法靠文档萃取读出来，实际推进中最大的阻力是什么？

季燕利 ：大部分企业有很多能干、业务水平出众的管理者，还有一部分面临整体抽象思维与逻辑思维能力挑战。这些管理者大多是解决具体任务、处理具体事务的经验型人才，能把自身实践经验提炼梳理成一套完整逻辑体系的人非常少，要让他们用计算机化的严谨逻辑梳理串联具体业务，难度非常高，核心原因就在于同时懂业务和逻辑梳理的跨界人才太少。

我们的解决方法，是让IT人员和业务专家协同配合：请业务专家梳理讲解自己处理业务的思考逻辑和实操方法，再由IT人员配合把这些内容萃取成标准化知识，萃取完成后再交还给业务专家校验确认。这个过程对双方的要求都很高，业务专家需要放下原有固有的惯性思维，而IT人员因为不掌握业务判断标准，只能在萃取完成后不断和业务专家沟通，请对方把控内容正误。

我们特别强调，业务专家需要离开业务现场，进驻到我们的IT团队，采用这种"反BP"的合作模式。不是IT人员下沉到业务一线，而是业务专家来到IT团队，不用处理具体业务，只需要调用自身过往经验梳理业务逻辑。人只要手上还压着具体业务，就一定会从这一块业务出发，而不是从整体出发。这件事对企业来说推进难度很高，多数企业高管往往很难理解这种模式的价值。但AI兴起之后，大家开始慢慢重视"知识是存储在个人脑中，还是沉淀在企业知识库中"这个课题。我相信未来，大部分企业领导者会逐步选择把个人经验从自身身上萃取出来，沉淀存放在企业知识库中。

刘湘明：AI时代，像店长、像你这样的管理者，应当如何适应变化，找准自身的全新价值？

季燕利 ：组织规模较大的时候，大家大量时间都用于开会协调，中层管理者的精力大多消耗在解决信息不对称、认知不一致的问题上。

AI到来之后，首先带来的改变是，你必须把自身的经验梳理成标准化的逻辑。如果依旧依靠感性经验解决问题，第一是浪费精力，更是对企业资源的浪费；第二，经验如果不沉淀为知识，就永远是飘忽不定的，企业也会始终在试错中摸索。

经验转化为标准，沉淀的标准越多，经营效率就越高，能够调动的资源也越多。而标准化建设本质就是知识库建设，内容越标准，知识库里沉淀的内容也就越丰富。因此对管理者来说，有两点核心要求：第一，培养逻辑性思维，不要再像过去那样依靠感性判断。第二，研究规则与结果之间的关联，过去管理者只管制定规则，现在要深入研究“用什么规则解决什么问题、会带来什么结果、什么样的规则效率更高”。因为现在规则运行已经实现线上化，也就是我们的工作群体系，过程的萃取、监督都已经清晰呈现，管理者只需要专注研究规则和结果的关系就可以。

另外还有一项非常现实的责任：结果永远需要有人承担。不管是AI还是自动化，都没办法承担结果责任，始终还是需要管理者来为最终结果负责。

刘湘明：企业不会选最聪明的AI，一定会选最可靠的AI。你们怎么实现可靠性？

季燕利：文章里已经写得很清楚。我们把企业业务结构化，梳理出了L1到L5这套层级逻辑，其中L1到L3是结果逻辑，L4、L5是过程逻辑。如果将AI部署在结果逻辑层，我们根本无法得知AI为什么得出这个判断、又是如何完成分析的。

而我们把AI部署在L4节点，L4本身就是最小决策单元。完成节点的AI化改造后，我们就能清晰看到AI在这个节点做出的每一步决策，以及对应L5输出的动作结果，AI的决策和后续动作之间的关系会完全透明化，一切都清晰可追溯。这种模式下AI的可靠性，远比部署在L1到L3结果层高得多。同时我们还可以根据最终结果反向调整L4节点的决策和L5的动作，通过持续迭代让AI的决策和动作越来越精准。整个过程不是黑盒，而是完全开放的白盒，一切都清晰可见。

但这套方案确实存在落地难点。第一，要把企业所有业务流程梳理成L1到L5的层级，本身就是一项大工程；第二，明确每个节点的定义和边界，又是一项工程；而每个节点要解决的核心问题，本质就是本体工程，这也是我们将本体放在L4层的原因。等L1到L5梳理完成之后，再去构建本体、训练AI，其实流程并不复杂，最复杂的反而是前期的梳理工程。

刘湘明：整个AI工程里，哪个环节的难度最被你低估了？

季燕利：我们在2021年就做过“品牌大脑”项目，那时很多当下的AI技术还没有诞生。当时我们最早是沿着算法、模型的方向推进研究，但在过程中发现了两个问题。

第一，数据量不足。你越深入研究就越会发现，想要让数字世界理解现实世界，不仅整体数据量不够，数据的精细程度也达不到要求。第二，我最早是业务出身，原本觉得“判断”这件事并不难，但想要让我做判断的逻辑被AI执行，才慢慢发现这真的是一项复杂工程：你需要把自身的思维逻辑、项目经验拆解成计算机能识别的规则，让计算机或者AI能够理解，再对应映射到现实世界的具体场景，这绝对不是一件简单的事。

我们当时原本计划用三年完成品牌大脑项目，到现在已经做了5、6年，还仍然处在起步阶段。

刘湘明：品牌大脑达到什么理想状态，你才觉得项目基本完成了？

季燕利 ：品牌的日常运营由多个部门、多个组织协作完成，每个组织会在不同时间节点做出不同判断，加之不同从业者的能力水平、判断经验各有差异，运营效率实际上会受组织能力的制约。

品牌大脑的作用，是把经营过程中所有问题、所有需要处理的节点，梳理成一套完整的体系、统一的逻辑，让AI从全局视角完成连接、解决问题。最终要实现的目标是：当任意一个环节出现问题时，它能够准确判断该问题对其他环节、对品牌整体运营会产生哪些影响。我们当年开发品牌大脑，就是奔着这个目标去的。

刘湘明：有没有出现过AI的意见和一线的意见相悖的情况？怎么处理这种冲突？

季燕利：同样一件事，不同的人得出的判断结论都会不一样，这是很正常的情况。AI得出的结论也会和部分人的意见产生冲突，这是必然会发生的。其实解决起来很简单，核心在于你所在组织的权限设置，决策权到底是交给人，还是交给AI。

人和人之间产生分歧，组织内部就会产生内耗，需要开会讨论、互相争论、各方妥协，最终才能达成一致。AI参与决策后，同样会面临这个问题。所以最终一定要有明确的负责人来承担决策后果，无论是决策来自人还是来自AI，这点是必然的。

第二点，你长期修正AI决策的过程，本身就是训练AI的过程。训练得越久，AI对业务的理解深度就越深。而AI最大的优势就是具备长期记忆，人在不同事务上积累的经验始终有限，AI的决策只要沉淀到一定程度，质量一定会超越人的决策，这也是必然的。到那个时候，决策就会逐步以AI的结论为准，因为AI考虑问题的全面性本身就超越人类。

刘湘明：有网友留言表示“AI还是应该多在产品创新上发力，在组织管理和流程上折腾没多大意义”，你对此怎么看？

季燕利：这个问题一定要把ToC和ToB场景区分开讨论。在ToC的逻辑里，AI确实应当侧重在产品创新上发力，站在用户个人角度来看必然是这样。

但在ToB场景中，最核心的问题在于：产品创新从来不是个体行为，一定是依托企业完成的创新。对企业而言，最终的产品创新不是某一个孤立的单点成果，而是企业方方面面能力整合输出的一套完整体系，而这套整合工作，原本就是依靠组织间的管理与协同实现的。所以我们才会说，要先解决组织问题，而非先解决创新问题。如果组织间的协同体系搭建完善，组织层面的创新会自然发生，随之而来的产品创新也水到渠成。

反过来，如果连组织协同问题都没解决，一上来就先做单一的产品创新，想要提升大规模企业的整体效率，难度已经非常大。放到现在来看，指望靠单点技术创新拉动整个大规模企业的发展，同样很难实现。

任务、 Agent、Skill 和中台： 判断如何被办成， 底座怎么拆出来

刘湘明：在AI时代，你考核供应商的标准发生了哪些改变？

季燕利：首先我们要把供应商分清楚，分为IT供应商和业务供应商两类。

针对IT供应商，我们的思路其实很简单，首先就是秉持合作共赢的理念来看待合作。现在IT领域技术迭代和人才更新的速度越来越快，仅靠企业内部的IT团队很难跟上节奏，如果不敞开门，和在细分领域足够专业的公司合作，我们很难做好这件事。反过来，那些在细分领域深耕的专业公司，来到我们这类有一定规模的综合性企业，我们目前有300多个系统在运行，对他们而言也是很好的技术落地场景，因此大部分供应商都愿意和我们合作。AI时代一定离不开合作，只靠单一资源、单一能力很难跟上技术发展的脚步。

第二点是边界问题。传统IT思维里边界感非常强，一定要先划分清楚“各自负责什么”才会推进工作，IT人员也很少会主动去理解业务逻辑。但到了AI时代，如果还等着业务人员把规则讲清楚再落地开发，那供应商也就没有存在的必要了，只要业务能把规则说清楚，AI自己就可以完成系统搭建。

所以现在更看重打破边界的跨界能力，IT人员要主动去理解业务、理解规则，明白什么样的规则会产出什么样的结果。供应商之间也是一样，必须打破边界，哪怕你的技术再专精，最终还是要落地到应用场景，而应用从来不是靠单一技术就能实现的，一定是多种技术组合起来，才能满足业务场景的需求。因此一定要打破边界，用全局思维思考问题。

刘湘明：从上次参观时你们展示的单点Agent，到如今能够完成长程复杂任务、真正形成实际生产力，这中间最难实现的技术突破点是什么？

季燕利：我们从2023年底就开始搭建Agent体系，最初做的是单点Agent，但Agent之间的协同合作问题一直没能得到解决。从去年年底到今年年初MCP这套体系推出后，正好帮我们解决了这个问题，因此我们今年又重新启动了自有Agent的开发工作。

在开发Agent的过程中，我们发现Agent首先需要理解“具体要完成什么任务”，明确需求后再调用Skill执行任务。原来Agent调用任务采用的是写死的自动化逻辑，现在改为Agent调用Skill，而Skill本身就是一套任务编排体系。我们只需要把企业内部这类编排的基础逻辑梳理清楚，让所有Agent都能理解规则，原来多Agent之间的匹配、协同问题就迎刃而解了。

我们之所以能在MCP推出后，快速搭建出Skill体系和IT工作台，主要有三个原因：

第一，我们已经通过工作群实现了业务在线化；

第二，在开发Agent阶段就已经完成了自动化搭建，由Agent调用自动化完成业务流程；

第三，MCP推出后，原本的自动化被梳理成了任务体系，解决了任务编排的问题；而任务编排后续环节对接的，正好是我们之前开发H5时梳理完成的API接口。什么任务对应什么样的编排逻辑、每个任务包含哪些执行步骤、每个步骤调用哪一个API接口，“任务-Agent-Skill-API”完整的逻辑链路就是这样。

（编者注：对话结束后，季燕利又补了一句这套体系和市面上"AI助手"的区别：工作台是建在工作群这套体系之上的，把原本各管一段的部门连在了一起；而单系统的AI助手只在自己那个系统的边界里，"一件事跨到第二个系统就断了"。在企业里，AI的作用是完成一件事，而不是为个人提效。）

刘湘明：你们目前系统里一共开发了多少个Skill？

季燕利 ：现在一共有230个。而且这230个都偏底层，是用于明确“Skill完成某个编排需要调用哪些技术底层逻辑”的Skill。面向业务场景的Skill，也就是“订单分配给Agent后，Agent完成订单处理时需要调用哪个Skill来执行”这类Skill我们还没做多少，目前才刚刚开始推进。前期我们做的主要是偏底层的、供上层Skill调用的基础Skill。

刘湘明：你是怎么看业务中台在你们这套系统里面发挥的作用？

季燕利 ：业务中台这个逻辑，2018 年的时候在国内很火。但做中台的逻辑，基本都是从 IT 的角度、从系统的角度去做。而中台本身，应该是从业务角度去做的。用 IT 的逻辑做中台，基本上没有成功的；我们做中台，用的是业务的逻辑。

用业务逻辑做中台，第一步还是用工作群，把业务的操作过程细化。再用 H5 去承接这个细化的操作过程，具体要干什么，用 H5 卡片承接；哪个操作过程、哪个操作需要哪些功能，H5 对接 API 接口来完成操作。在这个过程中，我们就逐渐沉淀出来：业务在应用过程中怎么拆系统、怎么拆微服务、怎么拆原子化。

这几年，我们的业务中台不是一年建成的，从2020年做到现在，只做到 80% 多、接近 90%，还没有完全做完。因为拆的过程不是一蹴而就的：先通过群的建设去理解业务的预操作、这个动作，然后才能拆出 H5；再从 H5 去看、再去拆中台。这样拆出来的中台，非常实用。

第二，它确实支撑了 AI 的应用，AI 应用也是在完成业务动作，所以它支撑了 AI。举个例子，我们现在做订单中心。以前我们的订单是分散的，分散在不同领域里，比如电商、线下门店、私域等等，各自是不同的规则。现在统一到一套规则里头，把订单中心作为统一标准化的规则，把它原子化，做成订单中心这套体系。而订单中心的逻辑，一定是根据业务场景做出来的——它不是我把系统拆出来的，是根据业务场景做出来的；它的拆法也是按业务场景、按全业务的逻辑去拆的，不是按系统逻辑拆的。

当然，订单中心的建设不是孤立的，它一定要和商品中心、库存中心、券中心、结算中心等等这些中心协同建设。因为订单最终要算账，它一定跟结算中心相连；你要做库存分析，就跟库存中心相连。这些其实是一体化的建设，不是简单的单一系统功能建设。（本文首发于钛媒体APP，文 | 智客Zhiker，作者｜郭虹妘，编辑｜盖虹达）

点击延伸阅读：季燕利专栏文章