文章指出，尽管 AI 客服在准确率和响应速度上表现出色，但用户在遇到复杂问题时仍倾向于转人工，导致 Agent 被弃用。核心原因在于用户体验不连续和信任感缺失，而非 Agent 的“笨”。作者提出了 AI Agent 的“四层产品决策架构”：上下文与记忆、数据与集成、技能与能力、评估与信任，并详细阐述了每一层的决策要点。特别强调在“评估与信任”层，承认不确定性反而能提升用户信任。文章还介绍了单 Agent、技能路由、工作流和协作式四种编排模式，并建议从简单的单 Agent 架构开始。最后，文章纠正了关于信任的最大误区，指出用户信任 Agent 并非因为它永远正确，而是因为它在犯错时表现得透明且优雅地交接。文章还分享了逐步过渡到 AI 优先客服的实践经验，并展望了 AI Agent 时代可能出现的新岗位。
编辑 | 云昭
上周，我和一位最近刚上线 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，需关注三点：
-
置信度校准：说 60% 时，就真的要做到 60%。
-
推理透明：展示检查过程与证据。
-
优雅交接：触及边界时，顺畅转人工，并带上完整上下文。
很多时候，用户要的不是“更准确”，而是“更透明”。
一个毫无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
