1. 项目概述当Unity遇上LLM一场关于脚本的深度探索如果你正在Unity里捣鼓LLMUnity这个插件想给游戏角色注入点“灵魂”结果发现脚本这块儿水有点深那你来对地方了。我最近也在一个项目里深度折腾LLMUnity从最初的兴奋到中间的迷茫再到最后把各种坑一个个填平整个过程就像是在解一个复杂的谜题。特别是脚本相关的部分官方文档往往语焉不详社区讨论也零零散散很多问题都得靠自己摸索。这篇文章就是把我踩过的坑、试过的错、以及最终验证可行的方案毫无保留地分享出来。无论你是想实现一个能和玩家自然对话的NPC还是想让多个AI角色之间产生有趣的互动甚至是处理复杂的对话逻辑流关于LLMUnity脚本的学习和探索这里都有你想知道的答案。我们不止讲“怎么做”更会深挖“为什么这么做”以及“怎么做更稳”。2. LLMUnity脚本体系核心架构解析在开始写第一行代码之前我们必须先搞清楚LLMUnity的脚本体系是怎么搭建的。这就像盖房子地基和框架没弄明白后面装修得再漂亮也容易塌。2.1 核心组件交互模型消息驱动的AI世界LLMUnity的核心思想是“消息驱动”。它不是一个让你直接调用API的简单封装而是构建了一套基于角色的异步通信框架。理解这一点至关重要否则你的代码会写得非常别扭。整个系统的核心是LLMCharacter组件。你可以把它想象成一个AI角色的“大脑”容器。每个你想赋予对话能力的GameObject上都需要挂载这个组件。但是LLMCharacter本身并不直接处理对话逻辑它更像一个接线员和状态管理器。真正的对话逻辑由你编写的脚本通过实现特定的接口如ILLMInteraction来定义。这些脚本被附加到LLMCharacter上LLMCharacter在收到消息比如玩家输入、或其他AI角色的消息时会调用这些脚本中对应的方法。这就是典型的“观察者模式”或“事件驱动”架构在Unity中的体现。一个常见的误区是试图在Update()里轮询或直接控制LLM的响应。这完全违背了插件的设计哲学会导致性能浪费和状态混乱。正确的做法是你的脚本“订阅”角色的事件如OnMessageReceived然后在事件回调里编写处理逻辑。2.2 脚本类型与职责划分在LLMUnity中你通常会编写两种主要类型的脚本交互处理器脚本这是主力。你需要创建一个继承自MonoBehaviour并实现ILLMInteraction接口的类。这个接口强制你实现ProcessInteraction方法。当LLMCharacter需要处理一个交互比如玩家说了一句话时就会调用这个方法。你在这个方法里构造发送给LLM如OpenAI的GPT的提示词Prompt处理返回的结果并决定下一步做什么比如播放一段语音、执行一个动画、或者给另一个角色发送消息。辅助与管理脚本这类脚本可能不直接处理交互但负责更上层的逻辑。例如对话管理器管理多个角色之间的对话回合、话题切换、全局状态。上下文记忆脚本负责维护和向Prompt中注入角色的长期记忆、短期对话历史。工具调用封装脚本如果LLM支持Function Calling/Tool Calling你需要编写脚本来将游戏内的功能如查询背包、打开门暴露给LLM。理解这种职责分离能让你写出更清晰、更易维护的代码。一个ILLMInteraction脚本最好只负责一个角色对一类信息的处理逻辑。3. 脚本编写中的五大核心问题与解决方案在实际编码中我遇到了几个非常典型且棘手的问题。下面我们来逐一拆解。3.1 问题一异步处理与Unity协程的完美融合LLM的API调用是网络I/O操作必然是异步的。但Unity的主线程是单线程的我们不能在异步回调里直接操作Transform、UI等Unity对象。同时我们又要避免主线程阻塞导致游戏卡顿。解决方案使用UniTask或封装良好的Coroutine。我强烈推荐使用UniTask需要导入UniTask插件它比原生协程更强大、性能更好并且能很好地与C#的async/await模式结合。假设我们在一个ILLMInteraction的ProcessInteraction方法中public async UniTaskVoid ProcessInteraction(InteractionData data) { // 1. 从data中获取输入消息 string userInput data.GetMessage(); // 2. 构建Prompt这里可以加入角色设定、历史对话等 string prompt BuildPromptForCharacter(userInput); // 3. 关键步骤异步调用LLM但不阻塞主线程 string llmResponse await SendRequestToLLMAsync(prompt).ConfigureAwait(false); // 4. **重要**await之后代码默认会在主线程恢复可以安全操作Unity对象 DisplayResponseOnUI(llmResponse); PlayTalkingAnimation(); // 5. 可能触发下一步例如自动回复给另一个角色 if (ShouldAutoReply()) { // 通过LLMCharacter发送消息 GetComponentLLMCharacter().SendMessage(new MessageData{...}); } } private async UniTaskstring SendRequestToLLMAsync(string prompt) { // 这里使用你选择的HTTP客户端如UnityWebRequest // 将请求发送到你的LLM服务端点本地或云端 // 返回LLM生成的文本 }注意如果你坚持使用原生协程请务必用yield return来等待UnityWebRequest.SendWebRequest()并在完成后的回调中使用MainThreadDispatcher之类的工具将操作派发回主线程否则极易引发“不是从主线程调用Unity API”的错误。3.2 问题二对话上下文与记忆的管理策略LLM本身是无状态的。如果你只是简单地把当前一轮的对话发过去AI角色很快就会“失忆”对话会变得前言不搭后语。管理上下文是LLM应用的核心挑战。解决方案实现一个分层级的记忆系统。我设计了一个简单的ConversationContextManager脚本它维护以下几个部分系统提示词角色的固定人设、背景、行为准则。每次请求都必须包含。短期记忆一个固定长度的对话历史队列例如最近10轮对话。每次新的交互都将这个历史拼接到Prompt中。长期记忆一个可选的、由关键信息如玩家姓名、达成的协议、重要事件组成的列表。这些信息会被选择性、总结性地注入到系统提示词或单独的记忆部分。在BuildPromptForCharacter方法中你的代码应该是这样的private string BuildPromptForCharacter(string currentInput) { StringBuilder prompt new StringBuilder(); // 1. 系统指令 prompt.AppendLine(你是一个生活在奇幻世界的铁匠名叫格罗姆。你性格豪爽热爱锻造。); prompt.AppendLine(_contextManager.GetLongTermMemorySummary()); // 注入长期记忆摘要 // 2. 短期对话历史 foreach (var exchange in _contextManager.GetRecentHistory()) { prompt.AppendLine(${exchange.speaker}: {exchange.message}); } // 3. 当前输入 prompt.AppendLine($玩家: {currentInput}); prompt.AppendLine(格罗姆:); // 引导AI开始回复 return prompt.ToString(); }每次收到LLM回复后你需要将“玩家: xxx”和“格罗姆: yyy”这对交换记录压入短期记忆队列。当队列超过长度时自动移除最老的记录。对于特别重要的信息可以调用_contextManager.SaveToLongTermMemory(key, value)。3.3 问题三多个AI角色间的通信与协调LLMUnity的魅力在于多个智能体间的互动。如何让角色A说的话能触发角色B的思考并回应解决方案利用LLMCharacter.SendMessage()和消息路由。每个LLMCharacter都有一个SendMessage(MessageData message)方法。MessageData里可以包含发送者、接收者、消息内容、甚至自定义数据。你可以创建一个“中央邮局”脚本或者使用更事件驱动的方式。我更喜欢后者在角色B的交互脚本中监听来自角色A的消息类型。角色A在生成回复后除了显示给玩家还可以决定是否要“告诉”角色B。// 在角色A的脚本中 private async UniTaskVoid ProcessInteraction(InteractionData data) { // ... 处理与玩家的对话得到回复 responseToPlayer ... // 判断是否需要告诉角色B if (responseToPlayer.Contains(告诉厨师)) { MessageData msgForChef new MessageData { Sender this.gameObject, // 发送者铁匠 Recipient GameObject.Find(Chef), // 接收者厨师 Content 玩家刚才说要一份大餐你准备一下。, CustomTag order_food }; GetComponentLLMCharacter().SendMessage(msgForChef); } } // 在角色B厨师的脚本中在其 Start() 或 Awake() 方法里订阅消息 void Start() { GetComponentLLMCharacter().OnMessageReceived HandleIncomingMessage; } private void HandleIncomingMessage(MessageData message) { if (message.CustomTag order_food) { // 触发厨师自己的对话处理逻辑 // 例如可以模拟一个来自“铁匠”的交互 InteractionData fakeInteraction new InteractionData(message.Content, message.Sender); ProcessInteraction(fakeInteraction).Forget(); // 使用Forget来触发异步方法 } }这样你就构建了一个去中心化的、基于事件的AI社交网络。3.4 问题四性能优化与请求节流无节制地向LLM API发送请求会导致高昂的成本和游戏卡顿。尤其是在有多个活跃AI角色的场景中。解决方案实现请求队列与冷却机制。全局请求队列创建一个单例管理器LLMRequestManager。所有发送LLM请求的调用都不直接发送而是封装成一个LLMRequestTask对象提交到这个管理器的队列中。限流器管理器以固定的频率例如每秒2次从队列中取出任务执行。这保证了无论游戏内发生多少对话对API的压力是平稳可控的。角色冷却为每个LLMCharacter设置一个冷却时间例如3秒。在一次请求结束后3秒内不再处理该角色的新请求。这模拟了“思考时间”也防止了玩家或系统快速点击导致的刷屏。// 简化的管理器核心逻辑 public class LLMRequestManager : MonoBehaviour { private QueueLLMRequestTask _requestQueue new QueueLLMRequestTask(); private float _lastRequestTime; public float requestInterval 0.5f; // 每秒最多2次 void Update() { if (Time.time - _lastRequestTime requestInterval _requestQueue.Count 0) { var task _requestQueue.Dequeue(); _lastRequestTime Time.time; // 在后台执行真正的网络请求 _ ExecuteTaskAsync(task); } } public void EnqueueRequest(LLMRequestTask task) { _requestQueue.Enqueue(task); } }在你的交互脚本中将SendRequestToLLMAsync调用改为LLMRequestManager.Instance.EnqueueRequest(myTask)。3.5 问题五错误处理与超时重试网络请求失败、API限流、返回内容格式异常……这些情况必须被妥善处理否则游戏会留下难以调试的Bug。解决方案健壮的错误处理链路。在你的异步请求方法周围包裹完善的try-catch并设计重试逻辑和降级方案。private async UniTaskstring SendRequestToLLMAsync(string prompt, int maxRetries 2) { int attempt 0; while (attempt maxRetries) { try { // 设置一个超时例如30秒 var cts new CancellationTokenSource(); cts.CancelAfterSlim(TimeSpan.FromSeconds(30)); // 这里是你的实际网络请求代码... // using var request CreateWebRequest(prompt); // var result await request.SendWebRequest().WithCancellation(cts.Token); // 检查HTTP状态码和返回内容 // if (result.isHttpError || result.isNetworkError) throw new Exception(...); // var response ParseResponse(result.downloadHandler.text); return response; } catch (OperationCanceledException) { Debug.LogWarning($LLM请求超时尝试 {attempt 1}/{maxRetries 1}); } catch (Exception e) { Debug.LogError($LLM请求失败 (尝试 {attempt 1}): {e.Message}); } attempt; if (attempt maxRetries) { await UniTask.Delay(1000 * attempt); // 延迟重试间隔递增 } } // 所有重试都失败返回一个降级的默认回复 return “看起来我有点走神了你刚才说什么来着; }同时在UI层当请求进行时应该显示一个“思考中…”的指示器当请求失败时给玩家一个友好的提示而不是让游戏僵住。4. 高级脚本技巧状态机与行为树整合对于更复杂的AI行为比如结合对话、移动、寻路、执行动作单纯依靠对话脚本会变得非常臃肿。这时可以将LLMUnity与经典的游戏AI技术结合。4.1 使用状态机管理对话流程你可以为AI角色定义一个状态机状态包括Idle空闲、Listening聆听玩家、Thinking请求LLM中、Speaking播放回复、PerformingAction执行LLM触发的游戏动作。ILLMInteraction脚本只负责在Listening或Thinking状态下的逻辑。状态之间的转换由另一个状态机脚本控制。这样LLM的对话能力就变成了AI整体行为的一个模块更容易与巡逻、战斗等其他模块共存。4.2 将LLM作为行为树的决策节点在行为树中你可以创建一个LLMQueryNode。当执行到这个节点时它向LLM发送当前游戏上下文如周围环境、玩家状态、自身目标并要求LLM从几个预设选项“攻击”、“对话”、“逃跑”、“寻找物品”中选择一个。LLM返回的选择结果决定了行为树接下来的执行分支。这赋予了AI更高层次的、基于语义理解的决策能力而不仅仅是回复文本。实现这个节点本质上就是构造一个让LLM做选择题的Prompt并解析其返回的选项索引。5. 调试与开发工作流建议开发LLMUnity应用调试比传统游戏逻辑更复杂因为输入输出都是非确定性的自然语言。本地日志系统建立一个强大的日志系统记录每一轮对话的完整Prompt和LLM的原始Response。将这些日志实时输出到Unity Editor的一个自定义UI窗口或文件中便于复现问题。Prompt模板化不要将Prompt字符串硬编码在C#脚本里。使用ScriptableObject或文本文件来存储Prompt模板用占位符如{character_name},{history}进行替换。这方便你非程序员队友如策划进行调整和迭代。模拟测试模式在编辑器中创建一个“模拟LLM”模式用一个简单的字符串列表或本地文本文件来模拟LLM的回复从而快速测试你的对话逻辑流而无需消耗API费用和等待网络延迟。版本控制PromptPrompt本身是极其重要的“代码”务必将其纳入版本控制如Git。记录每一次Prompt修改的意图和效果。折腾LLMUnity的脚本是一个不断在“创意想法”和“工程实现”之间寻找平衡的过程。它要求你既要有游戏开发的扎实功底又要对语言模型的工作原理有基本理解。最大的成就感莫过于看到自己创造的AI角色真的能说出符合其性格的话并与其他角色产生意料之外、情理之中的互动。这份动态的、由代码和模型共同演绎的故事正是游戏开发最迷人的地方之一。
1. 项目概述当Unity遇上LLM一场关于脚本的深度探索如果你正在Unity里捣鼓LLMUnity这个插件想给游戏角色注入点“灵魂”结果发现脚本这块儿水有点深那你来对地方了。我最近也在一个项目里深度折腾LLMUnity从最初的兴奋到中间的迷茫再到最后把各种坑一个个填平整个过程就像是在解一个复杂的谜题。特别是脚本相关的部分官方文档往往语焉不详社区讨论也零零散散很多问题都得靠自己摸索。这篇文章就是把我踩过的坑、试过的错、以及最终验证可行的方案毫无保留地分享出来。无论你是想实现一个能和玩家自然对话的NPC还是想让多个AI角色之间产生有趣的互动甚至是处理复杂的对话逻辑流关于LLMUnity脚本的学习和探索这里都有你想知道的答案。我们不止讲“怎么做”更会深挖“为什么这么做”以及“怎么做更稳”。2. LLMUnity脚本体系核心架构解析在开始写第一行代码之前我们必须先搞清楚LLMUnity的脚本体系是怎么搭建的。这就像盖房子地基和框架没弄明白后面装修得再漂亮也容易塌。2.1 核心组件交互模型消息驱动的AI世界LLMUnity的核心思想是“消息驱动”。它不是一个让你直接调用API的简单封装而是构建了一套基于角色的异步通信框架。理解这一点至关重要否则你的代码会写得非常别扭。整个系统的核心是LLMCharacter组件。你可以把它想象成一个AI角色的“大脑”容器。每个你想赋予对话能力的GameObject上都需要挂载这个组件。但是LLMCharacter本身并不直接处理对话逻辑它更像一个接线员和状态管理器。真正的对话逻辑由你编写的脚本通过实现特定的接口如ILLMInteraction来定义。这些脚本被附加到LLMCharacter上LLMCharacter在收到消息比如玩家输入、或其他AI角色的消息时会调用这些脚本中对应的方法。这就是典型的“观察者模式”或“事件驱动”架构在Unity中的体现。一个常见的误区是试图在Update()里轮询或直接控制LLM的响应。这完全违背了插件的设计哲学会导致性能浪费和状态混乱。正确的做法是你的脚本“订阅”角色的事件如OnMessageReceived然后在事件回调里编写处理逻辑。2.2 脚本类型与职责划分在LLMUnity中你通常会编写两种主要类型的脚本交互处理器脚本这是主力。你需要创建一个继承自MonoBehaviour并实现ILLMInteraction接口的类。这个接口强制你实现ProcessInteraction方法。当LLMCharacter需要处理一个交互比如玩家说了一句话时就会调用这个方法。你在这个方法里构造发送给LLM如OpenAI的GPT的提示词Prompt处理返回的结果并决定下一步做什么比如播放一段语音、执行一个动画、或者给另一个角色发送消息。辅助与管理脚本这类脚本可能不直接处理交互但负责更上层的逻辑。例如对话管理器管理多个角色之间的对话回合、话题切换、全局状态。上下文记忆脚本负责维护和向Prompt中注入角色的长期记忆、短期对话历史。工具调用封装脚本如果LLM支持Function Calling/Tool Calling你需要编写脚本来将游戏内的功能如查询背包、打开门暴露给LLM。理解这种职责分离能让你写出更清晰、更易维护的代码。一个ILLMInteraction脚本最好只负责一个角色对一类信息的处理逻辑。3. 脚本编写中的五大核心问题与解决方案在实际编码中我遇到了几个非常典型且棘手的问题。下面我们来逐一拆解。3.1 问题一异步处理与Unity协程的完美融合LLM的API调用是网络I/O操作必然是异步的。但Unity的主线程是单线程的我们不能在异步回调里直接操作Transform、UI等Unity对象。同时我们又要避免主线程阻塞导致游戏卡顿。解决方案使用UniTask或封装良好的Coroutine。我强烈推荐使用UniTask需要导入UniTask插件它比原生协程更强大、性能更好并且能很好地与C#的async/await模式结合。假设我们在一个ILLMInteraction的ProcessInteraction方法中public async UniTaskVoid ProcessInteraction(InteractionData data) { // 1. 从data中获取输入消息 string userInput data.GetMessage(); // 2. 构建Prompt这里可以加入角色设定、历史对话等 string prompt BuildPromptForCharacter(userInput); // 3. 关键步骤异步调用LLM但不阻塞主线程 string llmResponse await SendRequestToLLMAsync(prompt).ConfigureAwait(false); // 4. **重要**await之后代码默认会在主线程恢复可以安全操作Unity对象 DisplayResponseOnUI(llmResponse); PlayTalkingAnimation(); // 5. 可能触发下一步例如自动回复给另一个角色 if (ShouldAutoReply()) { // 通过LLMCharacter发送消息 GetComponentLLMCharacter().SendMessage(new MessageData{...}); } } private async UniTaskstring SendRequestToLLMAsync(string prompt) { // 这里使用你选择的HTTP客户端如UnityWebRequest // 将请求发送到你的LLM服务端点本地或云端 // 返回LLM生成的文本 }注意如果你坚持使用原生协程请务必用yield return来等待UnityWebRequest.SendWebRequest()并在完成后的回调中使用MainThreadDispatcher之类的工具将操作派发回主线程否则极易引发“不是从主线程调用Unity API”的错误。3.2 问题二对话上下文与记忆的管理策略LLM本身是无状态的。如果你只是简单地把当前一轮的对话发过去AI角色很快就会“失忆”对话会变得前言不搭后语。管理上下文是LLM应用的核心挑战。解决方案实现一个分层级的记忆系统。我设计了一个简单的ConversationContextManager脚本它维护以下几个部分系统提示词角色的固定人设、背景、行为准则。每次请求都必须包含。短期记忆一个固定长度的对话历史队列例如最近10轮对话。每次新的交互都将这个历史拼接到Prompt中。长期记忆一个可选的、由关键信息如玩家姓名、达成的协议、重要事件组成的列表。这些信息会被选择性、总结性地注入到系统提示词或单独的记忆部分。在BuildPromptForCharacter方法中你的代码应该是这样的private string BuildPromptForCharacter(string currentInput) { StringBuilder prompt new StringBuilder(); // 1. 系统指令 prompt.AppendLine(你是一个生活在奇幻世界的铁匠名叫格罗姆。你性格豪爽热爱锻造。); prompt.AppendLine(_contextManager.GetLongTermMemorySummary()); // 注入长期记忆摘要 // 2. 短期对话历史 foreach (var exchange in _contextManager.GetRecentHistory()) { prompt.AppendLine(${exchange.speaker}: {exchange.message}); } // 3. 当前输入 prompt.AppendLine($玩家: {currentInput}); prompt.AppendLine(格罗姆:); // 引导AI开始回复 return prompt.ToString(); }每次收到LLM回复后你需要将“玩家: xxx”和“格罗姆: yyy”这对交换记录压入短期记忆队列。当队列超过长度时自动移除最老的记录。对于特别重要的信息可以调用_contextManager.SaveToLongTermMemory(key, value)。3.3 问题三多个AI角色间的通信与协调LLMUnity的魅力在于多个智能体间的互动。如何让角色A说的话能触发角色B的思考并回应解决方案利用LLMCharacter.SendMessage()和消息路由。每个LLMCharacter都有一个SendMessage(MessageData message)方法。MessageData里可以包含发送者、接收者、消息内容、甚至自定义数据。你可以创建一个“中央邮局”脚本或者使用更事件驱动的方式。我更喜欢后者在角色B的交互脚本中监听来自角色A的消息类型。角色A在生成回复后除了显示给玩家还可以决定是否要“告诉”角色B。// 在角色A的脚本中 private async UniTaskVoid ProcessInteraction(InteractionData data) { // ... 处理与玩家的对话得到回复 responseToPlayer ... // 判断是否需要告诉角色B if (responseToPlayer.Contains(告诉厨师)) { MessageData msgForChef new MessageData { Sender this.gameObject, // 发送者铁匠 Recipient GameObject.Find(Chef), // 接收者厨师 Content 玩家刚才说要一份大餐你准备一下。, CustomTag order_food }; GetComponentLLMCharacter().SendMessage(msgForChef); } } // 在角色B厨师的脚本中在其 Start() 或 Awake() 方法里订阅消息 void Start() { GetComponentLLMCharacter().OnMessageReceived HandleIncomingMessage; } private void HandleIncomingMessage(MessageData message) { if (message.CustomTag order_food) { // 触发厨师自己的对话处理逻辑 // 例如可以模拟一个来自“铁匠”的交互 InteractionData fakeInteraction new InteractionData(message.Content, message.Sender); ProcessInteraction(fakeInteraction).Forget(); // 使用Forget来触发异步方法 } }这样你就构建了一个去中心化的、基于事件的AI社交网络。3.4 问题四性能优化与请求节流无节制地向LLM API发送请求会导致高昂的成本和游戏卡顿。尤其是在有多个活跃AI角色的场景中。解决方案实现请求队列与冷却机制。全局请求队列创建一个单例管理器LLMRequestManager。所有发送LLM请求的调用都不直接发送而是封装成一个LLMRequestTask对象提交到这个管理器的队列中。限流器管理器以固定的频率例如每秒2次从队列中取出任务执行。这保证了无论游戏内发生多少对话对API的压力是平稳可控的。角色冷却为每个LLMCharacter设置一个冷却时间例如3秒。在一次请求结束后3秒内不再处理该角色的新请求。这模拟了“思考时间”也防止了玩家或系统快速点击导致的刷屏。// 简化的管理器核心逻辑 public class LLMRequestManager : MonoBehaviour { private QueueLLMRequestTask _requestQueue new QueueLLMRequestTask(); private float _lastRequestTime; public float requestInterval 0.5f; // 每秒最多2次 void Update() { if (Time.time - _lastRequestTime requestInterval _requestQueue.Count 0) { var task _requestQueue.Dequeue(); _lastRequestTime Time.time; // 在后台执行真正的网络请求 _ ExecuteTaskAsync(task); } } public void EnqueueRequest(LLMRequestTask task) { _requestQueue.Enqueue(task); } }在你的交互脚本中将SendRequestToLLMAsync调用改为LLMRequestManager.Instance.EnqueueRequest(myTask)。3.5 问题五错误处理与超时重试网络请求失败、API限流、返回内容格式异常……这些情况必须被妥善处理否则游戏会留下难以调试的Bug。解决方案健壮的错误处理链路。在你的异步请求方法周围包裹完善的try-catch并设计重试逻辑和降级方案。private async UniTaskstring SendRequestToLLMAsync(string prompt, int maxRetries 2) { int attempt 0; while (attempt maxRetries) { try { // 设置一个超时例如30秒 var cts new CancellationTokenSource(); cts.CancelAfterSlim(TimeSpan.FromSeconds(30)); // 这里是你的实际网络请求代码... // using var request CreateWebRequest(prompt); // var result await request.SendWebRequest().WithCancellation(cts.Token); // 检查HTTP状态码和返回内容 // if (result.isHttpError || result.isNetworkError) throw new Exception(...); // var response ParseResponse(result.downloadHandler.text); return response; } catch (OperationCanceledException) { Debug.LogWarning($LLM请求超时尝试 {attempt 1}/{maxRetries 1}); } catch (Exception e) { Debug.LogError($LLM请求失败 (尝试 {attempt 1}): {e.Message}); } attempt; if (attempt maxRetries) { await UniTask.Delay(1000 * attempt); // 延迟重试间隔递增 } } // 所有重试都失败返回一个降级的默认回复 return “看起来我有点走神了你刚才说什么来着; }同时在UI层当请求进行时应该显示一个“思考中…”的指示器当请求失败时给玩家一个友好的提示而不是让游戏僵住。4. 高级脚本技巧状态机与行为树整合对于更复杂的AI行为比如结合对话、移动、寻路、执行动作单纯依靠对话脚本会变得非常臃肿。这时可以将LLMUnity与经典的游戏AI技术结合。4.1 使用状态机管理对话流程你可以为AI角色定义一个状态机状态包括Idle空闲、Listening聆听玩家、Thinking请求LLM中、Speaking播放回复、PerformingAction执行LLM触发的游戏动作。ILLMInteraction脚本只负责在Listening或Thinking状态下的逻辑。状态之间的转换由另一个状态机脚本控制。这样LLM的对话能力就变成了AI整体行为的一个模块更容易与巡逻、战斗等其他模块共存。4.2 将LLM作为行为树的决策节点在行为树中你可以创建一个LLMQueryNode。当执行到这个节点时它向LLM发送当前游戏上下文如周围环境、玩家状态、自身目标并要求LLM从几个预设选项“攻击”、“对话”、“逃跑”、“寻找物品”中选择一个。LLM返回的选择结果决定了行为树接下来的执行分支。这赋予了AI更高层次的、基于语义理解的决策能力而不仅仅是回复文本。实现这个节点本质上就是构造一个让LLM做选择题的Prompt并解析其返回的选项索引。5. 调试与开发工作流建议开发LLMUnity应用调试比传统游戏逻辑更复杂因为输入输出都是非确定性的自然语言。本地日志系统建立一个强大的日志系统记录每一轮对话的完整Prompt和LLM的原始Response。将这些日志实时输出到Unity Editor的一个自定义UI窗口或文件中便于复现问题。Prompt模板化不要将Prompt字符串硬编码在C#脚本里。使用ScriptableObject或文本文件来存储Prompt模板用占位符如{character_name},{history}进行替换。这方便你非程序员队友如策划进行调整和迭代。模拟测试模式在编辑器中创建一个“模拟LLM”模式用一个简单的字符串列表或本地文本文件来模拟LLM的回复从而快速测试你的对话逻辑流而无需消耗API费用和等待网络延迟。版本控制PromptPrompt本身是极其重要的“代码”务必将其纳入版本控制如Git。记录每一次Prompt修改的意图和效果。折腾LLMUnity的脚本是一个不断在“创意想法”和“工程实现”之间寻找平衡的过程。它要求你既要有游戏开发的扎实功底又要对语言模型的工作原理有基本理解。最大的成就感莫过于看到自己创造的AI角色真的能说出符合其性格的话并与其他角色产生意料之外、情理之中的互动。这份动态的、由代码和模型共同演绎的故事正是游戏开发最迷人的地方之一。
)
