用 LLM Agent 做实时赛事解说与数据播报

在RAG 赛事知识库那篇里我反复强调一件事：RAG 管静态知识，实时数据得靠工具调用。这篇就把实时那半补上——用 LLM Agent 搭一个能实时播报比分、生成解说词的赛事助手。

核心区别要先讲透：RAG 是「先检索固定资料再回答」，而 Agent 是「模型自己决定该调用哪个工具拿数据」。问「现在几比几」，Agent 会判断这需要实时数据，于是调用比分 API，拿到结果再组织成解说。这种「模型自主决定调用外部能力」就是工具调用（function calling）的精髓。Agent 的基础概念可以看AI Agent 完全指南。

为什么实时场景必须用 Agent

设想用户问的几种问题：

「巴西历史上拿过几次冠军」→ 静态知识，RAG 就够。

「现在这场几比几」→ 必须实时查，RAG 里的数据一定是过期的。

「梅西这场跑了多少米」→ 实时统计数据，得调数据 API。

后两类的共同点：答案在不断变化，唯一正解是让模型在回答的那一刻去外部拿最新数据。这就是 Agent + 工具调用存在的理由。

第一步：定义工具

工具就是一组你暴露给模型的函数。关键在描述写清楚——模型靠描述判断什么时候该调它。

python
tools = [
    {
        "type": "function",
        "function": {
            "name": "get_live_score",
            "description": "获取某场正在进行的比赛的实时比分和基本事件。"
                           "当用户问当前比分、谁进球了、比赛进行到第几分钟时调用。",
            "parameters": {
                "type": "object",
                "properties": {
                    "home_team": {"type": "string", "description": "主队名"},
                    "away_team": {"type": "string", "description": "客队名"},
                },
                "required": ["home_team", "away_team"],
            },
        },
    },
    {
        "type": "function",
        "function": {
            "name": "get_match_stats",
            "description": "获取一场比赛的详细统计：控球率、射门、跑动距离等。"
                           "用户问具体数据指标时调用。",
            "parameters": {
                "type": "object",
                "properties": {"match_id": {"type": "string"}},
                "required": ["match_id"],
            },
        },
    },
]

工具描述要像写给同事的说明：什么时候用、需要什么参数。描述含糊，模型就会在不该调的时候乱调、或该调时不调。

第二步：Agent 主循环

Agent 的运行是个循环：模型决定调工具 → 你执行 → 把结果喂回去 → 模型继续，直到它给出最终回答。

python
import json
from openai import OpenAI
client = OpenAI()
实际实现里这些函数去打真实的体育数据 API
def get_live_score(home_team, away_team):
    # 调用第三方实时比分 API（如 API-Football 等）
    return {"home": home_team, "away": away_team, "score": "1-0", "minute": 67}
DISPATCH = {"get_live_score": get_live_score}
def run_agent(user_msg):
    messages = [
        {"role": "system", "content": "你是世界杯实时解说助手，语言生动口语化，"
                                       "但所有比分和数据必须来自工具返回，不许编造。"},
        {"role": "user", "content": user_msg},
    ]
    while True:
        resp = client.chat.completions.create(
            model="gpt-4o", messages=messages, tools=tools,
        )
        msg = resp.choices[0].message
        if not msg.tool_calls:
            return msg.content  # 模型给出最终回答，结束
        messages.append(msg)
        for call in msg.tool_calls:
            args = json.loads(call.function.arguments)
            result = DISPATCHcall.function.name
            messages.append({
                "role": "tool",
                "tool_call_id": call.id,
                "content": json.dumps(result, ensure_ascii=False),
            })
print(run_agent("巴西这场现在什么情况？"))
→ Agent 调 get_live_score，拿到 1-0 第67分钟，再生成解说

这个循环就是所有 Agent 框架（LangGraph、AutoGen 等）底层在做的事。理解了裸循环，再用框架就清楚它在帮你管什么。想用框架管理更复杂的状态，看LangGraph 有状态 Agent 完全指南。

防幻觉：实时场景的头号风险

实时 Agent 最危险的失败模式是：API 还没返回，模型就自己「脑补」了一个比分。压住它的几个手段：

system prompt 死命令：「所有比分、数据必须来自工具返回，工具没返回就说还没拿到」。

工具失败要显式告知模型：API 超时就返回 {"error": "数据源暂时不可用"}，让模型如实转达，而不是回退到瞎编。

关键数字二次校验：比分这种，可以让模型把工具返回的原始数字附在回答里，方便核对。

Agent 的 system prompt 怎么写更稳，可参考AI Agent 系统提示词工程。

成本与延迟：别忽视

Agent 每轮可能多次调模型 + 调 API，实时解说对延迟敏感，几个优化点：

能用小模型的环节用小模型：判断「该调哪个工具」这种路由决策，gpt-4o-mini 足够，省钱省时。

缓存慢变数据：球队基本信息没必要每次实时查，缓存住。

并行调工具：如果一轮要查多场比赛，并行发起而不是串行等。

拼成完整赛事助手

到这里，你手上有了两块拼图：

RAG（上一篇）——回答历史、规则、球队这些静态知识。

Agent 工具调用（本篇）——回答实时比分、即时数据。

把两者合一：用户提问先经一个路由判断「这是静态知识还是实时问题」，分别走 RAG 或 Agent。这就是一个生产级赛事助手的骨架。

全部应用的全景，以及它们怎么串成产品，见AI 与 2026 世界杯应用盘点。从练手角度，建议先把单个工具的调用循环跑通——把这个裸循环吃透，比一上来套框架收获大得多。