准确率达90%，用户却疯狂弃用，一遇问题转人工，AI客服竟比电话语音还糟！ 原创

编辑 | 云昭

出品 | 51CTO技术栈（微信号：blog51cto）

上周，我和一位最近刚上线 AI Agent 的 PM 聊天。指标看上去非常亮眼：89% 的准确率、毫秒级的响应、用户调研反馈积极。

但实际情况却很打脸，上线没多久，用户纷纷弃用了。

典型的场景就是，用户一旦遇到真正的问题，Agent 就秒变菜鸡了。 

比如，当用户同时遇到账单争议和账号被锁时：

“我们的 Agent 能完美处理常规请求，但面对复杂问题时，用户尝试一次不顺利，就立刻放弃转而找人工。”

其实，这个问题似曾相识，绝非个例。几乎所有做智能客服的团队都会踩这个坑：

很多团队不断把精力放在让 Agent “更聪明”上，但真正的挑战其实是架构决策，而这些决策决定了用户如何体验、如何逐步信任 Agent。

为什么有的 Agent 看起来“有魔力”，有的却让人抓狂，以及在架构上究竟该如何取舍？

小编刚刚读到了一篇ProductCurious社区上一位大牛今天发表的文章，可以说是把这些问题解释得非常透彻。

图片

AI Agent 的架构与产品决策问题，事关产品的成败。

我们将用一个客服 Agent 的例子，来展示不同的架构选择如何影响结果。还会看到一个反直觉的信任策略（提示：不是“更准确”），为什么它更有利于用户采纳。

一、用户究竟为什么会弃用？

假如你要做一个帮助用户处理账号问题的 Agent——重置密码、账单咨询、套餐变更等等。

但如果用户这时候告知：“我无法登录账号，而且订阅似乎不对了”，这时候 Agent 到底应该怎么处理呢？

图片

场景 A：Agent 立即查询系统：发现昨天密码已重置但邮件未送达，同时账单异常导致套餐被降级。它解释清楚发生了什么，并提供“一键修复”选项。

场景 B：Agent 开始追问澄清：“你上次成功登录是什么时候？看到的报错信息是什么？能详细说下订阅问题吗？” 收集完信息后，它说：“让我帮你转接人工客服来核查账号和账单。”

很明显，A 明显优于 B。

同样的用户请求，同样的底层系统，却是两种完全不同的产品体验。

所以，用户不往往不是因为 Agent 笨而离开，而是因为：

体验不连续：简单问题能答，复杂问题就崩。

信任感缺失：Agent 自信满满，但结果不对。

所以，决定 Agent 成败的关键，不是准确率，而是：它在复杂、不确定场景下的表现。

二、四个Agent产品决策层

我们可以把 Agent 架构看成一个堆栈，每一层都是你必须做的产品决策。

图片

第 1 层：上下文与记忆（Agent 记住什么？）

决策：你的 Agent 该记多少？记多久？

这里不仅是是一个技术上的存储的问题，还涉及到理解的幻觉问题。记忆决定了 Agent 更像“机器人”还是“熟悉的同事”。

对于客服 Agent 而言，就需要判断：

• 只存当前对话，还是存用户完整历史？
• 是否记录用户使用习惯？
• 是否记下过往投诉？

因此，我们就需要管理这几类记忆，比如：

• 会话记忆：只记当前对话
• 客户记忆：跨会话的历史交互
• 行为记忆：使用模式（如常用移动端）
• 上下文记忆：账号状态、活跃订阅、近期活动

记得越多，越能预测需求，但也增加复杂性和成本。

第 2 层：数据与集成（接多深？）

决策：Agent 应该接入哪些系统？有多大权限？

接得越深，越难被替代，也越容易出故障。

对于客服 Agent 的选择如下：

• 只接 Stripe 的账单系统？
• 还是也接 Salesforce CRM、Zendesk 工单、用户数据库、审计日志？

多数团队会陷入“一口气集成所有系统”的陷阱，但成功案例往往只做 2-3 个关键集成，再根据用户需求逐步扩展。

第 3 层：技能与能力（你的差异化在哪？）

决策：Agent 应该具备哪些技能？深度如何？

这里决定你能否建立用户依赖。关键不是功能越多越好，而是选对能力。

客服 Agent 的决策思考如下：

• 只读账号信息？
• 还是能修改账单、重置密码、变更套餐？

每多一个技能，价值提升，但复杂性与风险也上升。

图片

实现提示：可以通过 MCP 让技能在不同 Agent 之间复用，而不是每次都重建。

第 4 层：评估与信任（用户如何预期？）

决策：你如何衡量成功，并向用户传达 Agent 的局限？

关键不是“更准确”，而是更可信。

客服 Agent 的决策考量如下：

• 是否展示置信度？
• 是否解释推理过程？
• 是否执行前都二次确认？

常见信任策略：

• 置信度提示：“我对账号状态很有把握，但账单细节需要再确认。”
• 透明推理：“我发现两次登录失败，付款方式也过期了。”
• 优雅边界：“这个账单问题较复杂，我转给拥有更多工具的专员。”
• 确认模式：什么时候直接执行，什么时候征求许可

