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

FBG 面临的核心难题在于体育博彩行业的监管碎片化。美国各州对支付方式、存款限额、提款时间线及负责任博彩要求均有独立规定，印第安纳州用户与新泽西州用户可能得到截然不同的答案。与此同时，客户咨询涵盖账户设置、交易历史、投注规则乃至自我排除选项等多元场景，单一模型或知识库难以全面覆盖。在重大赛事期间，支持请求量可在短时间内激增，系统必须在不降低响应质量的前提下即时扩容。

为解决上述挑战，FBG 放弃了单体聊天机器人方案，转而设计多智能体架构。整个系统遵循编排器模式：主监督智能体接收每条客户消息，根据意图判断调用哪些专属工具或子智能体，最终汇总结果并返回统一回复。这种设计使团队能够在不改动核心系统的前提下，按需添加新工具、新知识域或新业务单元，极大提升了迭代速度。FBG 高级软件工程经理 Luis Fernandez Rocha 表示，模块化正是团队快速行动的关键所在。

在技术选型上，FBG 选择 Amazon Bedrock 作为模型访问层，其模型无关的统一 API 让团队可以为不同任务匹配最合适的基础模型，并在更优模型出现时灵活切换。主监督智能体运行 Anthropic Claude，负责任博彩分类智能体则采用 Amazon Nova 2 Lite，对每条消息按合规批准的分类框架进行评估。高严重性分类会立即触发转人工流程，并携带完整对话上下文移交给人工坐席。Amazon Bedrock Guardrails 则在请求进入 AI 层之前提供提示注入检测与负责任 AI 防护。

系统的请求流转路径清晰且层次分明。客户通过 FBG 移动应用发送消息，经由 Salesforce Einstein 聊天界面层路由至运行在 Amazon EKS 上的 Spring AI 服务，完成令牌验证后进入 AI 智能体链路。监督智能体根据查询类型调用四类专属工具：RAG 工具从向量存储中检索 FAQ 类知识；账户工具通过 MCP 协议查询内部账户服务；交易工具获取存款、提款及投注活动记录；转人工工具则在客户主动要求或情境需要人工判断时触发升级。

FBG 的工程团队在 Amazon EKS 上已积累深厚的容器化运营经验，这使得各智能体可以独立部署、独立扩展、独立迭代，而无需相互耦合。由于整套系统运行在 FBG 既有的 AWS 环境之内，安全与治理控制得以自然继承，合规成本显著降低。FBG 首席技术官 Ian Botts 强调，团队的目标是构建一个随时间持续变好的系统，而非仅仅随规模变大的系统，这一理念贯穿了整个架构设计。

这套多智能体客服系统的落地为 FBG 带来了可量化的业务价值：客户问题解决速度加快，人工坐席队列压力降低，单次交互所需的人工介入次数减少，整体运营成本得到有效控制。更重要的是，模块化架构为未来扩展奠定了基础——无论是接入新州的合规规则、支持新业务线，还是替换性能更优的基础模型，均可在不重写核心系统的前提下实现。这一案例为同样面临高合规复杂度与高并发场景的企业提供了可借鉴的多智能体设计范式。

要点

• 编排器模式是应对复杂客服场景的有效架构选择，主监督智能体统一协调、专属子智能体各司其职，可在不改动核心系统的前提下灵活扩展新能力。
• 负责任博彩分类智能体对每条消息实时评估，高风险情况立即触发转人工并携带完整上下文，将合规要求内嵌于系统流程而非依赖事后审核。
• Amazon Bedrock 的模型无关 API 让团队可以为不同任务匹配最优基础模型，并随技术演进灵活替换，避免了对单一模型供应商的深度绑定。
• 基于现有容器平台（Amazon EKS）构建多智能体系统，可复用既有的安全、治理与运维能力，降低新架构的引入成本与合规风险。
• 模块化设计使各智能体能够独立迭代，是支撑业务快速扩张与多州合规差异化的关键工程决策。