当前位置：首页 > news >正文

基于GLM-5.2与讯飞Codex构建多模态AI智能体：打造专属世界杯AI看球伙伴

news 2026/8/8 3:56:35

1. 项目概述：当顶级AI模型遇上世界杯

最近在折腾一个挺有意思的项目，起因是世界杯快到了，作为一个资深球迷兼技术爱好者，我总想搞点新花样。看球嘛，一个人看总觉得差点意思，但朋友们的时差和对足球的热情程度又参差不齐。于是我就琢磨，能不能自己做一个专属的“AI看球搭子”？它不仅要懂球，能聊战术、评球员，还得有点“人味儿”，能接住我的各种梗和突发奇想。

这个想法听起来有点天马行空，但仔细一想，现有的技术工具其实已经能拼凑出个大概了。我的核心思路是，把两个领域的“尖子生”组合起来：一个是讯飞版Codex，它在代码生成和结构化任务处理上非常强悍；另一个是智谱的GLM-5.2，作为国内顶尖的大语言模型，它在中文理解、多轮对话和知识问答上表现突出。前者像是一个逻辑严谨、执行力超强的“战术分析师”，后者则像一个知识渊博、善于沟通的“解说评论员”。把它们俩结合起来，不就是一个能分析数据、又能陪你唠嗑的完美看球伙伴吗？

这个“AI搭子”的目标很明确：它不是一个简单的问答机器人。我希望它能做到几件事。第一，实时信息处理与解读：当比赛进行时，它能接入实时数据（比如射门、控球率、换人），并立刻给出像“这次进攻的线路很有想法，但最后一传处理得稍显急躁”这样的专业点评。第二，深度内容生成：在半场或全场结束时，能自动生成一份包含关键事件、战术变化、球员评分的数据简报。第三，沉浸式互动聊天：我能用最自然的方式问它“你觉得梅西刚才那个摆脱怎么样？”或者“为什么教练这时候要换下这个前锋？”，它能结合比赛上下文，给出有见地的回答。这本质上是一个**多模态AI智能体（AI Agent）**的构建实践，让两个大模型协同工作，一个负责“动手”（处理数据、生成内容），一个负责“动口”（理解意图、组织语言），共同完成复杂的、场景化的任务。

2. 核心组件深度解析：为什么是它们俩？

要搭建这样一个系统，选对“核心发动机”至关重要。市面上模型很多，但我最终锁定了讯飞版Codex和GLM-5.2这个组合，这背后有一系列的权衡和考量。

2.1 讯飞版Codex：精准的“执行者”

讯飞版Codex，或者更宽泛地说，这类基于GPT架构优化、专注于代码生成的模型，在这个项目中扮演的是结构化任务执行者的角色。它的核心优势不在于天马行空的创造，而在于精准地将自然语言指令转化为可执行的操作或结构化的输出。

确定性高，格式严谨：当你要求它“写一个Python函数，从某个API获取JSON格式的比赛数据，并提取出主队射门次数和控球率”时，它能生成语法正确、逻辑清晰的代码。这种能力对于处理实时数据流、解析固定格式的信息至关重要。相比之下，纯聊天模型可能会用一段文字描述该怎么做，但Codex直接给你可运行的脚本。
工具调用能力：现代AI应用离不开与各种工具和API的交互。Codex类模型经过训练，非常擅长理解“调用某个工具完成某件事”的指令。例如，我可以提示它：“调用get_live_stats()函数获取当前比分，然后调用generate_summary()函数用中文总结一下。” 它能很好地理解这种链式操作。
与GLM的分工：在这个架构里，GLM-5.2负责理解我模糊的、充满口语化的需求（比如“刚才那球怎么回事？”），并将其“翻译”成Codex能理解的精确指令（比如“查询最近5分钟内的‘射门’事件列表，并按威胁程度排序”）。Codex收到指令后，则负责具体执行——或生成查询代码，或直接组织已有数据。

