体育博彩客服不是普通的 FAQ 系统。用户提出“为什么不能下注”时,答案可能取决于所在州、账户状态、赛事阶段和实时风控信号;涉及责任博彩的问题,还必须立即进入受控流程。Fanatics Betting and Gaming 因此在 AWS 上构建了多智能体客服系统,把复杂任务交给职责明确的专业智能体,并针对重大赛事期间的流量突增设计弹性架构。
为什么一个通用智能体不够用
体育博彩支持请求至少包含三类差异明显的工作:
- 地域规则解释:同一种投注行为在不同州可能受不同规则约束,答案必须使用正确的司法辖区知识。
- 责任博彩处置:自我排除、限额、疑似失控行为等请求具有高风险和实时性,不能被当作普通问答处理。
- 账户与交易支持:充值、提款、身份验证、投注结算等问题需要访问受权限控制的业务工具。
如果让一个智能体同时掌握全部提示词、知识库和工具,它的上下文会迅速膨胀,工具选择也更容易出错。多智能体模式把系统拆成“协调者 + 专业智能体”:协调者识别意图和风险,再把任务交给规则、账户、支付或责任博彩智能体。
这种拆分的价值不只是提高回答质量,还建立了安全边界。例如,规则智能体可以只读知识库,账户智能体只能查询脱敏后的账户状态,而责任博彩智能体可以触发专门工作流并要求人工接管。
编排层才是系统的控制面
多智能体系统不能只靠模型自由对话。生产编排层至少要承担以下职责:
- 对请求进行身份验证,并补充州、语言、渠道和账户等级等可信上下文。
- 在调用模型前识别高风险关键词和业务信号。
- 根据意图选择专业智能体,而不是把所有工具同时暴露给模型。
- 为每次工具调用设置权限、超时、重试和幂等键。
- 保存路由结果、知识版本、工具调用与人工接管原因,支持审计。
在 AWS 上,可以这样实践:由 API 层接收客服请求,Lambda 或容器服务执行确定性校验,模型服务完成意图分类和回答生成,专业智能体通过受控工具访问知识库或业务 API。队列用于吸收赛事期间的突发流量,工作流服务负责长时间运行的升级与人工审批流程。
这里需要区分两种判断:模型适合处理语言歧义,代码适合执行硬规则。例如,“我觉得自己投注太多了”可以由模型识别语义,但是否冻结某类操作、如何记录自我排除请求,应由确定性策略和受审计的后端服务决定。
一个可改造的路由器示例
下面是一个最小可运行的 Python 示例。它不依赖具体 AWS SDK,用来展示多智能体入口应如何把高风险规则置于模型路由之前。实际接入时,可以把 AGENTS 中的函数替换为 Amazon Bedrock 模型调用、Lambda 函数或内部服务客户端。
运行前需要 Python 3.10 或更高版本:
from dataclasses import dataclass
from typing import Callable
@dataclass(frozen=True)
class SupportRequest:
message: str
state: str
customer_id: str
def responsible_gaming_agent(req: SupportRequest) -> str:
return (
"Your request has been routed to the responsible gaming workflow. "
"Do not provide promotional or wagering guidance."
)
def jurisdiction_agent(req: SupportRequest) -> str:
return f"Look up the approved betting rules for state={req.state}."
def account_agent(req: SupportRequest) -> str:
return f"Query the permitted account-support view for customer={req.customer_id}."
def general_agent(req: SupportRequest) -> str:
return "Search the approved customer-support knowledge base."
AGENTS: dict[str, Callable[[SupportRequest], str]] = {
"responsible_gaming": responsible_gaming_agent,
"jurisdiction": jurisdiction_agent,
"account": account_agent,
"general": general_agent,
}
HIGH_RISK_TERMS = {
"self exclude",
"self-exclude",
"stop gambling",
"betting too much",
"控制不住投注",
"自我排除",
}
def route(req: SupportRequest) -> tuple[str, str]:
text = req.message.lower()
# 硬安全规则必须先于模型分类执行。
if any(term in text for term in HIGH_RISK_TERMS):
agent_name = "responsible_gaming"
elif any(term in text for term in ("legal", "allowed", "state rule", "州规则")):
agent_name = "jurisdiction"
elif any(term in text for term in ("deposit", "withdraw", "account", "提款", "账户")):
agent_name = "account"
else:
agent_name = "general"
return agent_name, AGENTS[agent_name](req)
if __name__ == "__main__":
request = SupportRequest(
message="I am betting too much and want to self-exclude",
state="MA",
customer_id="cust_123",
)
selected_agent, action = route(request)
print({"agent": selected_agent, "action": action})
运行命令:
python3 support_router.py
这个示例刻意把责任博彩规则写在普通意图分类之前。生产系统还应从可信的账户或定位服务读取州信息,不能直接相信用户在消息中声明的位置。
为赛事流量设计弹性与降级
重大比赛开赛前、赛中判罚和结算阶段都可能产生尖峰。仅增加模型并发并不能解决问题,因为知识检索、账户 API、支付系统和人工队列都可能成为瓶颈。
可以为不同任务设置独立并发池:责任博彩请求拥有最高优先级;账户查询限制下游并发;普通 FAQ 可以使用缓存;非紧急的会话摘要和质量分析进入异步队列。下面是一份可改造的 AWS SAM 配置片段,假设入口使用 API Gateway、Lambda 和 SQS。资源名、并发额度及告警阈值需要按实际账户调整:
AWSTemplateFormatVersion: "2010-09-09"
Transform: AWS::Serverless-2016-10-31
Resources:
SupportQueue:
Type: AWS::SQS::Queue
Properties:
VisibilityTimeout: 90
RedrivePolicy:
deadLetterTargetArn: !GetAtt SupportDeadLetterQueue.Arn
maxReceiveCount: 3
SupportDeadLetterQueue:
Type: AWS::SQS::Queue
SupportRouter:
Type: AWS::Serverless::Function
Properties:
Runtime: python3.12
Handler: app.handler
Timeout: 30
MemorySize: 1024
ReservedConcurrentExecutions: 100
Environment:
Variables:
SUPPORT_QUEUE_URL: !Ref SupportQueue
Policies:
- SQSSendMessagePolicy:
QueueName: !GetAtt SupportQueue.QueueName
Events:
Api:
Type: Api
Properties:
Path: /support/messages
Method: post
队列不能用于拖延高风险响应。责任博彩请求应走同步快速通道,在后端记录事件并立即返回明确状态;队列更适合流量削峰、会话摘要、质量检查和允许延迟的后续任务。
上线前检查边界,而不只检查答案
采用这类架构时,建议重点核对以下项目:
- 每个智能体是否只有完成职责所需的最小工具权限。
- 州信息、账户状态和年龄验证是否来自可信系统。
- 责任博彩与合规规则是否能绕过生成式模型直接生效。
- 知识条目是否带司法辖区、有效期和版本元数据。
- 工具调用是否具备超时、重试、幂等和熔断策略。
- 流量洪峰时是否优先保障高风险请求,并为普通问答提供降级响应。
- 是否记录提示版本、路由决策、检索依据和人工接管结果,同时避免在日志中暴露敏感数据。
- 是否使用按州、意图和风险等级划分的测试集评估错误路由,而不只评估回答是否流畅。
多智能体不是把多个聊天机器人连在一起,而是把复杂支持流程拆成可授权、可观测、可降级的执行单元。对于体育博彩这类强监管业务,真正关键的是让模型负责理解语言,让策略服务负责硬约束,并让人工团队始终拥有清晰的接管路径。