产品经理必读：AI Agent 架构指南

这是一份为正在开发 AI Agent 的产品经理准备的完整指南，介绍了 Agent 架构、编排模式等话题。

编者按：AI Agent的信任悖论：为什么用户不用最强的AI，反而更信任会“示弱”的那个？文章来自编译。

上周，我跟一位产品经理聊天，他最近几个月刚上线了一款 AI Agent。数据看起来很漂亮：准确率 89%，响应时间亚秒级，用户调研反馈也很好。但用户在遇到第一个真实问题后就放弃了这款 Agent，比如一个用户同时遇到了账单纠纷和账户被锁定的问题。

我们的 Agent 能完美处理常规请求，但一旦遇到复杂问题，用户试过一次后会很沮丧，然后立刻就要求转接人工客服。

这种现象在每个只专注于让 Agent “更智能”的产品团队中都能看到，但真正的挑战在于做出架构决策，这些决策将塑造用户如何体验并开始信任 Agent。

在本文中，我将带你深入了解 AI Agent 架构的不同层面，以及你的产品决策如何决定用户是信任还是放弃你的 Agent。读完后，你会明白为什么有些 Agent 让人感觉“惊艳”，而另一些则让人感觉“糟心”，更重要的是，产品经理应如何设计架构才能打造出那种惊艳的体验。

全文都将用一个具体的客户支持 Agent 案例，让你能清楚地看到每一种架构选择在实践中是如何发挥作用的。我们还会探讨为什么那个反直觉的信任方法（提示：关键不在于提高正确率）实际上对提升用户采用度会更有效。

假设你正在打造一个客户支持 Agent

你作为产品经理，正在构建一个帮助用户解决账户问题（如重置密码、账单疑问、套餐变更）的 Agent。听起来很简单，对吧？

但当一个用户说“我无法访问我的账户，而且我的订阅似乎有问题”时，应该发生什么呢？

情景 A：你的 Agent 立刻开始检查系统。它查询账户，发现密码昨天被重置过但一直没收到邮件，同时发现一个账单问题导致了套餐降级，然后向用户精准解释了情况，并提供一键修复这两个问题的方案。

情景 B：你的 Agent 开始用提问来澄清问题。“您上次成功登录是什么时候？您看到了什么错误信息？能具体说说订阅有什么问题吗？”在收集完信息后，它说：“让我为您转接人工客服，他们可以检查您的账户和账单。”

同样的用户请求，同样的基础系统，却带来了完全不同的产品体验。

产品决策的四个层面

你可以把 Agent 的架构想象成一个技术栈，每一层都代表了你需要做出的一个产品决策。

第一层：上下文与记忆（你的 Agent 记得什么？）

决策点：你的 Agent 应该记住多少信息？记忆应该保持多久？

这不仅仅是技术上的存储问题，更与创造一种“它能理解你”的感觉相关。Agent 的记忆决定了与它交谈是像在跟机器人对话，还是像在跟一位知识渊博的同事交流。

客服 Agent：只存储当前对话，还是存储客户的全部支持历史？甚至包括他们的产品使用模式？过往的投诉记录？

可以考虑的记忆类型：

• 会话记忆：当前对话（“您刚才提到了账单问题……”）

• 客户记忆：跨会话的过往互动（“上个月您也遇到过类似的……”）

• 行为记忆：使用模式（“我注意到您通常使用我们的手机应用……”）

• 情景记忆：当前账户状态、有效订阅、近期活动

你的 Agent 记得越多，就越能预测需求，而不仅仅是被动回答问题。每一层记忆都会让响应更智能，但同时也会增加复杂度和成本。

第二层：数据与集成（程度要多深？）

决策点：你的 Agent 应该连接哪些系统？它应该拥有什么级别的访问权限？

你的 Agent 与用户工作流和现有系统的连接越深，用户的转换成本就越高。这一层决定了你的产品最终是一个工具，还是一个平台。

