UE5集成本地LLaMA模型：离线AI对话实现与中文乱码终极解决方案

1. 项目概述：当UE5遇见本地大语言模型

最近在捣鼓一个UE5的独立游戏项目，想给里面的NPC加上点“灵魂”，让它们能脱离网络，在本地就和玩家进行有来有回的对话。这想法听起来挺酷，但真做起来，从模型选型、引擎集成到最后的“中文乱码”这个老大难问题，每一步都像在开荒。市面上成熟的云端AI对话服务不少，但一来有网络延迟和稳定性顾虑，二来对独立开发者来说成本是个问题，三来数据隐私和玩法独特性也得考虑。所以，把像LLaMA这样的开源大语言模型（LLM）塞进UE5里，搞一个纯离线的AI对话系统，就成了一个既有挑战又极具吸引力的方向。

简单来说，这个项目就是在你的UE5游戏里，嵌入一个本地运行的LLaMA模型。玩家和NPC对话时，文本输入被发送到这个本地模型，模型生成回复后再传回游戏引擎，驱动NPC的语音、口型或UI显示。整个过程完全在本地完成，不依赖任何外部API。这特别适合那些注重叙事沉浸感、或需要高度定制化对话逻辑的RPG、冒险类游戏。当然，技术栈涉及UE5的C++/蓝图、模型推理后端（比如用C++库直接调用，或者通过本地HTTP服务桥接）、以及不可避免的字符编码处理。下面，我就把自己趟过的路、踩过的坑，特别是那个烦人的中文乱码问题，从头到尾捋一遍。

2. 核心方案设计与技术选型考量

2.1 为什么选择LLaMA及其量化版本

首先得说说为什么是LLaMA。在开源LLM领域，LLaMA系列（尤其是后来的Llama 2、Llama 3）在效果、社区支持和模型尺寸上取得了很好的平衡。对于游戏本地部署，我们最关心的是三点：模型大小、推理速度和硬件兼容性。原版的7B、13B参数模型动辄十几GB，直接塞进游戏里不现实。因此，模型量化是必经之路。

量化就是把模型参数从高精度（如FP32、FP16）转换为低精度（如INT8、INT4），从而大幅减少模型体积和内存占用，并提升推理速度。市面上有很多优秀的量化工具和已经量化好的模型，比如GGUF格式的模型，配合llama.cpp这个项目进行推理，是目前社区里离线部署的黄金组合。GGUF格式设计得就很友好，一个文件包含模型架构、权重和分词器所有信息，加载简单。对于游戏开发，我强烈推荐从Q4_K_M或Q5_K_M这类量化等级开始尝试。它们在精度损失和性能提升之间取得了很好的折衷。一个7B参数的模型，量化成Q4_K_M后，体积可以压缩到4GB左右，这在很多游戏PC上已经是可以接受的范畴了。

注意：量化等级中的“K”通常代表“k-quants”，是一种更先进的量化方法，比传统的按组量化（grouped quantization）效果更好。M代表“中等”（Medium）的量化粒度。对于初次尝试，Q4_K_M是性价比最高的选择。

2.2 UE5与LLM的集成架构：三种路径分析

把LLM集成到UE5里，不是简单地把一个C++库拖进去就行。我们需要一个稳定、高效且易于调试的通信机制。主流有三种思路：

路径一：纯C++库直接链接。把llama.cpp的库直接编译进UE5的插件或模块。这理论上性能最好，没有进程间通信开销。但实操非常复杂。UE5有自己的一套构建系统（UBT），第三方C++库的编译选项、依赖管理（如OpenBLAS、CUDA）很容易和UE5的编译环境冲突，光是解决编译问题就可能耗去大量时间。除非你的团队对UE5底层和C++构建有极深的掌控力，否则不推荐新手走这条路。

路径二：进程间通信（IPC）。单独启动一个llama.cpp的推理进程，UE5通过管道、共享内存或本地Socket与之通信。这种方式隔离性好，模型进程崩溃不会直接拖垮游戏引擎，也方便单独优化和更新模型部分。但实现起来有一定复杂度，需要处理进程启动、守护和双向通信协议。

路径三：本地HTTP服务桥接。这是我最推荐，也是目前最实用的方案。我们单独运行一个轻量级的HTTP服务器（比如用Python的FastAPI或Flask搭建），这个服务器负责加载LLaMA模型并暴露推理API。UE5则通过内置的HTTP或WebSocket模块（如VaRest插件，或UE5.1+自带的更完善的HTTP功能）向这个本地服务发送请求并获取结果。架构清晰，跨平台兼容性好（Windows/macOS/Linux都行），调试极其方便（可以直接用浏览器或Postman测试API），而且模型服务可以独立于游戏迭代。