注意：这里提到的“讯飞版Codex”是一个概念指代，意指具备强大代码生成与结构化任务处理能力的AI模型。在实际部署中，你可以根据实际情况选择讯飞星火认知大模型的相应API（如其代码生成能力），或其他厂商提供的类似功能模块。核心是获取一个可靠的“执行臂”。

2.2 GLM-5.2：智慧的“大脑”与“嘴巴”

智谱GLM-5.2是国内第一梯队的大语言模型，我选择它作为系统的“中枢大脑”和“交互界面”，主要基于以下几点：

顶尖的中文理解与生成能力：看球时的交流是高度口语化、充满网络用语和领域黑话的（比如“铁血防守”、“世界波”、“快乐足球”）。GLM-5.2在中文语境下的训练数据量质俱佳，能精准把握这些细微之处，让对话感觉更自然，不像是在和翻译软件聊天。
强大的知识融合与推理能力：一个优秀的足球搭子，不能只知道当前比赛。它需要知道梅西的职业生涯习惯、瓜迪奥拉的战术哲学、甚至两支球队的历史恩怨。GLM-5.2庞大的知识库和强大的推理能力，让它能把实时比赛信息与背景知识结合，说出“这次反击让我想起了2014年世界杯荷兰队对西班牙的那次经典进攻，虽然结果不同，但思路异曲同工”这样有深度的点评。
稳定的长上下文支持：一场足球比赛长达90分钟，对话会有很多轮。GLM-5.2支持的长上下文窗口，能够记住我们之前聊过的战术、点评过的球员，从而让整个对话有连贯性，不会出现“前言不搭后语”的情况。
安全与合规性：作为国内自主研发的模型，GLM在内容安全过滤和符合监管要求方面有天然优势。这对于构建一个公开或半公开可用的应用来说，是一个重要的减负项，我不需要花费大量精力去做后置的内容过滤。

组合逻辑的再梳理：简而言之，GLM-5.2是认知层，负责理解、规划和生成自然语言；讯飞版Codex是执行层，负责将规划转化为具体的、可执行的动作（代码、数据查询、格式化输出）。两者通过清晰的指令接口耦合，GLM决定“要做什么”和“怎么说”，Codex解决“怎么做”。

3. 系统架构设计与实现思路

有了核心组件，下一步就是设计一个能让它们协同工作的系统架构。这个架构并不复杂，但需要清晰地定义数据流和职责边界。我采用的是基于智能体（Agent）的经典两层架构。

3.1 整体工作流设计

整个系统的工作流可以看作一个闭环：

输入：我通过语音或文字输入一个问题或评论，例如：“阿根廷队上半场控球率这么高，为什么没进球？”
意图理解与规划（GLM-5.2负责）：GLM-5.2首先分析这句话。它会判断这需要事实数据（控球率、射门数据）作为支撑，还需要战术分析。于是，它会在内部规划一个任务列表：a) 获取上半场技术统计数据；b) 分析高控球率与进球转化率的关系；c) 结合阿根廷队特点给出观点。
任务分解与指令生成（GLM-5.2负责）：GLM将规划转化为给Codex的精确指令。例如，它可能生成这样一段结构化提示：“请执行以下操作：1. 调用fetch_first_half_stats(match_id=’ARG_vs_XXX’)获取技术统计。2. 提取主队（阿根廷）的控球率、射正次数、禁区内触球次数。3. 将数据组织成JSON格式返回给我。”
指令执行与数据获取（讯飞Codex负责）：Codex接收到这段指令后，会理解其意图，并生成或直接调用对应的代码函数，从预设的数据源（如模拟的数据库、或接入的体育数据API）中查询出所需数据，并严格按JSON格式返回。
信息综合与回复生成（GLM-5.2负责）：GLM拿到Codex返回的精准数据（如{“possession”: 68%， “shots_on_target”: 2， “touches_in_box”: 12}）。它将这些数据与自己的足球知识融合，生成最终回复：“从数据看，阿根廷上半场控球率高达68%，但射正只有2次，禁区内触球也不算多。这说明他们可能遇到了‘无效控球’的问题，在中前场缺乏穿透性的传球，更多是在中后场倒脚。对手的密集防守很成功，把空间压缩得很小。”
输出：这个回复通过文本或语音合成（TTS）输出给我，完成一轮交互。

