在AI智能体的热潮中，技术架构固然重要，但真正决定产品成败的，是场景定义、信任机制与人机协作的细节设计。本文从微软产品经理的案例出发，系统拆解智能体的四层架构与三种编排方式，帮助企业在“技术可行”之外，找到“产品可用”的落地路径。

现在市面上的AI产品的课程太多了，我大体看了下，基本上是在科普AI相关的技术支持架构，还有一些是手把手教大家如何搭建一个智能体。

学习这些无可厚非，通过这些课程了解些技术基础及AI技术的可实现能力，后续做智能体产品落地时可以很好的和技术沟通。

但是我们不要把关注点放错了地方。

产品经理最核心的能力，依然是：确定场景，解决问题，提供解决方案。做好业务和技术的沟通者，做好项目的管理者，做好产品落地的设计者.

只不过是，以前是通过代码实现的产品，现在可以通过大模型来实现。我们需要了解大模型的实现能力范围，甚至可能需要跟着工程师做一些特别细节的工作，比如定义场景标签，（话说这和以前定义产品埋点不一样吗）有些基础的要落下手和脚来支持的。

现在很多企业的智能体落地都在探索，就算有非常成熟的经验，没有人会把干货的东西实在的分享出来。

所以，产品经理稍安勿躁，不要被市面上说的天花乱坠的课程迷花了眼睛啊！

微软的高级产品经理Umang Sehgal分享了自己做智能客服机器人的一个案例过程，也是在提醒大家，它将构建智能体产品从一个纯粹的“技术优化问题”（如何提升准确率、增加技能），转变为一个如何用AI能力实现更好的解决方案（如何构建人机信任关系）。

或许带给我们更多思考。

1.做智能体，只需要关注智能体智商吗？

在这篇文章中，我将带你了解人工智能体架构的不同层次。你的产品决策如何决定用户是信任你的智能体还是放弃它。读完本文，你将明白为什么有些智能体让人感觉“神奇”，而有些智能体却让人“沮丧”，更重要的是，产品经理应该如何设计才能打造神奇的用户体验。

我们将全程使用一个具体的客户支持智能体案例，以便您能够清楚地了解每种架构选择在实践中的具体效果。我们还将解释为什么这种反直觉的信任方法（提示：关键不在于更频繁地做出正确的判断）实际上更有利于用户采纳。 假设你正在构建一个客户支持智能体。

你是产品经理，正在开发一个帮助用户解决账户问题的智能体程序——密码重置、账单查询、套餐变更等等。

听起来很简单，对吧？

但是，当用户说“我无法访问我的帐户，而且我的订阅似乎有问题”时，应该怎么办？

场景 A：您的智能体立即开始检查系统。它查找帐户，发现密码昨天已重置但电子邮件未送达，发现计费问题导致套餐降级，详细解释了发生的情况，并提供一键解决这两个问题的方案。

场景 B：您的客服人员询问了一些澄清问题。

“您上次成功登录是什么时候？您看到了什么错误信息？您能详细描述一下订阅问题吗？”

收集信息后，系统提示：“我会将您的问题转接给一位可以查看您账户和账单的人工客服。”

用户需求相同，底层系统相同，但产品却截然不同。

2.你的产品决策存在于以下四个层面

第一层：上下文与记忆（你的智能体记住了什么？）

决策：你的经纪人应该记住多少信息，以及应该记住多久？ 这不仅仅是技术上的存储——它关乎营造一种理解的假象。

你的智能体的记忆力决定了你感觉是在和机器人对话，还是在和一位知识渊博的同事对话。

对于我们的客服人员：你们是只存储当前的对话内容，还是会存储客户的全部支持历史记录？他们的产品使用模式？之前的投诉？

需要考虑的记忆类型：

• 会话记忆：当前对话（“您之前提到过账单问题……”）
• 客户记忆：跨会话的过往互动（“上个月您也遇到过类似的问题……”）
• 行为记忆：使用模式（“我注意到您通常使用我们的移动应用程序……”）
• 上下文记忆：当前账户状态、有效订阅、近期活动

