> 上一篇写了 Nubank、Anthropic、OpenAI 三个国外案例。有读者问：**国内的呢？** > > 这篇专门讲国内。三个案例分别来自零售（周黑鸭）、电商（抖音电商）和消费电子（OPPO），都是**已经上线运行的生产系统**，不是 PPT。 > > 每个案例包含：遇到什么问题 → 怎么设计架构 → Agent 扮演什么角色 → 配了什么工具 → 效果如何。 --- ## 案例一：周黑鸭 × 实在智能 — 600 小时/月对账自动化 ### 背景：50 个平台、90 个系统的数据孤岛周黑鸭是港股上市的休闲零食连锁品牌，全国上千家门店。它的业务同时入驻了 **50+ 电商平台**（美团、饿了么、抖音、京东等），内部有 **约 90 个系统**（ERP、WMS、CRM、BI 等）。每月财务对账时，员工需要在几十个系统之间来回切换： - 从电商平台导出订单数据 - 从 ERP 导出库存数据 - 从 WMS 导出物流数据 - 人工逐笔核对、标记差异 - 发现异常后再回到对应系统查证 **每月对账耗时约 600 小时**，涉及 8 名财务人员全职投入。 ### 架构设计 ```mermaid graph TB subgraph 数据源 P1[50+ 电商平台
美团/饿了么/抖音/京东] P2[ERP 系统
SAP/金蝶] P3[WMS 仓储系统] P4[CRM 会员系统] P5[BI 报表系统] end subgraph Agent-核心决策层 TARS[TARS 垂直大模型
决策中心] PLAN[任务规划引擎
自然语言→步骤分解] JUDGE[异常判断引擎
数据差异检测] end subgraph 执行层-RPA引擎 RPA[RPA 自动化引擎
非侵入式 UI 操作] ISSUT[ISSUT 屏幕语义理解
视觉识别+语义解析] HEAL[自愈机制
UI 变化自动适应] end subgraph 输出 R1[自动对账报告] R2[异常标记+原因分析] R3[自动触发补货/调拨] end P1 --> RPA P2 --> RPA P3 --> RPA P4 --> RPA P5 --> RPA RPA --> ISSUT ISSUT --> TARS TARS --> PLAN TARS --> JUDGE HEAL --> RPA JUDGE --> R1 JUDGE --> R2 JUDGE --> R3 style TARS fill:#fff3e0 style RPA fill:#e3f2fd style HEAL fill:#e8f5e9 ``` ### 核心技术：非侵入式操作 + 自愈机制传统自动化需要对接 API，但周黑鸭的 90 个系统中很多**没有开放 API**。实在智能的方案是： **非侵入式操作** — Agent 像"数字员工"一样，通过**视觉识别**操作电脑界面： - 识别屏幕上的按钮、输入框、表格 - 模拟人类的点击、输入、复制粘贴操作 - 不需要任何 API 接口或系统改造 **自愈机制（关键创新）**： ```mermaid graph LR A[UI 发生变化
按钮位置移动] --> B{ISSUT 视觉识别} B -->|语义匹配成功| C[定位新位置
继续执行] B -->|匹配失败| D[暂停任务
通知人工] D --> E[人工标注新位置] E --> F[更新视觉模型] F --> C style C fill:#c8e6c9 style D fill:#ffebee ``` 比如"提交"按钮从页面左侧移到右侧，传统 RPA 会报错停止。但 ISSUT 通过**语义理解**（识别"提交"这个词的含义）自动找到新位置，任务不中断。 ### Agent 角色分工 | 环节 | Agent 做什么 | 人做什么 | |------|-------------|---------| | 数据采集 | 自动登录 50+ 平台，导出报表 | 配置账号权限 | | 数据清洗 | 统一格式、去除重复、补全缺失 | 制定清洗规则 | | 对账核对 | 逐笔比对、标记差异 | 审核异常项 | | 异常分析 | 定位差异原因（退货/折扣/手续费） | 处理特殊异常 | | 报告生成 | 自动生成对账报告+建议 | 审批决策 | | 联动触发 | 库存不足→自动触发紧急采购 | 确认采购单 | ### 结果 | 指标 | 之前 | 之后 | |------|------|------| | 月度对账时间 | 600 小时 | **每日自动运行 14 小时** | | 涉及人员 | 8 名财务全职 | **8 人释放做分析工作** | | 年节省成本 | — | **约 188 万元/年** | | 准确率 | 人工 ~98% | **自动化 ~100%** | | 投资回收期 | — | **6-12 个月** | > 同平台案例 — **太平鸟（服装零售）**：30 家门店、1000+ 数据类型自动化后，人工干预从全职降到**每周仅 1 小时**，效率提升 **300%+**，成本降低 **80%**。 --- ## 案例二：抖音电商 × 扣子(Coze) — 多 Agent 协作客服系统 ### 背景：关键词匹配客服的瓶颈抖音电商的商家客服面临三个痛点： 1. **传统客服机器人靠关键词匹配**，不配置就回复不了，灵活性差 2. **机械式单轮问答**，无法理解上下文，经常答非所问 3. **大促期间咨询量暴增**，人工排队时间长，流失率高 ### 架构设计：多 Agent 流水线抖音电商没有用一个"万能 Agent"，而是把客服流程拆成**多个专业 Agent 协作**： ```mermaid graph TB USER[用户消息] --> GREET[寒暄收尾 Agent
识别问候/感谢/告别] GREET --> CLARIFY[问题澄清 Agent
补充缺失信息
确认用户意图] CLARIFY --> ROUTE{场景路由 Agent
意图分类} ROUTE -->|订单查询| S1[订单状态查询
对接订单系统] ROUTE -->|物流咨询| S2[物流信息查询
对接物流系统] ROUTE -->|售后问题| S3[售后服务 Agent
退款/换货/维修] ROUTE -->|产品咨询| S4[产品推荐 Agent
属性+知识库匹配] ROUTE -->|投诉建议| S5[人工转接
情感识别触发] S1 --> JUDGE[判断解决方案 Agent
评估回复质量+风险] S2 --> JUDGE S3 --> JUDGE S4 --> JUDGE JUDGE --> EXEC[协商执行 Agent
生成最终回复] EXEC -->|低风险| REPLY[自动回复用户] EXEC -->|高风险| HUMAN[人工审核] HUMAN --> REPLY style ROUTE fill:#fff3e0 style JUDGE fill:#e8f5e9 style HUMAN fill:#ffebee ``` ### Agent 角色定义每个 Agent 有明确的职责边界： | Agent | 职责 | 技术实现 | |-------|------|----------| | 寒暄收尾 | 识别问候/告别，维持对话温度 | 分类模型 + 情感分析 | | 问题澄清 | 当用户描述模糊时追问细节 | 多轮对话管理 + 槽位填充 | | 场景路由 | 将用户意图分发到专业 Agent | 意图分类（5 大类 + 子类） | | 判断方案 | 评估回复是否准确、是否有风险 | 质量评分模型 + 风险阈值 | | 协商执行 | 生成自然语言回复 | LLM + 产品属性知识库 | ### 人机协作模型抖音电商设计了一个**"有效干预率"**指标来评估人机协作质量： ```mermaid graph LR subgraph 评估维度 A[AI 回复质量
准确率/满意度] B[人工干预必要性
干预是否真的有用] C[自学习效果
干预后 AI 是否改善] end A --> SCORE[有效干预率
综合评分] B --> SCORE C --> SCORE SCORE -->|高| GOOD[模型表现好
减少人工干预] SCORE -->|低| BAD[需要优化
增加训练数据] style SCORE fill:#fff3e0 ``` **关键创新**：不只评估 AI 的表现，还评估**人工干预是否真的有必要**——避免"过度纠正"反而降低效率。 ### 结果 - 部分场景实现**全自动处理**，无需人工介入 - Agent **越用越聪明**，回答准确率持续提升 - 解决方案已**开源到扣子模板商店**：`coze.cn/s/uM1e-yIzEzo` - 探域科技等多家企业基于同一架构搭建了定制化客服方案 --- ## 案例三：OPPO × 百度文心智能体 — 多语种智能客服 ### 背景：全球化客服的语言壁垒 OPPO 在东南亚市场（越南、印尼等）面临客服挑战： - 用户用**口语化表达**描述手机问题，传统 FAQ 匹配不到 - 客服回复使用**技术术语**，用户听不懂 - **越南语、印尼语**等小语种客服人力稀缺 - 服务质量完全依赖**个别老员工经验**，无法复制 ### 架构设计 ```mermaid graph TB subgraph 用户触点 U1[中文用户] U2[越南语用户] U3[印尼语用户] end subgraph 知识层 KB[10万+ 篇服务经验文章
RAG 检索增强] EMB[向量嵌入引擎] RET[Top-K 相似度检索] end subgraph Agent-推理层 LLM[文心大模型
芯云模体全栈基础设施] NLU[口语理解模块
技术术语→通俗解释] ML[多语言生成模块
中/越/印尼语] end subgraph 输出 R1[通俗中文回复] R2[越南语回复] R3[印尼语回复] end U1 --> KB U2 --> KB U3 --> KB KB --> EMB --> RET --> LLM LLM --> NLU --> ML ML --> R1 ML --> R2 ML --> R3 style KB fill:#e3f2fd style LLM fill:#fff3e0 style ML fill:#e8f5e9 ``` ### 核心突破：从"个人经验"到"企业资产" OPPO 之前最大的痛点是：**优秀的客服经验锁在老员工脑子里**。通过文心智能体的 RAG 架构，10 万+ 篇历史服务案例被转化为**可检索、可复用的企业知识资产**： ```mermaid graph LR subgraph 之前 A[老员工经验
不可复制
离职即流失] B[知识碎片化
散落在各系统] C[新人培训慢
3-6 个月上手] end subgraph 之后 D[10万+ 知识条目
结构化存储] E[实时检索
秒级匹配] F[新人即插即用
Agent 辅助回复] end A --> D B --> E C --> F style D fill:#c8e6c9 style E fill:#c8e6c9 style F fill:#c8e6c9 ``` ### 结果 | 指标 | 提升 | |------|------| | 高频问题处理效率 | **2x（翻倍）** | | 越南语/印尼语表现 | **优秀** | | 服务质量 | 从**依赖个人**→**标准化企业资产** | > 同平台其他案例： > - **银河证券**：交易 Agent 将询价到下单转化效率提升 **3x** > - **百信银行**：风控 Agent 用 LLM 自进化风险特征，显著提升识别率 > - **阿尔特汽车**：气动 Agent 将风阻测试从 **10 小时 → 分钟级** --- ## 三个案例的共同启示 ```mermaid graph TB subgraph 启示一-选择正确的切入点 I1[周黑鸭：选了最耗人力
的重复性对账任务] I2[抖音：选了咨询量最大
的客服场景] I3[OPPO：选了人才最缺
的小语种服务] end subgraph 启示二-人机协作不是全自动 I4[关键决策仍由人做
Agent 执行+建议] I5[有效干预率指标
量化人机协作质量] I6[持续反馈循环
Agent 越用越准] end subgraph 启示三-非侵入式部署 I7[不改造现有系统
Agent 通过 UI 操作] I8[视觉识别+语义理解
适应 UI 变化] I9[零代码拖拽设计
业务人员可配置] end I1 --> I4 --> I7 I2 --> I5 --> I8 I3 --> I6 --> I9 style I1 fill:#e3f2fd style I4 fill:#fff3e0 style I7 fill:#e8f5e9 ``` ### 国内 AI Agent 落地的三个实用建议 1. **从"数字员工"思维开始** — 不要想着 AI 取代人，而是设计一个"数字员工"做最枯燥的部分。周黑鸭的 600 小时对账就是典型的"没人愿意做但必须做"的任务。 2. **优先选非侵入式方案** — 国内企业系统复杂（ERP/WMS/CRM 五花八门），API 对接成本极高。实在智能的视觉识别方案证明：**不碰系统内部，只操作界面**，反而是更务实的路径。 3. **知识资产化比自动化更重要** — OPPO 的案例最有价值的一步不是"自动回复"，而是把 10 万篇经验文档变成了可检索的知识库。**从"人在做"到"Agent 读了再做"**，这是质变。 --- **数据来源：** - 周黑鸭 × 实在智能：ai-indeed.com 官方案例、CSDN 技术详解 - 抖音电商 × 扣子：火山引擎开发者社区 (developer.volcengine.com) - OPPO × 百度文心：科技日报 2026-03 报道、百度智能云案例 - 太平鸟/银河证券/百信银行/阿尔特汽车：百度智能云年度报告

AI Agent 国内企业落地：三个从设计到生产的完整案例