AfterShip 如何用 AI Agent 重塑客服体验？

你一定经历过这样的崩溃时刻：

点开客服对话框，结果机器人却像复读机一样「请问有什么可以帮您」。

无论你怎么描述问题，它永远只会甩给你几篇 FAQ 链接。

最后，你不得不在「转人工」按钮上疯狂点击，然后在漫长的等待中怀疑人生。

但如果我告诉你，有一家公司把 AI 客服的问题解决率从 25% 提升到了 43%，并 让它真正能像人类客服一样能查系统、看截图、主动追问、甚至还会主动帮你接入人工客服，你相信吗？

这不是概念，而是 AfterShip 的算法和技术团队最近完成的一次技术升级。

今天，我们就来揭秘这次客服系统升级背后的故事。

一、为什么要升级 ？当客服团队被淹没在重复的海洋里

作为全球领先的电商 SaaS 平台，AfterShip 每个月要处理几十万条客户咨询。其中大部分都是重复性问题，比如：

「我的包裹到哪了？」「为什么物流状态不更新？」「订单怎么查不到？」

这些问题看似简单，却消耗了客服团队的大量精力。

更致命的是，这些咨询者很多并非 AfterShip 的直接客户，而是「客户的客户」——使用 AfterShip 服务的电商平台和品牌的 C 端用户。

结果就是：

客服团队的精力，被 C 端用户的海量低价值问题分散，而真正需要深度服务的 Enterprise（企业级）客户，反而得不到足够关注。

传统的解决做法是招更多客服，但这只会让成本不断飙升，并且治标不治本。

而上一代 AI 客服？只会查知识库和机械式复读的客服机器人，问题解决率仅有 25%。

于是，AfterShip 决定重新设计客服系统，迭代 Support 聊天机器人为客服 AI Agent，让 AI 真正变成既能思考、也能执行的「数字员工」。

二、技术架构：让 AI 既能思考，也会执行

2.1 无状态设计：简单，但更高效

大多数 AI 客服系统会在后端保存完整对话历史，构建“记忆系统”。

但 AfterShip 选择了另一条路——无状态设计。

每次请求时，业务系统会将完整的历史对话上下文传入，Agent 处理后返回结果，自身不保留状态。

这种看似“舍弃记忆”的做法，背后其实是深思熟虑的权衡：

• 对话记录早已有存储：业务数据库和前端都已保存完整对话。
• 减少重复维护：Agent 侧再建一套 Memory，不仅浪费资源，还带来数据一致性风险。
• 系统更易扩展：任何调用方都能轻松接入，Agent 无需依赖上下文缓存。

只有在确实需要“长期记忆”时（如上下文摘要、Agent 学习记录），系统才会启用轻量级 Memory 模块。

这让维护成本降低约 80%，同时为未来的 Context Engineering（上下文工程）留出了空间。

2.2 模型选择：平衡速度、可靠性与成本

选择大模型就像选车：你不可能同时要速度快、性能好、还便宜。

AfterShip 技术团队总结了 Agent 的「不可能三角」：

• 可靠性 (Reliability)：回答准确、工具调用稳定
• 速度 (Speed)：响应快、生成快
• 成本 (Cost)：API 调用费用低

经过大量测试，团队总结了部分大模型的特点：

在 Support Agent 这个场景下，对 Agent 能力要求如下：

• 生成速度快：推理速度要快。在实时对话场景中，无法实现“打字机”效果，因此仅有较快的 TTFT（Time to First Token）无法提升用户体验，必须保证端到端（TTFT + TPS + Tool Calling）的快速输出。
• 生成结果可靠：要求模型至少达到 Top-1 水平，能够处理各种边界情况，同时保证 Tool Calling 过程的稳定性。
• Context 容量较大：由于当前 Agent 的相关基建还在持续建设，很多 Context Engineering 的技巧还无法尽情施展。为了可以让 Agent 能接收较多的 Context，LLM Context 容量也需要相对较大。
• 支持多模态输入：用户经常会上传截图询问客服，少数会话甚至包含音频、视频。因此，所选模型必须具备多模态处理能力。
• 成本友好：模型的使用成本需与当前业务场景匹配。

综合判断下来，我们选择 gemini-2.5-flash 作为常规模型。

当然，随着接入工具增多、调用链路变复杂，2.5 Flash 未来可能需要升级到 Gemini 2.5 Pro，以应对更复杂场景。

