Fanatics 博彩平台多 Agent 客服架构解密

Fanatics Betting and Gaming（FBG）在 AWS 上构建了一个多智能体客户支持系统，用以解决体育博彩领域特有的挑战。客户期望即时获得准确的答案，尤其是在现场赛事进行期间，每一分钟都至关重要。客户会询问账户问题、存款限额、各州不同的监管规定以及负责任博彩资源。每个获得许可的运营商在各个司法管辖区的规则都不尽相同。建立在决策树之上的传统聊天机器人解决方案在这种复杂性面前力不从心，往往让客户感到沮丧，并随着人工坐席队列的不断增长而推高运营成本。

Fanatics Betting and Gaming（FBG）是一个将先进技术与深厚体育专业知识相结合的体育博彩平台。作为 Fanatics 品牌家族的一员，FBG 在美国多个州开展业务，服务于快速增长的用户群体，这些用户需要全天候支持，特别是在 NFL 季后赛和超级碗等高流量赛事期间。

随着支持量呈指数级增长，FBG 现有的支持模式每次交互需要更多人工作业介入，产生与客户群成比例增长的更高运营成本。团队意识到这是一个改善客户体验的机遇，同时也在为支持基础设施的下一阶段增长做准备。有几个因素使这个问题变得尤为困难。

美国每个州都有自己关于支付方式、存款限额、提款时间线和负责任博彩要求的规则。印第安纳州的客户得到的答案与新泽西州的客户不同。在大型体育赛事期间，支持请求可能激增至每两分钟超过 40 个咨询，系统需要在不降低响应质量的前提下即时扩展。

查询的多样性使问题更加复杂。客户咨询的内容涉及方方面面，从交易历史和账户设置到投注规则和自我排除选项。没有单一模型或知识库能够覆盖全部内容。此外，运营商必须实时识别并回应问题赌博的迹象。这需要对对话上下文的细致理解，而不是简单的关键词匹配。

FBG 需要一个能够自主处理这种复杂性、同时准确判断何时应该升级给人工坐席的系统。

"随着我们规模的扩大，我们知道支持体验也需要随之演进。我们希望为客户提供更快、更准确的答案，同时确保在负责任博彩或合规方面绝不妥协。目标是构建一个能够随时间变得更好、而非仅仅变得更大的系统。"

—— Ian Botts，首席技术官，Fanatics Betting and Gaming

FBG 没有依赖单一的整体式聊天机器人，而是设计了一个多智能体系统，让专业智能体处理客户交互的不同方面。由于团队已经在 Amazon Elastic Kubernetes Service（Amazon EKS）上建立了深厚的运营专业知识，他们可以在现有的容器平台上进行构建，独立地部署、扩展和迭代每个智能体。

FBG 选择 Amazon Bedrock，因为它能通过单一 API 访问多种基础模型，实现模型无关性，这让团队能够为每项任务匹配最佳模型，并在更好的选项出现时更换模型。由于 Bedrock 运行在现有的 AWS 环境内，系统也继承了 FBG 已建立的安全和治理控制，而 Amazon Bedrock Guardrails 提供了其合规要求所要求的负责任 AI 保障措施。

该架构遵循编排器模式。一个主要的编排智能体接收每条客户消息，协调专业工具和子智能体，并返回统一响应。这种设计让团队能够在不重写核心系统的情况下添加新功能，例如新工具、新知识领域和新业务单元。

"我们设计这个系统时，让每个智能体都有清晰的职责，可以独立改进。这种模块化是我们能够快速行动的原因。当我们需要支持新的案例类型或新的业务单元时，我们只需添加新的工具或智能体，而无需触及系统的其余部分。"

—— Luis Fernandez Rocha，软件工程高级经理，Fanatics Betting and Gaming

图 1 说明了这个多智能体客户支持系统在 AWS 上的端到端架构。

图 1：多智能体客户支持系统的端到端架构

客户消息通过 FBG 移动应用进入，经过 Salesforce Einstein 到达 Amazon EKS 上的 Spring AI 服务，然后流经 Amazon Bedrock Guardrails 和负责任博彩分类器，最后到达监督智能体。监督智能体调用专业工具，包括检索增强生成（RAG）管道、账户和交易 Model Context Protocol（MCP）服务器，以及转接坐席工具来生成响应。

