Unity调用DeepSeek API (兼容OpenAI SDK)：把Base URL改到TaoToken)
1. Unity 2025 LTS 里把 DeepSeek 接进游戏为什么绕不开 OpenAI SDK 兼容层如果你正在 Unity 2025 LTS 里做 NPC 对话、任务文本生成或者编辑器内的 AI 工具链大概率会遇到一个很现实的问题官方示例清一色是 Python而 Unity 侧只有UnityWebRequest和一堆需要自己拼的 JSON。DeepSeek API 本身兼容 OpenAI SDK 的请求格式这意味着你在 Unity 里不需要引入任何第三方大模型 SDK只要把 Base URL 指向兼容端点、把 API Key 放进请求头就能用同一套 C# 封装跑通对话、流式输出和 JSON 结构化返回。这篇内容面向独立游戏开发者和工具链工程师核心交付三件事一份可直接复制的 Unity C# 请求封装、Base URL 与 API Key 的配置片段、以及在 Editor 和打包后两端验证流式响应与错误码的检查清单。热词里的 Unity、DeepSeek API、OpenAI SDK 兼容层会贯穿全部步骤。先说清楚 DeepSeek 模型本身。DeepSeek-V3 是自研 MoE 架构671B 参数、激活 37B在 14.8T token 上预训练多项评测成绩超过 Qwen2.5-72B 和 Llama-3.1-405B性能上和 GPT-4o、Claude-3.5-Sonnet 属于同一梯队。对 Unity 项目来说更关键的一点是它是国内模型访问不需要任何额外网络配置这在打包后的玩家环境里能省掉大量兼容性排查。那为什么还要经过 OpenAI SDK 兼容层因为 Unity 生态里现成的 C# 封装、流式解析、重试逻辑几乎都是按 OpenAI 的chat/completions协议写的。你只要把请求地址从官方域名换成兼容端点其余字段——model、messages、stream、response_format——全部保持不变。这样做的直接收益是编辑器里调试好的代码打包后不用改一行就能跑团队里用过 OpenAI 接口的人上手成本接近零。我试过在 Unity 2025 LTS 的 Editor 里直接跑流式对话第一次踩的坑不是代码而是 Base URL 写成了带路径后缀的形式导致 404。后面会专门讲这个。整体路径可以拆成四步拿到可用的 API Key、确定 Base URL、写 C# 请求封装、在两端验证。下面按这个顺序展开每一步都给可复制的片段。2. TaoToken 前置准备Base URL、API Key 与模型 ID 三件套怎么配在写 Unity 代码之前先把服务端的三件套确定下来Base URL、API Key、Model ID。这三者缺一个请求都会失败而且报错信息往往不直观。很多人卡在第一步不是因为不会写代码而是因为把 Base URL 和完整请求路径混在一起了。Base URL 的作用是告诉客户端「请求发到哪个域名」。以 OpenAI SDK 的约定为例客户端会自动在 Base URL 后面拼接/chat/completions。所以你在配置里填的应该是根地址而不是完整路径。这一点在 Unity 里尤其容易搞错因为UnityWebRequest需要你手写完整 URL没有 SDK 帮你拼。API Key 的获取路径是进入控制台在 API Keys 页面创建一个新的 Key复制后立刻保存因为页面刷新后通常不再完整显示。Key 的格式一般以固定前缀开头放进请求头时前面要加Bearer注意中间有一个空格。这个空格漏掉是最常见的 401 原因之一。Model ID 决定你调用哪个模型。对话场景常用的是deepseek-chat对应 DeepSeek-V3。如果你要做推理增强类任务可以换成对应的推理模型 ID。Model ID 是大小写敏感的写错会直接返回模型不存在的错误。把三件套整理成一张对照表方便你在 Unity 配置里逐项核对配置项示例值填写位置常见错误Base URLhttps://taotoken.net/api请求根地址多写/chat/completions导致 404API Keysk-开头的一串字符请求头Authorization漏掉Bearer前缀或空格Model IDdeepseek-chat请求体model字段大小写写错、拼成deepseek-v3这里要强调一个容易混淆的点Base URL 和完整请求 URL 是两个东西。在 Unity 的UnityWebRequest里你需要的是完整 URL也就是 Base URL 加上/chat/completions。而在任何遵循 OpenAI SDK 约定的客户端里你只填 Base URL路径由 SDK 拼接。两种写法对应两种场景别混用。如果你用的是 Claude Code 这类工具配置方式又不一样它读的是环境变量或 settings 文件。但 Unity 项目里没有这套机制所以你要么把配置写进ScriptableObject要么放进Resources下的配置文件运行时读取。推荐后者因为打包后仍然可改不用重新出包。还有一个实践建议不要把 API Key 硬编码在 C# 脚本里。Unity 打包后的资源是可以被反编译的硬编码等于把 Key 公开。正确做法是运行时从服务端下发或者至少放进加密的配置里。开发阶段可以先用本地文件上线前务必替换。3. 可复制配置Unity C# 请求封装与 JSON 结构这一节给可直接复制的代码。先定义请求体的数据结构再写请求封装最后给出调用示例。所有片段都按 Unity 2025 LTS 的 API 写UnityWebRequest的用法和旧版本一致但注意 2025 LTS 对using语句和异步的支持更完整如果你用async/await需要额外引入UnityWebRequestAsyncOperation的封装。先看请求体的 JSON 结构。DeepSeek 兼容 OpenAI 的chat/completions协议核心字段是model、messages、stream。messages是一个数组每个元素有role和content。role可以是system、user、assistant。如果你要结构化输出再加response_format。using System; using System.Collections.Generic; [Serializable] public class ChatRequest { public string model; public ListChatMessage messages; public bool stream; public int max_tokens; public ResponseFormat response_format; } [Serializable] public class ChatMessage { public string role; public string content; } [Serializable] public class ResponseFormat { public string type; }注意[Serializable]是必须的否则JsonUtility无法序列化。但JsonUtility对嵌套数组和可选字段支持有限实际项目里更推荐用 Newtonsoft.JsonUnity 可以通过 Package Manager 安装com.unity.nuget.newtonsoft-json。下面的封装用 Newtonsoft兼容性更好。using System; using System.Collections; using System.Text; using Newtonsoft.Json; using UnityEngine; using UnityEngine.Networking; public static class DeepSeekClient { // Base URL 只填根地址路径在这里拼接 private const string BaseUrl https://taotoken.net/api; private const string ChatPath /chat/completions; public static IEnumerator PostChatT( string apiKey, ChatRequest request, ActionT onSuccess, Actionstring onError) { string url BaseUrl ChatPath; string json JsonConvert.SerializeObject(request); byte[] body Encoding.UTF8.GetBytes(json); using (UnityWebRequest www new UnityWebRequest(url, POST)) { www.uploadHandler new UploadHandlerRaw(body); www.downloadHandler new DownloadHandlerBuffer(); www.SetRequestHeader(Content-Type, application/json); www.SetRequestHeader(Authorization, Bearer apiKey); yield return www.SendWebRequest(); if (www.result UnityWebRequest.Result.Success) { onSuccess?.Invoke(JsonConvert.DeserializeObjectT(www.downloadHandler.text)); } else { onError?.Invoke($[{www.responseCode}] {www.error} | {www.downloadHandler.text}); } } } }调用示例void Start() { var req new ChatRequest { model deepseek-chat, stream false, max_tokens 512, messages new ListChatMessage { new ChatMessage { role system, content 你是一个游戏 NPC 对话生成器。 }, new ChatMessage { role user, content 生成一句欢迎玩家的话。 } } }; StartCoroutine(DeepSeekClient.PostChatChatResponse( apiKey: 你的 API Key, request: req, onSuccess: resp Debug.Log(resp.choices[0].message.content), onError: err Debug.LogError(err) )); }对应的响应结构[Serializable] public class ChatResponse { public string id; public ListChoice choices; } [Serializable] public class Choice { public int index; public ChatMessage message; public string finish_reason; }如果你要流式输出把stream设为true但UnityWebRequest默认会等整个响应结束才返回拿不到逐块数据。要真正流式需要用DownloadHandlerScript自定义接收或者用UnityWebRequest的downloadHandler配合receiveDataCallback。这部分在下一节验证时展开。配置片段建议放进一个ScriptableObject[CreateAssetMenu(fileName AIConfig, menuName AI/Config)] public class AIConfig : ScriptableObject { public string baseUrl https://taotoken.net/api; public string apiKey; public string modelId deepseek-chat; public int maxTokens 512; }这样在 Editor 里可以直接改打包后通过Resources.LoadAIConfig(AIConfig)读取。注意Resources目录下的资源会被打进包体Key 仍然可被提取所以生产环境要换成服务端下发。4. 验证请求Editor 与打包后两端的成功结果与流式检查写完封装下一步是验证。验证分两个环境Editor 和打包后。两者的差异主要在权限、网络和日志可见性上。Editor 里Debug.Log直接可见打包后要看 Player.log 或者自己写 UI 输出。先验证非流式请求。在 Editor 里运行上面的调用示例预期结果是 Console 里打印出模型生成的欢迎语。如果成功你会看到类似这样的返回{ id: chatcmpl-xxx, choices: [ { index: 0, message: { role: assistant, content: 欢迎来到这个世界冒险者。 }, finish_reason: stop } ] }看到finish_reason是stop说明请求完整结束。如果是length说明max_tokens设小了内容被截断。这个字段在调试 JSON 输出时特别有用因为 JSON 被截断会导致反序列化失败。再验证流式。流式的返回是 SSE 格式每行以data:开头最后一行是data: [DONE]。在 Unity 里要拿到逐块数据需要自定义DownloadHandlerScriptpublic class StreamHandler : DownloadHandlerScript { private readonly Actionstring onChunk; private readonly StringBuilder buffer new StringBuilder(); public StreamHandler(Actionstring onChunk) : base(new byte[1024]) { this.onChunk onChunk; } protected override bool ReceiveData(byte[] data, int dataLength) { if (data null || dataLength 0) return false; string text Encoding.UTF8.GetString(data, 0, dataLength); buffer.Append(text); string content buffer.ToString(); int newlineIndex; while ((newlineIndex content.IndexOf(\n)) 0) { string line content.Substring(0, newlineIndex).Trim(); content content.Substring(newlineIndex 1); if (line.StartsWith(data: )) { string payload line.Substring(6); if (payload ! [DONE]) onChunk?.Invoke(payload); } } buffer.Clear(); buffer.Append(content); return true; } }用这个 handler 替换默认的DownloadHandlerBuffer就能在onChunk里拿到每个增量片段。注意 SSE 的分块边界可能切断一行所以要用 buffer 缓存不完整的行等下一个分块再拼。这是流式解析最常见的 bug表现为偶尔丢字或者 JSON 解析失败。打包后验证时Debug.Log会写到Player.log路径因平台而异。Windows 在%USERPROFILE%\AppData\LocalLow\公司名\产品名\Player.logmacOS 在~/Library/Logs/公司名/产品名/Player.log。Android 用adb logcatiOS 用 Xcode 的 Console。建议在游戏里加一个调试面板把请求状态和错误码显示出来省得每次都要翻日志。验证清单可以整理成下面这样逐项打勾检查项Editor打包后说明非流式返回正常是是确认choices[0].message.content非空流式逐块输出是是确认onChunk被多次调用401 错误可复现是是故意用错 Key确认错误码超时处理是是断网后确认www.error有值中文不乱码是是确认Encoding.UTF8生效流式在打包后最容易出问题的是网络权限。Android 需要在AndroidManifest.xml里加INTERNET权限iOS 默认允许 HTTPS但如果你的 Base URL 是 HTTP 就会被 ATS 拦截。这些不是代码问题但排查起来很费时间提前确认能省不少事。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth 报错对照这一节按真实报错来。下面这些错误我在不同项目里都遇到过每个都给出原因和修复方式。401 Unauthorized。最常见的原因是 API Key 写错或者请求头格式不对。检查两点Key 是否完整复制Authorization头的值是否是Bearer加 Key中间有且只有一个空格。还有一种情况是 Key 被禁用或额度耗尽这时返回体里通常有更具体的说明。修复方式是重新生成 Key并确认请求头拼接逻辑没有多余字符。local proxy failed。这个错误通常出现在客户端配置了本地代理但代理服务没启动或者端口不对。Unity 本身不主动走系统代理但如果你用了某些网络库或者系统级代理设置就可能触发。排查方式是检查系统代理设置确认没有指向一个不存在的本地端口。如果你在代码里手动设置了www.proxy把它去掉再试。reading choices 报错。这个错误一般发生在反序列化阶段提示读取choices字段失败。原因通常是响应体不是预期的 JSON比如返回了 HTML 错误页或者流式响应被当成非流式解析。修复方式是先打印原始响应文本确认它是合法 JSON 再反序列化。流式场景下每个data:片段是独立的 JSON不能整体解析。OAuth 相关报错。如果你用的是某些需要 OAuth 授权的客户端报错可能提示 token 过期或 scope 不足。Unity 项目里一般用 API Key 而不是 OAuth所以遇到这类错误通常是配置串了。检查你填的是不是 API Key而不是某个 OAuth 的 access token。两者的请求头格式不同混用会直接 401。404 Not Found。Base URL 多写了路径或者少写了路径。记住Base URL 是根地址完整 URL 是 Base URL 加/chat/completions。如果你在 Base URL 里已经写了/chat/completions再拼一次就变成/chat/completions/chat/completions直接 404。模型不存在。Model ID 写错比如写成deepseek-v3而不是deepseek-chat。Model ID 是接口约定的标识符不是模型的市场名称。以控制台或文档里列出的为准。JSON 解析失败。response_format设为json_object时prompt 里必须包含json字样并给出期望的 JSON 样例。否则模型可能返回普通文本导致解析失败。另外max_tokens要设够防止 JSON 被截断。流式丢字。前面提过SSE 分块可能切断一行必须用 buffer 缓存不完整行。如果直接按分块解析就会偶尔丢字或者解析出半个 JSON。打包后请求失败但 Editor 正常。优先检查平台网络权限和 ATS 设置。Android 的INTERNET权限、iOS 的 HTTPS 要求、WebGL 的跨域限制都是常见原因。WebGL 还需要服务端返回正确的 CORS 头否则浏览器会拦截请求。把这些错误和对应的检查点整理成一张速查表出问题时按顺序排查报错最可能原因第一步检查401Key 或请求头格式Authorization值404URL 拼接错误Base URL 是否含路径local proxy failed本地代理配置系统代理设置reading choices响应非 JSON打印原始响应模型不存在Model ID 写错对照文档流式丢字分块边界处理buffer 逻辑排查的核心思路是先确认请求发出去了没有再确认响应回来了没有最后确认解析对不对。三步定位基本能覆盖九成问题。6. 语义一致 CTA把配置落到你的 Unity 项目里到这里Unity 侧调用 DeepSeek API 的完整路径已经走完三件套配置、C# 封装、两端验证、错误排查。接下来最实际的一步是把这些片段落到你自己的项目里。建议按这个顺序操作先在 Editor 里跑通非流式请求确认返回正常再切流式验证逐块输出最后打包到目标平台确认网络权限和日志输出。如果你还没有可用的 API Key或者想统一管理多个项目的调用额度可以到控制台创建和管理 Key。接入过程中遇到请求格式或错误码的问题接入文档里有完整的字段说明和示例。想先直观感受一下模型输出效果可以直接在模型对话里试几轮确认返回风格符合你的项目需求。如果你的项目涉及长期编码任务或者 Agent 工具链Coding Plan 提供了更适合持续调用的方案。配置这件事最怕的是「看起来能跑」但打包后出问题。所以务必在目标平台上做一次完整验证尤其是流式和错误处理。把调试面板做进游戏里比事后翻日志高效得多。
(2025)Unity调用DeepSeek API (兼容OpenAI SDK)：把Base URL改到TaoToken
1. Unity 2025 LTS 里把 DeepSeek 接进游戏为什么绕不开 OpenAI SDK 兼容层如果你正在 Unity 2025 LTS 里做 NPC 对话、任务文本生成或者编辑器内的 AI 工具链大概率会遇到一个很现实的问题官方示例清一色是 Python而 Unity 侧只有UnityWebRequest和一堆需要自己拼的 JSON。DeepSeek API 本身兼容 OpenAI SDK 的请求格式这意味着你在 Unity 里不需要引入任何第三方大模型 SDK只要把 Base URL 指向兼容端点、把 API Key 放进请求头就能用同一套 C# 封装跑通对话、流式输出和 JSON 结构化返回。这篇内容面向独立游戏开发者和工具链工程师核心交付三件事一份可直接复制的 Unity C# 请求封装、Base URL 与 API Key 的配置片段、以及在 Editor 和打包后两端验证流式响应与错误码的检查清单。热词里的 Unity、DeepSeek API、OpenAI SDK 兼容层会贯穿全部步骤。先说清楚 DeepSeek 模型本身。DeepSeek-V3 是自研 MoE 架构671B 参数、激活 37B在 14.8T token 上预训练多项评测成绩超过 Qwen2.5-72B 和 Llama-3.1-405B性能上和 GPT-4o、Claude-3.5-Sonnet 属于同一梯队。对 Unity 项目来说更关键的一点是它是国内模型访问不需要任何额外网络配置这在打包后的玩家环境里能省掉大量兼容性排查。那为什么还要经过 OpenAI SDK 兼容层因为 Unity 生态里现成的 C# 封装、流式解析、重试逻辑几乎都是按 OpenAI 的chat/completions协议写的。你只要把请求地址从官方域名换成兼容端点其余字段——model、messages、stream、response_format——全部保持不变。这样做的直接收益是编辑器里调试好的代码打包后不用改一行就能跑团队里用过 OpenAI 接口的人上手成本接近零。我试过在 Unity 2025 LTS 的 Editor 里直接跑流式对话第一次踩的坑不是代码而是 Base URL 写成了带路径后缀的形式导致 404。后面会专门讲这个。整体路径可以拆成四步拿到可用的 API Key、确定 Base URL、写 C# 请求封装、在两端验证。下面按这个顺序展开每一步都给可复制的片段。2. TaoToken 前置准备Base URL、API Key 与模型 ID 三件套怎么配在写 Unity 代码之前先把服务端的三件套确定下来Base URL、API Key、Model ID。这三者缺一个请求都会失败而且报错信息往往不直观。很多人卡在第一步不是因为不会写代码而是因为把 Base URL 和完整请求路径混在一起了。Base URL 的作用是告诉客户端「请求发到哪个域名」。以 OpenAI SDK 的约定为例客户端会自动在 Base URL 后面拼接/chat/completions。所以你在配置里填的应该是根地址而不是完整路径。这一点在 Unity 里尤其容易搞错因为UnityWebRequest需要你手写完整 URL没有 SDK 帮你拼。API Key 的获取路径是进入控制台在 API Keys 页面创建一个新的 Key复制后立刻保存因为页面刷新后通常不再完整显示。Key 的格式一般以固定前缀开头放进请求头时前面要加Bearer注意中间有一个空格。这个空格漏掉是最常见的 401 原因之一。Model ID 决定你调用哪个模型。对话场景常用的是deepseek-chat对应 DeepSeek-V3。如果你要做推理增强类任务可以换成对应的推理模型 ID。Model ID 是大小写敏感的写错会直接返回模型不存在的错误。把三件套整理成一张对照表方便你在 Unity 配置里逐项核对配置项示例值填写位置常见错误Base URLhttps://taotoken.net/api请求根地址多写/chat/completions导致 404API Keysk-开头的一串字符请求头Authorization漏掉Bearer前缀或空格Model IDdeepseek-chat请求体model字段大小写写错、拼成deepseek-v3这里要强调一个容易混淆的点Base URL 和完整请求 URL 是两个东西。在 Unity 的UnityWebRequest里你需要的是完整 URL也就是 Base URL 加上/chat/completions。而在任何遵循 OpenAI SDK 约定的客户端里你只填 Base URL路径由 SDK 拼接。两种写法对应两种场景别混用。如果你用的是 Claude Code 这类工具配置方式又不一样它读的是环境变量或 settings 文件。但 Unity 项目里没有这套机制所以你要么把配置写进ScriptableObject要么放进Resources下的配置文件运行时读取。推荐后者因为打包后仍然可改不用重新出包。还有一个实践建议不要把 API Key 硬编码在 C# 脚本里。Unity 打包后的资源是可以被反编译的硬编码等于把 Key 公开。正确做法是运行时从服务端下发或者至少放进加密的配置里。开发阶段可以先用本地文件上线前务必替换。3. 可复制配置Unity C# 请求封装与 JSON 结构这一节给可直接复制的代码。先定义请求体的数据结构再写请求封装最后给出调用示例。所有片段都按 Unity 2025 LTS 的 API 写UnityWebRequest的用法和旧版本一致但注意 2025 LTS 对using语句和异步的支持更完整如果你用async/await需要额外引入UnityWebRequestAsyncOperation的封装。先看请求体的 JSON 结构。DeepSeek 兼容 OpenAI 的chat/completions协议核心字段是model、messages、stream。messages是一个数组每个元素有role和content。role可以是system、user、assistant。如果你要结构化输出再加response_format。using System; using System.Collections.Generic; [Serializable] public class ChatRequest { public string model; public ListChatMessage messages; public bool stream; public int max_tokens; public ResponseFormat response_format; } [Serializable] public class ChatMessage { public string role; public string content; } [Serializable] public class ResponseFormat { public string type; }注意[Serializable]是必须的否则JsonUtility无法序列化。但JsonUtility对嵌套数组和可选字段支持有限实际项目里更推荐用 Newtonsoft.JsonUnity 可以通过 Package Manager 安装com.unity.nuget.newtonsoft-json。下面的封装用 Newtonsoft兼容性更好。using System; using System.Collections; using System.Text; using Newtonsoft.Json; using UnityEngine; using UnityEngine.Networking; public static class DeepSeekClient { // Base URL 只填根地址路径在这里拼接 private const string BaseUrl https://taotoken.net/api; private const string ChatPath /chat/completions; public static IEnumerator PostChatT( string apiKey, ChatRequest request, ActionT onSuccess, Actionstring onError) { string url BaseUrl ChatPath; string json JsonConvert.SerializeObject(request); byte[] body Encoding.UTF8.GetBytes(json); using (UnityWebRequest www new UnityWebRequest(url, POST)) { www.uploadHandler new UploadHandlerRaw(body); www.downloadHandler new DownloadHandlerBuffer(); www.SetRequestHeader(Content-Type, application/json); www.SetRequestHeader(Authorization, Bearer apiKey); yield return www.SendWebRequest(); if (www.result UnityWebRequest.Result.Success) { onSuccess?.Invoke(JsonConvert.DeserializeObjectT(www.downloadHandler.text)); } else { onError?.Invoke($[{www.responseCode}] {www.error} | {www.downloadHandler.text}); } } } }调用示例void Start() { var req new ChatRequest { model deepseek-chat, stream false, max_tokens 512, messages new ListChatMessage { new ChatMessage { role system, content 你是一个游戏 NPC 对话生成器。 }, new ChatMessage { role user, content 生成一句欢迎玩家的话。 } } }; StartCoroutine(DeepSeekClient.PostChatChatResponse( apiKey: 你的 API Key, request: req, onSuccess: resp Debug.Log(resp.choices[0].message.content), onError: err Debug.LogError(err) )); }对应的响应结构[Serializable] public class ChatResponse { public string id; public ListChoice choices; } [Serializable] public class Choice { public int index; public ChatMessage message; public string finish_reason; }如果你要流式输出把stream设为true但UnityWebRequest默认会等整个响应结束才返回拿不到逐块数据。要真正流式需要用DownloadHandlerScript自定义接收或者用UnityWebRequest的downloadHandler配合receiveDataCallback。这部分在下一节验证时展开。配置片段建议放进一个ScriptableObject[CreateAssetMenu(fileName AIConfig, menuName AI/Config)] public class AIConfig : ScriptableObject { public string baseUrl https://taotoken.net/api; public string apiKey; public string modelId deepseek-chat; public int maxTokens 512; }这样在 Editor 里可以直接改打包后通过Resources.LoadAIConfig(AIConfig)读取。注意Resources目录下的资源会被打进包体Key 仍然可被提取所以生产环境要换成服务端下发。4. 验证请求Editor 与打包后两端的成功结果与流式检查写完封装下一步是验证。验证分两个环境Editor 和打包后。两者的差异主要在权限、网络和日志可见性上。Editor 里Debug.Log直接可见打包后要看 Player.log 或者自己写 UI 输出。先验证非流式请求。在 Editor 里运行上面的调用示例预期结果是 Console 里打印出模型生成的欢迎语。如果成功你会看到类似这样的返回{ id: chatcmpl-xxx, choices: [ { index: 0, message: { role: assistant, content: 欢迎来到这个世界冒险者。 }, finish_reason: stop } ] }看到finish_reason是stop说明请求完整结束。如果是length说明max_tokens设小了内容被截断。这个字段在调试 JSON 输出时特别有用因为 JSON 被截断会导致反序列化失败。再验证流式。流式的返回是 SSE 格式每行以data:开头最后一行是data: [DONE]。在 Unity 里要拿到逐块数据需要自定义DownloadHandlerScriptpublic class StreamHandler : DownloadHandlerScript { private readonly Actionstring onChunk; private readonly StringBuilder buffer new StringBuilder(); public StreamHandler(Actionstring onChunk) : base(new byte[1024]) { this.onChunk onChunk; } protected override bool ReceiveData(byte[] data, int dataLength) { if (data null || dataLength 0) return false; string text Encoding.UTF8.GetString(data, 0, dataLength); buffer.Append(text); string content buffer.ToString(); int newlineIndex; while ((newlineIndex content.IndexOf(\n)) 0) { string line content.Substring(0, newlineIndex).Trim(); content content.Substring(newlineIndex 1); if (line.StartsWith(data: )) { string payload line.Substring(6); if (payload ! [DONE]) onChunk?.Invoke(payload); } } buffer.Clear(); buffer.Append(content); return true; } }用这个 handler 替换默认的DownloadHandlerBuffer就能在onChunk里拿到每个增量片段。注意 SSE 的分块边界可能切断一行所以要用 buffer 缓存不完整的行等下一个分块再拼。这是流式解析最常见的 bug表现为偶尔丢字或者 JSON 解析失败。打包后验证时Debug.Log会写到Player.log路径因平台而异。Windows 在%USERPROFILE%\AppData\LocalLow\公司名\产品名\Player.logmacOS 在~/Library/Logs/公司名/产品名/Player.log。Android 用adb logcatiOS 用 Xcode 的 Console。建议在游戏里加一个调试面板把请求状态和错误码显示出来省得每次都要翻日志。验证清单可以整理成下面这样逐项打勾检查项Editor打包后说明非流式返回正常是是确认choices[0].message.content非空流式逐块输出是是确认onChunk被多次调用401 错误可复现是是故意用错 Key确认错误码超时处理是是断网后确认www.error有值中文不乱码是是确认Encoding.UTF8生效流式在打包后最容易出问题的是网络权限。Android 需要在AndroidManifest.xml里加INTERNET权限iOS 默认允许 HTTPS但如果你的 Base URL 是 HTTP 就会被 ATS 拦截。这些不是代码问题但排查起来很费时间提前确认能省不少事。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth 报错对照这一节按真实报错来。下面这些错误我在不同项目里都遇到过每个都给出原因和修复方式。401 Unauthorized。最常见的原因是 API Key 写错或者请求头格式不对。检查两点Key 是否完整复制Authorization头的值是否是Bearer加 Key中间有且只有一个空格。还有一种情况是 Key 被禁用或额度耗尽这时返回体里通常有更具体的说明。修复方式是重新生成 Key并确认请求头拼接逻辑没有多余字符。local proxy failed。这个错误通常出现在客户端配置了本地代理但代理服务没启动或者端口不对。Unity 本身不主动走系统代理但如果你用了某些网络库或者系统级代理设置就可能触发。排查方式是检查系统代理设置确认没有指向一个不存在的本地端口。如果你在代码里手动设置了www.proxy把它去掉再试。reading choices 报错。这个错误一般发生在反序列化阶段提示读取choices字段失败。原因通常是响应体不是预期的 JSON比如返回了 HTML 错误页或者流式响应被当成非流式解析。修复方式是先打印原始响应文本确认它是合法 JSON 再反序列化。流式场景下每个data:片段是独立的 JSON不能整体解析。OAuth 相关报错。如果你用的是某些需要 OAuth 授权的客户端报错可能提示 token 过期或 scope 不足。Unity 项目里一般用 API Key 而不是 OAuth所以遇到这类错误通常是配置串了。检查你填的是不是 API Key而不是某个 OAuth 的 access token。两者的请求头格式不同混用会直接 401。404 Not Found。Base URL 多写了路径或者少写了路径。记住Base URL 是根地址完整 URL 是 Base URL 加/chat/completions。如果你在 Base URL 里已经写了/chat/completions再拼一次就变成/chat/completions/chat/completions直接 404。模型不存在。Model ID 写错比如写成deepseek-v3而不是deepseek-chat。Model ID 是接口约定的标识符不是模型的市场名称。以控制台或文档里列出的为准。JSON 解析失败。response_format设为json_object时prompt 里必须包含json字样并给出期望的 JSON 样例。否则模型可能返回普通文本导致解析失败。另外max_tokens要设够防止 JSON 被截断。流式丢字。前面提过SSE 分块可能切断一行必须用 buffer 缓存不完整行。如果直接按分块解析就会偶尔丢字或者解析出半个 JSON。打包后请求失败但 Editor 正常。优先检查平台网络权限和 ATS 设置。Android 的INTERNET权限、iOS 的 HTTPS 要求、WebGL 的跨域限制都是常见原因。WebGL 还需要服务端返回正确的 CORS 头否则浏览器会拦截请求。把这些错误和对应的检查点整理成一张速查表出问题时按顺序排查报错最可能原因第一步检查401Key 或请求头格式Authorization值404URL 拼接错误Base URL 是否含路径local proxy failed本地代理配置系统代理设置reading choices响应非 JSON打印原始响应模型不存在Model ID 写错对照文档流式丢字分块边界处理buffer 逻辑排查的核心思路是先确认请求发出去了没有再确认响应回来了没有最后确认解析对不对。三步定位基本能覆盖九成问题。6. 语义一致 CTA把配置落到你的 Unity 项目里到这里Unity 侧调用 DeepSeek API 的完整路径已经走完三件套配置、C# 封装、两端验证、错误排查。接下来最实际的一步是把这些片段落到你自己的项目里。建议按这个顺序操作先在 Editor 里跑通非流式请求确认返回正常再切流式验证逐块输出最后打包到目标平台确认网络权限和日志输出。如果你还没有可用的 API Key或者想统一管理多个项目的调用额度可以到控制台创建和管理 Key。接入过程中遇到请求格式或错误码的问题接入文档里有完整的字段说明和示例。想先直观感受一下模型输出效果可以直接在模型对话里试几轮确认返回风格符合你的项目需求。如果你的项目涉及长期编码任务或者 Agent 工具链Coding Plan 提供了更适合持续调用的方案。配置这件事最怕的是「看起来能跑」但打包后出问题。所以务必在目标平台上做一次完整验证尤其是流式和错误处理。把调试面板做进游戏里比事后翻日志高效得多。