[RFC] 041 - 多模型服务商三期: 二线 Providers 支持 / OpenAI Compatible 模型服务商 #2040
arvinxx
started this conversation in
RFC | 特性开发
Replies: 2 comments
This comment has been hidden.
This comment has been hidden.
-
Agent Runtime 抽包为独立模块将暂时在后续 RFC 中单独实现 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
在 #737 上线后,我们在短短 2 个月内完成了 10+ 模型服务商的支持! 这完全仰仗了社区诸多小伙伴的努力,才让 LobeChat 在这么短的时间内就快速完成了这么多 Provider 的支持,非常感谢~
根据之前预判的节奏,过去两个月相当于做了整个二期的工作:
等 6 月会计划开始做多模型服务商的三期,在此先把 RFC 写了,和大家一同探讨一下接下来要做的事情。
背景
二线 Provider
虽然主流的 10+ providers 已经足够 80% 的场景使用。 但是目前仍然有不少 Provider 由于其神奇脑回路的 API 设计,没法低成本接入。
例如:
而本期就需要找到参考实现,将它们集成进 LobeChat 中(视成本,可能会考虑仅在 Cloud 版中提供)。
OpenAI Compatible 模型服务商
其实现在的主流趋势还是很明显的,大家都在往 OpenAI 接口兼容方向做,因此提供一个添加自定义 OpenAI 兼容服务商的需求就会比较强烈。
完整集成链路代码优化
在 #1916 里已经初步完成了一轮代码简化,目前 provider 的开发已经无需感知 token 传递、providerConfig 的独立实现等相对细节的问题,但是仍然存在需要自定义 RuntimeError 、 error message 等问题,这需要进一步精简代码实现,理论上所有的 RuntimeError 应该可以抽象为精简的几类,这样无需再做没必要的扩展。
Agent Runtime 抽包为独立模块
等知识库部分做完,到时候应该就能相对完善得总结出来一个 agent runtime 需要提供的方法了,到时候就可以把 Agent Runtime 的标准方法定义出来。并将现在的包抽取成一个独立的
npm
模块,供社区在其他业务场景下使用。Model Card 在产品中更细节的应用
比如 max_token
Beta Was this translation helpful? Give feedback.
All reactions