本项目将采用路径三。它的架构如下图所示（概念描述）：游戏客户端（UE5）将玩家输入文本通过HTTP POST发送到本地运行的llama.cpp服务器，服务器调用模型生成回复，再以JSON格式返回给UE5。UE5收到后解析JSON，触发后续的游戏逻辑（显示对话、播放语音等）。

2.3 工具链准备清单

在开始敲代码之前，我们需要把工具备齐：

1. UE5项目：建议使用5.0或以上版本，确保HTTP模块功能完整。
2. Python环境：用于搭建本地HTTP服务器。推荐使用Anaconda或Miniconda创建独立的虚拟环境。
3. llama.cpp：从GitHub克隆最新版本，并按照官方文档编译。Windows用户可以使用CMake和Visual Studio编译；macOS和Linux用户用make通常更简单。编译时可以根据你的显卡选择加速后端（如CUDA for NVIDIA, Metal for Apple Silicon, Vulkan for AMD/Intel）。
4. 量化模型文件：从Hugging Face等社区平台下载你心仪的LLaMA模型GGUF格式文件。例如，Llama-2-7B-Chat-GGUF或Llama-3-8B-Instruct-GGUF的Q4_K_M版本。
5. Python依赖：主要是Web框架（如fastapi）、ASGI服务器（如uvicorn）、以及用于调用llama.cpp的Python绑定（llama-cpp-python）。这个绑定库封装了C++接口，用起来比直接折腾C++舒服多了。
6. UE5插件（可选但推荐）：VaRest插件。虽然UE5自带HTTP模块，但VaRest对JSON的解析和构造更加直观易用，能节省大量开发时间。

3. 搭建本地LLaMA推理服务器

3.1 编译与配置llama.cpp

首先搞定llama.cpp。假设我们在Windows上操作，使用CMake和Visual Studio 2022。

# 1. 克隆仓库 git clone https://github.com/ggerganov/llama.cpp cd llama.cpp # 2. 创建构建目录并配置 mkdir build cd build # 根据你的硬件选择。例如，用CUDA加速： cmake .. -DLLAMA_CUBLAS=ON # 如果只用CPU（不推荐，速度慢）： # cmake .. -DLLAMA_BLAS=ON -DLLAMA_BLAS_VENDOR=OpenBLAS # 3. 编译 cmake --build . --config Release

编译成功后，在build/bin/Release目录下会生成main.exe和server.exe等可执行文件。server.exe就是我们需要的，一个能提供HTTP API的模型服务器。

3.2 使用Python封装与启动HTTP服务

直接使用server.exe命令行虽然可以，但为了更方便地控制参数、处理请求和集成到我们的工作流，用Python包装一层是更好的选择。这里我们用llama-cpp-python库。

首先安装必要的Python包：

pip install fastapi uvicorn llama-cpp-python

llama-cpp-python在安装时会自动编译C++绑定，请确保你的环境有C++编译器。

接下来，创建一个名为llama_server.py的脚本：

from fastapi import FastAPI, HTTPException from pydantic import BaseModel from llama_cpp import Llama import uvicorn import sys app = FastAPI(title="UE5 LLM Local Server") # 定义请求/响应模型 class ChatRequest(BaseModel): prompt: str max_tokens: int = 128 temperature: float = 0.7 stop: list = ["\n", "Human:", "AI:"] # 停止词，防止生成跑偏 class ChatResponse(BaseModel): response: str tokens_used: int # 全局模型实例 llm = None @app.on_event("startup") async def load_model(): global llm model_path = "./models/llama-2-7b-chat.Q4_K_M.gguf" # 你的模型路径 print(f"正在加载模型: {model_path}") try: # n_ctx 是上下文长度，根据你的需求调整。n_gpu_layers 表示有多少层放到GPU上，-1表示全部。 llm = Llama(model_path=model_path, n_ctx=2048, n_gpu_layers=-1, verbose=False) print("模型加载成功！") except Exception as e: print(f"模型加载失败: {e}") sys.exit(1) @app.post("/chat", response_model=ChatResponse) async def generate_chat_response(request: ChatRequest): if llm is None: raise HTTPException(status_code=503, detail="Model not loaded") try: # 调用模型生成 output = llm( request.prompt, max_tokens=request.max_tokens, temperature=request.temperature, stop=request.stop, echo=False # 不返回输入的prompt ) generated_text = output['choices'][0]['text'].strip() tokens_used = output['usage']['total_tokens'] return ChatResponse(response=generated_text, tokens_used=tokens_used) except Exception as e: raise HTTPException(status_code=500, detail=f"Generation failed: {str(e)}") if __name__ == "__main__": # 启动服务器，监听本地8000端口 uvicorn.run(app, host="127.0.0.1", port=8000)

