家装行业的信息化建设长期面临一个现实难题：订单分散在B2B、DMS、OMS、C2F等平台，财务数据沉淀于SAP，各系统之间缺乏贯通桥梁。商派ShopeX针对这一场景提出了"AI智能体层"建设方案，核心思路被其称为"AI外骨骼架构"——对既有的八套业务系统不动一行原有代码，在其上叠加一层AI能力层，让问数、预警、报表、技能等以往必须依靠大量二次开发才能实现的功能，直接从这层生长出来。
该方案的落地对象是一家知名家装品牌。商派方面引述的一项判断是："这些系统该有的都有了，换是换不动的。要的是上面有一层 Agent 来桥接。"
四重压力倒逼架构改造
该家装企业面临的困境首先是人力问题。订单部门在微信端以人工方式响应对接渠道与合作角色的日常询问，同一问题存在几十种不同问法，口径难以统一，问答类需求占到全部90项需求的三成。
其次是架构层面的割裂。订单信息分布在B2B、DMS、OMS、C2F，财务则落在SAP，跨系统的数据查询、预警与报表只能通过大量二次开发来解决，成本高、周期长。
第三重压力来自管理诉求。推送预警中有相当比例属于催办与考核范畴，比如超期未提、达成缺口、订单经理考评与一票否决，客户需要一种能够推动渠道按规则行动的工具，而不只是服务渠道。
第四重压力体现在节点上。订货会期间咨询量成倍增长，主战场转移至经销商的手机端，覆盖会前政策解读、会中查单、会后预警全流程。
90项需求收拢为四类能力
商派将这90项需求归入四个模块。其中问答类共27项，涉及政策、返利、交期、账户对账等，统一进入知识库作答，以保证同一问题对应同一答案，无法回答时转入人工处理而不会强行编造。
查询与报告类共19项，支持一句话查询全链路并自动输出报告。MCP实时对接八套系统取数，一张订单从下单到履行的过程可以一次性问清，报告依照统一口径生成。
推送提醒类共16项，覆盖超期未提、预定金不足、达成缺口、账户余额等情形，由阈值触发后主动送达企业微信、短信或挂件，将问题发现从事后提前到事前。
技能类共28项，把资深员工手上的工作自动化，涵盖交期分配、预定金冻结解冻、对账审核等。规则要求先书面确定再执行，高风险动作须经过确认门并保留全流程审计回执。
两种智能体形态共享同一底座
商派的"AI外骨骼架构"可概括为：老系统相当于骨骼，整套保留；AI是穿戴在外部的能力层，动力由它提供，原有动作保持不变。其中嵌入式智能体嵌入系统内部充当助手，工作台智能体WorkBuddy则在系统外部实现对系统的完整操控，此前者的典型体现是嵌在B2B或DMS页面任意位置的H5挂件——用户无需离开系统即可完成对话办理；后者由自然语言驱动，支持跨系统查数、订单诊断报告、销售预测、以销定产建议、批量处理及推送配置等内部作业。
两条智能化线路并非二选一，而是各自覆盖不同场景，共用同一套MCP连接、Skill技能与Token生态。经销商在挂件中询问"我订300套能拿几个点返利"，与订单中心在WorkBuddy中查询"高定渠道本月达成多少"，调用的是同一批连接器、同一套权限规则与同一池Token。二者区别在于，嵌入式智能体由后台蓝图配置、面向移动场景，工作台智能体由自然语言驱动、面向生产作业。
为什么不动老系统
该品牌八套系统承载着十年以上的业务流程与数据积累，替换任何一套都意味着业务停摆、数据迁移与全员再培训。商派方案选择在系统外部附加一层"会说话的手"，系统本身保持零改动。
在接入方式上，所有查询与回写均经MCP连接器调用系统已有API，不触动数据库、不做二次开发。连接器移除后系统即恢复原状，实现零侵入与可回退。八套第三方系统逐一盘点API后再开发连接器，一套验收一套、一套计价一套。
在数据归属上，订单、库存、财务等主数据仍保留在OMS、DMS与SAP中，AI仅负责读取并经确认门回写，不新建数据库，以避免"系统一套数、AI一套数"的对账灾难。知识类数据进入知识库，交易类实行实时查询而不建立缓存副本。
在成本对比上，替换八套系统的代价包括业务停摆、数据迁移与全员重新培训，周期以年计算；加挂的方式则是接通一套使用一套。按照规划，12月订货会将先上线挂件四模块，验证后再逐套扩展连接器，把风险切分为小段推进。
在治理兜底上，治理闸门被设置在智能层与老系统之间，AI具备读取、运算并提供建议的权限；但涉及往系统内写入的操作，必须先给出"改哪张单、改什么字段、影响多少金额"的清单，由人工确认后才执行，且全流程留回执。越权取数在到达老系统之前即被拦截。
订货会端到端流程拆解
方案以订货会场景对完整链路做了拆解，分为会前、会中、会后三个阶段。12至14号节点构成底座支撑，01号节点属于配置环节，02至08号节点对应经销商在手机端走完的完整订货路径，09至11号节点则内部线会前会后的具体作业。
会前阶段进行打底与配置，包括订货会四模块（数据、政策、产品、品类）准备、权限视图按渠道角色设置、知识库就绪、蓝图配置上线以及兜底转人工机制。会中，经销商在移动端可直接获得该角色对应的政策视图，询问订货量对应的返利点数、获取品类推荐，跨系统查询订单、库存、余额，进行达成测算以确认补齐哪些产品可以够到下一档返利，下单动作经过确认门后回写至DMS或B2B，订单进度与物流也可通过一句话查询。会后，超期未提、预定金不足、业绩缺口等信息由挂件、企业微信、短信主动触达；内部则自动生成诊断报告、执行推送规则并在以销定产建议进入OMS工单。经销商全程不离开订货页面、不安装新应用，每一步AI回答都注明数据来源。
方案完全按照数据性质安排四条管道，而非把所有数据搬入同一数据湖。静态知识走知识库，交易数据走MCP实时查询，阈值事件走事件引擎，AI产生的结果走回写与审计。知识库采用RAG方式，可进行结构化建库和检索增强；MCP实时查询不设置缓存副本，每次查询原始系统并标注时点；事件引擎订阅交易数据变化，在阈值命中时触发，把预警提前到事故发生之前；结果数据经确认门放行后才写入原系统。与之带来的衡量指标包括人工接待量降低、政策口径达成一致、查单效率从半天缩短到秒级、跨部门协调归零、超期未提率下降以及资金占用可控，同时资深员工的经验沉淀为资产，新员工上手周期缩短。
数据权限方面，面向多层面的渠道与角色设定明确的数据范围。不同代理商针对同一政策问题会得到各自视角的回答，价格员、结算专员、导购各看各的数据。这种隔离在MCP层完成，而非在应用层打补丁。
四类部件各司其职
商派方案中，Skill负责把流程转化成可执行动作，MCP负责让AI够得着系统，Token负责用量与成本，双智能体负责在何种位置由何种使用者来用。
Skill技能包把一个标准化步骤文档化、可重复执行业务流程，内含取数规则、计算逻辑、动作清单与确认节点。其执行链路为trigger触发、fetch取数、compute计算、确认门与act执行及receipt回执。22项技能需求由业务方共创产生，首批包括交期按波次分配、预定金冻结解冻、报关单装箱清单生成。
MCP连接器充当AI与系统之间的同传角色，把各系统API注册为标准工具供所有智能体统一调用，权限与数据范围在这层切分清楚。部署上同样是八套系统逐套盘点、一套一验收一计价。
Token生态方面，每次AI请求消耗Token，可按请求、按模型查询，多实例共用一个池。订货会期间的峰值用量可提前预估，预算按Token包与订阅分级报送，以回应"一个Skill多少钱"的疑问。
双智能体中，外部形态即嵌入式挂件，长在系统里，服务于经销商与管理层；内部形态即WorkBuddy，依附于系统之外，服务订单中心与IT。订货会现场以外部线为主，会后的经营分析以内部线为主，双方读取同一批连接器。
六类场景前后对比
第一类在问答效率上：此前为微信人工回复、会议峰值接不住，落地后由挂件提供全天候同问同答，人工只处理转办与例外，衡量指标为接待量、转人工率、未解决率。
第二类在变更效率上：此前多个系统数据靠人工拼合、一个订单查询需耗费半天，落地后一句话即可说清全链路，并附带数据时点标注，衡量指标为查单耗时与跨部门协调次数。
第三类在风险发现上：此前超期未提、预定金不足均在事后才暴露，落地后由阈值触发主动送达，扣款预警提前至事前，衡量指标为超期未提率、预定金占用与达成率。
第四类在诊断与产供销协同上：此前报告依赖资深员工使用Excel制作、出一次需要数天，落地后报告分钟级自动生成，以销定产建议可直接进入OMS工单，衡量指标为报告产出时长与预测准确率。
第五类在政策一致性与培训成本上：此前政策依靠资深员工口头传递、新人上手缓慢，落地后知识库统一应答，老员工经验被固化为Skill，衡量指标为新人上手周期与政策争议单数。
十个典型场景的工程实证
方案通过10个场景验证具体实现路径，每个例子均按执行管线、所需客户数据、接口开放内容、参数配合方式与模型选型五方面演示。为便于定位，管线中不同颜色代表不同环节：蓝色表示MCP取数，绿色为规则计算，紫色为LLM处理与输出，琥珀色为事件与工单，红色为确认门。
场景01为嵌入式推荐产品，以"推荐几款带数显的恒温淋浴器"为例。挂件触发后由LLM抽取槽位，进行混合检索召回，再结合规则与销量排序，最终输出推荐卡片。其中属性采结构化过滤方式读取产品中台，卖点话术采用向量召回，参数数字必须来源于结构化字段以防止幻觉。一次建库覆盖产品对比、竞品对比、品类核心产品等五类问句。实现前提是产品中台属性结构化及属性词典（如"数显"对应"带屏"），以及手册PDF批量导出建库。
场景02解答补单金额问题，对应"6月和7月还需要下单多少"的需求。触发后进行时间窗解析，从三个来源取数，以目标减已下单算出缺口，对缺口加以解读后给出一键转下单草案。取数来源包括作为绩效源或Excel的目标、来自B2B的已下单数据及来自SAP的已提货数据。金额计算不交给LLM，公式固化在Skill内可审计。实现前提涉及保障度公式、目标数据源与剔除口径三项书面签认，原因是一个小疏漏可能引发经销商以截图对质。
场景03为每周订单诊断报告，属于事件加双端类型。包含七模块全维度诊断与下单建议。每周定时批处理，分别对各模块取数，经症候库诊断后由LLM生成叙述，再双端分发。七个模块分别是提货达成、订单保障、提货均衡性、未提订单、交期分析、问题诊断与下单建议、以及提货计划与资金准备。数字只引用计算层结果，LLM不进行自由诊断。核心在于症候库共创，需要经过2到3场工作坊，梳理首批20至30条症候规则，用真实数据回放校准"催提货还是催下单"的判断。
场景04处理未提订单与预定金测算，需求问题为"6-7月还要提多少货，准备多少预定金"。触发后拆分出两个子任务，从OMS、SAP与知识库取数，进行规则计算，形成资金准备清单，冻结申请须通过确认门。预定金的计算公式为订单额乘以品类比例求和，由于数字关系金额需零容错，LLM不介入算术。实施的先行条件是预定金比例表，同时SAP财务接口授权周期最长，建议尽早发起申请。
场景05对应超期未提明细与扣款预警，问题是"我有没有超期未提的订单"。采用每日批扫主动推送与实时问答被动查询两条路径，两者共用同一判定内核与分级触达。问答与推送共用同一套判断逻辑，保证"问的和推的"一致；触达链路按挂件、企业微信、短信逐级上升，但同一订单在同一周内不重复打扰。误报是该场景的最大风险，超期口径须经财务书面确认；上线前要用近3个月的历史数据回放对账，AI判定与实际扣款的一致率不低于99%才可开启推送。
场景06用于对账单与账户余额查询，示例问题是"查询一下5月对账单"。触发后识别意图并做强制鉴权，从SAP取数，进行模板渲染与勾稽自检后输出账单卡片。当出现期初加发生不等于期末的情况时会拦截不展示；月中查询会将关账口径需要提前标注的规则一并考虑，界面须写清数据口径。这一场景要求按"财务级"标准交付，坚持三条规则：数字只从SAP调取、关账口径必须标注、AI不裁决差异而是提供一键异议工单通道。
场景07为加急订单申请这类的写入动作，示例语句为"请帮我加急XX订单"。流程是根据信息收集相应槽位，对可行性做出预判，经确认门确认，进行工单双推至总代与订单员，状态回传并在超时时升级。AI只从事收集、预判、流转、回传四项工作，加急能否完成由人工决定，确认门中明确"不承诺加急结果"。碰到延误、延期、投诉等关键词时立即跳过预判，转入高优工单。这一场景被视为"AI不越权"的样板，同页的修改地址、售后催单、投诉转接三类同族需求均可套用同一模板。
场景08在工作台端查询"XX零售中心到区域出货情况"。WorkBuddy触发后进行维度解析，以快照聚合方式取数，再做权限裁剪，最终输出图表支持下钻。鉴于出货明细达到千万行级别，方案引入T+1日快照并预先聚合的轻量数仓路线，而非实时扫描SAP生产库，也不对外开放text2SQL，以确保模板化聚合的可控可审计。区域数据较为敏感，需要销售管理部门与IT共同签认角色与权限范围矩阵后才开放。
场景09适用于"完成率不足50%，请及时提货"类通知。采用定时加阈值双触发，按经销商计算并分级判定，输出个性化文案后通过多触点以频控方式触达。方案中提前提供了8类消息模板，把措辞一并确立，相当于验收标准自带；LLM仅用来使称谓与语气自然，数字始终锁定引用计算层。工程量集中在与SAP过账事件的对接、企业微信userid与手机号档案的清洗和频控策略的拍板，建议先在挂件上做单通道灰度两周，随后再开启升级链路。
场景10是在工作台中查询"某款单品还能卖多久？"。触发后进行SKU解析，从销存四面取数，用两期算法得出健康评级并附加LLM解读。一期的算法用于计算，即可售天数等于库存除以加权日均销量（采用移动平均），当天即可上线；二期在积累3个月标注后重新评估采用时间序列模型。与之属于同族的热销TopN、库存健康度、欠货分析功能共用一个销存数据面。对客户而言，可将分析直接实现，但相应预测能力分成两期，二期启动时序模型可获得可验收的依据。例如部分客户主动将销售预测部署评估安排靠后。
实施所需的三个配合清单
方案要求多方在两个层面上保持配合。在IT接口开放层面，SAP需提供出货、余额、预定金、对账单与过账事件的订阅，支付周期最长，应最先启动；B2B需要按状况开放订单查询与草案回写；OMS需要提供未提订单、交期、在途排产与具体工单；库存中台、C2F、产品中台需要给出库存、定制进度、属性与系列或门类映射以及分店层级；渠道类如企业微信应用消息、短信网关、工单系统也需要提前准备。
在业务规则参数落纸层面，涉及财务类的预定金比例表、冻结解冻扣款规则、对账与关账口径；涉及目标类的保障度公式、目标按月拆分、剔除口径、预警分级策略与数值指标；涉预警类的超期判定起点、扣款倒计时、频以及降噪策略与流程可用性需求。每一项规则都要在正式运行之前先行确立。
在组织和实际转对比测算类 Skill，确保公式文，还得组织共创与验收机制层面，需要业务部门在工作坊中彼此确认，举办2至3场工作坊，由资深订单员用真实数据进行回放校准。针对预警类功能的服务，上线之前须用近3个月历史数据回放对账，一致率不得低于99%。流程上推进则依靠样张签认、标注反推与务数据回流，在灰度阶段讲究先单渠道、先小客户群；12月订货会前要先行完成一轮灰度。以上都通过经验定型，目的是顺畅地接纳企业内部能力框架的落地。
小结
商派ShopeX这一方案的实质，是在B2B、DMS、OMS、C2F与SAP这八套既有系统之上叠加AI外骨骼通用能力层，而不替换老系统。其技术路径可概括为五句话：问答走知识库的RAG、查询走MCP实时查、计算走规则化Skill、推送走事件引擎、报告走批处理加受控生成逻辑框架，所有写入动作均须经过确认门。这种架构保证既有系统的智能化、专属体化与闭环运转更加水到渠成。