3.2 关键技术模块拆解

为了实现上述流程，我们需要构建几个关键模块：

指令路由与协调模块：这是系统的大脑皮层。它接收用户输入，首先判断问题类型：是纯聊天（“梅西厉害吗？”）、事实查询（“现在比分多少？”）、还是复杂分析（“预测一下下半场走势”）。根据类型，决定是直接由GLM回答，还是启动“GLM规划 -> Codex执行 -> GLM合成”的链条。这里可以设计一套简单的规则或基于嵌入向量的分类器。
工具封装层：为了让Codex能可靠地“执行”，我们需要将所有的数据获取能力封装成一个个标准的“工具”（函数）。例如：
- get_live_score(match_id): 获取实时比分。
- get_match_stats(match_id, period): 获取某时间段技术统计。
- get_player_heatmap(player_id, match_id): （模拟）获取球员热图数据。
- search_historical_event(keyword): 搜索历史类似比赛事件。这些工具的接口描述（函数名、参数、返回值格式）需要清晰地提供给GLM和Codex。GLM根据需求选择工具，Codex则负责调用。
上下文管理模块：足球对话是连续的。这个模块负责维护对话历史，将相关的历史信息（如前几分钟聊过的战术、提到的球员）以摘要或关键信息的形式，随着新问题一起送入模型，保证对话的连贯性。
数据源接口：这是系统的“眼睛”。理想情况下应该接入真实的体育数据API（如一些提供实时赛况的开放数据源）。在原型阶段，我们可以用静态的JSON文件或简单的本地数据库来模拟，预先存入一场经典比赛的数据，用于测试和演示。

3.3 原型搭建与工具选型

在实际动手时，我建议从最简单的原型开始。以下是一个可行的技术栈选择：

后端框架：FastAPI。轻量、异步支持好，非常适合快速构建API。它将作为整个系统的总控制器，接收用户请求，协调GLM和Codex的调用。
模型调用：
- GLM-5.2：通过其官方提供的API进行调用。需要注意API的速率限制和成本。
- 讯飞Codex（或类似功能）：调用讯飞星火认知大模型的API，重点使用其代码生成和函数调用能力。也可以考虑其他开源或商用的代码模型作为备选。
开发语言：Python。生态丰富，在AI和数据处理方面有绝对优势，也是大多数模型API的首选客户端语言。
模拟数据：用json文件或sqlite数据库存放一场比赛的关键事件时间线、技术统计、球员名单等。

一个最简单的启动流程：

用FastAPI写一个/chat的POST接口。
接口收到用户消息后，先调用GLM-5.2 API，并附上对话历史和工具列表的描述，提示GLM“是否需要使用工具来回答这个问题？如果需要，请给出工具调用指令”。
解析GLM的返回。如果它返回了工具调用指令（如{“action”: “call_tool”， “tool_name”: “get_live_score”， “args”: {…}}），则用Codex或直接编写代码执行该工具，获取数据。
将工具执行的结果数据，连同原始问题，再次发送给GLM-5.2，让它生成最终回答。
将最终回答返回给用户。

4. 核心环节实现与提示词工程

系统架构搭好了，但要让两个AI模型听懂我们的话并高效协作，关键在于“提示词工程”。这就像给两位顶尖专家下达清晰、无歧义的工作指令。

4.1 定义GLM-5.2的“角色”与系统提示

首先，我们需要给GLM-5.2一个明确的身份和任务框架。这通过“系统提示词”来实现。这个提示词需要精心设计，并放在每一轮对话的开头，以固定其行为模式。

核心系统提示词示例：