这个脚本做了几件事：

1. 使用FastAPI创建了一个Web应用。
2. 在启动时加载指定的GGUF模型文件到内存（和显存）。
3. 暴露了一个/chat的POST接口，接收包含对话提示词（prompt）和生成参数的JSON。
4. 调用llama-cpp-python的接口进行推理，并将生成的文本和使用的token数返回。

运行这个脚本，你的本地LLaMA服务器就启动了。可以用curl或Postman测试一下：

curl -X POST http://127.0.0.1:8000/chat -H "Content-Type: application/json" -d "{\"prompt\":\"你好，请介绍一下你自己。\"}"

3.3 服务器性能调优与参数解读

模型服务器跑起来了，但想要对话流畅，还得调教一番。关键参数都在Llama()初始化和生成调用里：

• n_ctx：上下文窗口大小。决定了模型能“记住”多长的对话历史。2048对于短对话足够，但如果想做长篇剧情对话，可能需要4096甚至更多。注意，增大n_ctx会线性增加内存占用。
• n_gpu_layers：GPU层数。设置为-1会尝试将所有模型层卸载到GPU，这是获得最佳速度的关键。如果你的GPU显存不够（比如小于8GB），可能需要减少这个数字，让部分层留在CPU。
• max_tokens：单次生成的最大token数。控制回复长度。太短可能说不完，太长会导致生成慢且可能偏离主题。128-256是对话的常用范围。
• temperature：温度参数，控制生成的随机性。0.0表示完全确定性（每次相同输入得到相同输出），值越大越有创意但也可能胡言乱语。0.7是一个不错的起点。
• stop：停止序列。当模型生成包含这些字符串时，会停止生成。精心设置stop可以防止模型无限生成下去，或者模仿出你不想要的对话格式。

实操心得：在UE5端，最好对玩家输入和模型输出都做一个长度限制和敏感词过滤。模型有时会生成非常长的废话，或者包含不合适的內容。在服务器端或UE5端做一层后处理是必要的。

4. UE5客户端集成与通信实现

4.1 使用VaRest插件进行HTTP通信

UE5自带的HTTP模块功能基础，处理JSON比较繁琐。VaRest插件极大地简化了这个过程。在UE商城下载并启用VaRest插件后，我们就可以在蓝图中方便地调用HTTP接口。

首先，在UE5中创建一个蓝图函数库（Blueprint Function Library）或直接在某个Actor的蓝图中，构造一个向本地服务器发送请求的异步任务。核心步骤是：

1. 构造请求JSON：使用VaRest的Construct JSON Value和Set String Field节点，构建一个包含prompt、max_tokens等字段的JSON对象。
2. 创建HTTP请求：使用VaRest的Call URL节点。将URL设置为http://127.0.0.1:8000/chat，方法设置为POST。
3. 设置请求头与内容：添加Content-Type为application/json的请求头，并将上一步构造的JSON对象转换为字符串，设置为请求内容（Body）。
4. 绑定回调事件：Call URL节点执行后，会触发一个OnCompleted事件。在这个事件里，我们可以获取到服务器返回的JSON响应。
5. 解析响应：从响应中，通过Get Root Json和Get String Field节点，提取出response字段，这就是AI生成的对话文本。

4.2 设计稳健的异步对话流程

在游戏中，网络请求必须是异步的，否则会阻塞游戏线程导致卡顿。我们需要设计一个状态机来管理对话流程：

1. 空闲状态：等待玩家触发对话。
2. 输入状态：玩家通过UI输入文本。
3. 请求发送状态：将玩家输入文本，可能连同之前的对话历史（用于提供上下文）一起格式化成prompt，发送HTTP请求。此处必须显示一个加载指示器（如转圈图标），告诉玩家正在思考。
4. 等待响应状态：异步等待服务器返回。可以设置一个超时（如30秒），超时后提示玩家“AI没有响应”。
5. 响应处理状态：收到响应后，解析文本。首先进行后处理：去除多余空格、换行，处理可能的乱码（下一节重点讲）。然后将文本显示在UI上，并可能触发语音合成、NPC口型动画等。
6. 返回空闲状态：准备下一次对话。