请求如何在系统中流转

客户通过 FBG 移动应用发送消息，该应用连接到 Salesforce Einstein 作为聊天界面层。请求通过标准 REST 调用路由到运行在 Amazon EKS 上的 Spring AI 服务。该服务验证客户令牌并调用 AI 智能体。

请求随后通过 Amazon Bedrock Guardrails，在进入 AI 层之前帮助检测提示注入。一个由 Amazon Nova 2 Lite 驱动的负责任博彩分类智能体，根据合规批准的分类框架评估每条消息。高严重性分类会立即触发向人工坐席的转接，并携带完整对话上下文。

运行在 Amazon Bedrock 上的 Anthropic Claude 监督智能体，根据客户的意图确定调用哪些工具。根据查询内容，监督智能体调用一个或多个专业工具，其中一些通过 MCP 调用，另一些位于服务本地：

检索增强生成（RAG）工具从向量存储中检索相关知识，用于 FAQ 式问题。

账户工具（MCP）查询内部账户服务以获取客户特定信息。

交易工具（MCP）检索近期交易历史，包括存款、取款和投注活动。

转接坐席工具在客户明确要求或情况需要人工判断时升级给人工坐席。

监督智能体综合工具响应并向客户返回自然语言响应。

深度剖析：关键架构组件

在本节中，我们深入探讨使系统正常工作的四个组件：Amazon EKS 托管平台、自定义 RAG 管道、负责任博彩分类器，以及帮助保障对话安全的护栏。

用于智能体托管和 MCP 服务器的 Amazon EKS

FBG 在 Amazon EKS 上运行其整个 AI 栈，将其 MCP 服务器和 Spring AI 服务托管为 Kubernetes 服务。MCP 服务器暴露的工具通过 REST 调用外部服务，如账户服务和交易历史服务。本地工具直接位于 Spring AI 服务中，与 Claude 大语言模型（LLM）并置。这些包括 RAG 工具和转接人工工具。

这种方法为多智能体系统提供了几个优势。MCP 服务器和 Spring AI 服务可以根据需求独立扩展。当 FBG 需要支持额外的业务领域或功能时，添加新的 MCP 服务器只是另一个 Kubernetes 部署。团队还可以在不重新部署整个系统的情况下更新单个工具。新的 MCP 工具被添加到现有 MCP 服务器中，无需新的 Pod 部署。

FBG 使用 Spring AI 作为其应用框架，它提供原生 MCP 支持。MCP 服务器定义监督智能体可以动态发现和调用的工具。团队选择 Spring AI 是因为他们的开发人员拥有深厚的 Java 专业知识，这让他们能够快速行动。对于使用 Python 的团队，Strands Agents 是 AWS 的开源 SDK，提供类似的智能体编排和 MCP 支持。

对于考虑类似方法的团队，Amazon EKS 提供了管理多个智能体服务规模化所需的容器编排。MCP 提供了智能体之间工具通信的标准化协议。喜欢托管体验的团队也可以探索 Amazon Bedrock AgentCore，这是一个在任何框架或模型上构建、连接和优化智能体的平台。AgentCore 还支持 MCP 用于工具集成。

使用 Amazon Titan 嵌入的自定义 RAG

系统中使用最频繁的工具是 RAG 管道。FBG 构建了一个自定义实现，而不是使用托管知识库，这让他们能够对摄取、分块和检索过程进行精确控制。

RAG 管道的工作流程如下。支撑文档从上游来源收集，包括各州特定的支付方式指南、FAQ 文章、负责任博弈资源和账户管理指南。文档使用基于 token 的分块策略进行分割，即每个文档被划分为固定数量 token（模型处理的文本单位）的片段，而非按句子或段落分割。这使团队能够对分块边界进行细粒度控制。然后使用 Amazon Titan V2 对这些片段进行嵌入，生成存储在 MongoDB Atlas 中的向量表示。

当客户提出问题时，系统使用 LLM 将查询转换为适合向量搜索的形式，然后对文档存储执行相似性搜索。对于特定司法管辖区域的问题，系统会同时执行州特定搜索和通用搜索，在将结果传递给监督智能体进行响应生成之前合并结果。

这种定制方法在知识库有复杂检索需求时特别有价值，例如需要将特定州文档和通用文档组合在单一响应中。知识库在持续扩展，每月有数百份新文档添加，团队通过对话分析识别差距。