你是一个专业的足球评论AI助手，拥有丰富的足球知识和敏锐的比赛洞察力。你的任务是帮助用户分析和讨论足球比赛。 你具备以下能力： 1. 可以查询比赛的实时数据、历史统计、球员信息等。 2. 可以根据数据和分析，提供专业的战术解读、球员点评和比赛预测。 3. 可以用生动、有趣、易懂的语言与用户交流，适当使用足球圈内的术语和梗。 【重要工作流程】： 当用户的问题需要具体数据支持时（例如涉及比分、统计、特定事件），请不要直接编造数据。你应该规划如何获取这些数据。 - 思考：用户的问题需要哪些数据？ - 规划：生成一个清晰的“工具调用请求”。这个请求必须是严格的JSON格式，只包含以下字段： { “need_data”: true, “tool_name”: “工具函数名”, “parameters”: {“参数1”: “值1”， “参数2”: “值2”}， “question_for_final_answer”: “需要基于数据回答的原始问题” } 例如，对于问题“法国队上半场角球有几个？”，你应该回复： { “need_data”: true, “tool_name”: “get_match_stats”， “parameters”: {“team”: “France”， “period”: “first_half”， “stat_type”: “corners”}， “question_for_final_answer”: “法国队上半场角球有几个？” } 如果用户的问题只是普通聊天或不需要精确数据，请直接回答，并设置 “need_data”: false。 当前对话历史摘要：[此处由上下文管理模块填入] 可用的工具列表：[列出封装好的所有工具函数及其说明]

这个提示词做了几件事：赋予角色（专业评论员）、划定能力范围、规定输出格式（特别是需要数据时的JSON结构）、提供示例。这能极大地提高GLM输出结果的稳定性和可解析性。

4.2 设计Codex的“工具调用”提示

当后端收到GLM发出的“工具调用请求”JSON后，就需要调用Codex（或直接执行）来完成任务。给Codex的提示需要侧重于精准执行。

Codex提示词示例：

你是一个代码执行专家。请根据以下任务描述，生成Python代码来调用工具获取数据。 工具函数定义： def get_match_stats(match_id: str, team: str, period: str, stat_type: str) -> dict: “““根据比赛ID、球队、时间段和统计类型，获取数据。period可以是 ‘first_half’， ‘second_half’， ‘full_match’。stat_type可以是 ‘goals’， ‘possession’， ‘shots’， ‘corners’等。””” # 函数内部会连接数据源进行查询 pass 任务请求： { “tool_name”: “get_match_stats”， “parameters”: {“team”: “France”， “period”: “first_half”， “stat_type”: “corners”} } 请生成调用该函数并返回结果的代码。假设比赛ID是固定的 ‘WORLD_CUP_2022_FINAL’。

Codex会根据这个提示，生成类似下面的代码：

result = get_match_stats(match_id=‘WORLD_CUP_2022_FINAL’， team=‘France’， period=‘first_half’， stat_type=‘corners’) print(result) # 或者以JSON格式返回

后端安全地执行这段代码（或在沙箱中），就能得到{“corners”: 5}这样的数据。

4.3 数据合成与最终回复生成

拿到Codex执行返回的原始数据后，我们将其和用户的原始问题（从question_for_final_answer字段获取）一起，再次发送给GLM-5.2，让它生成友好、专业的最终回复。

最终合成提示词示例：

这是用户关于足球比赛的问题：“[question_for_final_answer]”。 我们已经查询到了相关数据，数据如下（JSON格式）： [这里填入获取到的数据，例如：{“corners”: 5}] 请你作为一名专业的足球评论员，基于以上准确数据，对用户的问题进行解答。解答需要： 1. 直接、明确地回答数据部分（例如：“法国队上半场获得了5个角球。”）。 2. 结合你的足球知识，对数据进行简要解读（例如：“这个角球数量在势均力敌的决赛中属于正常偏多，说明法国队在左路/右路制造了不小的压力。”）。 3. 语言保持自然、口语化，像朋友间聊天一样。

