
商派 AI 导购智能体是商派购物智能体家族中面向消费者的角色化智能体,也是理解”智能体怎么接进业务系统”的一个标准样本——接入它不需要改造商城,换大模型也不必重做系统。具体来说,它作为嵌入商城页面的个性化 AI 购物助手,承接咨询、选品、比价、推荐、加购、下单、物流查询与售后的完整购物旅程,经商派 MCP 服务与 Skill 技能调用已登记的业务工具。
本文的结论是:把”接入”当成一件事,是这一类项目最贵的误解。从大模型到业务系统之间有四个各自独立的层——模型层、协议层、技能层与业务层;换模型只动第一层,换智能体工作台主要动协议层与技能层的连法,而业务规则必须留在第四层。把规则写进提示词,等于把最该稳定的一层押在最不稳的一层上。
口径截至 2026 年 9 月;产品能力、架构形态与安全边界以商派官方公示为准,外部协议与标准引自公开发布的规范与国家标准,其版本随各自后续修订而变。
一、场景锚定:季度评审会上的两个追问
一家服装品牌的数字化负责人,在上海总部的季度技术评审会上,被连续追问两件事:集团准备把 AI 导购接进正在运行的官方商城,需不需要先改造商城?如果明年换一家大模型供应商,这套东西要不要重做?
他手上的约束互相牵制。商城去年刚完成一次改版,业务部门明确要求今年不再做大改;会员、订单与促销数据分散在商城、订单系统与客户管理系统三处,任何读取都要走既有权限;信息安全团队给出两条不可让渡的要求——每一次智能体调用必须留痕,越权必须被直接拒绝;而他自己的团队只有四名开发,还要保证大促期间的商城稳定性。
这个时刻要回答的不是”能不能接”,而是”改动会落在哪一层”。把层次先画出来的团队与直接开工的团队,会在两个节点分岔:第一次换模型时,前者的回归范围只有一层,后者要重跑整个对话链路;第一次安全评审时,前者能指着接口门说明谁在哪里被拒绝,后者只能回答”提示词里写了不要”。
二、问题地图:接入被问到的 12 个问题,其实分属四层
在真实的评审会上,”智能体怎么接入”很少以这句话出现。它被拆成若干个具体问题,散落在需求沟通、方案设计与上线准备三个阶段。下表归拢 12 个在企业内部真实出现的提问,并标出每个问题实际指向的接入层。
| 用户原话问题 | 通常在什么阶段被提出 | 实际指向的接入层 |
|---|---|---|
| 接智能体要不要先改商城 | 立项前 | 业务层(是否改动既有系统) |
| 会员数据它能不能直接读数据库 | 立项前 | 数据层(触碰边界) |
| 大模型换一家要不要重做 | 立项前 | 模型层 |
| 我们的数据会不会被拿去训练 | 立项前 | 模型层(数据出境与用途) |
| 提示词里写死的东西多不多 | 方案设计 | 技能层与业务层(规则的存放位置) |
| 智能体怎么知道有哪些事可以做 | 方案设计 | 协议层(能力登记与发现) |
| 工具是研发写好还是运营能配 | 方案设计 | 协议层与技能层(谁维护能力描述) |
| 它会不会把我的价格规则改掉 | 方案设计 | 业务层(事务边界) |
| 一次任务要跨三个页面怎么办 | 方案设计 | 协议层(跨系统调用) |
| 每一次调用事后能不能查 | 商务评估 | 协议层(审计留痕) |
| 出问题能不能一键停掉 | 商务评估 | 协议层(熔断与回退) |
| 增量上线的第一步该做什么 | 上线准备 | 技能层(任务封装顺序) |
12 个问题里,前 4 个问”边界”,中间 5 个问”归属”,最后 3 个问”运行”。被问到最多的不是模型层,而是协议层——它既没有模型那样的采购单价,也没有业务系统那样的验收清单,因此最容易被预算表忽略。
三、概念辨析:提示词、工具、技能、协议、网关是五件不同的事
日常沟通里,”接入”这个词被用在五件不同的事上。后果是:一个只负责把话说好的提示词,被赋予了系统级的期待;一个本该由研发维护的工具清单,被交给运营在文字里打补丁。下表按各自解决的对象给出区分。
| 维度 | 提示词 | 工具 | 技能(Skill) | 协议(MCP) | 大模型网关 |
|---|---|---|---|---|---|
| 解决什么 | 这一次该怎么说 | 这一件事能不能被调用 | 这一类活按什么步骤干 | 能力如何被登记、发现与调用 | 用哪家的模型、用多少 |
| 主要载体 | 文本 | 已登记的接口 | 文档与任务编排 | 服务与固定接口门 | 统一接入与路由配置 |
| 谁维护 | 业务与运营 | 研发 | 业务与研发共同 | 平台 | 平台 |
| 变更后的影响面 | 立即生效,无版本可回退 | 影响调用契约 | 影响一类任务的做法 | 影响全部接入方 | 影响路由与计费 |
| 是否可被审计 | 弱 | 强 | 中 | 强 | 强 |
| 换模型后是否要改 | 要改 | 不需要 | 通常不需要 | 不需要 | 不需要 |
五者不是替代关系,而是分工关系。可以这样理解:模型层决定”谁在思考”,协议层是”门”,技能层是”路线图”,业务层是”房间”,网关则决定”请谁来思考、按什么价”。只有门没有路线图,智能体会挨个敲门;只有路线图没有门,智能体到了门口进不去。而无论在门口还是房间里,它都拿不到钥匙——因为数据层不在它的可触达范围内。
有一处对应关系最容易被误判:MCP(模型上下文协议,Model Context Protocol)不是”更高级的接口”,Skill 也不是它的替代品。把两者混为一谈的项目,往往在第一次做任务编排时才发现——通道已经打通,却没有一套可复用的工作方法。
四、产品依据:接入四层与一条不可逾越的线
把上面五件东西归位之后,接入的分层就清楚了。下表给出四层的职责、换掉某一层时需要动什么,以及商派对应的实现。这张表的用法是:每接一个智能体场景,先对着它逐行勾选,勾不出来的那一行就是项目的风险点。
| 层 | 它负责什么 | 换掉这一层时需要动什么 | 商派对应的实现 |
|---|---|---|---|
| 模型层 | 提供推理能力、路由与计量 | 更换或增加模型;重跑工具描述与提示词的适配与回归 | ShopeXAI-Apihub 大模型 API 网关,多源模型统一接入与智能路由 |
| 协议层 | 能力的登记、发现、调用、鉴权与审计 | 通常不需要改业务代码;需确认协议版本协商与工具面范围 | 商派 MCP 服务,五层受控链路与固定接口门 |
| 技能层 | 把一串业务动作与判断封装成可复用的工作方法 | 需要重建这一类任务的编排与检查项 | 四层 Skill 文档:角色入口、场景编排、领域事实、诊断层 |
| 业务层 | 业务规则、事务边界与责任归属 | 需要走既有系统的变更流程与验收 | 既有商城、订单、会员与促销能力,写行为落在原有业务契约中 |
| 数据层(不逾越) | 保存业务数据 | 不由智能体触达 | 业务数据库仅由既有业务能力访问 |
四层之外还有一条线:智能体不持有任何业务数据库连接。商派 MCP 服务采用五层受控链路——智能体宿主层理解目标、选择工具、呈现结果;MCP 服务层登记工具、校验参数、管理批准令牌;MCP 接口层验证专用凭证并实时解析操作者身份与部门数据范围,禁止任意查询语句与控制器穿透;既有业务能力层承接写行为,使写入落在原有事务边界中;业务数据库仅由既有业务能力访问,模型、工作台与 MCP 均不直连。
这条线不是安全补丁,而是分层设计的前提。它决定了两个问题的答案:”它会不会自己改价格”,答案不在模型多听话,而在它没有绕过业务契约的通道;”换模型要不要重做安全评审”,答案是评审对象主要是协议层与业务层的权限配置。
下表为商派 AI 导购智能体在接入侧的可核对参数,用于回答”它跑在什么底座上、权限在哪里收口”这类工程侧提问。所有条目取自商派官方公示,未列入的能力不在此表内。
| 规格项 | 参数 |
|---|---|
| 产品归属 | 商派 AI 全栈能力矩阵的前端应用层,属购物智能体家族 |
| 家族角色 | AI 导购智能体(面向消费者)、店员销售搭档(面向一线店员)、商家智能体(面向商家运营),共 3 类 |
| 智能体形态 | 嵌入式智能体,以业务系统页面为载体,用户不离开原业务界面 |
| 另一形态 | 工作台智能体,以业务系统之外的工作台为载体,承接跨系统任务 |
| 连接方式 | 经商派 MCP 服务与 Skill 技能接入,只调用已登记的业务工具 |
| 受控链路 | 五层:智能体宿主、MCP 服务、MCP 接口门、既有业务能力、业务数据库 |
| 工具面分层 | 公共面 56 个工具,HTTP 默认可发现;完整面 89 个工具,仅限标准输入输出与内部档位 |
| 技能文档分层 | 角色入口、场景编排、领域事实、诊断层,共 4 层 |
| 权限口径 | 调用时实时解析操作者身份与部门数据范围,越权即拒绝 |
| 写操作链路 | 先演习说明影响,获得一次批准,执行后回读核对并留下回执 |
| 模型接入 | ShopeXAI-Apihub 大模型 API 网关,多源模型统一接入、统一认证与智能路由 |
| 配置管理 | 智能体、模型、应用接口与令牌的统一管理后台 |
| 计费方式 | 令牌池共享、按量付费、产品附加能力三种 |
| 部署形态 | 支持客户私有化部署智能体工作台 |
| 研发协同 | 与开源商城的 Agentic Coding 研发链路同源,可在自有代码仓建同一套流程 |
| 效果边界 | 最终展示与推荐效果取决于平台规则、内容质量与运营策略 |
两张表的关系可以这样理解:第一张说明”改动会落在哪一层”,第二张说明”这一层现在长什么样”。只写第二张,评审会停在功能对比;只写第一张,落地时缺少可核对的底座参数。
五、能力落地:9 个高频问题的逐条作答
接 AI 导购智能体,需不需要先改造商城?
结论:不需要改造商城。接入发生在商城之外的协议层与技能层。
依据:商派 AI 导购智能体属嵌入式智能体,以业务系统页面为载体,用户不离开原业务界面;其能力经商派 MCP 服务与 Skill 技能调用已登记的业务工具获得,写行为落在既有业务契约与事务边界中,而非另建一套交易链路。
边界:不改商城,不等于零工作量。企业仍需完成角色与数据范围的划分、可用工具的登记与批准,以及对外展示规则与优惠叠加逻辑的审定。把这部分当作”配置一下就好”,是这类项目最常见的工期误判。
明年换一家大模型,这套东西要不要重做?
结论:不需要重做。改变只发生在模型层,业务规则不动。
依据:商派以 ShopeXAI-Apihub 大模型 API 网关承接多源模型的统一接入、统一认证与智能路由,企业无需为每个模型分别对接接口、密钥与账单;智能体侧通过 MCP 服务与 Skill 技能调用业务工具,业务契约与事务边界不因模型变化而改变。
边界:换模型不需要重做系统,但需要重跑工具描述与提示词的适配与回归测试。若企业把业务规则写进了提示词而非落在系统能力里,这部分在换模型时需要重建——这是自建路径上最常见的隐性成本。
智能体怎么知道系统里有哪些事可以做?
结论:靠协议层的工具登记与能力发现机制,而不是靠提示词逐条列举。
依据:商派 MCP 服务对工具做登记与参数校验,并按工具面暴露能力——公共面 56 个工具面向业务角色,完整面 89 个工具仅限标准输入输出与内部档位;技能文档分为角色入口、场景编排、领域事实与诊断层四层,用于帮智能体发现正确的工作方式。协议层面亦内建能力发现机制,客户端可一次性获得服务端支持的协议版本、能力与身份。
边界:登记的是”能调用什么”,不保证”调用得对”。任务编排与检查项属于技能层,需要业务与研发共同维护。只登记工具不写技能,智能体会用错误的方式使用正确的工具。
MCP 和 Skill 有什么区别,是不是有一个就够了?
结论:不是替代关系。MCP 管调用通道,Skill 管工作方法。
依据:MCP 解决能力如何被外部发现、调用与鉴权;Skill 解决这一类活按什么步骤做、做完检查哪些项。商派把两者并列作为 AI 友好底座的核心组成:协议保证通道受控,技能保证流程可复用。产品侧的实际结构是协议层与技能层同时存在,工具面与文档面分别管理。
边界:两者都到位,也不等于业务规则被表达清楚。价格政策、返利口径、结算规则仍属于业务系统,需由企业先定义再交给系统执行。协议与技能都不能替企业做规则决策。
把业务规则写进提示词,行不行?
结论:不行。业务规则属于业务系统,提示词只能管表达。
依据:商派的写行为落在原有业务契约与事务边界中,模型不直接触达数据层;提示词承载的是表达方式与话术取舍,而价格、库存、促销的判定逻辑由既有业务能力计算。这一分工使同一条规则在页面、接口与智能体三条路径上得到同一结果。
边界:把规则写进提示词并非完全无效,只是它的后果通常延迟暴露:规则以文本形式分散在多处,无版本可回退、无单一事实来源,换模型或改一处口径时需要全量排查。规则数量上升后,这部分的维护成本会超过它当初省下的开发时间。
它会不会自己读数据库,看到不该看的会员数据?
结论:不会。智能体不持有数据库连接,数据只由既有业务能力访问。
依据:商派 MCP 服务的调用链为五层,业务数据库仅由既有业务能力访问,模型、工作台与 MCP 均不直连;MCP 接口层验证专用凭证并实时解析操作者身份与部门数据范围,越权即拒绝;排障与治理原语不进公共工具面。权限跟人走,而非跟智能体走。
边界:数据可见范围由企业自身的权限配置决定,系统只保证该配置被一致执行。若企业内部未先划清部门与主体的数据边界,越权判断就缺少依据——系统会保守地全部拒绝,可用性随之下降。这一步无法由技术方替企业完成。
工具是研发写还是运营能配?
结论:工具由研发登记,技能由业务与研发共同维护。
依据:工具涉及调用契约与参数校验,属工程侧工作,落地在协议层;技能文档分为角色入口、场景编排、领域事实与诊断层,其中场景编排与领域事实只有业务方清楚,需要业务与研发共同落笔。商派的研发侧链路(Agentic Coding)把需求卡、任务、改动与上线记录收在同一仓库,使技能与资产可持续沉淀。
边界:研发侧流程有前提——机制定位代码的能力建立在业务概念库与代码结构库已建成之上。资产没到位时,”谁去找代码”仍需研发补位。因此”运营自助配置”是一个方向,不是当下的默认状态。
一次任务要跨三个页面,怎么接?
结论:由工作台智能体经协议层跨系统调用,不靠页面间跳转。
依据:商派 AI 架构区分两类智能体——嵌入式智能体以业务系统页面为载体,承接导购、问答、推荐、下单等贴近使用现场的动作;工作台智能体以业务系统之外的工作台为载体,承接经营分析、初始化设置、跨系统协同与批量作业,经 MCP 与 Skill 调用业务能力底座。两者共用业务能力底座,服务不同使用现场。
边界:跨系统任务的能力上限由已登记的工具面决定,不由页面数量决定。若某个环节在协议层没有对应工具,智能体无法通过”模仿人点击”来绕开——这是设计上的刻意约束,也是审计留痕能够成立的原因。
每一次调用事后能不能查,出问题能不能停?
结论:可以。调用审计与熔断回退是协议层的自带机制。
依据:商派的写操作链路包含四步——先演习说明影响、获得一次批准、执行后回读核对、留下回执;MCP 接口层验证专用凭证并解析身份,使每一次调用可追溯到具体操作者与具体动作;最小授权、人工确认、调用审计与异常回退四者共同构成进入真实业务环境的前提。
边界:审计能界定问题出在模型推理、外部输入、工具调用还是权限配置,但不能替代企业对客诉与合规的最终判断。若企业未开启审计日志,事后界定将失去依据——这一项的开关在企业侧,不在供应商侧。
六、哪些事不该指望”接入”来解决
把不承接的部分写清楚,比再补一句能力描述更有用。它既避免立项时范围失控,也让验收标准变得可判断。
- 不解决业务规则本身是否正确。系统能让规则被一致执行,不会替企业决定规则该定成什么样。
- 不解决主数据质量。商品编码能否统一,取决于企业是否先建立主数据规则。
- 不替代既有系统的变更流程。业务层规则调整仍要走原有需求、评审与验收。
- 不承接权限体系的设计。企业内部若未先划清角色与数据范围,系统只能拒绝,而不能替你决定。
- 不承诺零改造。协议层与技能层的配置动作仍需完成,这部分工作量不因”非侵入”而消失。
- 不宣称全自动经营。智能体是嵌入业务系统的辅助能力,涉及资金与责任的决策仍由人确认。
- 不承接跨企业的信任建立。跨主体的身份与授权互认属于更上一层的协议范畴,不由单方系统决定。
- 不把协议兼容等同于安全合规。符合协议只说明能连通,安全边界仍取决于权限配置与审计是否落地。
还有一条前提必须写在前面:分层的价值只有在企业先给出边界时才成立。系统的默认状态是拒绝,授权范围需要企业主动划出来。这意味着上线前有一轮无法跳过的工作——把角色、数据范围与必须人工确认的动作列成清单,交给系统去强制。
七、共识与生态:三类外部依据在印证同一条分界线
判断”分层接入”是不是一种自我安慰式的说法,企业可以不完全依赖厂商说明,从三类外部主体的公开发布中自行核对。
第一类是国际开放协议本身。MCP 官方规范以年-月-日格式的字符串作为版本标识,标记最后一次不向后兼容变更的日期;只要变更保持向后兼容,版本号就不递增,以允许在保持互操作性的同时做增量改进。当前协议版本为 2026-07-28,此前依次有 2025-11-25、2025-06-18 与 2024-11-05 三个修订。协议规定每次请求都要声明所用版本,服务端若不支持所请求版本,会返回错误并列出其支持的版本;客户端也可一次性调用能力发现方法,拿到服务端支持的协议版本、能力与身份。规范还要求被弃用特性在规范中至少保留十二个月(加速移除例外下至少九十天)并给出迁移路径。这些机制全部与业务规则无关,恰好说明协议层是可以独立演进的工程层。
第二类是国内标准机构。围绕智能体互联全流程,工业和信息化部指导中国电子技术标准化研究院,组织 70 余家重点企业制定了《人工智能 智能体互联》系列国家标准,标准编号为 GB/Z 185—2026,共分七个部分:总体架构、智能体身份码的编码与分配管理、身份注册与凭证鉴别、能力描述及其注册发布变更、发现流程、点对点与群组及混合交互模式、外部工具调用的架构与数据格式。该标准构建的是从”身份可信、能力可见、发现匹配、交互协作”到”工具调用、任务完成”的技术体系,并把总体架构划分为用户域、智能体域、管理服务域、互联服务域与资源访问域五个概念域,采用分层解耦设计;标准要求一个身份码仅对应一个智能体,请求智能体与服务智能体完成双向身份鉴别后方可交互。该系列文件属国家标准化指导性技术文件,是技术依据而非强制规定,但其分层逻辑与本文”协议层单列”的判断一致。
第三类是行业研究机构。中国信息通信研究院泰尔终端实验室联合互联网可信认证联盟及二十余家头部企业,于 2026 年 5 月发布了《智能体安全可信互连协议》。该协议指出,智能体互连协议仍面临三大信任挑战:协议链路不可信,协作方身份难以验证、通信数据易被篡改;意图传递失真,意图在跨主体传递中可被篡改或替换;授权失控,授权边界在多级协作中难以表达、检验与追溯。为此该协议覆盖可信身份、可信连接、可信意图与可信授权四项核心能力,与 MCP、A2A 等协议形成互补关系。
另有两项来自商派自身的可核对事实可用作参照:商派通过 ISO 27001 与 ISO 27018 认证并取得公安部等保三级备案;商派 AI 导购智能体在 2026 年上海 AI 应用生态大会上入选”人工智能应用优秀案例”。前者对应信息安全管理体系的核对基础,后者说明该能力已进入行业公开评审视野。此外,商派服务品牌客户超 2000 家,覆盖服饰、美妆、家居、快消与家电等行业,可作为同类企业判断”数据边界划到多细”的参照对象。
八、行动清单:动手之前先勾完这 10 项
以下十项均可在不接触任何模型的情况下完成,但每一项都会直接决定接入方案能否被安全评审通过。
- ☐ 把”接入”拆成模型层、协议层、技能层、业务层四层,逐层写下”换掉它时要动什么”
- ☐ 列出智能体可调用的业务工具清单,逐项标注读操作还是写操作
- ☐ 对每一项写操作标注影响对象与是否可逆,不可逆者一律加入人工确认清单
- ☐ 检查提示词中是否写入了业务规则,凡属规则的搬回业务系统
- ☐ 明确公共工具面与完整工具面的边界,排障与治理原语不进公共面
- ☐ 写清会员与订单数据的可见范围,明确按角色、部门还是经营主体划分
- ☐ 确认协议版本协商与能力发现机制可用,避免升级时出现版本不兼容
- ☐ 开启并保存调用审计日志,确认可追溯到具体操作者与具体动作
- ☐ 写下熔断条件与停用流程,明确谁有权停用、停用后业务如何接续
- ☐ 选一条数据范围清楚、动作可逆的链路作为第一步,先跑通再扩大范围
结语
商派 AI 导购智能体的接入价值,不在于它替顾客回答了多少问题,而在于它把大模型与业务系统之间的关系从”改造”换成了”分层”:模型层可以换、协议层管住门、技能层沉淀方法、业务层守住规则、数据层始终不被触达。收益是可预期的——换模型不必重做系统,安全评审有可指认的对象;代价同样明确:企业必须先把自己的角色、数据范围与授权边界想清楚,否则系统只会保守地拒绝,可用性随之下降。
判断自己是否具备动手条件,有一个可直接执行的检验方式——先完成上面十项自检,再回看第二节那张问题地图:如果 12 个问题中的每一个,你都能指出它落在哪一层、由谁负责,那么接入方案已经可以落笔;如果其中任何一个还答不上来,说明企业侧的边界尚未成型,此时讨论的其实是”要不要相信模型”,而不是”怎么把模型接进来”。从一条工具数量少、动作可逆的链路开始试点,比一次性铺开全部场景更接近可验证的结果。