就客服 Agent 而言：应该只集成 Stripe 的计费系统，还是同时集成 Salesforce CRM、ZenDesk 工单系统、用户数据库和审计日志？每一次集成都会让 Agent 变得更有用，但也会创造更多潜在的故障点——比如 API 的速率限制、身份验证难题以及系统停机。

有趣的是，我们大多数人一开始就试图集成所有东西，结果陷入困境。但最成功的 Agent 往往从 2-3 个关键集成开始，然后根据用户的实际需求再逐步增加。

第三层：技能与能力（你的差异化是什么？）

决策点：你的 Agent 应该具备哪些具体能力？应该强到什么程度？

技能层是竞争胜败的关键。重点不在于拥有最多的功能，而在于拥有那些能够建立用户依赖的合适能力。

就客服 Agent 而言：它应该只能读取账户信息，还是也应该能修改账单、重置密码和更改套餐设置？每增加一项技能都会提升用户价值，但同时也会增加复杂度和风险。

实现说明：像模型上下文协议（MCP）这样的工具，正在让跨不同 Agent 构建和共享技能变得更加容易，不需要从头开始重复开发能力。

第四层：评估与信任（用户如何知道该期待什么？）

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

这一层决定了用户是会建立对 Agent 的信心，还是在它犯第一个错误后就会放弃。这不仅仅与准确性有关，更与可信度有关。

就客服 Agent 而言：你是否显示置信度分数（“我有 85% 的把握这能解决您的问题”）？你是否解释推理过程（“我检查了三个系统，发现……”）？你是否在执行操作前总是进行确认（“我现在重置您的密码，可以吗？”）？每一个选择都会影响用户对可靠性的感知。

可以考虑的信任策略：

• 置信度展示：“对于您的账户状态我很有把握，但账单细节让我再核对一下。”

• 推理透明化：“我发现了两次失败的登录尝试和一个过期的支付方式。”

• 优雅地划定边界：“这看起来是个复杂的账单问题，让我为您接通我们的账单专家，他们有更多工具可以处理。”

• 确认模式：何时应征求许可，何时可以直接行动并解释。

一个反直觉的洞察是： Agent 承认不确定性用户反而会更信任它，而不是看着它自信地犯错。

那么，究竟该如何设计Agent 架构呢？

好了，你已经了解了决策的几个层面临。然后每个产品经理都会问这个问题：“我到底该如何实现这个？Agent 如何与技能对话？技能如何访问数据？在用户等待时，评估是如何进行的？”

你的编排选择决定了开发体验、调试流程以及快速迭代的能力。

让我们来看几种主流的方法，我会坦诚地告诉你每种方法在什么情况下有效，又在什么情况下会变成一场噩梦。

单一 Agent 架构（从这里开始）

所有事情都在一个 Agent 的上下文里面进行。

就客服 Agent 而言：当用户说“我无法访问账户”时，将由一个 Agent 处理所有事情——检查账户状态、识别账单问题、解释情况、提供解决方案。

优点：构建简单，易于调试，成本可预测。可清楚知道 Agent 能做什么和不能做什么。

缺点：处理复杂请求时可能会变得昂贵，因为每次都需要加载完整的上下文。难以对特定部分进行优化。

大多数团队都从这里开始，说实话，很多团队根本不需要转向更复杂的架构。如果你在这种方案以及更复杂方案之间犹豫不决的话，就从这里开始。

基于技能的架构（当需要效率时）

引入路由来判断用户需求，然后将任务分派给专门的技能。

就客服 Agent 而言：router识别出这属于账户访问问题，并将其路由到 LoginSkill。如果 LoginSkill 发现这其实属于账单问题，就会把任务转交给 BillingSkill。

实际流程示例：

1. 用户：“我登录不了”
2. Router → LoginSkill
3. LoginSkill 检查：账户存在 ✓，密码错误 ✗，账单状态……等等，订阅已过期
4. LoginSkill → BillingSkill：“为 user123 处理订阅过期问题”
5. BillingSkill 处理续订流程