通过这三段式的提示词设计，我们构建了一个稳定的协作链条：GLM思考规划 -> Codex精准执行 -> GLM润色输出。这个模式可以扩展到更复杂的多工具调用场景。

5. 实战调试与效果优化

把系统跑起来只是第一步，让它真正像个“懂球”的搭子，还需要大量的调试和优化。这个过程充满了“踩坑”和“顿悟”。

5.1 初期常见问题与排查

在项目初期，我遇到了几个非常典型的问题：

GLM不按格式输出：这是最头疼的问题。明明在系统提示里要求返回JSON，它有时还是会直接输出一段话，比如“用户想查询角球数，我需要调用get_match_stats工具…”。这会导致后端解析失败。
- 排查与解决：
  - 强化格式指令：在系统提示中，将格式要求用更加强硬、重复的方式强调。例如使用“你必须”、“只能”、“严格遵循”等词语，并用json代码块展示示例。
  - 调整温度参数：调用GLM API时，将temperature参数调低（比如从0.8调到0.2）。这个参数控制输出的随机性，调低后模型会更倾向于选择最确定、最符合提示的答案，有利于固定格式。
  - 后处理与重试：在代码中加入简单的后处理逻辑。如果返回内容不是合法JSON，尝试用正则表达式提取可能包含的JSON部分，或者直接向模型发送一条修正指令：“你上次的回复格式不正确，请严格按照要求的JSON格式重新回答。”
Codex生成的代码有误或无法执行：例如，生成的函数参数顺序错了，或者使用了不存在的变量。
- 排查与解决：
  - 提供更详细的工具文档：在给Codex的提示中，把工具函数的签名、参数类型、返回值、可能抛出的异常写得尽可能详细，甚至提供一个调用成功的例子。
  - 使用更具体的示例：示例不要只用伪代码，尽量用真实的、可运行的代码片段作为示例，让Codex“依葫芦画瓢”。
  - 执行环境隔离：一定要在安全的沙箱环境（如docker容器）或严格的资源限制下执行生成的代码，防止恶意或错误的代码影响主系统。
上下文遗忘或混淆：在多轮对话中，AI可能会忘记之前提过的球队、球员或讨论的焦点。
- 排查与解决：
  - 实现对话历史管理：不要简单地把所有历史对话都塞进提示词（会超长且混乱）。可以维护一个“对话摘要”，每轮对话后，用GLM对当前对话的核心信息（如：我们正在讨论阿根廷对法国的上半场，焦点是梅西的活跃区域和法国的防守策略）进行摘要，并将这个摘要作为下一轮对话的系统提示补充部分。
  - 关键信息显式传递：对于非常重要的上下文（如当前比赛的ID），可以在每轮请求中，由后端主动将其作为“已知事实”插入到用户问题之前，例如：“已知当前讨论的比赛ID是：MATCH_123。用户问：…”

5.2 提升“懂球感”的进阶技巧

解决了基本运行问题后，就要追求“神似”了，让AI的点评不显得外行。

注入足球领域知识：在给GLM的系统提示中，可以加入一些足球领域的核心分析框架。例如：
“在分析比赛时，你可以从这些维度思考：攻防转换速度、阵地战组织、边路与中路进攻比重、定位球威胁、关键球员的对位情况等。” 这相当于给了AI一个思考的脚手架，让它输出的内容更有结构，更专业。
利用实时事件流：如果数据源支持，不要只给AI“死数据”（如最终统计）。可以模拟或接入事件流（Event Stream），比如“第23分钟，梅西在禁区弧顶接到传球，左脚射门被门将扑出”。AI结合具体事件进行评论，会比单纯说“射门次数为5”生动得多。
风格化调整：通过提示词，你可以定制AI搭子的性格。比如：
- 激情解说型：“你的语言要富有激情，多使用感叹号，可以加入‘漂亮！’‘这球太可惜了！’等感叹词。”
- 冷静分析型：“你的语言要保持客观冷静，侧重战术和数据分析，避免过多情绪化表达。”
- 幽默调侃型：“你可以适当使用网络流行语和幽默的比喻，让聊天更轻松有趣。”
处理模糊与未知问题：AI不是神，肯定会遇到不知道或数据没有的问题。要提前设计好应对策略。在系统提示中告诉GLM：“如果用户的问题涉及未知信息或当前数据无法支持，请诚实告知‘根据现有数据，我无法确认这一点’，但可以基于一般足球知识进行推测，并明确指出这是推测。”

