我遇到一个挺隐蔽的 bug

**现象：**

用 buildingai 接了 new-api 中转站，GPT 模型一对话就报错：

```
Item with id 'msg_06ce50bb8a7fc23f0069df2faa6c3081968ac1346e468123b0' not found.
```

页面提示 `openai_error` 或者 `chat error`，流式输出直接断掉。

**排查过程：**

- 换了三个不同的 new-api 中转站，同一个报错
- 在密钥管理那边走"自定义"模板，填 baseURL 和 API key，一样炸
- 关掉记忆功能、关掉联网搜索，该报的还是报
- 同一个中转站，Claude 和 Gemini 完全没事，就 GPT 模型不行

**定位：**

翻了源码发现，请求打到的全是 `/v1/responses`。new-api 对 Responses API 的 `previous_response_id`（`msg_xxx` 格式的内部 ID）处理不了，甩回来一句 not found。

---

## 我的解决过程

排查到 buildingai 的 `openai` provider 在 `packages/@buildingai/ai-sdk/src/providers/openai/index.ts` 里，`languageModel()` 内部调的是 `@ai-sdk/openai` 的 `provider.languageModel()`。这个 SDK v3 把 `languageModel()` 绑死了 `/v1/responses`。改成 `provider.chat()` 就走 `/v1/chat/completions` 了。就一行：

```javascript
// 改前
return this.baseProvider.languageModel(modelId);
// 改后
return this.baseProvider.chat(modelId);
```

更乌龙的是后来我发现，把提供商名字从 `openai` 改成了一个瞎编的 `openai-1`，就不报错了。回头看 registry 源码，没有 `openai-1` 这个名字，系统查不到就 fallback 到了 `custom` provider。`custom` 内部用的是 `createOpenAICompatible`，走 `/v1/chat/completions`，new-api 完美兼容。正经叫 `openai` 反而炸，起个野名字倒能用了。

这也解释了我切多个中转站都报一样错的原因——不是中转站的问题，是 buildingai 把所有 `openai` provider 的请求全往 `/v1/responses` 上发。

---

## 建议：能不能参考 Cherry Studio 的做法

Cherry Studio 加提供商的时候直接让你选类型：OpenAI、OpenAI-Response、Gemini、Anthropic、Azure OpenAI、New API、CherryIN、Ollama 等。用户不用管底层是什么协议，选对应的就行。用中转的选 New API，用官方的选 OpenAI，用新特性的选 OpenAI-Response，互不干扰。

buildingai 这边 provider 类型全是内置写死的，不管后端挂的是官方还是中转站，选了 `openai` 就一律走 Responses API。走"自定义"密钥模板也没用，底层调的还是同一个逻辑。现实是挂 new-api / one-api 中转站的人真不少，如果能借鉴一下 Cherry 的粒度：

| 提供商类型 | 底层接口 | 适用场景 |
|---|---|---|
| OpenAI | `/v1/chat/completions` | 直连或中转，通用兼容 |
| OpenAI-Response | `/v1/responses` | 官方 OpenAI，走新特性 |
| New API | `/v1/chat/completions` | new-api / one-api 中转站 |
| Ollama | `/v1/chat/completions` | 本地模型 |

核心就一句话：别让用户猜底层是什么协议，把协议亮出来当可选项。Cherry Studio 这套分类已经跑通了，直接参考就行。

GVP BidingCC / BuildingAI

内容风险标识

评论 (1)

GVPBidingCC / BuildingAI

内容风险标识