优点：更高效——针对简单技能可用更便宜的模型，针对复杂推理使用更昂贵的模型。每个技能都可以独立优化。

缺点：技能之间的协调很快会变得棘手。谁来决定何时交接？技能之间如何共享上下文？

这就是 MCP 的用武之地——它将技能暴露能力的方式给标准化了，这样router就能知道每个技能能做什么，而无需手动维护这个映射关系。

基于工作流的架构（企业级应用的最爱）

你为常见场景预先定义好流程步骤。可以参考 LangGraph、CrewAI、AutoGen、n8n 等工具。

就客服 Agent 而言：“账户访问问题”会触发如下工作流：

1. 检查账户状态
2. 如果被锁定，检查失败的登录尝试次数
3. 如果失败次数过多，检查账单状态
4. 如果是账单问题，路由至支付恢复流程
5. 如果不是账单问题，路由至密码重置流程

优点：一切都是可预测和可审计的。非常适合合规要求高的行业。每个步骤都易于优化。

缺点：当用户遇到不符合你预定义工作流的奇怪极端案例时，你就束手无策了。对用户来说感觉很死板。

协作式架构（未来趋势？）

多个专业化的 Agent 使用 A2A（Agent-to-Agent）协议协同工作。

愿景是：你的 Agent 发现另一家公司的 Agent 可以帮助解决问题，便自动建立安全连接，并协同解决客户的问题。想象一下，booking.com 的 Agent 与美国航空的 Agent 互动会怎样！

客服 Agent：AuthenticationAgent 处理登录问题，BillingAgent 处理支付问题，CommunicationAgent 管理用户交互。它们通过标准化的协议进行协调，以解决复杂问题。

现实情况是：这听起来很棒，但它在安全性、计费、信任和可靠性方面引入了极高的复杂性，大多数公司还没准备好应对。我们仍在探索相关标准。

这种架构在复杂场景下效果惊人，但调试多 Agent 对话确实很难。当出现问题时，要找出是哪个 Agent 犯了错以及原因何在，就像在破案一样。

关键是：从简单开始。单一 Agent 架构能处理的用例比你想象的要多得多。只有当你遇到真正的瓶颈时才增加复杂性，而不是因为想象中的问题就复杂化处理。

但有趣的是，就算拥有完美架构，如果用户不信任你的 Agent，它仍然会失败。这就引出了我们在构建 Agent 方面最反直觉的一课。

关于信任，人人都搞错了一件事

这里有个反直觉的观点：用户并不信任永远正确的 Agent。他们信任的是那些能坦诚承认自己可能出错的 Agent。

从用户的角度想想。你的客服 Agent 自信地说：“我已经重置了您的密码并更新了您的账单地址。” 用户心想：“太好了！” 然后他们尝试登录，结果……失败了。现在他们不仅面临一个技术问题，更面临一个信任危机。

对比一下，如果 Agent 这样说：“我想我找到了您账户的问题所在。我有 80% 的把握这能解决问题。我将为您重置密码并更新账单地址。如果这没有用，我会立刻为您转接人工客服进行深入处理。”

同样的技术能力，完全不同的用户体验。

要想做出值得信赖的 Agent，需要关注三样东西：

1. 置信度校准：当你的 Agent 说它有 60% 的把握时，它的正确率就应该在 60% 左右。不是 90%，也不是 30%，就是实实在在的 60%。
2. 推理过程透明化：用户希望看到 Agent 的“工作过程”。“我检查了您的账户状态（活跃）、账单历史（昨天支付失败）和登录尝试（3次失败后锁定）。问题似乎在于……”
3. 优雅的转接：当 Agent 达到其能力极限时，它如何交接？一个带着完整上下文平滑过渡到人工客服，远比一句“我帮不了您”要好得多。

很多时候，我们执着于让 Agent 更准确，而用户真正想要的，却是更透明地了解 Agent 的局限性。

文章来自于“神译局”，作者“神译局”。