背景 or 问题
背景
我用智谱GLM-5来完成日常的AI活动。
AutoBangumi已经实现openai,智谱支持OpenAI协议兼容接入,所以接入难度应该比较低,token不用白不用
希望确认
根据 CONTRIBUTING.md,该功能应该提交到3.2-dev?
目标 & 方案简述
目标
为 LLM 解析功能增加 BigModel Provider 支持,并保持现有 OpenAI / Azure 配置与默认行为不变。
方案概述
计划增加以下能力:
- 新增
BigModel 作为可选 Provider 类型
- 在设置界面中增加 BigModel 的 API 地址与模型选项
- 在后端增加 BigModel 兼容调用分支
- 对 BigModel 返回结果做必要的解析适配
- 默认模型使用
glm-5-turbo
兼容性
- 不修改现有默认 Provider
- 不改变 OpenAI / Azure 的现有行为
- 仅在用户主动选择
BigModel 时启用对应逻辑
方案设计 & 实现步骤
这个需求已经在我自己的fork feat/bigmodel-support,并单元测试通过、在CentOS 8 Linux amd64平台测试通过、API测试通过。
由Codex + GPT 5.4完成,人工review。
默认给openai写的prompt效果很差,因此BigModel模型使用了一套中文的、更清晰的prompt
同时,看到有RFC已经提到 #1009 开放OpenAI协议的完全自定义模型,所以我的fork对openai.py做了一个比较大的变动,将OpenAI协议的LLM实现直接抽象出来,把当前openai和azure的耦合拆开,模型供应商用profile去做,让预置其它家OpenAI协议兼容的模型变得更容易,未来前端稍作修改之后,可以按照这个RFC设想的目标,完全放开、自由填写。(仅测试BigModel,未测试openai和Azure,因为我没他们家apikey)
替代方案 & 对比
No response
背景 or 问题
背景
我用智谱GLM-5来完成日常的AI活动。
AutoBangumi已经实现openai,智谱支持OpenAI协议兼容接入,所以接入难度应该比较低,token不用白不用
希望确认
根据
CONTRIBUTING.md,该功能应该提交到3.2-dev?目标 & 方案简述
目标
为 LLM 解析功能增加
BigModelProvider 支持,并保持现有 OpenAI / Azure 配置与默认行为不变。方案概述
计划增加以下能力:
BigModel作为可选 Provider 类型glm-5-turbo兼容性
BigModel时启用对应逻辑方案设计 & 实现步骤
这个需求已经在我自己的fork feat/bigmodel-support,并单元测试通过、在CentOS 8 Linux amd64平台测试通过、API测试通过。
由Codex + GPT 5.4完成,人工review。
默认给openai写的prompt效果很差,因此BigModel模型使用了一套中文的、更清晰的prompt
同时,看到有RFC已经提到 #1009 开放OpenAI协议的完全自定义模型,所以我的fork对openai.py做了一个比较大的变动,将OpenAI协议的LLM实现直接抽象出来,把当前openai和azure的耦合拆开,模型供应商用profile去做,让预置其它家OpenAI协议兼容的模型变得更容易,未来前端稍作修改之后,可以按照这个RFC设想的目标,完全放开、自由填写。(仅测试BigModel,未测试openai和Azure,因为我没他们家apikey)
替代方案 & 对比
No response