[开源推广] Octopus 更新,API聚合网关,让你的 Agent 再也不会由于API的问题中止,再也不用发送继续!

bestrui 2026-08-17 16:40 1

本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：

我的帖子已经打上开源推广标签： 是

我的开源项目完整开源，无未开源部分： 是

我的开源项目已链接认可 LINUX DO 社区： 是

我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是

以上选择我承诺是永久有效的，接受社区和佬友监督： 是

以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出

这次重构真的是一个很大的重构,上次和佬友们讨论了一下

这个项目搁置了一段时间,最近开始重新捡起来了,经过这么长时间的沉淀,有些想法想和佬友们讨论一下,其实很久之前就想发个帖子了
主要是项目的定位问题
^-^
个人想法以及一些吐槽
目前我自己是这样想的:

重构日志,改为请求实时可视化,另外日志不再保存到数据库
保持单机部署,目前的分发功能是想直接删了的,目标就是给自己个人一个用户使用的,真的需要分发的话newapi就是一个很好的选择
各种官方的 oa…

对项目的定位目标做了一些调整

举个真实的场景例子

codex 接入octopus后进行对话

codex显示 working

此时octopus日志端就会推送一条日志

点击日志后显示重试请求详情,此时octopus会拦截所有的错误,不会返回给codex,codex仍在等待

手动选择渠道后,渠道正常响应,透传或者协议转换后发送给codex

也就是说整个请求链路都是可视化的,任何错误信息都会被octopus拦截,并且不会传给codex,codex不会因为上游错误而中止,再也不需要发送继续了

下面是本次更新的具体信息:

删除了以下功能:

embedded 等接口,仅保留了 /chat/completions /responses /messages

单渠道多KEY,多URL

各种故障转移策略

日志储存到数据库

重构优化了:

日志

删除了保存到数据库的功能,之前有反馈说日志会导致数据库文件爆炸,后面考虑了历史日志对于本项目的定位来说没有用,而且之前的设计也不支持查询历史日志,没有实际意义

请求到达时立即显示一条日志,点击日志后可以查看实时请求状态,并可以快速切换渠道

故障转移

之前的故障转移还有各个别的网关软件我都看到很多人都在吐槽故障转移不好用,所以本次直接删了,改为手动切换,不会出现自动切换渠道时掉缓存的问题 (解决不了问题,那就解决问题的功能)

协议转换

不同协议之间的转换直接使用的 axonhub

新增了透传,同协议下默认走透传,不会出现各种奇怪的工具调用

前端

优化性能页面之间的切换应该流畅多了

日志页面秒开,不会等很久了

地址:

最新回复 (19)

fooyao 08-17 16:42

1楼

这个拦截功能，稍微改一下，用来破限刚刚的
shengmingboai 08-17 16:44

2楼

窝趣，更新了一直在用的工具，UI无敌好看
fengchris 08-17 16:44

3楼

真的是诈尸了好久没更新了都转战其他fork版了

之前有个bug是即使有回复也显示context cancled 好像是回复的格式不标准导致的
Paulwalker 08-17 16:44

4楼

正好需要
Ryayn 08-17 16:47

5楼

^-^希望其余newapi suib2api迅速借鉴
Lieben 08-17 16:49

6楼

虽然佬一直不更新，但我一直在好好用，周围朋友也在用。好纠结，现在到底是停下所有任务更新好呢，还是等所有任务完成在更新好呢。
Lieben 08-17 16:50

7楼

但是故障转移功能是我最喜欢的功能。我用的真的好顺啊，啊啊啊啊
moShang 08-17 16:51

8楼

any是不是也可以不停地重试一直到接入为止 ^-^
bestrui 楼主 08-17 16:53

9楼

等我再沉淀一下个人能力后续再加上吧,目前的故障转移真的不好做,渠道切换恢复冷却,健康检查,东西太多了

切的快会丢缓存,切的慢会被抱怨响应慢 ^-^
bestrui 楼主 08-17 16:55

10楼

现在同协议直接透传了,请求体,请求体,响应体,响应头这几个octopus仅只读做统计,不做任何修改,应该不会出现这种问题了
Sienna Smith 08-17 16:56

11楼

感谢分享！

最近需要多api key轮换时每个key 都能通过不同的 socks5 代理使用，相当于一个 key 当做多个key 来用，所有 key 轮换一遍也就是乘了一个 socks5 代理服务器的倍数。
fengchris 08-17 16:57

12楼

老的数据库会自动迁移么不然又得全部重新输一遍 ^-^
bestrui 楼主 08-17 16:59

13楼

会的,如果有使用单渠道多URL多KEY的话还是自己备份一遍,别的功能影响不大
Dreams 08-17 17:12

14楼

好了没问题了我docker容器的网络问题修复了
bestrui 楼主 08-17 17:19

15楼

别加v1,另外 i/o timeout 这个是你得加个代理,你这个API能直连吗?
半岛铁盒 08-17 17:26

16楼

删除渠道功能好像有bug，我想删一个渠道点了没反应
Hertz9409 08-17 17:33

17楼

佬，刚刚更新体验了一下，日志这块感觉可以再优化下。

1.加个处理中的日志的过滤

2.点开日志后，已经关闭的渠道可以过滤掉

3.故障转移的功能去掉了，日志这个可以考虑加一个自动轮询开关，渠道失败几次（和设置中的熔断器配置对上）后自动跳下一个，这样也省的手动点切换了

4.当前日志记录下每个渠道重试了几次最好能显示出来
bestrui 楼主 08-17 17:46

18楼

F12 截图看一下请求响应

加个处理中的日志的过滤

故障转移的功能去掉了，日志这个可以考虑加一个自动轮询开关

暂时不会加自动的功能了,不太好加

熔断器配置

这个是没删干净,下一版我删掉

当前日志记录下每个渠道重试了几次最好能显示出来

现在有显示啊
小飞侠 08-17 17:52

19楼

希望故障转移能早点强势回归,毕竟大部分情况用的是中转站,而中转站可以说95%的概率无法保持长期稳定,一般都要同时使用好几个才行,故障转移很有必要. 另外不知道透传是不是能做到只更改了请求地址和api-key其他都保持不变-主要有些中转站要求比较严怕万一相比从cli终端发出去的多了一些其他的可能就被判违规使用了. 感谢佬的项目,其实我自己也一直想弄个完全透传+错误自动重试+故障自动转移降级的适用于cc/codex这些的