在蓝图中，可以使用Delay节点配合自定义事件来模拟简单的异步等待，但更清晰的做法是利用AsyncTask或直接使用VaRest回调事件驱动的流程。

4.3 对话上下文管理与Prompt工程

要让对话有连续性，必须给模型提供上下文。简单来说，就是把之前几轮对话的历史也作为prompt的一部分送给模型。一个常见的格式是：

Human: 你好。 AI: 你好！我是这个世界的向导，有什么可以帮你的？ Human: 今天的天气怎么样？ AI: （模型将基于之前的对话生成回复）

在UE5端，我们需要维护一个对话历史数组（TArray<FString>）。每次玩家发言后，将“Human: [玩家文本]”加入历史；每次收到AI回复后，将“AI: [AI文本]”加入历史。发送请求时，将整个历史数组用“\n”连接起来，作为最终的prompt发送。

但要注意，上下文不能无限增长（受n_ctx限制）。一个策略是只保留最近N轮对话（例如最近5轮），或者当历史token数超过某个阈值时，丢弃最老的几轮对话。这需要在UE5端进行简单的逻辑控制。

注意事项：Prompt的格式直接影响模型输出。如果你用的模型是Llama-2-Chat或Llama-3-Instruct这类针对对话微调过的版本，它们可能有自己推荐的格式（如[INST]标签）。请务必查阅你所下载模型卡（Model Card）中的说明，使用正确的格式，这样才能激发出模型的最佳对话能力。

5. 中文乱码问题的根源与终极解决方案

这是本项目最棘手的部分，也是很多开发者容易栽跟头的地方。中文乱码通常不是单一问题，而是字符编码在多个环节传递中不一致导致的“链条断裂”。我们来逐一排查并加固每个环节。

5.1 乱码产生的三大环节剖析

1. UE5内部编码与HTTP传输环节：UE5内部使用FString，本质上是TCHAR的容器，在Windows上通常是UTF-16。当我们通过HTTP发送JSON时，需要将FString转换为传输用的字节流。如果转换时使用了错误的编码（比如本地ANSI码页），中文字符就会变成乱码。
2. Python HTTP服务器接收与处理环节：FastAPI默认期望接收UTF-8编码的JSON。如果UE5发送的不是UTF-8，FastAPI在解码时就会出错。即使解码成功，在Python内部处理字符串时，也需要确保是Unicode（str）对象。
3. LLaMA模型分词与生成环节（最核心）：LLaMA原生的分词器（Tokenizer）是基于BPE（Byte Pair Encoding）训练的，对多字节字符（如中文）的支持取决于训练数据。虽然LLaMA在大量多语言数据上训练过，但其分词方式可能导致一个中文字被拆成多个子词（subword），这本身不是乱码，但会影响生成效果。而真正的乱码往往发生在：模型生成的token序列被解码回字符串时，如果解码器没有使用正确的UTF-8编码来处理这些可能包含多字节字符的字节，就会产生诸如“我是”这样的乱码。

5.2 环节一：确保UE5发送UTF-8编码的JSON

在使用VaRest插件时，确保其Call URL节点发送的JSON字符串是UTF-8编码。VaRest的JSON Value对象在设置字符串字段时，内部会处理编码。但为了绝对安全，可以在构造请求Body时，显式地进行转换。

在C++中，如果你是自己构造HTTP请求，可以这样做：

FString Prompt = TEXT("你好，世界"); TArray<uint8> RequestBody; FTCHARToUTF8 Converter(*Prompt); RequestBody.Append((uint8*)Converter.Get(), Converter.Length()); // 然后将RequestBody设置为HttpRequest的内容

在蓝图中，VaRest插件通常已经处理好了。但你需要检查VaRest的SetStringField节点输入的字符串是否来自正确的文本输入框（确保UI文本框本身支持中文输入）。

5.3 环节二：强化Python服务器的编码健壮性

在我们的FastAPI服务器中，需要明确指定请求和响应的编码。

首先，确保Pydantic模型能正确接收UTF-8字符串。BaseModel的字符串字段默认就是处理Unicode的，这没问题。关键是在加载模型和调用生成时。

修改llama_server.py的加载和生成部分，强调编码处理：