反直觉发现：当 Agent 承认不确定性 时，用户的信任度反而更高。

三、那么，Agent架构该如何做？四种常见架构模式

理解层次后，Agent 产品开发面临的核心问题则是：

Agent 如何调用技能？技能如何访问数据？用户等待时如何评估？

这就涉及到编排模式。不同模式决定了你的开发体验、调试难度与迭代速度。

图片

1. 单 Agent 架构（入门）

一个 Agent 包办所有。

• 优点：简单易建、好调试、成本可控
• 缺点：复杂请求下容易昂贵，难以单独优化

大部分团队从这里起步，很多甚至无需升级。

2. 技能路由架构（需要效率时）

有一个路由器来分发任务给专门的技能。

• 优点：高效，可用便宜模型处理简单技能
• 缺点：技能间协调复杂，谁来决定何时交接？

MCP 在这里大显身手，标准化了技能暴露方式。

3. 工作流架构（企业最爱）

预定义流程，类似 LangGraph、CrewAI、AutoGen。

• 优点：可审计，合规友好，步骤可优化
• 缺点：边缘情况卡死，用户体验僵硬

4. 协作式架构（未来方向）

多个专门 Agent 用 A2A 协议协作。

• 愿景：如 Booking.com 的 Agent 和 美国航空的 Agent 自动对接解决跨系统问题。
• 现实：安全、计费、信任、可靠性问题尚未解决。调试极其困难。

图片

所以建议：如果大家正在学习开发 Agent，还是要从简单开始。单 Agent 架构能覆盖大多数场景。只有遇到实际瓶颈再增加复杂度。

四、关于信任的最大误区

但请记住：即使架构完美，如果用户不信任，Agent 依然会失败。

用户不会因为 Agent 永远正确而信任它，而是因为它“在犯错时还表现得那么理直气壮”。

简单举个例子更容易理解：

• bad 案例：Agent 自信满满地说“我已重置密码并更新账单地址”，结果用户仍然无法登录 → 技术问题变成了信任问题。
• good 案例：Agent 说“我 80% 确信这样能解决问题，如果不行，我会立即转人工。”

你看，虽然技术能力是一样的，但体验会截然不同。要打造可信的 Agent，需关注三点：

1. 置信度校准：说 60% 时，就真的要做到 60%。
2. 推理透明：展示检查过程与证据。
3. 优雅交接：触及边界时，顺畅转人工，并带上完整上下文。

很多时候，用户要的不是“更准确”，而是“更透明”。

五、一个毫无AI感的AI客服做法

“我真的不理解，怎么有人会直接把一堆工具和数据源交给 AI，让它们对客户开放使用。就用户体验来说，这简直糟透了，有时候甚至比电话语音菜单还差。

”一位非常厉害的网友也分享了自己帮企业打造智能客服的经验。“在我看来，应该慢慢、谨慎地过渡到 AI 优先的客服方式！”

1.明确 AI 的能力范围：只允许它解决那些高概率能搞定的问题。提示语可以是：“你只能帮助处理以下问题。”

2.立刻转人工：如果超出范围，就立即转交人工，比如“如果你不能帮忙，立刻转人工。”

3.“解锁代理”机制：给客服人员配一个 AI，他们可以用它来回答问题，并评估效果，用这些反馈来推动开发路线。

4.逐步扩展范围：如果“解锁代理”在某类问题上表现不错，就把它纳入可处理范围。

5.最后，还需要有一个方法，在你更新系统时能回放和测试历史对话。（这在我的 TODO 清单里）

“我给一些小企业实现过这种流程，结果非常顺畅，几乎没人察觉到背后有 AI。在某个客户那里，甚至没有显式的“转人工”步骤：客服人员直接在手机上收到提醒，接管对话。”

六、Agent 带来新的岗位新变化

在 AI Agent 如火如荼的时代，许多原来的开发思路、设计框架都产生了amazing 的变化。

最大的一个感受就是，我们以前单纯围绕用户需求来做开发、做产品的做法似乎已经不太奏效，我们还需要面向 AI 或 Agent 的能力去逐步构建和引导。

小编一直以为，AI 绝不会挤压人类的工作空间。相反，它会创造出更多共走岗位新角色。根据小编之前的调查，以及跟多位在一线负责 AI 产品开发的大佬的采访交流，总结至少会有以下几个方向的进化：

• 智能体体验设计师：设计人与 Agent 的交互模式，关注“提示语”“反馈机制”“上下文切换”的体验。（上下文工程就是其中一块）
• AI 能力编排师：不需要写底层代码，但要理解如何调用不同智能体、工具与 API，编排成完整解决方案。（这一块，小编了解到已经有数家中大厂在如此做了。）
• 价值验证者：用实验快速验证“AI 生成体验”是否真的为用户带来价值。（初创产品MVP打造）
• 风险管控者：对 AI 带来的伦理、安全、合规风险提出产品层面的应对措施。（各种对齐技巧等等）

话说回来，希望本文提供的Agent 决策框架，能帮助到大家！提前祝周末愉快~

参考链接：​​https://www.productcurious.com/p/a-pms-guide-to-ai-agent-architecture​​

本文转载自​​51CTO技术栈​​，作者：云昭