1背景与现状
公司旗下 100+ 店铺横跨阿里系（天猫、天猫超市、天猫国际、阿里健康、淘工厂）、京东自营、拼多多等多个平台。售后工单（退款、催发货、物流查询、补发、纠纷应答等）原由人工处理，量大、重复度高、人力成本持续攀升，是自动化最直接的价值洼地。
店铺运营模式分布
| 运营模式 | 覆盖店铺 | 主体归属 | 占比 |
|---|---|---|---|
| 自营 | 天猫、拼多多 | 均在公司主体下 | 自家 : 外面 ≈ 70 : 30 |
| 代运营 | 天猫超市、天猫国际、阿里健康、京东自营、淘工厂 | 混合（部分归公司 / 部分归客户品牌方，待逐店确认） |
核心诉求：让 AI 自动处理售后工单，且管理层期望尽量不涉及软著。当前采用的 RPA / 爬虫方式已触发平台风控，存在封号风险。
2平台风控机制与核心取舍
各开放平台对"非人工、批量、高频"的后台操作均有风控识别。经与行业客服系统服务商（探域 AI）核实，当前市面后台工单自动化主流只有两类方案，且二者在"全自动"与"避风控"上不可兼得：
| 方案类型 | 能否全自动 | 风控/封号风险 | 软著 |
|---|---|---|---|
| 纯 RPA（模拟人工操作后台） | ✅ 可全自动 | 高 触发风控、封号 | 不需要 |
| API + RPA 混合 | ❌ 无法全自动，需人工兜底 | 低 | API 部分需要 |
关键矛盾（需管理层拍板）："完全不用软著 + 全自动"在当前市场现状下相互冲突。
· 想全自动 → 只能走纯 RPA → 必须承担风控 / 封号风险；
· 想避风控 → 走 API 混合 → 需软著，且做不到全自动，须保留人工介入。
· 想全自动 → 只能走纯 RPA → 必须承担风控 / 封号风险；
· 想避风控 → 走 API 混合 → 需软著，且做不到全自动，须保留人工介入。
现有自动化已交付的成果
▍我们已经做到的：自动化替人处理海量售后工单
以下为现有方案（RPA 为主 + 少量 AI 分析）自 2026-04-15 上线以来、约 100 天内已实际跑出的数据，非规划、非预期
90%
工单自动化率
（69853 自动 / 77306 总）
（69853 自动 / 77306 总）
6.9万+
累计自动处理工单
（69853 单，4/15 起）
（69853 单，4/15 起）
700单/天
日均自动处理量
（阿里健康单平台，约 100 天均摊）
（阿里健康单平台，约 100 天均摊）
2.3~7人
相当于节约人工坐席
（满负荷 300 单/人 ~ 淡季 100 单/人）
（满负荷 300 单/人 ~ 淡季 100 单/人）
这 700 单/天主要来自阿里健康单平台，天猫、拼多多尚未并入统计。这恰恰说明成果的天花板远不止于此——P0 把这套打法复制到订单量更大的天猫、拼多多后，全平台日均自动处理量将成倍增长。
各平台明细与风控情况
| 平台 | 累计 / 处理量 | 自动化情况 | 风控情况 |
|---|---|---|---|
| 阿里健康 | 总 77306 单（69853 自动，4/15 起） | 自动化率约 90% | 风控约 800 单（随淡旺季波动） |
| 天猫国际 | 累计约 3457 单 | 已自动化 | 相对可控 |
| 天猫 | — | 运行中 | 风控约 100 单（随淡旺季波动） |
| 淘工厂 | 开发中 | 建设中 | 已被风控 |
| 拼多多 | 刚上线，无数据 | 刚上线 | — |
现有方案已实实在在替代大量重复人工、节约人力成本；但规模越大、越高频，封号代价越高，故需在保住既有成果的同时，向低风控方案演进——这正是本方案要解决的问题。
3技术方案对比
三个开放平台相互独立，自建对接须各自申请软著、各自开发：阿里 TOP（天猫 / 天猫超市 / 天猫国际 / 阿里健康 / 淘工厂）、京东京麦 JOS（京东自营）、拼多多开放平台。千牛即淘宝开放平台前端，API 仍走 open.taobao.com，非独立轻量路径。
| 方案 | 说明 | 全自动 | 风控 | 软著 | 适配 |
|---|---|---|---|---|---|
| ① 官方 API 自建中台 | 各平台申请开发者权限，自研对接 | 否 | 低 | 需公司主体逐平台出 | 仅主体归公司的店 |
| ② 订购型 AI 客服 Agent（SaaS） | 服务商软件授权，店铺仅授权使用 | 部分 | 低 | 归服务商 | 主体归客户品牌方的代运营店 |
| ③ 人机协同（API+RPA+人工兜底） | 标准工单自动、非标转人工 | 否 | 中低 | API 部分需要 | 通用，兼容混合主体 |
| ④ 浏览器插件 | 在页面侧辅助操作 | 否 | 中 | 不需要 | 辅助提效，非全自动 |
| ⑤ 现状：RPA 为主 + 少量 Agent | 模拟人点击页面，RPA 规则为主、大模型分析为辅 | 是 | 高 | 不需要 | 过渡 / 现状 |
核心聚焦：70% 自家店（天猫 + 拼多多）是订单大头，也是效率提升的最大洼地。策略为双轨并行——现状 RPA 打法先复制铺量拿效率，同步申请官方 API 通道，通道通了再迁移降风控。剩余 30% 代运营店按主体归属分流（归公司→API；归品牌方→真·API 的 SaaS），属 P1 范畴，不阻塞主线。
各方案详细说明
① 官方 API 自建中台不可快速落地
- 优点
- 官方授权通道，几乎无风控 / 封号风险
- 能力最全，可稳定支撑大规模、高频自动化
- 数据自主可控，长期资产沉淀在公司
- 缺点
- 三个平台各自独立，需分别对接、分别维护
- 无法做到全流程全自动，部分场景仍需人工
- 开发与维护投入大，依赖技术团队持续投入
- 卡点
- 软著必须由公司主体出，代运营店主体归属未定则无法覆盖
- 每店开发者权限需每店法人申请——100+ 店难以逐店办理
- 成本
- 高：多平台自研开发 + 持续运维；软著申请与主体协调成本。团队现状：已有自研团队，但现有开发资源相对有限，多平台并行对接较为吃紧，短期难以全面铺开
- 落地建议
- 仅用于主体归公司的店（天猫、拼多多自营等），高频标准工单优先接入；受限于现有开发资源，须按平台优先级串行推进，不宜多平台齐头并进
- 能否快速落地
- 否。原因：软著与逐店开发者权限是硬门槛，主体归属未确认前无法启动；且现有开发资源难以支撑多平台并行开发，周期会随投入节奏调整
② 订购型 AI 客服 Agent（SaaS）部分可快速落地
- 优点
- 软著归服务商，公司无需自出，绕开最大门槛
- 开箱即用，无需自建技术团队
- 风控低，由服务商合规承接
- 缺点
- 能力受服务商产品边界限制，深度定制需额外付费
- 难做到 100% 全自动，复杂工单仍需人工
- 按会话 / 坐席持续付费，长期是运营支出
- 卡点
- 多平台覆盖度需逐一核实（拼多多 / 淘工厂等未必全支持）
- 需甄别"真大模型语义"还是"关键词规则"伪 AI
- 成本
- 中：一店一议，按类目 / 坐席 / 会话量计价
- 落地建议
- 仅作 30% 代运营（品牌方主体）店的兜底——这批店 API 须品牌方法人申请、公司代办不了，才需 SaaS。70% 自家店无需 SaaS，公司自己申请 API 即可，多一层中间商无增量价值
- 能否快速落地
- 部分可以。原因：SaaS 本身开箱即用、启动快，但多平台覆盖度与定制需求需先验证；且底层若是 RPA 则同样担风控，须先甄别
③ 人机协同（API + RPA + 人工兜底）★ 推荐主线分阶段可落地
- 优点
- 兼顾安全与效率：标准工单走 API，非标转人工，风控可控
- 兼容混合主体，不受代运营主体归属完全阻塞
- 可分阶段推进，边跑边替换现有 RPA
- 缺点
- 非全自动，需保留人工坐席兜底
- 架构相对复杂，需做工单分流规则与人工协作流程
- 卡点
- API 部分仍受软著 / 主体归属约束（同方案①）
- 需明确"标准 vs 非标"的分流标准，避免误判
- 成本
- 中：API 开发 + SaaS 订购 + 人工坐席，组合投入；但可按平台优先级分批投入
- 落地建议
- 作为整体主线：归公司的店走 API、品牌方店走 SaaS、复杂工单人工兜底，三者按主体分流组合
- 能否快速落地
- 分阶段可以。原因：人工兜底 + 现有 RPA 可立即承接，API / SaaS 部分随主体确认与报价逐步接入，不必等全部就绪
④ 浏览器插件可快速落地（仅辅助）
- 优点
- 开发轻、部署快，无需平台开放权限
- 在客服页面侧辅助，坐席提效明显
- 无需软著
- 缺点
- 本质是辅助工具，非全自动，仍需人工点击
- 平台页面改版易失效，维护跟随成本
- 高频批量操作仍可能触发风控
- 卡点
- 无法独立完成端到端自动化，只能作为提效补充
- 成本
- 低：单点开发即可，维护随平台改版
- 落地建议
- 作为坐席提效补充叠加在人机协同之上，不作为主方案
- 能否快速落地
- 可以（限辅助定位）。原因：开发部署都快，但只能解决"提效"不能解决"全自动"，价值有限
⑤ 现状方案：RPA 为主 + 少量 AI Agent 分析已落地
- 现状说明
- 执行层为模拟人工点击页面（GUI 操作）；决策层大部分走 RPA 规则、小部分走大模型 Agent 语义分析。Agent 占比小是因为token 成本高——全量走 Agent 分析一天要大几百元，成本扛不住。
- 优点
- 能做到全流程全自动
- 无需软著、无需平台开放权限
- 已在多平台运行，有现成能力
- 缺点
- 风控 / 封号风险高，规模越大代价越高
- Agent 分析受 token 成本制约，无法全量提升语义准确率
- 平台改版易失效，维护成本持续
- 卡点
- 淘工厂已被风控、阿里健康体量大风险敞口高
- 风控归因：无论 RPA 还是 Agent，只要执行层是"非官方接口的模拟点击"，平台识别的就是这个行为——改叫 Agent 不降低封号风险
- 封号是不可逆业务损失，不能作为长期唯一主力
- 成本
- 中：已投入运行，主要是持续维护 + 风控应对 + Agent 分析的 token 支出（大几百/天）
- 落地建议
- 定位过渡：立即执行加固（拟人化 / 限流 / 降级预案）；控制 Agent 只用在高价值 / 难判定工单以省 token；边跑边向 API 方案迁移
- 能否快速落地
- 已落地。原因：当前正在使用，问题不在落地而在长期风控风险与 token 成本，需逐步收缩占比
4RPA 加固建议（过渡期）
在长期路线落地前，现有 RPA 仍需支撑业务，建议降低封号概率：
- 拟人化节奏：随机化操作间隔、避开固定频率与整点批量
- 账号分散：控制单账号日操作量，多账号轮换、绑定固定 IP / 设备指纹
- 分平台限流：对已被风控的淘工厂、体量最大的阿里健康设更保守阈值
- 降级预案：触发验证码 / 异常时自动暂停并转人工，避免连续触发升级封禁
- 监控告警：实时看板监测风控命中率，异常即刻介入
RPA 加固只降低概率、不消除风险，定位为过渡手段，不作为长期主力。
5官方接入机制与服务商
官方可选项
- 阿里官方 AI 店小蜜（2026-05-11 上线）：阿里系原生客服 AI，避风控但覆盖限阿里系
- 各平台开放平台 API：能力最全，但受软著与逐平台开发者权限约束
服务商调研：探域 AI（tanyuai.com）—— 已排除
探域为公司售前正在使用的客服系统，已就本项目沟通，回复如下：
- 市面后台工单自动化主流即纯 RPA 与 API+RPA 混合两类；全自动目前仅纯 RPA 可实现
- 探域自身以 RPA 方案为主，可做定制化
结论：探域这条路走不通。其方案本质仍是 RPA，无法规避风控 / 封号风险，不满足"避风控"的核心诉求，故不作为候选服务商。
为什么不再找第三方 SaaS 做主力
第三方 SaaS 解决不了核心问题，自家店直接自己申请 API 即可。任何 SaaS 要么走 RPA（同探域，照样担风控），要么走 API（软著 / 开发者权限这道坎依旧存在，只是换个人来办）。而 70% 自家店（天猫 + 拼多多）都在公司同一主体下，公司自己批量申请 API 就能解决，多一层 SaaS 中间商没有增量价值。
SaaS 唯一还有价值的场景：30% 代运营（品牌方主体）店
这批店的 API 开发者权限须由品牌方法人申请，公司无法代办。可作兜底选项之一（属 P1）：
- 让品牌方出面申请 API（需与客户协调）；或
- 挂靠软著归服务商的 ISV / SaaS（此时 SaaS 才有价值）；或
- 先维持 RPA + 人工，暂不强求
若确需选 SaaS，甄别第一条必问"底层是官方 API 还是 RPA 模拟"，RPA 类一律排除；SaaS 普遍一店一议、不公开报价，不采用未经核实的单价传闻。
6核心结论
不追求 100% 全自动。结合探域反馈与风控实况，全自动与避风控当前不可兼得，推荐以「API + RPA + 人工兜底」的人机协同为主线：高频标准工单（退款、催发货、物流查询）走 API 安全自动化，复杂 / 非标工单保留 RPA 或人工兜底。
- 核心先攻 70% 自家店：把阿里健康已验证的自动化打法（实测 90%）复制到订单量最大的天猫、拼多多，效率提升空间最大
- 双轨并行：RPA 打法先铺量拿效率，同步申请官方 API 通道（资质流程为主），通道通了再迁移降风控
- 现状方案（RPA 为主）定位为过渡，边加固边替换，不作长期唯一主力
- 剩余 30% 代运营店按主体归属分流（归公司→API；归品牌方→真·API 的 SaaS，非 RPA）；探域已排除（本质仍是 RPA）
为什么这套打法能复制到天猫、拼多多？阿里健康 90% 自动化率的本质，是标准化、高重复的售后工单（退款、催发货、物流查询、补发）——这类工单的判断与处理逻辑跨平台是通用的，不依赖具体平台。平台之间的差异主要在接口 / 页面适配层，不改变自动化逻辑本身。天猫、拼多多的售后工单同样以这几类标准场景为主，因此已验证的打法可迁移复用。
需说明：90% 是阿里健康的实测值，天猫、拼多多的具体自动化率取决于各自工单结构（如拼多多"仅退款"等平台特有规则占比），落地时以实测校准为准，但"标准工单可自动化"这一核心逻辑成立。
需说明：90% 是阿里健康的实测值，天猫、拼多多的具体自动化率取决于各自工单结构（如拼多多"仅退款"等平台特有规则占比），落地时以实测校准为准，但"标准工单可自动化"这一核心逻辑成立。
7优先级建议
P0 最核心：攻下 70% 自家店（天猫 + 拼多多）
- 把阿里健康已验证的自动化打法（实测 90% 自动化率）复制到订单量最大的天猫、拼多多自营店——这两家是自家主体、订单大头，效率提升空间最大（标准工单逻辑跨平台通用，详见第 6 节说明）
- 双轨并行：① RPA 打法立即铺量、快速拿效率；② 同步为自家店申请官方 API 通道（软著 / 开发者权限，主要是资质流程，不占开发人力），通道通了再迁移
- RPA 铺量的同时执行加固（拟人化 / 限流 / 降级预案），控制天猫、拼多多的风控敞口
P1 长期通道 + 30% 代运营
- 自家店 API 通道跑通后，把 RPA 流量逐步迁到 API，降风控
- 视推进节奏适当补充开发资源或外包 API 对接，支撑多平台并行
- 逐店确认 30% 代运营店主体归属：归公司→并入自家申请的 API；归品牌方→兜底三选一（品牌方申请 API / 挂靠 ISV SaaS / 维持 RPA+人工）
- 建立人工兜底与工单分流规则（标准走自动、非标转人工）
P2 优化扩展
- 接入阿里 AI 店小蜜等平台原生能力，补齐阿里系覆盖
- 控制 AI Agent 只用在高价值 / 难判定工单，优化 token 成本
- 沉淀售后知识库与自动化率、风控命中率监控看板