企业AI智能体搭建的秘密：技术之外，你绝对不能忽视的关键因素！

目前市场上关于人工智能的课程琳琅满目，经过我的观察，这些课程大多集中在普及AI技术的基本架构和手把手指导如何构建智能体。学习这些内容无疑是有益的，它们帮助我们掌握一些技术基础，了解AI技术的实现能力，这对后续智能体产品的落地将有助于与技术团队的有效沟通。

然而，我们必须确保不偏离重点。作为产品经理，最核心的能力依然在于明确场景、解决问题以及提供切实可行的解决方案。我们要成为业务与技术之间的桥梁、项目的管理者以及产品落地的设计师。如今，许多产品是通过代码实现的，而现在则可以借助大型模型来完成。了解大模型的能力范围是必要的，甚至可能需要与工程师合作处理一些具体的细节工作，比如定义场景标签，这与过去定义产品埋点的工作并无二致。

当前，很多企业在智能体的落地上仍在探索阶段。即使拥有成熟的经验，往往也很难获得实用的干货分享。因此，作为产品经理，我们应保持冷静，不要被市场上那些华丽的课程所迷惑。

微软的高级产品经理Umang Sehgal分享了自己在智能客服机器人项目上的经历，提醒我们要将智能体产品的构建从单纯的“技术优化问题”转向如何利用AI能力提供更优的解决方案，尤其是如何建立人机之间的信任关系。这一转变为我们提供了更多的思考空间。

在这篇文章中，我将引导你了解人工智能体架构的不同层次，以及你的产品决策如何影响用户对智能体的信任。通过阅读这篇文章，你将明白为什么有些智能体让人感到“神奇”，而有些则令人“沮丧”。更重要的是，作为产品经理，应该如何设计以创造出卓越的用户体验。

我们将通过一个具体的客户支持智能体案例，帮助你清晰理解不同架构选择在实践中的效果。同时，我们还将探讨为何这种反直觉的信任机制（提示：关键在于不在于频繁做出正确判断）实际上更有利于用户的接受度。

假设你正在构建一个客户支持智能体，作为产品经理，你负责开发一个帮助用户解决账户问题的智能体程序，例如密码重置、账单查询和套餐变更等。听起来似乎很简单，对吧？然而，当用户说“我无法访问我的帐户，而且我的订阅似乎有问题”时，你该如何应对呢？

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

场景B：你的客服人员开始询问一些澄清问题。“您上次成功登录是什么时候？您看到了什么错误信息？您能详细描述一下订阅问题吗？”在收集信息后，系统提示：“我会将您的问题转接给一位可以查看您账户和账单的人工客服。”

尽管用户需求相同，底层系统也相似，但产品的表现却截然不同。决策在于你的智能体应该记住多少信息，以及记住多久。这不仅涉及技术存储，更关乎营造一种理解的假象。智能体的记忆能力决定了用户的感受——是在与机器人对话，还是在与一位知识丰富的同事交流。

对于客服人员，你们是仅存储当前对话内容，还是会记录客户的全部支持历史、产品使用模式及之前的投诉？需要考虑的记忆类型是：智能体记住的信息越多，越能预测客户需求，而不仅仅是被动回答问题。记忆层级越多，响应就越智能，但同时也会增加复杂性和成本。

决策还包括你的智能体应该连接哪些系统，以及应该拥有什么级别的访问权限。智能体程序与用户工作流程和现有系统的连接越深入，用户就越难切换。这一层连接决定了你是工具还是平台。对于客户支持智能体而言，它应该只与Stripe的计费系统集成，还是也应该与Salesforce CRM、ZenDesk工单系统、用户数据库和审计日志集成？每增加一项集成，客服智能体的功能就会增强，但同时也会带来更多潜在的故障点，例如API速率限制、身份验证挑战和系统停机时间。

有趣的是，大多数团队都会陷入试图一次性集成所有系统的困境。然而，最成功的智能体通常最初只集成了2-3个关键系统，然后根据用户的实际需求逐步增加。

决策还包括你的智能体应具备哪些具体能力，以及这些能力应该深入到什么程度。你的技能层面将直接影响你在竞争中的成败。关键不在于拥有最多的功能，而是拥有能够建立用户依赖性的正确能力。对于客服人员而言，智能体应该仅能读取账户信息，还是也应该能够修改账单、重置密码和更改套餐设置？每增加一项技能，用户的价值就会提升，但同时也会增加复杂性和风险。

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