@app.post("/chat", response_model=ChatResponse) async def generate_chat_response(request: ChatRequest): ... try: # 确保prompt是Python的str（Unicode）对象，FastAPI通常已保证。 # 关键在llama-cpp-python的调用。llama-cpp-python库内部会处理字符串到C++的转换。 # 我们需要确保传入的是正确的Unicode字符串。 prompt_text = request.prompt # 可以在这里加一个日志，确认收到的文本是否正确 print(f"收到请求，prompt: {prompt_text[:100]}...") output = llm( prompt_text, # 直接传入Unicode字符串 max_tokens=request.max_tokens, temperature=request.temperature, stop=request.stop, echo=False ) generated_text = output['choices'][0]['text'].strip() # **核心修复步骤：尝试用UTF-8强制解码一次，忽略错误（但通常不需要，除非库有bug）** # generated_text = generated_text.encode('utf-8', 'ignore').decode('utf-8') # 实际上，llama-cpp-python返回的已经是Python str。如果还有乱码，问题可能更深。 tokens_used = output['usage']['total_tokens'] return ChatResponse(response=generated_text, tokens_used=tokens_used) except Exception as e: raise HTTPException(status_code=500, detail=f"Generation failed: {str(e)}")

更有效的做法是在启动Llama模型时，就确保分词器能正确处理中文。llama-cpp-python的Llama类在初始化时，可以传入一个特殊的参数来改善多语言支持，但通常默认设置已足够。如果遇到持续乱码，一个“重型武器”是在生成时指定encoding，但该库API可能不直接暴露。这时，问题根源很可能在模型文件或llama.cpp本身。

5.4 环节三：终极方案——使用专门的中文优化模型与分词器

如果以上步骤都做了，中文输出还是乱码，那极有可能是你下载的基础模型文件本身对中文支持不佳，或者配套的分词器词汇表缺失中文字符。

解决方案是使用针对中文优化过的模型。社区有很多优秀的双语或中文增强模型，它们不仅在训练数据中包含了更多高质量中文语料，其分词器也更好地覆盖了中文字符。例如：

• Chinese-LLaMA-Alpaca系列：专门为中文优化的LLaMA模型，扩充了中文词表，中文理解和生成能力显著提升。
• Qwen系列：通义千问的基座模型，原生对中文支持非常好。
• Yi系列：零一万物发布的模型，中文能力强劲。

去Hugging Face或ModelScope寻找这些模型的GGUF量化版本。下载后，替换掉你之前用的原始LLaMA模型。使用这些模型，乱码问题几乎可以百分百解决，因为从训练源头就保障了中文的编码和分词正确性。

实操心得：这是我踩过最大的坑。最初使用原始的Llama-2-7B的GGUF文件，中文输出时好时坏，经常出现乱码。后来换成了Chinese-LLaMA-2-7B的GGUF版本，问题迎刃而解。所以，模型选型是解决中文问题的根本。

5.5 乱码排查流程图与速查表

当你遇到乱码时，可以按照以下流程图快速定位问题：

UE5 UI显示乱码？ ├─是 → 检查UE5文本框字体是否包含中文字符集。 └─否 → UE5发送的HTTP请求Body乱码？（用日志或抓包工具如Fiddler查看） ├─是 → 确保UE5端字符串转换为UTF-8字节流。 └─否 → Python服务器收到的JSON乱码？（打印request.prompt查看） ├─是 → 检查FastAPI是否默认使用UTF-8解码。检查请求头Content-Type。 └─否 → Python服务器调用模型后生成的文本乱码？（打印generated_text查看） ├─是 → **核心问题！** 尝试更换为中文优化模型（如Chinese-LLaMA）。 └─否 → UE5收到HTTP响应后解析显示乱码？检查VaRest解析JSON后的字符串编码。

常见乱码现象与解决方案速查表：

6. 性能优化与实战调试技巧

6.1 降低延迟：流式传输与生成优化

默认的/chat接口是等模型生成全部文本后才一次性返回，对于长文本，玩家需要等待较长时间。流式传输（Streaming）可以极大地改善体验，模型生成一个token就返回一个token，UE5可以实时地、逐字显示出来，像真人打字一样。

llama-cpp-python和llama.cpp的server都支持流式响应。你需要修改Python服务器，使用FastAPI的StreamingResponse，并调用模型时设置stream=True。在UE5端，则需要处理分块的HTTP响应。这涉及到更复杂的异步处理和文本拼接，但体验提升是质的飞跃。