智能智能体记住的信息越多，就越能预测客户需求，而不仅仅是被动地回答问题。记忆层级越多，响应就越智能，但也会增加复杂性和成本。

第二层：数据与集成（深入到什么程度？）

决策：您的智能体应该连接到哪些系统，以及它应该拥有什么级别的访问权限？

智能体程序与用户工作流程和现有系统的连接越深入，用户就越难切换。这一层连接决定了你是工具还是平台。

对于我们的客服智能体来说：它应该只与 Stripe 的计费系统集成，还是也应该与 Salesforce CRM、ZenDesk 工单系统、用户数据库和审计日志集成？

每增加一项集成，客服智能体的功能就会增强，但同时也会带来更多潜在的故障点——例如 API 速率限制、身份验证挑战和系统停机时间。

有趣的是，我们大多数人都会陷入试图一次性集成所有系统的困境。但最成功的智能体最初只集成了 2-3 个关键系统，然后根据用户的实际需求添加更多系统。

第三层：技能与能力（你的独特之处是什么？）

决策：你的智能体应该具备哪些具体能力，以及这些能力应该深入到什么程度？

你的技能层面决定了你在竞争中的成败。关键不在于拥有最多的功能，而在于拥有能够建立用户依赖性的正确能力。

对于我们的客服人员：它应该只读取账户信息，还是也应该能够修改账单、重置密码和更改套餐设置？

每增加一项技能，用户价值就会提升，但同时也会增加复杂性和风险。

实施说明：像 MCP （模型上下文协议）这样的工具使得在不同智能体之间构建和共享技能变得更加容易而无需从头开始重建能力。

第四层：评估与信任

决策：如何衡量成功并向用户传达智能体局限性？

这一层决定了用户是否会对你的智能体建立信任，还是会在第一次出错后就放弃它。这不仅仅关乎准确性，更关乎可信度。

对于我们的客服人员：

1. 您是否会显示置信度评分（例如，“我有 85% 的把握可以解决您的问题”）？
2. 您是否会解释您的理由（例如，“我检查了三个系统，发现……”）？
3. 您是否总会在采取行动前进行确认（例如，“我现在应该重置您的密码吗？”）？

每一种选择都会影响用户对可靠性的感知。

可考虑的信任策略：

• 信心指标：“我对您的账户状态有信心，但请允许我再次核对账单详情。”
• 推理过程清晰明了：“我发现两次登录尝试失败和一个已过期的支付方式”。
• 委婉的沟通方式：“这看起来像是一个复杂的计费问题——让我帮您联系我们的计费专家，他可以使用更多工具。”
• 确认模式：何时征求许可，何时采取行动并解释

反直觉的发现：用户更信任那些承认自己不确定的智能体，而不是那些自信地犯错的智能体。

3. 那么，究竟该如何设计一个智能体呢？

好的，现在你已经理解了各个层级。

接下来是每个产品经理都会问的实际问题：

1. 我该如何实际实现它？
2. 智能体如何与技能交互？
3. 技能如何访问数据？
4. 用户等待时如何进行评估？”

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

1. 单智能体架构（简单入门）

所有事情都发生在某个主体的视角下。

对于我们的客服人员：当用户说“我无法访问我的帐户”时，一名客服人员会处理所有事情——检查帐户状态、识别账单问题、解释发生了什么、提供解决方案。

其优势在于：构建简单、易于调试、成本可预测。您可以清楚地了解您的智能体可以做什么和不能做什么。

为什么不行：处理复杂请求时开销会很大，因为每次都要加载完整的上下文。而且很难优化特定部分。

大多数团队都是从这里开始的，说实话，很多团队也根本不需要再往后发展。如果你正在犹豫是选择这个还是更复杂的方案，那就从这里开始吧。

2. 基于技能的架构（效率最高）

路由器会找出用户的需求，然后将任务交给具备专业技能的人员。

对于我们的支持人员：路由器识别出这是一个账户访问问题，并将请求路由到“登录技能”。如果登录技能发现实际上是计费问题，则会将请求转交给“计费技能”。

