前言

上一篇我已经把 DevEco Code 从安装到跑通完整过了一遍。

如果你已经装好了，那接下来大概率会遇到同一个问题：默认模型能不能继续用？能。但如果你想切换成自己更熟悉的模型，或者接入第三方服务，该怎么配？

这篇文章就专门讲这件事。

不聊太空的概念，直接讲实际操作：DevEco Code 的模型配置入口在哪里、deveco.jsonc 怎么写、每个字段是什么意思、配完之后怎么验证有没有生效。

先说结论：DevEco Code 支持两种模型使用方式

根据 DevEco Code 官方文档，登录后可以直接使用官方提供的免费模型通道。

在工具里输入 /models，就能进入模型配置界面。当前免费提供的是 GLM-5.1，单账号默认每分钟 50 次请求。

除此之外，也可以通过 Ctrl + A 打开 Provider 选择界面，配置支持的第三方模型。

也就是说，它至少支持两种思路：

• 直接用官方默认模型：省事，开箱即用。
• 接入自定义模型：更灵活，可以统一接你自己的模型服务、网关或者中转接口。

如果你只是偶尔体验一下，默认模型其实已经够用了。

但如果你对模型能力、上下文长度、输出长度，甚至价格和稳定性有要求，那自定义配置就很有必要。

官方给了配置方式，我们就照着来

官方文档里已经明确给出了 deveco.jsonc 的配置方式。

示例如下：

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "deveco": {
      "name": "DevEco Code",
      "models": {
        "glm-5": {
          "tool_call": true,
          "limit": {
            "context": 200000,
            "output": 8192
          }
        }
      },
      "options": {
        "baseURL": "https://api.openbitfun.com/v1",
        "apiKey": "{env:DEVECO_API_KEY}"
      }
    }
  }
}

这段配置的意思很简单：provider 下面定义模型提供方，每个提供方里再去声明自己的模型、能力和接口地址。

所以后面的核心思路其实就一句话：保留原有官方模型配置，再额外新增你自己的模型提供方。

第一步：先确认当前模型状态

正式改配置之前，建议先登录 DevEco Code 看一下当前初始状态。

从图里你也能看出来，初始状态通常只有官方默认模型。

这一步的意义不是“看个热闹”，而是为了后面对比：配完之后模型列表有没有新增，最直观。

第二步：找到 deveco.jsonc

接下来要做的，就是先找到配置文件位置。

可以在终端里执行下面这条命令：

find . -name "deveco.jsonc"

找到之后，直接打开它开始改就行。

如果你的环境里还没有这个文件，也可以按官方支持的方式新建并填写配置。

第三步：把自定义模型加进去

下面是一个比较完整的配置示例。

我这里保留了原有的 DevEco Code 官方模型，同时新增了一个自定义的 1api 提供方，用来接入 gpt-5.3-codex 模型。

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "deveco": {
      "name": "DevEco Code",
      "models": {
        "glm-5": {
          "tool_call": true,
          "limit": {
            "context": 200000,
            "output": 8192
          }
        }
      },
      "options": {
        "baseURL": "https://api.openbitfun.com/v1",
        "apiKey": "{env:DEVECO_API_KEY}"
      }
    },
    "1api": {
      "name": "GPT-5.3 Codex 模型",
      "models": {
        "gpt-5.3-codex": {
          "tool_call": true,
          "limit": {
            "context": 128000,
            "output": 16384
          },
          "vision": true
        }
      },
      "options": {
        "baseURL": "模型地址Url <http://xxxxxx/v1>",
        "apiKey": "API key"
      }
    }
  }
}

这里有几个点建议你特别注意一下。

不要把官方模型直接删掉

最稳妥的方式，是在原有配置基础上追加，而不是上来就把官方 provider 全改没了。

这样做的好处很明显：

• 出问题时更容易回退。
• 可以同时保留多个模型来源。
• 后面在界面里切换模型也更方便。

baseURL 和 apiKey 要填你自己的真实值

这一点很好理解。

baseURL 对应模型服务的接口根地址，apiKey 对应访问密钥。示例里的内容只是占位符，真正使用时一定要换成你自己的值。

tool_call 和 vision 不要乱配

• tool_call: true 表示这个模型支持工具调用。
• vision: true 表示这个模型支持图片识图能力。

如果你的模型本身不支持这些能力，强行写上去不一定会报错，但实际使用时很可能表现异常。所以这里最好按模型真实能力来填。

这些字段分别是什么意思？

为了避免看配置文件时一头雾水，我把关键字段整理成了一个对照表。

配置字段	配置文件对应写法	说明
gpt-5.3-codex	键名 "gpt-5.3-codex"	models 下的模型唯一标识
name	外层 name	提供方或模型的展示名称
vendor:1api	provider 外层键 "1api"	provider 顶级节点的厂商标识
apiKey	options.apiKey	接口访问密钥
url	options.baseURL	中转或官方接口根地址
supportsToolCall	tool_call: true	模型支持工具函数调用
supportsImages	vision: true	模型支持图片识图输入

你可以把这张表当成一个速查表。

后面不管你接的是别的 GPT 系列、兼容 OpenAI 协议的模型，还是团队内网代理服务，本质上都还是围绕这些字段在改。

第四步：配置完成后，怎么验证有没有生效？

配完最怕什么？

最怕你以为已经生效了，结果实际上工具压根没读到配置。

所以改完之后，第一件事不是直接开干，而是先去看模型列表有没有变化。

如下图所示，这是我配置完成后的模型列表。这里我选择了 gpt5.4 这个模型来做测试。

只要你能在模型列表中看到新增的提供方或者模型名称，基本就说明配置已经被正确识别了。

第五步：拿真实问题试一下

光看到模型名字出现，还不算真正验证完成。

更靠谱的方式，是直接拿一个真实开发问题去提问，看看回答质量、上下文理解和输出风格是不是符合预期。

我这里是在鸿蒙开发者论坛里找了一个实际问题来测试。

回答效果如下：

这一步我建议你也照着做。

因为模型是否“可用”，和模型是否“好用”，完全是两回事。真正决定体验的，往往不是配置有没有写对，而是这个模型在你的实际开发场景里回得怎么样。

什么时候值得折腾自定义模型？

如果你还在犹豫要不要配，我的建议很直接。

下面这几种情况，值得配：

• 你想用自己更熟悉的模型：比如某个模型的代码风格、响应速度更对你胃口。
• 你有统一网关或中转服务：希望所有模型调用都从自己的服务走。
• 你对上下文或输出长度有要求：默认模型不一定总能满足复杂场景。
• 你需要多模型切换：不同任务切不同模型，效率会更高。

如果你只是想先体验一下 DevEco Code，那官方默认模型足够你开始。

但如果你已经准备把它当成日常 HarmonyOS 开发工具链的一部分，那自定义模型这一步，我觉得迟早都要做。

总结

到这里，DevEco Code 的模型配置就算完整跑通了。

整体看下来，这件事并不复杂：找到 deveco.jsonc，补充 provider 配置，填好 baseURL 和 apiKey，最后去模型列表和真实问题里做一次验证，就差不多了。

下一篇我准备继续往下写，聊聊 怎么给 DevEco Code 配置 Skill，让模型不只是会回答问题，而是真的多长一对“手脚”。