"构建自己的 RAG 管道让我们完全控制了模型看到的内容及其检索信息的方式。每个州都有不同的规则，所以我们需要将特定州文档和通用文档组合在单一响应中的能力。这种控制级别在准确性方面产生了决定性的差异。"

— Sharoze Amir，Fanatics Betting and Gaming 软件工程师

使用 Amazon Nova 进行负责任博弈分类

负责任博弈是监管要求，也是 FBG 的核心价值观。团队与合规部门合作构建了一个分类系统。该系统评估客户互动以确认是否符合负责任博弈标准，并在需要时为客户连接正确的资源。

系统使用 Amazon Nova 2 Lite，这是一款轻量级、快速分类模型。团队有意选择了较小的模型。任务定义明确，有清晰的示例和有限的结果集，因此更大、更昂贵的模型只会增加延迟而不会提高准确性。

模型同时接收当前消息和完整对话历史，使其能够检测升级模式，而非依赖单条消息的关键词匹配。当系统识别出高严重性问题时，会立即将客户转接给人工代理，并提供完整对话上下文。较低严重性的标记则记录下来供合规审查，同时允许对话继续进行。

这是一个广泛适用的模式：对于范围明确的分类任务，使用满足准确性要求的最小模型，并将更大的模型留给开放式推理。

"现成的支持智能体对每次对话一视同仁。我们的不能这样——关于取款的问题可能实际上是负责任博弈的时刻，而识别这一点需要与我们的合规框架深度集成。这就是为什么我们在 AWS 内部构建：没有供应商会按照我们行业的要求处理那些敏感领域。"

— Trevor Gurgick，Fanatics Betting and Gaming 应用 AI 主管

用于安全防护的 Amazon Bedrock 护栏

FBG 使用 Amazon Bedrock 护栏来帮助防范提示注入，并帮助保持对话在适当范围内。团队调整了护栏配置，以在安全性和客户服务互动的现实之间取得平衡——过于严格的过滤器会在客户体验中造成摩擦。

关键洞察：根据实际用例调整护栏，而非默认应用最大限制。对于客户支持，提示注入防护至关重要，但过于激进的內容过滤会产生误报，使客户感到沮丧。

多模型架构

FBG 在 Amazon Bedrock 上运行多模型架构，采用深思熟虑的自下而上的方法进行模型选择。对于负责任博弈等分类任务，他们使用 Amazon Nova 2 Lite。它快速、成本效益高，对于存在清晰示例的定义明确的分类任务来说已经足够。对于对话管理等监督和编排任务，他们使用 Amazon Bedrock 上的 Anthropic Claude Sonnet。Claude 处理复杂推理、工具编排和自然对话。对于 RAG 管道中的嵌入，他们使用 Amazon Titan V2，它生成高质量的向量表示。关于 AWS 区域中的模型可用性，请参阅 Amazon Bedrock 中的按 AWS 区域划分的支持模型。

团队对监督智能体使用跨模型区域的轮询策略，确保在峰值事件期间永远不会达到吞吐量限制。因为每个模型都通过相同的 Amazon Bedrock API 访问，将不同工作负载路由到不同模型无需对底层基础设施进行任何更改。

在部署后的前两个月内，基于 FBG 的内部指标，多智能体系统相比 FBG 之前的支持体验带来了可衡量的改进。人工介入率提高了约 56%，这意味着更多客户问题现在无需人工代理介入即可解决。解决率提高了约 53%，客户的问题得到了实际解决而非被推诿。系统已自主解决了数千个案例，由于 AI 驱动的交互成本仅为人工代理交互成本的一小部分，因此实现了显著的成本节约。客户满意度也在上升。对话质量有了如此显著的提高，以至于客户经常没有意识到他们正在与 AI 互动。

在重大体育赛事期间，系统在保持一致性能和响应质量的同时处理高请求量。Amazon EKS 自动扩展确保 MCP 服务器和 Spring AI 服务在流量激增时自动增加容量，无需人工干预。这意味着，无论是平静的星期二还是超级碗，客户都能获得相同的快速、准确响应，而不论同时有多少其他人在提问。

持续改进：评估与迭代

