[RFC] 054 - OpenAI Compatible Runtime 兼容不同 Stream 提取模式

[arvinxx]

背景

Minimax 和 Spark 是两个比较奇葩的provider 实现。他们的接口虽然兼容了 OpenAI 的格式，但他们的抛错不是直接 throw 错误码，而是在 stream 中输出错误状态。

Spark:

[stream start] 2024-7-29 13:44:7.188
[chunk 0] 2024-7-29 13:44:7.192
{"code":11200,"message":"AppIdNoAuthError:(13:44:07.207) domain.general","sid":"cha000b44cb@dx190fd047923b8f3532","id":"cha000b44cb@dx190fd047923b8f3532","created":1722231847}

目前 OpenAI Compatible Factory 并不支持 自定义 Stream 模块的提取逻辑，因此使得 Minimax 的 provider 是拷贝了代码重写的：
#2087

但单纯为了一个错误状态而重新写一个 Provider Runtime 实现明显不优雅。因此这个 RFC 对 OpenAI Compatible Runtime 需要提供的扩展点做一个通盘梳理，基于此来实现 Spark 的错误处理，并重构 Minimax 实现。

思路

基于 插件四期 中的实现思路，我们目前已经具备了修改 Stream 的能力，因此只需要提供 Stream 的扩展点，使得其他 Provider 可以扩展 stream chunk 的提取逻辑即可。

进展

• 基于 Spark PR 改造 OpenAI Compatible Factory ✨ feat: Add Spark model provider #3098
• 重构 minimax provider 实现

[hezhijie0327]

Spark function call result:

{"code":0,"message":"Success","sid":"cha000b2c83@dx1911d28ea7fb8f3532","choices":[{"message":{"role":"assistant","content":"","tool_calls":{"type":"function","function":{"arguments":"","name":"clock-time____getCurrentTime____standalone"}}},"index":0}],"usage":{"prompt_tokens":58,"completion_tokens":0,"total_tokens":58}}

Route: [spark] AgentRuntimeError: {
  cause: undefined,
  message: 'e.message.tool_calls?.map is not a function',
  name: 'TypeError',
  stack: 'TypeError: e.message.tool_calls?.map is not a function\n    at /app/.next/server/edge-chunks/719.js:9:1429\n    at Array.map (<anonymous>)\n    at Object.start (/app/.next/server/edge-chunks/719.js:9:1334)\n    at setupReadableStreamDefaultController (node:internal/webstreams/readablestream:2435:23)\n    at setupReadableStreamDefaultControllerFromSource (node:internal/webstreams/readablestream:2467:3)\n    at new ReadableStream (node:internal/webstreams/readablestream:278:7)\n    at U (/app/.next/server/edge-chunks/719.js:9:1280)\n    at Object.chat (/app/.next/server/edge-chunks/719.js:9:2777)\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n    at async /app/.next/server/app/api/chat/[provider]/route.js:1:1428'
}

[arvinxx]

离谱啊，这个 tool_calls 居然是个对象而不是数组…

[hezhijie0327]

讯飞那边反馈了下，说是会去改 但是具体啥时候处理就不清楚了... 哎 已经帮他们至少抓了两三个 BUG 了...

[arvinxx]

@hezhijie0327 哎，那他们抛错的逻辑会改吗？别到时候重构完他们又对齐到 OpenAI 的方案了😅

[hezhijie0327]

之前提过，被他们换了个话题，跑偏到他们 user 参数不支持上去了，但是把离谱的是只有免费的 general 模型有着问题，其他模型支持说是隐藏特性待开发的预留参数

最近看到他们官网已经放着 OpenAI SDK 的 demo 了，我要么去开个 case 看看？反正我刚刚试了下抛错的逻辑暂时没改
https://www.xfyun.cn/doc/spark/HTTP%E8%B0%83%E7%94%A8%E6%96%87%E6%A1%A3.html#_7-%E4%BD%BF%E7%94%A8openai-sdk%E8%AF%B7%E6%B1%82%E7%A4%BA%E4%BE%8B