2.3 工具体系：从「查答案」到「真干活」

这是本次升级的核心亮点。传统 AI 客服只会查知识库，而 AfterShip 的 Support Agent 拥有完整的内外部工具调用能力：

内部工具（提升对话质量）：

• 知识库查询（匹配 How-to 文档、FAQ）
• 问题分类（自动打标签）
• 智能判断何时需要人类介入
• 对话摘要生成（转人工时提供上下文）

外部工具（真正的干活能力）：

• Tracking Tool：当用户问「为什么物流不更新」，AI 会自动调用接口刷新状态
• Courier Tools：查询快递公司信息
• Order Tools：查询订单详情
• Detect Tools：问题检测与诊断

举个实际案例：用户：「我的包裹显示已签收，但我没收到！」

传统 AI：复读 FAQ → 用户崩溃 → 转人工

AfterShip AI Agent 客服：

调用 Order Tool 查询订单号 ️ 调用 Tracking Tool 查看物流详情 ️ 发现物流商数据异常 ️ 调用 Refresh Tool 刷新状态 ️ 发现实际未签收，向用户解释并提供追踪链接 ️ 如仍无法解决，生成问题摘要转人工

这使得 AI 不再只是一个问答机器，而是真正能“动手”解决问题的数字同事。

2.4 协议层：AG-UI 协议的标准化和灵活性

为了让前端、后端、不同业务模块的 Agent 能高效协作，AfterShip 采用了 AG-UI（Agent UI）协议，这是一套标准化的 Agent 通信规范。

时序图：

为什么要选择标准协议？主要有三个考量：

一是解耦前后端：前端不需要关心后端用什么框架（LangChain、LangGraph 还是其他）。

二是能快速接入：任何遵循协议的客户端都能直接调用 Agent。

三是全链可监控：每个事件节点都能追踪，便于调试。

目前，Agent 之间的调用，也通过 A2A（Agent-to-Agent）协议 实现标准化互通，为多 Agent 协作奠定了基础。

三、从细节出发：优化落地体验

3.1 多模态理解：看懂用户的截图

过去，当用户上传截图时，AI 只能机械回复「请描述您的问题」，体验极差。现在，AfterShip 的 Agent 已能直接识别图片内容。

例如，当用户上传一张「Error 403: Access Denied」的截图时，系统会： 1️⃣ 识别截图文字； 2️⃣ 判断为权限问题； 3️⃣ 查询用户账户状态； 4️⃣ 返回具体解决方案。

这种能力的背后，是多模态识别在客服场景的首次深度应用。它让 AI 能“理解”用户所见，减少了来回沟通。

3.2 主动追问：AI 学会了「反问」

早期版本中，如果用户问题模糊（比如输入「创建不了」），AI 通常会直接调用知识库，结果往往答非所问。

升级后，AI 会主动追问：

• 「您具体是在创建什么时遇到问题？」
• 「方便提供截图或错误信息吗？」
• 「这个问题是从什么时候开始的？」

这种「追问能力」让问题解决率提升了 15 个百分点。

3.3 防偷懒机制：让 Agent 强制按规则执行

大语言模型有个「坏习惯」：在多轮对话中喜欢偷懒，不调用工具。

比如业务要求每条 Query 都要生成 Category 分类标签，但测试发现 AI 在第 3、4 轮对话时，经常「忘记」调用分类工具。

为此，团队增加了一个后处理层：系统会在每次 Agent 输出后自动检测是否调用了指定工具；如未调用，则强制补调。

这种「防偷懒机制」让工具调用率保持在 100%，也体现了团队对「AI 不可全信」的工程理解 ——关键逻辑，必须有护栏。

3.4 安全防护：从 MCP 漏洞中学到的教训

在升级的前一天，安全团队提前发现了一个由 MCP 引发的潜在漏洞：

攻击者有可能可以通过精心设计的 Prompt，让 AI 调用了 Tracking 查询工具，获取其他节点信的数据！

问题暴露后，团队立即采取措施：

• 关闭存在风险的 MCP Server
• 推行 JWT 鉴权机制：所有工具调用必须带用户身份 Token
• 在工具层做二次校验：拒绝任何异常参数请求。

这次事件让团队重新认识到：

再强的 Prompt 防护，都不如代码级别的安全限制。

涉及用户数据的调用，永远需要“人类思维”来兜底。