实际流程示例：
用户：“我无法登录”
路由器 → 登录技能
LoginSkill 检查：账户存在 ✓，密码正确 ✗，账单状态…稍等，订阅已过期
登录技能 → 计费技能：“处理用户123的过期订阅”
BillingSkill负责续订流程

这种方法的优势在于：效率更高——你可以使用成本更低的模型来处理简单的技能，使用成本更高的模型来处理复杂的推理。每项技能都可以独立优化。

为什么行不通：技能之间的协调很快就会变得棘手。谁来决定何时交接？技能之间如何共享上下文？

MCP 的真正作用就在于此——它规范了技能如何展现其功能，因此您的路由器无需手动维护映射关系即可了解每个技能的功能。

3. 基于工作流的架构（企业首选）

您可以预先定义常见场景的工作流程。例如 LangGraph、CrewAI、AutoGen、N8N 等。

对于我们的客服人员来说：“账户访问问题”会触发一个工作流程：

1. 查看账户状态
2. 如果系统锁定，请检查登录失败尝试次数
3. 如果故障次数过多，请检查计费状态
4. 如果出现账单问题，请转至付款追讨程序。
5. 如果不是账单问题，请跳转到密码重置页面

其优势在于：一切皆可预测且可审计，非常适合合规性要求高的行业，且每个步骤都易于优化。 为什么行不通：当用户遇到不符合你预设工作流程的特殊情况时，你会束手无策。用户会觉得这种方式很僵化。

4. 协作式智能体架构（还未实现？）

多个专业智能体使用 A2A（代理对代理）协议协同工作。

愿景：您的客服人员发现另一家公司的客服人员可以协助解决问题，系统会自动建立安全连接，并协作解决客户的问题。想象一下 Booking.com 的客服人员与美国航空公司的客服人员合作的场景！

我们的支持智能体分为三个部分：AuthenticationAgent 处理登录问题，BillingAgent 处理支付问题，CommunicationAgent 管理用户交互。它们通过标准化协议进行协调，以解决复杂问题。

现实情况是：这听起来很棒，但它会引入安全、计费、信任和可靠性方面的复杂性，而大多数公司尚未做好准备。我们仍在制定相关标准。

对于复杂的场景，这种方法可以产生惊人的效果，但调试多智能体对话却异常困难。一旦出现问题，找出哪个智能体犯了错误以及错误原因，就像侦探工作一样。

但有趣的是，即使架构完美，如果用户不信任你的智能体，它仍然会失败。这就引出了构建智能体时最违反直觉的一点。

信任这件事，每个人都会犯错。

这里有个违反直觉的现象：用户并不信任总是正确的客服人员，他们信任的是那些在可能出错时会坦诚承认的客服人员。

换位思考一下用户。你的客服人员自信满满地说：*“我已经重置了您的密码并更新了您的账单地址。”

用户心想：“太好了！” 然后他们尝试登录，结果……却失败了。现在他们遇到的不仅仅是技术问题，还有信任问题。

相比之下，客服人员可能会说：“我觉得我找到了您账户的问题所在。我有 80% 的把握这次能解决问题。我会重置您的密码并更新您的账单地址。如果还是不行，我会立即将问题转交给能够深入调查的专业人员。”

技术能力相同，用户体验却截然不同。

建立值得信赖的智能体需要关注三件事：

1. 置信度校准：

当你的经纪人说有 60% 的置信度时，它应该在大约 60% 的情况下是正确的。不是 90%，也不是 30%。而是实际的 60%。

2. 解释过程的透明度：

用户希望看到客服人员的工作过程。“我查看了您的账户状态（已激活）、账单记录（昨天付款失败）和登录尝试记录（3次失败后账户被锁定）。问题似乎是……”

3. 优雅的升级：

当你的智能体达到能力极限时，它如何交接？平稳地过渡到能够提供完整信息的人工客服，远比直接说“我帮不上忙”要好得多。

很多时候，我们过于执着于提高智能体的准确性，而用户真正想要的却是智能体局限性方面的更多透明度。

原文链接：https://www.productcurious.com/p/a-pms-guide-to-ai-agent-architecture