问题描述
后台 AI Provider 已允许填写自定义 endpoint,但在当前 core 的 AI runtime / 测试连接路径中,保存后的自定义 endpoint 仍可能没有真正覆盖注册模型的默认 base URL。
实际表现是:即使在管理后台把 OpenAI Compatible Provider 的 endpoint 配置为代理或中转地址,请求仍可能落到官方 OpenAI / Pi 注册模型的默认地址,最终在不支持地区的服务器上报错:
OpenAI API error 403 Country/Region or Territory not supported
这类配置在前端看起来已经保存成功,但运行时并没有按用户填写的 endpoint 发请求。
预期行为
当 AI Provider 配置里存在自定义 endpoint 时:
- OpenAI Compatible / Anthropic 等 provider 的 runtime 应优先使用用户保存的 endpoint;
- 即使模型可以从 Pi/OpenAI provider registry 中解析到,也应让自定义 endpoint 覆盖注册模型自带的 base URL;
getAiProviderById 这类运行时读取路径应使用已经解密后的配置,避免加密 API key 在测试连接或实际调用中被错误使用。
不是前端侧问题
我重新看了一遍调用链,这个问题不太适合只在前端修。
前端主要负责收集和保存 provider 的 endpoint/apiKey/model 配置;真正构造模型、选择 baseUrl、执行测试连接和运行时请求的是 core 后端里的 AI runtime adapter 和配置服务。因此前端可以改展示或表单校验,但无法保证后端最终请求一定走自定义 endpoint。
对应修复点在:
apps/core/src/modules/ai/runtime/pi-runtime.adapter.ts
apps/core/src/modules/configs/configs.service.ts
已准备的补丁
我已经在 fork 中基于最新 mx-space/core@master 准备了一个最小修复分支:
提交信息:
fix(ai): honor custom provider endpoints
补丁做了这些事:
- 当 registry 中存在模型定义且用户配置了自定义 endpoint 时,保留 registry 模型元数据,但覆盖
baseUrl 为用户配置的 endpoint。
- 让 runtime 解析 provider 配置时走解密后的 config cache,避免 encrypted apiKey 被直接用于 AI 测试/调用。
- 增加回归测试,覆盖自定义 endpoint 覆盖注册模型 base URL,以及 provider 配置解密读取路径。
验证
在 fork 分支上已重新执行:
pnpm -C apps/core exec vitest run test/src/modules/ai/pi-runtime.adapter.spec.ts test/src/modules/configs/configs.service.spec.ts
pnpm -C apps/core run typecheck
结果:
- 2 个测试文件通过
- 31 个测试用例通过
apps/core typecheck 通过
PR 创建受阻
我本来想直接向 mx-space/core 提 PR,但 GitHub API 创建 PR 时报了权限错误:
GraphQL: poboll does not have the correct permissions to execute CreatePullRequest (createPullRequest)
fork 本身已确认是 mx-space/core 的公开 fork,所以先把补丁分支和 compare 链接放在 issue 里,方便维护者直接审阅或手动拉取。
问题描述
后台 AI Provider 已允许填写自定义
endpoint,但在当前 core 的 AI runtime / 测试连接路径中,保存后的自定义 endpoint 仍可能没有真正覆盖注册模型的默认 base URL。实际表现是:即使在管理后台把 OpenAI Compatible Provider 的 endpoint 配置为代理或中转地址,请求仍可能落到官方 OpenAI / Pi 注册模型的默认地址,最终在不支持地区的服务器上报错:
这类配置在前端看起来已经保存成功,但运行时并没有按用户填写的 endpoint 发请求。
预期行为
当 AI Provider 配置里存在自定义
endpoint时:getAiProviderById这类运行时读取路径应使用已经解密后的配置,避免加密 API key 在测试连接或实际调用中被错误使用。不是前端侧问题
我重新看了一遍调用链,这个问题不太适合只在前端修。
前端主要负责收集和保存 provider 的
endpoint/apiKey/model配置;真正构造模型、选择baseUrl、执行测试连接和运行时请求的是 core 后端里的 AI runtime adapter 和配置服务。因此前端可以改展示或表单校验,但无法保证后端最终请求一定走自定义 endpoint。对应修复点在:
apps/core/src/modules/ai/runtime/pi-runtime.adapter.tsapps/core/src/modules/configs/configs.service.ts已准备的补丁
我已经在 fork 中基于最新
mx-space/core@master准备了一个最小修复分支:提交信息:
补丁做了这些事:
baseUrl为用户配置的 endpoint。验证
在 fork 分支上已重新执行:
pnpm -C apps/core exec vitest run test/src/modules/ai/pi-runtime.adapter.spec.ts test/src/modules/configs/configs.service.spec.ts pnpm -C apps/core run typecheck结果:
apps/coretypecheck 通过PR 创建受阻
我本来想直接向
mx-space/core提 PR,但 GitHub API 创建 PR 时报了权限错误:fork 本身已确认是
mx-space/core的公开 fork,所以先把补丁分支和 compare 链接放在 issue 里,方便维护者直接审阅或手动拉取。