决策的另一个层面是如何衡量成功，并向用户传达智能体的局限性。这一层决定了用户是否会对你的智能体建立信任，还是会在第一次出错后就放弃它。这不仅关乎准确性，更关乎可信度。对于客服人员来说，每一种选择都会影响用户对可靠性的感知。

可考虑的信任策略是，用户更信任那些承认自己不确定的智能体，而不是那些自信地犯错的智能体。

现在你已经理解了各个层级，接下来是每个产品经理都会问的实际问题。你的编排选择将决定开发体验、调试过程以及快速迭代的能力。

所有事情都发生在某个主体的视角下。对于我们的客服人员来说，当用户说“我无法访问我的帐户”时，客服人员会处理所有事情——检查帐户状态、识别账单问题、解释发生了什么、提供解决方案。其优势在于构建简单、易于调试、成本可预测。你可以清楚了解智能体可以做什么和不能做什么。

然而，处理复杂请求时的开销可能很大，因为每次都需要加载完整的上下文，而优化特定部分也相对困难。大多数团队都是从这里开始的，实际上很多团队并不需要再往后发展。如果你在选择这个还是更复杂的方案时犹豫不决，不妨从这里开始。

路由器会找出用户的需求，并将任务交给具备专业技能的人员。对于支持人员而言，路由器识别出这是一个账户访问问题，并将请求路由到“登录技能”。如果登录技能发现实际上是计费问题，则会将请求转交给“计费技能”。这种方法的优势在于效率更高——可以使用成本更低的模型来处理简单的技能，而使用成本更高的模型来处理复杂推理。每项技能都可以独立优化。

然而，技能之间的协调可能会变得棘手。谁来决定何时交接？技能之间如何共享上下文？MCP的真正作用在于此——它规范了技能如何展现其功能，因此路由器无需手动维护映射关系即可了解每个技能的功能。你可以预先定义常见场景的工作流程，例如LangGraph、CrewAI、AutoGen、N8N等。

对于客服人员来说，“账户访问问题”将触发一个工作流程。其优势在于一切皆可预测且可审计，特别适合合规性要求高的行业，每个步骤都易于优化。但当用户遇到不符合预设工作流程的特殊情况时，可能会导致僵化的体验。

多个专业智能体使用A2A（代理对代理）协议协同工作。愿景是，当客服人员发现另一家公司的客服人员可以协助解决问题时，系统会自动建立安全连接，共同解决客户的问题。想象一下Booking.com的客服人员与美国航空公司的客服人员合作的场景！

我们的支持智能体分为三个部分：AuthenticationAgent处理登录问题，BillingAgent处理支付问题，CommunicationAgent管理用户交互。它们通过标准化协议进行协调，以解决复杂问题。现实情况是，这听起来很棒，但它会引入安全、计费、信任和可靠性方面的复杂性，而大多数公司尚未做好准备。我们仍在制定相关标准。

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

然而，即使架构完美，如果用户不信任你的智能体，它仍然会失败。这就引出了构建智能体时最违反直觉的一点。信任是每个人都会犯错的事情。这里有一个反直觉的现象：用户并不信任总是正确的客服人员，而是信任那些在可能出错时会坦诚承认的客服人员。

换位思考一下用户的感受。你的客服人员自信满满地说：“我已经重置了您的密码并更新了您的账单地址。”而用户心想：“太好了！”但他们尝试登录时却失败了。这不仅是技术问题，更是信任问题。

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

建立值得信赖的智能体需要关注三件事：置信度校准、解释过程的透明度和优雅的升级。置信度校准是指当智能体说有60%的置信度时，它应该在约60%的情况下是正确的，而不是90%或30%。解释过程的透明度是用户希望看到客服人员的工作过程，例如：“我查看了您的账户状态（已激活）、账单记录（昨天付款失败）和登录尝试记录（3次失败后账户被锁定）。问题似乎是……”

优雅的升级则是当智能体达到能力极限时，如何交接给能够提供完整信息的人工客服，平稳过渡远比直接说“我帮不上忙”要好得多。很多时候，我们过于执着于提高智能体的准确性，而用户真正想要的却是智能体局限性方面的更多透明度。

通过这些思考，我们不仅能提升产品的质量，更能在用户心中建立起信任，从而实现更好的用户体验。