你一定经历过这样的崩溃时刻：
点开客服对话框，结果机器人却像复读机一样「请问有什么可以帮您」。
无论你怎么描述问题，它永远只会甩给你几篇 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% 的数字成果，而是团队在每一个技术决策和落地上的克制与务实。
没有追逐最“炫”的技术，而是选择最合适的方案；没有为了噱头而堆功能，而是专注让每次回答更准确一点。
这才是工程师文化的核心：注重细节乐盈配资，并用极客精神探索最合适的技术，解决最真实的问题。
万宝配资提示：文章来自网络，不代表本站观点。
