Fanatics Betting and Gaming 如何在 AWS 上构建多智能体客户支持系统

Fanatics Betting and Gaming (FBG) 在 AWS 上构建了一个多智能体客户支持系统，以解决体育博彩领域独有的挑战。客户期望获得即时、准确的答案，尤其是在分秒必争的赛事直播期间。客户会咨询账户问题、存款限额、各州特定法规以及负责任博彩资源等相关内容。不同司法管辖区的规则各不相同，而运营商在每个辖区都持有牌照。基于决策树的传统聊天机器人解决方案难以应对这种复杂性，常常让客户感到沮丧，并因人工客服排队增加而导致成本上升。

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

面对支持量呈指数级增长的情况，FBG 的工程团队在 AWS 上构建了一个多智能体 AI 系统，能够更快、更准确地解决客户问题，且成本仅为纯人工支持的一小部分。在本文中，我们将介绍该架构、所涉及的 AWS 服务，以及您在设计自己的多智能体客户支持解决方案时可以考虑的模式。

挑战

随着 FBG 的规模扩大，其现有的支持模式需要每次交互投入更多人工，导致运营成本随客户群规模同比例上升。团队意识到，在为客户改善体验的同时，也有机会为下一阶段的增长做好准备支持基础设施。有几个因素使这个问题尤为棘手。

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

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

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

“随着规模扩大，我们知道支持体验也需要随之进化。我们希望在确保绝不牺牲负责任博彩或合规要求的前提下，为客户提供更快、更准确的答案。目标是构建一个能随时间不断改进的系统，而不仅仅是变得更大。”

解决方案概述

FBG 没有依赖单一的 monolithic 聊天机器人，而是设计了一个多智能体系统，由专门的智能体分别处理客户交互的不同方面。由于团队已经在 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 展示了高层架构。

客户消息通过FBG移动应用进入，经由Salesforce Einstein传递至Amazon EKS上的Spring AI服务，随后流经Amazon Bedrock Guardrails和负责任博彩分类器，最终到达主管代理（Supervisor Agent）。主管代理调用各类专用工具，包括检索增强生成（RAG）管道、账户与交易模型上下文协议（MCP）服务器，以及转接人工工具，以生成响应。

请求如何流经系统

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

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

主管代理在Amazon Bedrock上运行Anthropic Claude，根据客户意图决定调用哪些工具。根据查询内容，主管调用一个或多个专用工具，部分通过MCP调用，部分为服务本地工具：

• 检索增强生成（RAG）工具：从向量存储中检索相关知识，用于常见问题解答类问题。
• 账户工具（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构建了自定义实现，而非使用托管知识库，从而对摄取、分块和检索过程拥有精确控制。

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

当客户提出问题时，系统会利用LLM将查询转换为适合向量搜索的形式，然后对文档库执行相似性搜索。对于涉及特定司法管辖区的问题，系统会同时执行州特定搜索和通用搜索，将结果合并后再传递给主管代理生成回复。

当您的知识库具有复杂的检索需求（例如需要在单条回复中结合州特定文档和通用文档）时，这种定制方法尤其有价值。知识库在持续扩展中，团队通过对话分析发现内容缺口，每月新增数百份文档。

“构建我们自己的RAG管道让我们完全掌控模型能看到什么以及如何检索信息。每个州都有不同的规则，所以我们需要能够在单条回复中结合州特定文档和通用文档。这种控制级别对准确性起到了决定性作用。”

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

负责任博彩既是监管要求，也是FBG的核心价值观。团队与合规部门合作构建了一套分类系统。该系统评估客户互动，确认负责任博彩标准得到满足，并在需要时将客户连接到正确的资源。

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

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

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

“现成的客服代理对每次对话都一视同仁。我们的不行——一个关于提款的问题可能实际上是一个负责任博彩的关键时刻，识别这一点需要与我们的合规框架深度集成。这就是为什么我们在AWS上自研：没有供应商能按照我们行业要求的方式来处理这些敏感领域。”

使用Amazon Bedrock Guardrails保障安全

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

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

多模型架构

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之前的支持体验带来了可量化的改进。问题解决率（containment rate）提升了约56%，意味着更多客户问题现在无需人工客服介入即可解决。解决率（resolution rate）提升了约53%，客户的问题得到了实际解决，而非被转交或推诿。该系统已自主解决了数千个案例，节省了大量成本，因为AI驱动的交互成本仅为人工客服交互的一小部分。客户满意度也呈上升趋势。对话质量提升显著，客户常常意识不到自己是在与AI交互。

在大型体育赛事高峰期，系统能够处理高并发请求量，同时保持稳定的性能和响应质量。Amazon EKS的自动扩缩功能确保MCP服务器和Spring AI服务在流量激增时自动增加容量，无需人工干预。这意味着，无论是平静的周二还是超级碗比赛日，无论同时有多少客户在提问，客户都能获得同样快速、准确的响应。

持续改进：评估与迭代

构建智能体只是开始。FBG方法的突出之处在于他们在系统部署后持续投入改进。团队将多智能体系统视为一个有生命的产品，而非一次性的实施。他们审查对话日志，跟踪解决准确性，并利用真实客户交互来优化提示词、调整工具行为，并识别知识库中的空白。这种持续投入确保系统随着时间的推移变得越来越智能，而不是随着客户需求的变化而退化。

其评估策略的核心是一个“LLM-as-a-Judge”系统，该系统自动审查每一段已完成的对话，判断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框架。

关于作者