你是不是也想过玩《上古卷轴5天际》时身边能有一个“活人队友”一样的存在它听得懂你说话、能根据当前战斗场景给出建议、会在你迷路时提醒任务方向甚至能陪你闲聊几句剧情最近开发者打造的低延迟 AI 游戏伙伴Varkos引发了不少玩家和开发者的关注。它的核心卖点不是“套壳聊天机器人”而是能够在游戏过程中实时感知、实时响应、低延迟交互真正做到“陪玩”而非“问答工具”。这篇文章不会只停留在新闻解读。我会结合当前 AI 游戏助手的主流实现思路从低延迟架构、实时语音交互、游戏状态监听、流式响应、本地化部署等角度拆解 Varkos 这类项目背后的技术细节并手把手带大家搭建一个简化版但不失完整性的“实时 AI 游戏伙伴”工程骨架。如果你是游戏开发者、AI 应用开发者或者正在研究“大模型 实时场景”落地的技术人这篇文章应该能给你不少可落地的思路。1. 低延迟 AI 游戏伙伴到底是什么1.1 从“聊天机器人”到“游戏伙伴”的跨越我们平时接触的 AI 助手大多是“用户提问 → AI 回复”的单轮对话模式。但在游戏场景中这种交互远远不够。试想一个真实场景玩家正在和巨龙战斗血量见底此时他喊了一句“快给我加血”。传统的聊天机器人会回复“好的我建议你使用治疗药水”然后……就没有然后了。玩家需要自己打开背包、找到药水、喝下去整个过程中 AI 完全没有参与游戏本身。而 Varkos 这类“游戏伙伴”的体验完全不同它听到你的语音后自动识别当前游戏状态战斗中、潜行中、对话中、地图界面。它不只是“建议”而是直接触发游戏内动作比如自动使用治疗药水、切换武器、施放法术。它的响应速度必须足够快否则战斗早就结束了再聪明的回复也毫无意义。所以低延迟 AI 游戏伙伴的本质是大模型能力 游戏状态感知 实时动作执行的三位一体。1.2 Varkos 解决了什么痛点传统游戏 AI 助手有几个痛点响应延迟高。通用大模型 API 的响应时间通常在 2-5 秒这在游戏场景中是不可接受的。缺乏游戏感知能力。AI 不知道玩家当前在什么场景、面对什么敌人、血量多少、任务做到哪一步。交互方式不自然。玩家不可能在激战中停下来打字。执行链路断裂。AI 给出了建议但玩家还得手动操作所谓“AI”其实只是“搜索增强版攻略”。Varkos 的定位就是把这些痛点一次解决掉。从工程角度来看它最值得学习的是实时链路设计语音输入 → 意图识别 → 游戏状态融合 → 大模型推理 → 动作执行 → 语音反馈全链路的延迟必须被严格压缩。1.3 适合谁关注这个项目如果你是下面几类人这篇文章的技术拆解会对你有帮助游戏开发者想在自己的游戏里接入 AI NPC、AI 队友或智能助手。AI 应用工程师研究大模型如何从“聊天”走向“执行”如何打破 API 延迟瓶颈。独立开发者想做一款 AI 游戏周边工具需要完整技术参考。技术爱好者单纯对“如何实现游戏实时 AI”这件事感兴趣。2. Varkos 的核心技术定位2.1 低延迟实时 AI 的生命线延迟是 Varkos 这类项目最核心的指标。我们换算一下人正常的语音对话中300-500ms 的响应延迟是可以接受的超过 1 秒就会明显感到“卡顿”。而游戏场景中一场遭遇战可能只有 10-20 秒如果 AI 回复需要 3 秒基本等于废了。所以Varkos 的低延迟设计会从这几个层面入手流式输出Streaming不等大模型生成完整回复而是“边生成边输出”首 token 延迟TTFT可能只有几百毫秒。本地小模型 云端大模型混合意图识别、关键词提取等轻量任务用本地模型复杂推理才走云端大模型。缓存与预计算把常见场景比如“加血”“切换武器”“打开地图”的指令提前缓存本地直接匹配。游戏内快捷键触发 语音识别并行语音识别结果一边出一边就进入意图识别而不是等整句话说完。2.2 实时感知AI 如何“看懂”游戏Varkos 另一个关键技术点是对游戏状态的实时感知。这里一般有几种实现方式读取内存数据直接读取游戏进程内存获取角色血量、坐标、任务 ID、当前场景等数据。优点是精确度高缺点是需要为每个游戏单独写适配器且可能违反游戏用户协议。屏幕像素识别通过截图 OCR 图像分类识别游戏 HUD 上的血条、敌人数量、当前界面等。优点是通用性强缺点是实时性稍差。日志与事件钩子通过游戏内置的日志或 Mod SDK 获取事件。比如 Skyrim 的 Script ExtenderSKSE允许 Mod 读取游戏事件。Varkos 据公开资料显示针对《上古卷轴5天际》使用了游戏内 Mod 或外部 Hook 的方式获取实时状态这也是它能做到“精准陪玩”的原因之一。这里需要强调一点所有游戏数据读取和自动化操作都必须在单机、离线、合法授权的环境下使用。不要将其用于联机游戏作弊或破坏他人游戏体验这一点工程师必须有底线意识。2.3 实时交互不仅仅是文字对话Varkos 的交互方式是“全语音 游戏内反馈”玩家用麦克风说“帮我把弓箭换成长剑”。AI 识别意图后在游戏内直接切换武器。AI 再用语音回复“已切换当前敌人距离较远建议保持潜行”。这套交互闭环涉及语音活动检测VAD→ 语音识别ASR→ 意图理解NLU→ 游戏状态融合 → 大模型推理 → 动作脚本执行 → 语音合成TTS。每一个环节的延迟都会被仔细优化这就是低延迟 AI 游戏伙伴和普通聊天机器人最大的区别。3. 低延迟实时链路设计逐层拆解在写代码之前我们先梳理清楚链路中每一层的作用和延迟控制手段。这部分理解透了后面写代码才不会跑偏。3.1 语音输入层目标把玩家的语音在极短时间内转成文本。常用方案本地 Whispersmall/base 模型进行 ASR。流式语音识别比如 faster-whisper 或 sherpa-onnx可以在说话过程中增量识别。游戏场景下建议使用按键说话Push-to-Talk避免环境音误触发。延迟优化点使用量化模型int8换取推理速度。只对有效语音段做识别静音段丢弃。识别过程中如果已经识别出关键短语例如“加血”“换武器”可以提前交给意图识别层不必等整句话结束。3.2 意图识别层目标判断玩家这句话是想“执行动作”还是“询问信息”。例如“快加血” → 执行类意图需要触发游戏动作。“这个任务怎么做” → 信息类意图需要结合任务状态生成攻略回复。“你觉得这个龙好看吗” → 闲聊类意图直接大模型生成回复即可。延迟优化点使用轻量分类模型几 MB 到几十 MB本地运行。关键词优先匹配规则命中常用指令直接走快捷路径不走大模型。规则引擎兜底 模型兜底的双层结构。3.3 游戏状态融合层目标把玩家的意图和当前游戏状态拼装成“大模型可理解的上下文”。比如玩家说“帮我加血”如果不告诉大模型“玩家当前血量 20%、背包有 12 瓶治疗药水、正处于战斗状态”大模型只能给出通用建议。而 Varkos 能直接拼装出类似这样的上下文当前角色血量: 20% 当前场景: 龙裔VS远古巨龙 可用道具: [治疗药水x12, 魔法药水x5] 推荐动作: 使用治疗药水延迟优化点游戏数据读取线程和服务主线程分离避免 IO 阻塞。状态数据按需获取不要每次都全量读取游戏内存。状态上下文做模板化减少 token 数量降低大模型推理时间。3.4 大模型推理层目标生成自然语言回复或决策结果。Varkos 这类项目一般会采用本地模型 云 API 混合策略本地模型负责低延迟基础回复。云端大模型负责复杂推理、长对话、知识问答。流式输出保证玩家能迅速听到第一个字。延迟优化点使用量化模型 GPU/CPU 合理配置。设置合理的最大生成长度避免模型啰嗦。使用 Function Calling 或结构化输出让模型直接输出可执行动作 JSON减少二次解析耗时。3.5 动作执行与反馈层目标把 AI 的决策变成游戏内的实际操作。在《上古卷轴5天际》中可以通过 Mod 方式监听并触发游戏动作。例如通过 SKSE 插件接收外部指令执行“切换武器”“喝药”“施法”等操作。延迟优化点游戏动作指令尽量用本地 Socket / 共享内存传递不要走 HTTP。动作队列做成 FIFO避免指令堆积。执行完成后立刻异步返回结果触发下一轮语音反馈。4. 环境准备与项目结构下面我们动手搭建一个简化版但完整可运行的“低延迟 AI 游戏伙伴”工程骨架。我会以 Python 为主语言覆盖语音识别、意图识别、大模型流式回复、动作事件输出、延迟监听等核心模块。4.1 开发环境说明项目说明操作系统Windows 10/11 或 Ubuntu 20.04Python 版本3.10语音识别faster-whisper大模型可选用本地 Ollama Qwen2.5 7B也可以接 OpenAI 兼容 API语音合成edge-tts 或 pyttsx3游戏通信预留 Socket Server实际对接游戏 Mod / 自动化工具依赖管理pip requirements.txt版本说明faster-whisper 和 Ollama 都在快速迭代本文示例以稳定可运行为目标具体版本请按你的环境调整。4.2 创建项目结构建议先创建如下目录结构varkos-demo/ ├── main.py # 主程序入口 ├── requirements.txt # 依赖 ├── core/ │ ├── __init__.py │ ├── asr.py # 语音识别模块 │ ├── nlu.py # 意图识别模块 │ ├── game_state.py # 游戏状态模拟模块 │ ├── llm_engine.py # 大模型推理模块 │ ├── executer.py # 动作执行模块 │ └── latency.py # 延迟统计模块 ├── configs/ │ └── config.yaml # 配置文件 └── logs/ └── .gitkeep4.3 安装依赖pip install faster-whisper edge-tts pynput pyyaml requests如果你使用 Ollama 本地模型ollama pull qwen2.5:7b5. 完整实战从语音到动作的低延迟闭环接下来我们分模块编写核心代码。为了让你更容易看到全貌我会把代码拆成清晰的文件并在关键位置加上注释。5.1 配置模块先创建一个简单的配置文件。# 文件路径configs/config.yaml asr: model_size: small # 可选 tiny/base/small/medium device: auto # auto 自动选择 GPU/CPU compute_type: int8 # 量化类型int8 可显著提升推理速度 llm: provider: ollama # ollama 或 openai model: qwen2.5:7b # 本地模型名称 base_url: http://localhost:11434 temperature: 0.7 max_tokens: 256 game: socket_host: 127.0.0.1 socket_port: 8123 latency: log_enabled: true # 是否打印延迟日志 max_tolerate_ms: 1500 # 延迟容忍阈值5.2 语音识别模块ASR我们用 faster-whisper 实现语音识别。为了降低延迟这里做两个优化使用 int8 量化模型。识别过程中打印出“已识别的中间结果”方便后续做提前触发。# 文件路径core/asr.py from faster_whisper import WhisperModel import time class ASREngine: def __init__(self, config): self.config config self.model WhisperModel( config[asr][model_size], deviceconfig[asr][device], compute_typeconfig[asr][compute_type], ) def transcribe(self, audio_path: str) - dict: 将音频文件转为文本。 返回包括文本、耗时和分段信息。 start time.time() segments, info self.model.transcribe( audio_path, languagezh, vad_filterTrue, # 过滤静音 ) text .join(seg.text for seg in segments) elapsed_ms (time.time() - start) * 1000 return { text: text, elapsed_ms: elapsed_ms, language: info.language, }调用效果示例asr ASREngine(config) result asr.transcribe(test.wav) print(result[text], result[elapsed_ms])5.3 意图识别模块NLU意图识别不能总等大模型太慢。这里采用“关键词规则 轻量映射”的方式覆盖游戏中最常用的指令。# 文件路径core/nlu.py import re class NLUEngine: 意图识别优先匹配本地规则未命中再交给 LLM。 def __init__(self, config): self.config config self.intent_map { heal: [加血, 回血, 治疗, 喝药, 补血, 加血药], switch_weapon: [换武器, 切换武器, 用长剑, 用弓箭, 拿出法杖], cast_spell: [施法, 释放法术, 用魔法, 放火球, 闪电], open_map: [打开地图, 地图], quest_hint: [任务, 下一步, 怎么做, 去哪, 任务提示], chitchat: [你好, 你是谁, 聊聊, 天气], } def parse(self, text: str) - dict: 返回意图结构confidence 表示规则置信度。 规则置信度低于 0.6 时调用方可选择是否走 LLM。 for intent, keywords in self.intent_map.items(): for kw in keywords: if re.search(kw, text): return { intent: intent, confidence: 0.9, trigger: kw, } return { intent: unknown, confidence: 0.1, trigger: , }这里设计了一个“先本地后云端”的双层结构。高频指令加血、换武器能直接命中耗时可以控制在 1ms 级别。5.4 游戏状态模拟模块真实场景下这里会和游戏内存读取或 Mod 事件总线对接。为了让示例能独立运行我先做一个模拟状态模块模拟一个“正在战斗中的龙裔角色”。# 文件路径core/game_state.py import random class GameState: 模拟游戏状态实际项目中可替换为读取游戏进程数据或对接 Mod SDK。 def __init__(self): self.health 80 self.magicka 100 self.stamina 100 self.current_weapon 铁剑 self.in_battle False self.potions {治疗药水: 12, 魔法药水: 5} def update(self): 模拟游戏状态变化。 实际项目中这里应定时从游戏内存或 Mod 事件中拉取最新数据。 self.health max(0, self.health random.randint(-5, 3)) self.in_battle random.random() 0.6 def snapshot(self) - str: 生成一段文本描述拼接到大模型 Prompt 中。 weapon_map { current_weapon: self.current_weapon, health: self.health, magicka: self.magicka, stamina: self.stamina, in_battle: self.in_battle, potions: self.potions, } return str(weapon_map)5.5 大模型推理模块这里实现两个关键能力支持 Ollama 本地模型流式输出。支持把游戏状态上下文拼接到 Prompt 中。# 文件路径core/llm_engine.py import json import requests class LLMEngine: def __init__(self, config): self.config config self.provider config[llm][provider] self.base_url config[llm][base_url] self.model config[llm][model] def build_prompt(self, user_text: str, game_state_str: str) - str: 组装带游戏状态的 Prompt。 游戏状态注入是低延迟陪玩的关键。 system_prompt ( 你是一个游戏 AI 伙伴正在陪玩家游玩《上古卷轴5天际》。 你需要根据玩家话语和当前游戏状态给出简短、直接、可执行的回复。 如果玩家要求执行动作请输出 JSON 格式的动作指令例如 {action: use_potion, target: 治疗药水} ) return ( f{system_prompt}\n\n当前游戏状态\n{game_state_str}\n\n f玩家说{user_text}\n\n请回复 ) def stream_chat(self, prompt: str): 流式调用本地大模型。 返回生成器的迭代器逐块输出文本。 if self.provider ollama: url f{self.base_url}/api/chat payload { model: self.model, messages: [{role: user, content: prompt}], stream: True, options: { temperature: self.config[llm][temperature], num_predict: self.config[llm][max_tokens], }, } resp requests.post(url, jsonpayload, streamTrue) for line in resp.iter_lines(): if not line: continue data json.loads(line) token data.get(message, {}).get(content, ) if token: yield token else: raise ValueError(Unsupported LLM provider)这里的核心是Streaming。玩家不用等整段回复而是“听到第一个字就感觉 AI 已经回应了”这在感知延迟上能大幅降低焦虑感。5.6 动作执行模块动作执行模块在真实项目中会通过 Socket 或共享内存把指令发给游戏 Mod。这里我们先用一个模拟器把指令打印出来同时预留 Socket 发送逻辑。# 文件路径core/executer.py import socket import json class ActionExecuter: 动作执行器。 真实场景把动作指令通过 Socket 发送给游戏内 Mod 插件。 演示场景打印并统计指令。 def __init__(self, config): self.config config self.host config[game][socket_host] self.port config[game][socket_port] def execute(self, action: dict) - bool: 执行动作指令。 action 示例{action: use_potion, target: 治疗药水} # 真实对接游戏时这里会发送给游戏 Mod # with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s: # s.connect((self.host, self.port)) # s.sendall(json.dumps(action).encode(utf-8)) print(f[动作执行] 收到指令: {json.dumps(action, ensure_asciiFalse)}) return True5.7 主流程把整条链路串起来现在我们把这些模块组装成一个主程序。流程如下玩家说话演示中直接用文本模拟语音识别结果也支持传入音频文件。意图识别判断如果是动作指令直接走动作执行。如果是复杂问题拼接游戏状态后调用大模型流式生成回复。记录每个阶段的耗时找出延迟瓶颈。# 文件路径main.py import sys import yaml from core.asr import ASREngine from core.nlu import NLUEngine from core.game_state import GameState from core.llm_engine import LLMEngine from core.executer import ActionExecuter from core.latency import LatencyTimer def load_config(): with open(configs/config.yaml, r, encodingutf-8) as f: return yaml.safe_load(f) def main(): config load_config() # 初始化各模块 nlu NLUEngine(config) game_state GameState() llm LLMEngine(config) executer ActionExecuter(config) # 演示模式如果传入音频文件路径就做真实 ASR否则用命令行文本输入 if len(sys.argv) 1: asr ASREngine(config) timer LatencyTimer() timer.start(asr) asr_result asr.transcribe(sys.argv[1]) timer.stop(asr) user_text asr_result[text] print(f[ASR] 识别结果{user_text}耗时{asr_result[elapsed_ms]:.0f}ms) else: user_text input(请输入你说的话或输入音频路径) timer LatencyTimer() game_state.update() state_str game_state.snapshot() # 1. 意图识别 timer.start(nlu) intent_result nlu.parse(user_text) timer.stop(nlu) print(f[NLU] 意图{intent_result[intent]}置信度{intent_result[confidence]}) # 2. 判断是否需要走大模型 if intent_result[intent] unknown: prompt llm.build_prompt(user_text, state_str) print([LLM] 需要调用大模型生成回复...) timer.start(llm_first_token) for token in llm.stream_chat(prompt): # 生产中可以把 token 通过 TTS 播报出来这里直接在终端输出 print(token, end, flushTrue) timer.stop(llm_first_token) print(\n) else: action map_intent_to_action(intent_result[intent], game_state) if action: executer.execute(action) else: prompt llm.build_prompt(user_text, state_str) print([LLM] 生成回复...) for token in llm.stream_chat(prompt): print(token, end, flushTrue) print(\n) timer.print_summary() def map_intent_to_action(intent: str, game_state: GameState) - dict: 根据意图映射为游戏动作指令。 if intent heal: return {action: use_potion, target: 治疗药水} if intent switch_weapon: return {action: switch_weapon, target: 长剑} if intent cast_spell: return {action: cast_spell, target: 火球术} if intent open_map: return {action: open_map} if intent quest_hint: return None # 需要大模型生成攻略信息 return None if __name__ __main__: main()补充一个简单的延迟统计模块# 文件路径core/latency.py import time class LatencyTimer: def __init__(self): self.records {} self._current {} def start(self, name: str): self._current[name] time.time() def stop(self, name: str) - float: elapsed_ms (time.time() - self._current[name]) * 1000 self.records[name] elapsed_ms return elapsed_ms def print_summary(self): print(\n 延迟统计 ) for name, ms in self.records.items(): print(f{name}: {ms:.1f}ms) print()5.8 运行演示启动 Ollama 服务后运行主程序python main.py输入我受伤了快帮我加血预期输出[NLU] 意图heal置信度0.9 [动作执行] 收到指令: {action: use_potion, target: 治疗药水} 延迟统计 nlu: 0.3ms 再输入一个复杂问题比如这个主线任务下一步应该去哪由于意图识别为quest_hint会调用本地大模型生成带游戏状态的回复。你可以看到流式输出的效果。6. 延迟优化像 Varkos 一样追求毫秒级响应上面的代码只是骨架。要真正做到 Varkos 级别的低延迟还需要做更深一层的优化。6.1 从“串行”改成“并行”目前我们的流程是ASR 完成 → 再 NLU → 再 LLM。这是串行延迟是迭加的。优化思路识别过程中并行触发ASR 识别到“加血”两个字不等整句结束立刻触发 NLU。状态预取玩家按键说话的同时后台已经开始拉取游戏状态。LLM 预热把 Prompt 模板提前拼接好只等待识别文本填入。6.2 本地小模型做“第一响应”大模型不可能在 200ms 内完成高质量回复但本地小模型可以。一个更进阶的架构是语音识别完成后本地小模型比如 0.5B 的量化模型立刻生成一个“初步回复”。这个初步回复先通过 TTS 播报出去。云端大模型生成更完整的回复后再进行补充。从玩家感知角度AI 的反应速度是“秒回”的这是典型的延迟掩盖策略。6.3 固定 Prompt 模板 状态缓存不要每次都动态拼接大段 Prompt。合理方式是系统提示词保持固定构建时只替换状态和玩家文本。游戏状态按 10ms 或 50ms 的频率缓存减少读取次数。识别到连续相同意图时直接返回上次动作不走 LLM。6.4 语音合成的流式播放语音合成TTS也不能等大模型完整输出。推荐方案大模型流式输出时按句子切分文本。每得到一个完整句子立刻交给 TTS 合成并播放。TTS 也选流式模式的引擎比如 edge-tts 支持边合成边播放。这样玩家听到 AI 回复的“第一个字”的延迟可能只有 600-900ms这在游戏场景中已经是非常好的体验了。7. 常见问题与排查思路问题现象常见原因解决思路ASR 识别延迟过高CPU 机型运行 large 模型改用 small/base 模型开启 int8 量化LLM 回复很慢首字迟迟不出来模型未预热或 Prompt 太长减小 max_tokens精简游戏状态描述使用流式输出提前预热模型游戏状态数据不准确获取频率太低或没有实时同步提高状态缓存刷新频率改用 Mod 事件订阅机制动作执行不生效Socket 端口不通或协议不一致确认游戏 Mod 监听端口使用 JSON 格式报文增加调试日志语音唤醒误触发环境音干扰使用按键说话增加 VAD 滤波调整唤醒词灵敏度本地模型显存不足模型参数量过大换用 4bit 量化模型降低 batch size使用 CPU 推理交互响应时间超过 2 秒链路串行调用导致累计延迟并行化 ASR/NLU/状态读取使用短语触发提前动作另外排查延迟问题时强烈建议先做“各阶段耗时打点”不要凭感觉优化。Varkos 这类低延迟系统每一毫秒都需要精打细算。8. 最佳实践与工程建议8.1 安全与合规优先这里必须重点强调所有游戏数据读取、动作注入只在单机离线环境中使用。不应将此类技术用于联机游戏作弊、破坏其他玩家体验。涉及游戏 Mod 开发时请先阅读游戏用户协议和 Mod 开发规范。特别是带有语音功能和自动执行能力的工具必须明确告知用户“这是 AI 辅助不是作弊外挂”。8.2 异步事件驱动架构我建议不要像本文演示代码那样用“大 while 循环”驱动而是采用事件驱动架构语音输入事件。游戏状态变化事件。LLM 输出流事件。动作执行完成事件。用 asyncio 或消息队列解耦各模块能显著提高系统的实时性和可维护性。8.3 延迟可观测性给每个请求打上唯一 ID记录音频开始时间。ASR 完成时间。NLU 完成时间。LLM 首 token 时间。TTS 开始播放时间。动作执行完成时间。这样一旦延迟超标你能立刻定位是哪一个环节而不是到处猜。8.4 分层缓存策略指令缓存相同意图和相似状态下直接复用动作结果。回复缓存常见问题直接命中模板回复完全不用 LLM。模型缓存把 LLM 常驻显存避免每次加载模型。8.5 不要忽视玩家体验细节低延迟不仅仅是“技术指标”更是一种产品体验AI 回复要短。超过 50 个字就不像“队友”了像“文档”。回复语义要和游戏状态强相关。玩家残血时AI 不应该聊哲学。失误要能打断。玩家说“算了”时立即停止当前动作执行。有语音反馈的同时最好在屏幕上给出文字提示照顾不想开声音的玩家。9. 结语Varkos 这类低延迟 AI 游戏伙伴本质上代表了 AI 应用的一个重要方向大模型不再只是问答工具而是能感知环境、实时响应、直接执行动作的数字存在。本文从概念拆解到架构设计再到可运行的工程骨架完整走了一遍“低延迟 AI 游戏伙伴”的实现路径。你可以基于这套代码继续扩展接入真实的 SKSE Mod实现《上古卷轴5》内的动作执行。用 faster-whisper 做真实的语音输入链路。接入更完整的 RAG 知识库让 AI 能回答任务攻略、剧情背景、装备属性等问题。加一个 Web 控制台实时监控各阶段延迟。如果你正在做 AI 游戏助手或实时 AI 应用不妨从延迟打点开始先量清楚自己的系统慢在哪再决定优化方向。如果这篇文章对你有帮助可以收藏备用。也欢迎在评论区聊聊你对“AI 游戏伙伴”的看法分享一下你在实时 AI 应用落地中踩过哪些坑。