此外，推理速度本身可以通过以下方式优化：

• 使用GPU层数：确保n_gpu_layers设置正确，让模型尽可能跑在GPU上。
• 调整批处理大小：虽然对话通常是单条，但如果你有多个NPC需要同时生成，可以尝试批处理。
• 使用更快的量化格式：Q4_0比Q4_K_M更快，但精度稍低。在速度敏感的场景可以权衡。
• 升级硬件：这不用说，一张好的NVIDIA显卡（如RTX 3060 12G以上）是体验的保证。

6.2 内存与显存管理

本地运行LLM最吃资源的就是内存和显存。一个7B的Q4模型加载后，可能占用4-6GB的RAM/VRAM。你需要密切关注：

• 游戏本身的内存占用：UE5项目本身就很吃内存。
• 模型加载方式：llama.cpp支持将部分模型层保留在内存，部分映射到磁盘（mmap），这可以减少初始内存占用，但可能会增加推理时的磁盘IO。在Llama()初始化时，可以使用use_mmap=True参数。
• 显存不足回退：如果GPU显存不够，n_gpu_layers设置过多会导致OOM（内存溢出）。程序应该能优雅地回退到CPU推理，或者给出明确错误提示。在UE5端，可以尝试在游戏设置中提供“AI对话质量”选项，让玩家选择使用更小、更快的模型。

6.3 实战调试：日志与错误处理

一个健壮的系统离不开完善的日志。在Python服务器端，记录每一个请求的输入、输出、耗时和可能的错误。在UE5端，将HTTP请求的状态（成功、失败、超时）和响应内容打印到输出日志（Output Log）中。

关键的错误处理点：

1. HTTP请求失败：网络错误、服务器未启动。UE5端应检测并提示玩家“AI服务未连接”。
2. 服务器内部错误：模型加载失败、生成失败。服务器应返回500错误和具体信息，UE5端接收后显示友好提示。
3. 响应超时：设置合理的HTTP超时时间（如60秒），超时后取消请求，提示“AI思考超时”。
4. 内容安全过滤：模型可能生成不受控的内容。必须在UE5端或服务器端加入一层内容过滤，检查生成的文本是否包含违禁词或不适合游戏场景的内容。

在开发过程中，我习惯在UE5中创建一个简单的调试HUD，实时显示当前对话状态、最近一次请求的耗时和返回的原始文本，这对定位问题非常有帮助。

7. 扩展思路与项目进阶

实现基础对话只是第一步。有了这个框架，你可以做很多有趣的扩展：

1. 角色扮演与系统提示词：通过修改发送给模型的prompt，你可以轻松让AI扮演不同角色。例如，在prompt开头加上“你是一个脾气暴躁的老兵”或“你是一个知识渊博但说话慢吞吞的巫师”，模型的回复风格会随之改变。你可以为每个NPC设计独特的系统提示词。
2. 结合游戏状态：将游戏内的状态信息（如玩家位置、时间、任务进度、NPC心情值）作为上下文的一部分送给模型。例如：“现在是游戏内的夜晚，正在下雨。玩家刚刚完成了‘寻找草药’的任务。NPC当前对玩家的好感度是友好。玩家说：……”
3. 语音输入输出：集成本地语音识别（STT）和语音合成（TTS）库，实现真正的语音对话。玩家对着麦克风说话，文字被识别后送给AI，AI的文本回复再被转换成语音播放出来。
4. 多模态探索：虽然LLaMA是纯文本模型，但你可以将游戏画面中的关键信息（通过图像描述模型生成文本）作为上下文输入，让AI能“看到”并评论周围环境。
5. 本地知识库检索：为游戏世界构建一个本地知识库（如任务文档、物品描述、历史背景）。当玩家提问时，先从这个知识库中检索相关片段，然后将“问题+检索到的知识”一起送给模型，让回答更精准、更贴合游戏设定。

这个离线AI对话系统就像为你游戏世界注入了“灵魂”的起点。从解决最基础的中文乱码问题开始，一步步构建起稳定、可用的对话框架，再到后期融入游戏逻辑和角色设定，整个过程充满了工程挑战和创造乐趣。最重要的是，它让你的游戏真正拥有了独一无二、动态生成的叙事可能性，这是任何预设脚本对话树都无法比拟的。开始动手吧，从下载一个中文GGUF模型和启动那个Python服务器开始，你的NPC正在等待被赋予生命。