OMP 接入 AIGoCode：模型已写入，默认模型还要核对 config.yml

模型已写进 models.yml，为什么还要检查另一个文件

在 OMP 中添加了 AIGoCode 供应商和模型，准备继续项目任务时，先核对终端默认模型是否也指向它。官方文档把自定义模型和默认选择放在两个文件里：models.yml 保存模型定义，config.yml 保存终端默认模型。只检查其中一份，无法完成这条配置核对链。

本文针对“已有模型条目，准备把它设为默认”的任务，给出两份文件之间的对照方法，不假定你遇到的所有连接错误都来自默认设置，也不替你修改现有配置。

找到同一目录下的两份文件

AIGoCode 的 OMP 文档 列出的文件位置如下：

先确认正在检查的是这一组文件，再对照内容。已有配置中需要加入新供应商时，文档要求将新 provider 加入现有 providers；默认模型部分则要求在现有 modelRoles 中设置 default，其他字段保持原值。操作前保留原文件，避免为切换一个模型而覆盖整份配置。

把 provider 名和模型 ID 接到 default

可以把每组配置当成一个三项核对：供应商键、该供应商下面的模型 ID，以及 modelRoles.default 的目标。官方示例的对应关系是：

重点是两份文件的引用一致。例如，你准备使用文档中的 Claude 示例，就逐项确认模型定义里确有 aigocode-claude、它下面包含 claude-opus-5-5，默认目标也对应这组名称。这里是在检查引用是否连上，并不是说仅填写这一串目标就能代替供应商和认证配置。

如果你在原有文件中自定义过名称，先核对自己的完整引用关系；不要把文档示例中的一小段直接混进现有配置后就认为切换完成。

默认目标对上后，再核对协议与认证

名称一致只能完成引用检查，协议和 Key 仍要配合。官方三组示例还给出这些差异：

文档要求先在 API Key 页面创建对应分组的 Key。Claude 示例另有一项容易漏掉：auth 为 apiKey，并同时填写 apiKey 和 headers.x-api-key，两处都替换为同一把 Key。检查时只在本机核对，不要将真实值贴到排错记录中。

这些地址属于 OMP 当前文档示例。不要拿另一个工具的地址习惯替换，也不要把三种协议的 Key 随意交换。关于工具与协议的通用关系，可参照 第三方工具 Key 分组与协议矩阵，再回到 OMP 自身字段核对。

保存两个文件后重启，再确认本次结果

文档要求保存两份文件后重新启动 omp，发送一条消息，收到模型回复作为接入验证。若只保存模型定义，还没有设置默认目标，先补齐引用再做验证；若配置都对上但仍失败，就保留具体报错，不要继续猜测默认设置是唯一原因。

建议给这次操作留一条不含秘密的记录：修改了哪份模型定义、选用了哪个 provider/model ID、默认目标是什么、何时重启、是否收到回复。这样下次切换时可以直接对照两份文件，而不是从安装步骤重新开始。

本文没有实际运行 OMP 或发起模型调用，不将文档示例当作个人环境接通证明。若后续需要提交错误信息，可按 API 排错日志脱敏流程 准备材料；本文也不推断 modelRoles 其他角色的执行行为。