构建智能体只是开始。令 FBG 的方法脱颖而出的是他们在部署后持续改进系统方面所做的投资。团队将多智能体系统视为活的产品，而非一次性实现。他们审查对话日志、跟踪解决准确性，并使用真实客户互动来优化提示、调整工具行为以及识别知识库中的差距。这种持续投入确保系统随着时间推移变得更加智能，而非随着客户需求演变而退化。

其评估策略的核心是一个 LLM 即评判者系统，自动审查每个已完成的对话，分类 AI 是否成功解决了案例或其是否未能达标。运营团队每天审查这些评估，识别智能体在哪些方面存在困难的模式，并提交改进工单来弥补这些差距。这创建了一个反馈循环，使智能体随着时间推移可衡量地变得更好。

在工程方面，团队通过实时可观测性指标监控系统健康状况，包括幻觉检测、延迟和成本跟踪。在开发新功能或测试变更时，他们从生产环境提取实际客户对话，并针对更新的架构进行重放，以在任何内容触及客户之前发现边缘情况。

一项特别有效的纪律是团队在提示工程方面的方法。当性能下降时，他们不会急于转向更强大（也更昂贵）的模型，而是首先查看系统提示是否可以改进，或者指令是否存在矛盾。这在推动持续质量改进的同时保持低成本，只有在提示已针对任务完全优化后才会升级模型。希望系统化这一纪律的团队可以使用 Amazon Bedrock 中的高级提示优化，它根据评估标准优化提示并跨多个模型比较结果，然后才确定迁移。

入门指南：构建你自己的多智能体支持系统

如果你希望构建类似的多智能体客户支持系统，这是一个实用的起步路径。

狭隘定义范围

FBG 最初仅上线了 20 多种案例类型中的 4 种。从狭小的范围开始可以让你快速证明价值、建立评估基础设施，并在扩展之前了解什么有效。选择具有最高数量和最清晰解决标准的案例类型。

建立基础设施

在 Amazon EKS 上部署智能体服务以获得完全控制，或使用 Amazon Bedrock AgentCore 获得托管体验。使用 MCP 实现编排器和工具服务之间的通信。

构建 RAG 流水线

从 Amazon Bedrock Knowledge Bases（全托管 RAG 能力）开始，如果你需要对检索逻辑进行细粒度控制，则使用 Amazon Titan 嵌入模型构建自定义流水线。无论采用哪种方式，都要在分块策略上投入时间。它对响应质量的影响比模型选择更大。

从第一天起就实施护栏和合规措施

使用 Amazon Bedrock Guardrails 帮助抵御提示注入。如果你的行业有合规要求（游戏、医疗、金融），尽早构建分类智能体。从一开始就集成比事后改造要容易得多。

从小型模型开始选择

为每个任务使用满足准确性要求的最小模型。将更大的模型留给需要复杂推理的编排智能体。Amazon Bedrock 让在迭代过程中切换模型变得简单直接。

尽早投入评估建设

与智能体一起构建评估流水线，而不是事后补救。从第一天起就追踪包含率、解决率和客户满意度。使用 LLM-as-a-Judge 模式大规模自动化对话审查。

Fanatics Betting and Gaming 的多智能体架构展示了如何将 Amazon EKS、Amazon Bedrock、MCP 和专用 AWS AI 服务相结合，提供随业务扩展的客户支持，同时保持质量和合规性。通过使用专门的智能体执行不同任务（包括编排、知识检索、分类和工具执行），该系统处理了州级法规复杂性、实时负责任游戏检测和高流量体育赛事等难题。

本文中的模式适用范围广泛。狭隘地定义你的范围，使用职责明确的专门智能体，选择满足准确性要求的最小模型，并从一开始就投入评估基础设施建设。

如果你准备构建类似的多智能体客户支持系统，请先定义你的智能体边界并识别每个智能体需要的工具。你可以在 Amazon EKS 上部署智能体，以获得对扩展和编排的完全控制，或使用 Amazon Bedrock AgentCore 作为托管运行时为你处理基础设施。在 AI 层，Amazon Bedrock 让你通过单一 API 访问 Anthropic Claude 和 Amazon Nova 等模型，而 Amazon Bedrock Guardrails 可以帮助你添加安全检查而无需自定义代码。要开始使用，请参阅 Amazon Bedrock 入门指南和 Strands Agents 文档——这是一个支持基于 MCP 的工具编排的开源 Python 框架。