很多朋友问我，这套售后机器人的“脑子”到底是怎么长的？为什么它既能听得懂买家五花八门的抱怨，又能准确无误地操作后台退款？其实这就涉及到这套系统的核心技术架构——智能对话（AI大脑）和自动化执行（RPA手脚）是怎么配合的。我自己不是技术大牛，但在跟技术团队反复磨合的过程中，也算搞懂了这套组合拳的门道。今天就用最通俗的大白话，跟大家聊聊这个架构是怎么设计和落地的。
常见的两种技术路线：纯RPA vs RPA+AI大模型
最初选型的时候，我在这两种路线之间犹豫了很久。市面上一些老牌的RPA工具（像影刀、UiPath）属于第一类；而新兴的AI智能客服（像晓多、乐言）属于第二类。但我们要做的是售后处理，不是单纯的聊天，所以需要既懂业务又懂对话的架构。
| 技术路线 | 纯RPA流程自动化 | RPA+AI大模型（我们选的） |
|---|---|---|
| 核心逻辑 | 模拟人工点击、输入，按固定规则执行操作 | AI理解语义后动态生成策略，RPA负责执行 |
| 适用场景 | 企业内部报表生成、数据迁移等重复性高、无变动的任务 | 面向消费者的售后处理，语义多变、规则复杂 |
| 对“人话”的理解 | 只能识别关键词（如“退款”），无法理解上下文 | 能理解意图（如“快递被狗叼走了”=物流异常） |
| 灵活性 | 低，平台页面改版就失效 | 高，重点走API接口，UI变化影响较小 |
| 开发难度 | 较低，主要是录屏和流程编排 | 较高，需要调优大模型 + 开发RPA脚本 |
| 典型风险 | 无法处理未定义的新场景，容易报错 | 大模型“幻觉”风险，可能乱承诺赔付 |
对比下来，我们的业务面对的是真实消费者，他们的表述千奇百怪，纯RPA搞不定。而纯AI客服虽然会聊天，但它没法自己动手改订单状态。所以，RPA+AI大模型融合架构是我们唯一的选择。
双核驱动：AI大脑如何精准“听懂”人话
这套架构的第一步，是让机器理解买家到底想要什么。我们用的是行业专属大模型+精细意图识别体系。
这不是用通用的文心一言或者ChatGPT直接接进来，而是把过去两年店铺积累的所有客服聊天记录、售后工单数据，经过清洗和脱敏后，喂给大模型进行微调训练。这样训练出来的模型，才能准确识别我们特定行业的黑话和客户情绪。
我们设定了四级意图识别体系，给大家举个例子：
- 一级意图（售后类）：买家说“我想退货” -> 进入售后处理分支。
- 二级意图（退货原因）：“质量不好” -> 分支A；“买错了” -> 分支B；“不想要了” -> 分支C。
- 三级意图（具体诉求）：“运费谁出？” -> 触发运费险解释话术；“什么时候退钱？” -> 触发退款时效查询。
- 四级意图（情绪识别）：检测到“投诉”、“差评”、“再也不买了”等极端情绪词汇 -> 自动标记为高优先级，并触发人工介入预警。
这套组合拳打下来，我们在双11大促期间，意图识别准确率确实稳定在了98%以上，极少出现答非所问的情况。
手脚协同：RPA是如何“无痛”操作后台的
理解了意图之后，关键就是怎么执行。RPA在这里扮演了“机械手”的角色。
这里要特别强调一下RPA的两种实现方式，也是选型时的大坑：
- UI自动化（界面元素抓取）：像影刀这类工具，本质是录屏。它记住的是“屏幕上(x:100, y:200)位置有个按钮”，然后模拟点击。缺点很明显：只要平台页面改版（哪怕换了个颜色或挪了个位置），脚本就失灵了。
- API自动化（接口调用）：这是更高阶的做法。RPA直接调用电商平台公开的API接口，通过数据交换来完成操作（比如调用taobao.refund.apply接口直接发起退款）。优点：不受页面UI变动影响，速度快，稳定性极高。
我们强烈要求开发团队采用API优先（API First）策略。能走接口的，坚决不模拟点击。只有在极少数没有开放API的环节（比如某些平台的赠品核销），才用UI自动化作为辅助，并设置了严格的异常重试和告警机制。
举个实际的执行链路例子：
- 步骤1：买家在抖音发来消息：“这个衣服质量太差了，我要退货。”
- 步骤2：AI大脑分析意图 -> “退货退款” + “质量原因”。
- 步骤3：决策引擎（我们加的中间件）判断：该订单金额89元 < 自动退货阈值200元，且该买家信誉良好。
- 步骤4：RPA执行器启动：
- 调用抖音API 创建退货售后单（售后类型：退货退款，原因：质量问题，备注：已授权）。
- 调用抖音API 发送客服消息（内容：亲，抱歉给您带来困扰，已为您开通退货入口，请点击填写单号）。
- 步骤5：等待买家填单。
- 步骤6：检测到买家填单后，RPA调用ERP接口 创建退货入库单（等待仓库收货）。
- 步骤7：仓库PDA扫码确认收货，回传消息。
- 步骤8：RPA调用抖音API 确认收货并执行退款。
整个流程行云流水，全程不需要任何人工去后台操作界面。
风控与安全：在“自动”和“可控”之间找平衡
自动化虽然爽，但安全永远是第一位的。我在架构设计时特别强调了三层护栏：
第一层：操作阈值护栏。RPA执行任何退款操作前，必须过一道“闸门”。比如：
- 单笔退款金额 > 200元 -> 暂停自动执行，推送待审核工单。
- 该买家近30天退款次数 > 3次 -> 标记为高风险，暂停自动执行。
- 当前店铺剩余可流动资金 < 1万元 -> 暂停所有自动退款任务。
第二层：数据日志护栏。所有RPA的操作，不论成功还是失败，都要记录详细的操作日志（包括时间、操作人/机器人、接口返回报文、IP地址等）。这不仅是审计需要，万一出了BUG导致误退款，这是唯一的回溯证据。
第三层：AI回复审计护栏。大模型回复的话术虽然能根据上下文生成，但涉及金额、日期、承诺的部分，我们设置了正则表达式规则强制覆盖。比如无论AI怎么发挥，话术中涉及“赔偿金额”的地方，只能用我们规则里设定好的数值（如“补偿您5元优惠券”），防止AI乱承诺导致资损。
避坑指南：架构设计中容易被忽略的技术细节
这里再唠叨几句纯技术层面的坑：
- 接口调用频率限制：各大电商平台的API都有QPS（每秒查询率）限制。比如淘宝API限制每秒最多调用5次。你的RPA设计必须内置限流器，不能一股脑全冲过去，否则会被平台封禁IP。我们要把任务均匀打散，模拟人工低频操作。
- 会话状态管理：当客服在一个会话里处理多个问题时，AI需要记住上下文。比如买家先说“我要退货”，AI给了地址，买家又说“算了不退了”。这时候系统要能把关联的RPA任务（退款单）同步撤销或暂停，否则就会出现“买家说不退了，机器人还在后台申请退款”的乌龙。
- 大模型部署位置：如果你们的业务涉及大量客户敏感信息（如地址、电话），强烈建议大模型私有化部署。如果因为成本原因只能用公有云API，那必须对传输数据进行脱敏处理（比如把“张三，电话138****1234”替换成“客户A”），确保不外泄。
- 异步处理与消息队列：不要把AI解析、规则判断、RPA执行全部塞在一个同步进程里，那样响应太慢且容易崩溃。要用消息队列，把任务解耦。比如AI解析完意图后，生成一个“退款任务”丢进队列里，RPA Worker从队列里捞任务去执行，这样即使RPA卡住了，也不会影响AI接收新的买家咨询。
常见问题解答（FAQ）
问：大模型会不会回答错误导致激怒客户？ 答：会的，这就是“幻觉”问题。我们的应对是：关键场景（催发货、申请售后）用固定模板+变量填充，不用生成式AI自由发挥。只有在闲聊、安抚情绪等非关键场景才让大模型自由生成。另外，设置了满意度回访，一旦客户回复“不满意”或“人工”，立刻转接。
问：多个店铺共用一个RPA机器人，账号切换会不会出问题？ 答：我们的架构里有独立的账号凭证保险箱，所有店铺的登录Token加密存储。RPA执行任务时，会根据店铺ID去保险箱动态拉取对应的Token，模拟该店铺身份操作。Token过期时，系统会发短信通知管理员重新授权，不会硬跑导致失败。
问：系统上线后，需要配置专门的技术人员维护吗？ 答：基本不需要。日常维护主要是监控日志和调整退款策略阈值（比如大促期间手动调高自动退款上限），这些业务人员（客服主管）通过后台可视化界面就能配置。只有遇到平台接口版本升级或重大BUG时，才需要联系服务商技术支持介入。
问：如果平台没有提供某个操作的API接口，RPA是不是就做不了？ 答：可以用UI自动化（模拟点击）来补充。但我们需要对UI操作加双重确认：比如在点击“退款”按钮前，让RPA先截屏保存当前页面状态，并校验页面文本是否包含“确认退款”字样，确认无误再点击，降低误操作概率。同时，这类UI操作要定期人工复核。
问：AI大模型是越用越聪明吗？ 答：需要有数据反馈机制才能越用越聪明。我们的系统设计了“人工修正”功能——如果AI把“快递慢”识别成了“质量问题”，客服在后台纠正后，这条数据会自动进入标注库，定期用于模型再训练。如果不做这个闭环，模型就一直是初始状态，不会自我进化。