四、效果与挑战：43% 只是开始

AI 升级上线的第一个月，团队重点关注了 4 个核心指标：问题解决率、延迟、工具调用、以及多模态支持。

4.1 数据说话

43% 并不是一个“炫目”的数字，但它意味着：

• 每月减少上万次人工客服介入低价值问题
• 客服团队可以专注 Enterprise 客户
• 用户平均等待时间从 15 分钟降至 5 分钟

这些变化的背后，不仅是模型的升级，更是架构与流程的整体优化。

4.2 剩下的 57%，为什么还解决不了？

团队系统分析了所有转人工的 Case，发现主要原因有：

这些数据让团队更清楚地看到下一步优化的方向：

• 扩展工具权限：让 AI 能安全执行部分低风险操作（如查询、修改基础字段）。
• 情绪识别与优先转接：识别愤怒语气并自动安抚或转人工。
• 用户角色澄清：在界面明确提示「我是 AfterShip 客服，不是商家客服」。

4.3 技术瓶颈：Prompt 的尽头是什么？

随着系统复杂度提升，AfterShip 团队也发现仅靠「调 Prompt」和「加记忆」难以持续提升。

目前的迭代过程是：收到 Bad Case → 人工分析 → 调整 Prompt → 上线测试

这个循环效率低、可迁移性差，也容易陷入“人工修补循环”。

于是我们开始探索一种新的方式：Agent 微调（Fine-tuning for Agents）。

传统模型微调是调参数，但 Agent 微调是调 Memory：

• 收集 Good Case 和 Bad Case
• 让 AI 学习「在场景 A 用方法 A 成功了」
• 让 AI 学习「在场景 B 用方法 C 失败了」
• AI 自动构建决策 Memory，下次遇到类似场景时调用最优策略

未来，Agent 还将具备「自我改进（Self-Improvement）」能力： 当系统检测到用户不满意时，AI 会自动复盘并更新内部策略，下次遇到类似问题时尝试不同解法。

目前，这套机制仍在测试阶段，但它标志着 AfterShip 正在向真正的「可自我优化系统」迈进。

五、给开发者和企业的启示：打造 Super Agent 的 4 条经验

如果你也想构建类似的客服 AI Agent 系统，这里有 4 条血泪经验：

1️⃣ 选模型看场景，不要迷信「最强」

• 实时对话场景：速度 > 能力，选 Gemini Flash
• 复杂推理场景：能力 > 速度，选 Claude 或 GPT
• 成本敏感场景：优先开源模型 + 自建推理

2️⃣ 无状态设计是银弹还是陷阱？

• 如果业务侧已有完整存储，Agent 就该无状态
• 如果依赖上下文推理和多步任务 → 适度引入有状态缓存或短期记忆；
• 错误做法：业务侧和 Agent 侧存两份一样的数据

3️⃣ 安全是生命线

• 原则 1：涉及隐私数据的工具，必须后端二次校验
• 原则 2：用 JWT 而非 API Key 做鉴权
• 原则 3：定期做渗透测试，别等安全团队找上门

4️⃣ 建立 Human-in-the-Loop 机制，让 AI 和人类真正协作

• 让客服团队评估 AI 回答质量，按满意度分级
• 收集 Bad Case 但不要只靠人工修复
• 终极目标：让 AI 从 Bad Case 中自我学习

六、未来已来：Agent 时代的客服长什么样？

AfterShip 的客服 Agent 升级只是开始。

可以预见未来 3 年内，Agent 会成为每个部门和职场人的标配：不只客服，销售、财务、HR 都会有专属 Agent。

随着 Agent 能力以及 多 Agent 协作的不断成熟，系统将逐步迈向 Zero Human Intervention —— 95% 的常规问题将实现完全自动化解决。

但无论 AI 多么强大，有一点始终是不会变的：

真正需要同理心、创造力和战略决策的工作，依然属于人类。

AI 的到来，不是为了取代人，而是来把我们从重复劳动中解放出来去做更有价值的事。

AfterShip 的这次升级，真正核心的地方，并不是 43% 的数字成果，而是团队在每一个技术决策和落地上的克制与务实。

没有追逐最“炫”的技术，而是选择最合适的方案；没有为了噱头而堆功能，而是专注让每次回答更准确一点。

这才是工程师文化的核心：注重细节，并用极客精神探索最合适的技术，解决最真实的问题。