我用 3 天做了一个跨境电商客服 Agent Demo
从零到可演示:用交付包把跨境电商客服 Agent 的核心能力在 3 天内跑通,给客户看到真实效果。
背景:一个反复出现的问题
AI 服务商在拜访跨境电商客户时,几乎每次都会被问到同一句话:“你们有没有跑通过的 Demo?”
这句话背后有两层意思:第一,客户不信任 PPT,他们想看真实运行效果;第二,他们的时间有限,不愿意为一个“还在探索阶段”的服务商先付费。
本文记录我们如何用 3 天时间,从一个跨境电商客服的真实场景出发,用交付包快速搭出一个可演示的客服 Agent。
Day 1:场景锁定与数据准备
第一天最重要的事不是写代码,而是锁定演示场景。我们选择了跨境电商最高频的五类问题:物流查询、订单状态、退款退货、尺码咨询、多语言 FAQ。
数据准备包括:从客户或公开数据中整理一份 FAQ 文档(约 50 条问答)、一份模拟订单表(含物流号、状态字段)、一套退换货规则说明。
这些数据是 Agent 能回答问题的基础,脱离真实数据的 Demo 很难打动客户。
- FAQ 文档:中英双语,覆盖物流、退款、尺码、产品信息四个模块
- 模拟订单表:20 条记录,字段包含 order_id / status / tracking_number / logistics_provider
- 退换货规则:纯文本即可,Agent 会引用原文作答
- 人工转接条件:明确哪些问题不能由 Agent 处理(如投诉、金额争议)
Day 2:接入交付包,跑通核心流程
交付包提供了一套已调试好的 Prompt 架构,包含 System Prompt 模板、工具调用定义(查订单、查物流)、多语言识别逻辑和人工转接判断规则。
我们只需要把第一天准备的数据填进去,替换演示用的接口地址,就可以在本地跑起来。整个过程大约 4 小时。
跑通之后,我们做了约 30 轮手动测试,重点覆盖幻觉场景(问没有的订单)、工具调用失败(接口超时)、恶意注入(用户试图绕过规则)。
- System Prompt 替换:品牌名、语气风格、禁止回答的话题
- 工具调用:将查订单接口指向本地 mock JSON
- 多语言:测试中文、英文、西班牙文混入的情况
- 人工转接:触发关键词后验证是否返回转接提示
Day 3:打磨演示流程,准备话术
Demo 能跑通和“演示”是两回事。第三天的核心任务是设计演示脚本——哪几个问题先问、哪个问题用来展示工具调用、用哪个失败场景展示人工转接。
我们准备了 6 个演示对话,刻意包含一个“Agent 不知道答案、诚实说不知道”的场景——这个场景往往比完美回答更能赢得客户信任。
最后,把演示界面做成一个简单的网页聊天框,客户自己可以输入问题,不需要我们操作。
演示当天:客户反馈
演示当天,客户问了 10 多个问题,包括几个他们刻意设计的“刁难问题”。Agent 在 8 个问题上给出了准确回答,2 个触发了人工转接,1 个诚实回答了“这个信息我没有,需要人工确认”。
客户的评价是:“比我想象的靠谱。” 这已经是跨越“是否要继续谈”这道门槛所需要的最低标准。
3 天的核心价值不是做一个完美的系统,而是用最短时间证明“这件事可以做”。
关键经验
- 场景越窄越好:第一个 Demo 只覆盖 5 类问题,不要贪多
- 数据真实性决定演示质量:用客户自己的 FAQ 效果远好于通用数据
- 演示脚本比代码更重要:提前设计 6 个对话,覆盖正常+边界+失败三种情形
- 幻觉和转接的处理是加分项:展示系统“知道自己不知道”比展示它“什么都能答”更重要
- 交付包的价值:省去的是 Prompt 架构设计、工具调用逻辑、测试用例设计这三块最耗时的部分
查看全部交付包,快速启动你的 Agent 项目