5.3 性能与成本考量

这是一个现实问题。两个大模型的API调用都不便宜，尤其是高频交互时。

缓存策略：对于相同的数据查询请求（例如“法国队上半场角球数”），其结果在短时间内是不会变的。可以在后端建立缓存机制（使用redis或内存缓存），将(工具名，参数)作为键，查询结果作为值，设置一个合理的过期时间（如1分钟）。这样能极大减少对Codex和数据源的重复调用。
简化工具调用：并非所有问题都需要走“规划->执行”的完整链条。对于一些非常简单的、事实性的、且你确信GLM知识库中已有的问题（如“梅西效力于哪个俱乐部？”），可以直接让GLM回答，无需触发工具调用。这需要在指令路由模块做好判断。
异步与流式响应：对于需要复杂分析的问题，生成答案可能需要较长时间。可以采用异步处理，先快速返回一个“正在分析…”的提示，后台处理完后再推送完整结果。或者采用流式响应，让AI边“想”边“说”，提升用户体验。

6. 项目总结与未来展望

构建这个“AI世界杯搭子”的过程，更像是一次对现有AI能力边界和协作模式的深度探索。它不是一个能直接上线的产品，而是一个非常有价值的原型验证。通过这个项目，我清晰地看到了像GLM-5.2这样的通用大模型与像Codex这样的垂直工具模型如何取长补短。GLM提供了理解、规划和沟通的“大脑”，而Codex提供了精准、可靠的“双手”。这种“大脑+手脚”的智能体模式，是解决复杂、多步骤现实任务的一个非常有力的范式。

在实际操作中，最大的挑战并非来自技术本身，而是如何让两个模型“听懂”彼此的“语言”，也就是提示词工程和接口设计。这需要开发者对两个模型的能力边界、思维习惯有深刻的理解。例如，GLM需要被明确地引导去“思考是否需要数据”以及“如何格式化它的需求”，而Codex则需要极其清晰、无歧义的“工作说明书”。

这个项目的潜力远不止于看球。它的框架可以平移到很多场景：

金融分析助手：GLM理解用户关于市场、财报的复杂问题，规划分析步骤；Codex调用数据API获取股价、财务指标，进行计算，最后GLM生成分析报告。
智能旅行规划：GLM理解用户“想找一个安静、有美食、适合周末放松的海边城市”的需求，规划查询步骤；Codex调用地图、酒店、美食评分API；GLM整合信息生成个性化攻略。
企业内部知识库问答：GLM理解员工关于公司制度、项目历史的问题；Codex检索向量数据库或知识图谱；GLM生成准确、友好的回答。

最后分享一个我踩过的大坑：在早期测试时，我一度想让GLM一次性规划多个工具调用，比如同时获取比分、控球率和射门数据。结果发现，这大大增加了GLM输出格式的复杂性和不稳定性，也使得后端调度逻辑变得复杂。后来我果断改为单步执行策略：一次只完成一个最核心的数据查询动作。如果用户问题确实复杂，可以通过多轮对话，像剥洋葱一样一层层解决。这虽然增加了交互轮次，但极大地提高了系统的稳定性和可维护性。在AI应用开发中，有时候“慢就是快”，用简单的、鲁棒性高的设计去替代复杂的、脆弱的“智能”，往往是更明智的选择。

查看全文

http://www.cnnetsun.cn/news/3901838.html