碎碎念
这次依旧是咕咕了一个月！不知不觉立秋了啊，有没有喝秋天的第一杯奶茶啊~
虽然没有更新文章，但是我也不是纯玩！首先在工作上，由于成为了牛马，每到月末或者下个月初，都需要发布版本迭代产品，所以总会遇到一些非常复杂的问题。比如我的同事，这个周末直接加了两天班，看得我心电图都一停一停的。。。
除了工作，当然还有一部分个人时间啦~
七月月初，看到了青桔哥哥自己开发的青桔认证，再瞅了瞅我的Casdoor，顿时满满的嫌弃，于是我也打算自己重写一个！刚开始的时候，我是打算基于Casdoor进行剪枝，重写前端，来达到自己想要的效果。经过仔细研究代码后发现，这个项目其实并不是特别适合我，整体结构有些难以理解，光熟悉代码可能都需要耗费大量时间。
于是我干脆从头开始写，只需要后续将数据迁移过去就可以啦！不过真正开始写之后才发现，这玩意怎么这么麻烦啊。。。单论各种协议暂且不谈，光是登录校验、多层次用户体系这些东西，就已经给我整得力竭了，更别提我还没有打算实现多组织功能。
期间不止一次想过放弃，毕竟现在的方案其实也不是不能用🤪
不过最终还是坚持把它重写了，实际上嘛，就是钱的问题嘻嘻。一个月时间，消费了 100 余元，最终实现了一个可用版本。目前功能基本没有什么问题，并且也基本实现了用户无感迁移，包括第三方登录、账号密码登录等功能。
本站链接 · 来自本站，本站可确保其安全性，请放心点击跳转清羽通行证LiuShen's Blog欢迎大家来测试bug！当前已经接入所有有关本站认证的系统，后续也会上一些公众服务，并接入当前认证系统！敬请期待啦！
回到正题，在前面几个月期间，我也是用了近千的Token了。有一个小问题一直让我感觉非常烦：每当遇到API出问题时，只能等待程序自己重试。如果长时间无法成功，最终就会直接报错，需要解决服务端的问题后，手动点击继续，非常影响体验。
特别是对于晚上开启/goal模式的用户来说，对于API的SLA有着比较高的要求。一旦程序停止运行，可能一整晚的任务都会直接停摆，只能第二天起来重新点击继续，属实有点折磨。同时，在CCSwitch中切换API也需要重启程序才能生效，无法做到热切换，这也是一个比较明显的痛点。针对这个问题，我寻找了很多解决方案，但是很多方案并不是特别理想。并不是说这些程序不好，只能说术业有专攻。
最终，我选择了AxonHub，这篇文章将介绍我对于此类程序的探索过程，以及AxonHub的一些优点和食用方式！
探索记录
实际上刚开始的时候，我第一时间测试的就是 AxonHub，但是由于初次接触时，感觉整体配置稍微有些复杂，其中组织、项目、用户、角色、权限、配置等一系列概念一股脑地摆在面前，让我一时间有点眼花缭乱，所以暂时放弃了继续深入研究，转而尝试了一些其他项目。
不过经过一圈体验下来，最终这些项目都没有被我采用。这里需要提前说明一下，并不是说这些项目本身不优秀，实际上每个项目都有自己的设计理念和适用场景，只是在我的使用需求下，有些功能并不是特别匹配。毕竟这类聚合/中转项目，本身侧重点都有所不同，有的偏向简单代理，有的偏向企业级管理，有的则更注重模型调度和流量控制，很难单纯地评价谁一定更好。
所以本文后续对于这些项目的介绍和对比，更多是基于我个人实际使用过程中的体验，以及在个人场景下的选择，并不代表绝对的优劣。如果你的使用场景不同，可能最终的选择也会完全不同。
疯狂叠甲！
感谢朋友送的一台2-2香港机器，搭建中转站用的很快乐，速度也很快！在此推荐一下对应的厂商吧~
PS: 虽然小厂服务器很便宜，性能相应的也会比大厂的强一些，但是稳定性可能会稍差，注意理性消费，按需付费，养成异地备份的习惯哦~
NewAPI
首先登场的就是我们耳熟能详的NewAPI，相信大家对于这位元老级项目并不陌生。作为大模型聚合类项目中的代表之一，它凭借着较早的出现时间以及完善的功能体系，占据了目前市场中相当大的使用比例。很多中转站站长都会选择基于NewAPI搭建自己的 API 服务，用于个人使用或者商业化运营。
NewAPI最大的特点就是完善的企业级能力，包括多用户管理、充值系统、渠道管理以及完整的后台运营能力等。通过这些功能，即使没有太多开发经验，也可以快速搭建一个具备商业化能力的 API 中转服务。
在功能方面，NewAPI内置了丰富的模型支持以及大量默认接入方式，同时支持多种模型渠道管理。除此之外，还支持通过OAuth接入Codex（虽然听说体验还有一些提升空间），后台也可以对接现成的收费系统、兑换码系统，并支持周订阅、月订阅等不同计费模式。同时针对不同时间窗口，还可以进行频率限制，整体功能覆盖范围非常全面。
NewAPI的界面设计也相当不错，整体布局清晰，功能分类合理。我个人尤其喜欢新版的UI设计，相比早期版本有了明显提升，整体观感更加现代化。甚至到了现在，虽然我已经不再主要使用它，但依然保留了一个站点。
人无完人，金无足赤。NewAPI虽然功能强大，但在实际使用过程中也存在一些不足。
其中比较明显的一点就是渠道之间的调度能力相对薄弱，不同渠道之间的负载分配、优先级控制等能力并不算突出，目前比较实用的可能主要还是亲和性调度，但是能力也有限，只能保证尽可能的提高命中率。这也导致NewAPI更偏向于企业化运营场景，对于单纯希望实现多 API 聚合、自动切换的个人用户来说，可能并不是最优选择。
哦对，最后附上一下我自己使用的NewAPI自定义主页模板。虽然这份代码同样也是 AI 辅助生成的，不过经过多次调整和优化后，我个人觉得整体效果还是比较清爽的，同时也适配了响应式布局以及暗色模式。
如果你也在使用NewAPI，或者单纯想美化一下自己的首页，欢迎直接拿去魔改使用！
Sub2API
说到这个，就不得不提一下传奇 Codex 了。感谢奥特曼，让我们用上了相对平价的token，而 Sub2API 这个项目，就是专门用于将通过OAuth登录的订阅转换成可以直接通过API调用的Token。
这样一来，就极大方便了将自己的订阅接入到各种程序中使用，也让多人共享一个订阅成为可能（虽然现在更多的是滥用）。例如，多个人共同订阅一个Pro，整体成本会比直接购买多个账号低不少，同时一些试用中的Plus账号也可以通过该项目进行接入。
因此，目前市面上的 AI API 中转方案中，除了大量使用NewAPI的用户外，另一大类就是基于Sub2API搭建的方案。
这个项目实际上我自己并没有部署，不过我的朋友使用当前项目搭建了一套服务，并且接入了众多API，平时我也一直在使用，整体体验还是非常不错的，所以这里就拿他的实例来展示一下。
首先就是用户侧的仪表盘：
相比于NewAPI，Sub2API舍弃了一些偏企业运营方向的功能，例如模型广场、多渠道管理等，也没有复杂的渠道调度体系。
但是，它在OAuth认证方面有着非常明显的优势。对于Codex等需要账号认证的场景来说，Sub2API的接入体验更加完善，账号稳定性也相对更高。根据朋友的实际使用反馈，在部分场景下，其请求命中率也会比其他方案更优秀一些。
当然，缺点也同样明显，首先就是调度能力相对不足。Sub2API虽然支持账号之间的一定程度重试，但是主要还是基于请求失败后的补偿机制，并不能根据实时负载情况进行动态调度，也无法真正做到负载均衡。
这也是我最终没有选择部署它的主要原因。对于我来说，我并不太需要一套非常完善的OAuth账号管理体系，我更关注的是如何将多个第三方渠道进行统一接入，并根据实际情况进行调度。而这一点，恰好是Sub2API相对薄弱的地方，甚至在这方面相比NewAPI也没有明显优势。
不过，如果将Sub2API和NewAPI结合起来，我认为这会是一个非常完善的中转方案。一个负责OAuth认证、账号管理以及多账号重试，一个负责渠道管理、模型聚合以及商业化能力，二者结合后，除了中间缺少一层更加智能的调度系统外，在OAuth认证、优雅的模型广场、美观的用户前台、多样化订阅方案等方面，基本已经覆盖了一个成熟中转站所需要的大部分能力。
所以如果你的目标是搭建一个面向用户的 AI API 中转服务，并且需要接入账号池，那么Sub2API和NewAPI的组合方案，依然是一个非常值得考虑的选择，不过对于我个人而言，Sub2API依旧不是最终答案。毕竟它针对商业化场景优化的很多功能，并不是我的实际需求。
那么，继续看看下一个项目吧！
MetaPI
其他类似的中转程序我也懒得继续看了，上面两个基本已经覆盖了目前大部分中转站的基础需求。至于市面上比它们更加优秀的方案，基本上都是各家自己研发的哩~所以这里介绍一个稍微“歪门邪道”的方案——MetaPI。
严格来说，MetaPI并不是一个用于搭建中转站的程序，而是一个“汇聚其他中转站的中转站”（懵了吧嘻嘻）。具体来说，由于目前市面上大量中转站都是基于NewAPI、Sub2API等框架搭建，这些程序本身都有比较完善的API接口。但是，当你拥有越来越多的中转站账号后，新的问题也随之出现：站点太多，管理起来非常麻烦，时间一长，不仅容易忘记某些站点的存在，甚至还会出现余额长期闲置，最后默默躺在某个角落吃灰的情况。
而MetaPI正是为了解决这个问题而诞生的，它通过对接NewAPI等中转程序的接口，实现了签到、签发API Key、检查模型价格、切换分组等功能，将多个站点的余额统一汇聚到一个入口进行管理；同时，它还对这些接口进行了进一步整合，让一个API Key就可以灵活调用多个上游中转站，并且可以在站点内部手动或者定时自动执行签到操作，最大程度减少人工管理成本。
tmd谁给官方DEMO站点的密码改了啊！！！！！
在功能方面，MetaPI的完成度其实相当不错。
它支持统一代理网关，兼容OAI和A\接口，同时支持多种接口类型，甚至包括嵌入模型的Embeddings接口。除此之外，还支持完整的SSE流式传输，并且可以基于上游站点自动发现可用模型，零配置生成路由表。
在调度方面，MetaPI也加入了一些比较实用的机制，例如根据成本、余额、使用率等因素进行加权分配通道负载，同时支持失败通道冷却避让。这一点相比前面介绍的两个项目，确实有着比较明显的优势。
不过，MetaPI的问题也同样明显。由于它希望覆盖的功能非常全面，导致整体功能比较复杂，配置起来也容易让人感觉繁琐。很多配置项单独看起来并没有问题，但是实际组合使用时，经常会出现多层嵌套的情况，对于想要保持配置简洁的人来说，学习成本确实不低。
另外，由于项目功能较多，维护压力也会相应增加，目前社区反馈中也存在一些待解决的问题，因此现阶段我个人并不是特别推荐直接用于生产环境。
当然，抛开维护情况不谈，我自己其实也部署体验了一下。实际配置过程中，确实有一种“功能很多，但是不知道某个功能到底应该在哪里配置”的感觉。对于代码洁癖患者来说，看到大量暂时用不到的配置项，以及层层嵌套的配置关系，多少会有一点难受，所以我个人测试了一下午之后，最终还是逐渐放弃了这个方案。
并不是说MetaPI不好，实际上它的一些设计思路非常优秀，尤其是多站点聚合和智能调度，其实我一直想找个能简单的定时签到的程序，只是对于我的使用场景来说，它解决的问题并不是我当前最需要的，因此，丢掉！
AxonHub
最后就来到了重头戏，AxonHub！
正如它的名字一样，All-in-One AI，对于个人使用场景来说，这是我目前体验过最好用的程序，没有之一。当然，这里特指个人场景。
虽然AxonHub也提供了一些企业级功能适配，但是它并没有像NewAPI一样针对商业化运营进行优化。例如订阅系统、模型广场、充值系统等功能都没有提供，目前更多的是围绕用户请求管理、模型调用以及渠道调度展开。
这其实也是一种取舍，毕竟功能越多，系统复杂度也会随之提升，而AxonHub选择将重点放在了AI调度和开发体验上，这和上面的NewAPI和Sub2API是完全不同的一条路。
虽然定位偏向个人使用，但是前面也提到了，AxonHub依然具备一定的企业级能力，例如多用户、角色、项目等功能。对于个人用户来说，初次配置时可能会感觉稍微有一点复杂，但是熟悉之后并不会影响日常使用。
而真正让我选择它的核心原因，还是它在模型调度方面的能力。在模型页面中，可以非常简单地配置不同渠道的优先级，如下：
针对每个模型不同的优先级，也可以设置对应的调度策略，例如自适应、模型熔断、故障迁移等。
它会根据模型配置的权重，从高优先级渠道开始逐一尝试。如果当前渠道请求失败，则自动切换到下一个渠道进行重试，直到请求成功。整个过程对于用户来说是无感的，不会暴露中间的重试过程，这一点体验非常优秀。
在自适应策略下，它并不会简单地进行轮询或者平均分配负载。
比如我这里按照成本进行排序，那么它会优先尝试低成本渠道，如果当前渠道可用，就会暂时保持对该渠道的使用，并在一段时间后重新检测更低成本的渠道。
这样既可以保证较高的缓存命中率，又可以尽可能降低调用成本，这种调度逻辑对于AI API来说非常实用。
以前使用其他API时，经常会遇到空返回的情况（特别是鱼鱼有一段时间给程序改炸了）。这种情况比较麻烦，因为请求本身可能被判定为成功，导致程序不断进行重试、打断，再重试、再打断，最终直接让任务停摆。
而在AxonHub中，遇到类似的空返回请求时，会自动识别并进行重试，而不是直接将异常结果返回给用户。同时，这些情况也会参与后续渠道权重计算，让系统能够逐渐避开不稳定的渠道，这一点非常人性化。
由于AxonHub主要面向个人以及开发者场景，因此它支持保存用户请求记录，方便在出现异常时进行问题复盘。
不过这里需要注意一下，请求记录不要保存太长时间，曾经我就因为这个功能，把服务器磁盘直接打爆了一次。。。
目前唯一让我感觉稍微不太舒服的一点，就是价格配置。
AxonHub无法直接同步上游已有的模型价格，需要手动填写。虽然内部提供了一些默认数据，但是覆盖范围感觉还不是特别完整，例如codex-auto-review这类模型的价格目前就无法自动获取，多少会影响一点使用体验。
不过这些都属于细节问题，对于一个主要解决调度问题的程序来说，基础能力做好其实更加重要。
在协议支持方面，AxonHub的覆盖范围也非常全面，无论是Claude Code还是Codex，都可以轻松接入。同时，它还支持一些比较小众的协议，比如哈基米协议。
虽然这些协议可能使用场景并不大，但是嘛，我可以不用，但是不能没有！
OK，这一节我们主要介绍了AxonHub的功能特点，下面再来介绍一下项目具体的使用以及部署方式吧！
部署教程
上面简单介绍了AxonHub的功能，那么下面就正式开始部署吧！
顺便提一嘴，前面没有选择Sub2API的原因之一，就是它的配置流程对我来说还是有点复杂。我个人一直都不太喜欢纯文本配置文件，相比之下，更偏爱可视化操作，甚至有时候连Docker Compose都懒得写（笑）。
所以这一节我会介绍两种部署方案：一种是使用Docker Compose快速拉起，另一种则是依赖1Panel应用商店进行可视化安装，大家按自己的习惯选择即可。
Docker
首先就是最简单的Docker部署。
这里不推荐直接使用docker run命令，虽然能够启动，但是后续维护、升级都会相对麻烦，因此更推荐使用Docker Compose进行管理。
# 克隆项目
git clone https://github.com/looplj/axonhub.git
cd axonhub
# 设置环境变量
export AXONHUB_DB_DIALECT="tidb"
export AXONHUB_DB_DSN="<USER>.root:<PASSWORD>@tcp(gateway01.us-west-2.prod.aws.tidbcloud.com:4000)/axonhub?tls=true&parseTime=true&multiStatements=true&charset=utf8mb4"
# 启动服务
docker-compose up -d
# 查看状态
docker-compose ps至于为什么需要先克隆仓库，是因为启动时依赖项目中的配置文件，所以不能直接拉取镜像启动。
配置文件如下：
站外引用 · 引用站外地址，不保证站点的可用性和安全性AxonHub 配置文件github.com@looplj启动完成之后直接访问即可，至于具体的配置和使用方法，我们放到下一章节再详细介绍。
1Panel
除了直接使用Docker Compose之外，还可以选择通过1Panel进行安装。
不过目前1Panel官方应用商店还没有收录AxonHub，所以这里需要借助第三方应用商店。
这里我自己维护了一份仓库，欢迎大家使用：
站外引用 · 引用站外地址，不保证站点的可用性和安全性AppStore: 🌭清羽飞扬自建非官方第三方1Panel应用仓库github.com@willow-god仓库中其实已经包含了比较完善的安装说明，不过这里还是再介绍一遍。后续网站里的其他部署文章也会直接引用这一套流程，就不用每次都重新写啦。
定时更新
1Panel应用商店本质上是读取本地应用目录，因此需要定期从远程仓库同步最新内容。
我的仓库提供了两种同步方式：一种是同步全部应用，另一种是仅同步指定应用。
如果没有特殊需求，我更加推荐使用完整同步，后续维护起来也会更加方便。
首先是完整同步脚本：
#!/bin/bash
set -euo pipefail
IFS=$'\n\t'
GIT_REPO="https://cnb.cool/Liiiu/appstore"
TMP_DIR="/opt/1panel/resource/apps/local/appstore-localApps"
LOCAL_APPS_DIR="/opt/1panel/resource/apps/local"
trap 'rm -rf "$TMP_DIR"' EXIT
echo "📥 Cloning appstore repo..."
[ -d "$TMP_DIR" ] && rm -rf "$TMP_DIR"
git clone "$GIT_REPO" "$TMP_DIR"
echo "🔄 Mirroring apps..."
cd "$TMP_DIR"
if [[ -f ./mirror.sh ]]; then
chmod +x ./mirror.sh
./mirror.sh
else
echo "⚠️ mirror.sh not found, skipping mirroring"
fi
cd -
mkdir -p "$LOCAL_APPS_DIR"
for app_path in "$TMP_DIR/apps/"*; do
[ -d "$app_path" ] || continue
app_name=$(basename "$app_path")
local_app_path="$LOCAL_APPS_DIR/$app_name"
echo "🔁 Updating app: $app_name"
[ -d "$local_app_path" ] && rm -rf "$local_app_path"
cp -r "$app_path" "$local_app_path"
done
echo "✅ Sync completed."将脚本添加到1Panel侧边栏的计划任务中，创建一个Script类型任务即可。我个人习惯设置为每天晚上十点半或者十一点自动执行，基本能够保证应用商店保持最新状态。
手动同步
虽然应用文件可以通过定时任务自动同步，但是同步到1Panel数据库这一步，目前官方还没有提供定时任务接口。虽然我尝试过直接调用接口，不过暂时还没有研究明白，所以目前还是需要大家偶尔手动点击一下”同步本地应用”QAQ
由于计划任务通常不会立即执行，所以第一次建议直接手动运行一次脚本。
脚本执行完成且没有报错之后，打开侧边栏进入应用商店，在”未安装”页面点击”更新本地应用商店”，即可将同步下来的应用加载到应用商店中。
如果一切正常，就能够看到对应的应用了。
如果你不希望将第三方仓库中的所有应用都同步到本地，也可以使用单应用同步脚本。
#!/bin/bash
set -euo pipefail
IFS=$'\n\t'
# ========= 配置：要安装的应用列表 =========
APPS_TO_INSTALL=(
"axonhub-mysql"
)
# ========= 常量 =========
GIT_REPO="https://cnb.cool/Liiiu/appstore"
TMP_DIR="/opt/1panel/resource/apps/local/appstore-localApps"
LOCAL_APPS_DIR="/opt/1panel/resource/apps/local"
trap 'rm -rf "$TMP_DIR"' EXIT
echo "📥 Cloning appstore repo..."
[ -d "$TMP_DIR" ] && rm -rf "$TMP_DIR"
git clone "$GIT_REPO" "$TMP_DIR"
echo "🔄 Running mirror.sh (if exists)..."
cd "$TMP_DIR"
if [[ -f ./mirror.sh ]]; then
chmod +x ./mirror.sh
./mirror.sh || echo "⚠️ mirror.sh 执行失败，继续..."
else
echo "⚠️ mirror.sh not found, skipping mirroring"
fi
cd - >/dev/null
mkdir -p "$LOCAL_APPS_DIR"
# ========= 遍历安装列表 =========
for app_name in "${APPS_TO_INSTALL[@]}"; do
app_path="$TMP_DIR/apps/$app_name"
local_app_path="$LOCAL_APPS_DIR/$app_name"
if [[ ! -d "$app_path" ]]; then
echo "❌ 应用 $app_name 不存在于仓库，跳过"
continue
fi
echo "🔁 Updating app: $app_name"
[ -d "$local_app_path" ] && rm -rf "$local_app_path"
cp -r "$app_path" "$local_app_path"
done
echo "✅ Selected apps sync completed."以上脚本以axonhub-mysql为例，只会同步当前指定的应用。
如果你希望应用商店保持尽可能精简，可以采用这种方式；当然，我个人还是更推荐完整同步，毕竟应用商店里放着一些没安装的应用，对我来说倒也没什么影响。而且我的仓库也会尽量保持与官方仓库存在一定差异，例如提供不同的部署方式，或者收录官方暂未提供的应用。
安装程序
同步完成之后，就可以直接在应用商店中点击安装了。
目前我维护的版本主要提供MySQL部署方案，虽然原仓库同时支持SQLite等方式，但我个人还是更推荐使用一个正经的数据库。虽然对于个人用户来说，性能差距几乎感觉不到，但是后续迁移、维护都会更加方便。
另外，考虑到我自己的使用习惯，我还额外适配了MariaDB，与MySQL保持高度兼容的同时，在资源占用和性能方面也有不错的表现。
有了应用商店之后，剩下的安装流程应该对于冰雪聪明的你来说就不是什么问题啦~
所以下一节，我们就开始讲解AxonHub的具体使用方式。
食用方法
AxonHub虽然整体定位偏向个人使用，但实际上也提供了不少企业级能力，所以初次接触的时候，还是会感觉有一点复杂。不过真正理解了它的设计思路之后，你会发现很多配置其实都是为了后续维护方便，而不是故意增加学习成本。这一节我就按照我自己的使用习惯，介绍一下我是如何配置整个AxonHub的，希望能让大家少踩一些坑。
创建项目
首先进入控制台之后，需要先创建一个项目。
这里的项目可以理解为一个独立的工作空间，我个人目前只有一个项目，所以所有模型、渠道以及规则都放在里面统一管理。如果后续有不同的用途，例如工作、个人，甚至多个团队，也可以创建多个项目进行隔离，这样各自的配置互不影响，管理起来也更加清晰。
添加渠道
接下来就是渠道部分，也就是添加各个厂商或者中转站的位置。
这里有一点我觉得稍微麻烦一些，就是目前无法实时同步不同站点的模型价格，需要自己手动维护。不过转念一想，不同中转程序暴露出来的API都不完全一致，如果为了兼容各种程序而不断增加适配，最终很容易出现功能越来越多，但维护越来越困难的情况。相比之下，我还是更倾向于目前这种相对简单稳定的实现方式。
这里实际上也可以直接配置渠道权重，不过我并不建议这样做。因为随着渠道越来越多，在渠道层维护权重会逐渐变得混乱，后续修改优先级的时候还需要一个一个调整，很容易遗漏。所以我的建议是，这里只负责添加渠道，把所有渠道维护完整即可，真正的调度策略放到后面的开发者规则里面统一管理。
另外，在每个渠道右侧的三个点中，还可以设置模型价格、模型名称映射等配置。如果不同渠道模型名称不一致，或者需要自定义价格统计，都可以在这里完成。我这里就不过多展开了，属于比较基础的配置，大家自己点进去看看基本就明白了。
配置模型
接下来就是整个项目最重要的配置——模型。
仔细观察一下我的配置，你会发现我几乎没有给每个模型单独配置渠道顺序，也没有一个模型维护一套规则。
原因很简单，我把整个渠道优先级全部放到了开发者规则里面统一维护。这样最大的好处就是后续新增模型的时候，不需要重新配置一遍渠道顺序，只需要绑定对应的模型名称即可，大大降低了后续维护成本。
对于模型数量比较多的人来说，这种维护方式会舒服很多，不然几十上百个模型，每次新增或者调整渠道都要修改一次，时间一长真的会改到怀疑人生。
开发者规则
整个配置里面，我认为最重要的其实就是开发者规则。
我这里按照成本、稳定性以及响应速度等几个维度，对所有渠道进行排序，然后按照从低成本到高成本的顺序配置优先级。
注意，这里的数字越小，优先级越高。
开发者规则配置完成之后，后续新增模型就会轻松很多。
我们只需要添加对应模型，并绑定对应的模型ID即可。由于全局优先级已经提前维护好了，所以这里实际上只需要再添加一条”全局精准匹配模型”规则，就能够直接继承整套调度策略，后续即使增加新的渠道，也只需要修改一处地方即可，所有模型都会自动生效。
这里还有一个比较容易踩坑的地方，就是优先级。
AxonHub的设计中，同一个模型如果同时命中了多个优先级，最终会采用优先级最高（数字最小）的那条规则。因此，这里的”全局精准匹配模型”规则，一定要设置一个比开发者规则优先级更低的数字，也就是填写一个更大的数字。
例如我的开发者规则全部都在1~9之间，那么这里直接填写10即可。
如果这里误填成了例如1，那么它就会和开发者规则拥有相同的优先级，最终所有渠道都会失去原本按照成本和稳定性进行调度的能力，基本就会退化成随机选择。所以这一点一定要特别注意，也是我当时折腾了半天才发现的问题。
重试策略
配置完成之后，其实其他地方基本都不用怎么调整了。
虽然左边还有很多配置项，例如追踪线程之类的功能，但是我自己用了几个月，到现在一次都没有真正用到过。所以如果第一次接触，不需要把所有配置全部研究一遍，先把最核心的几个地方配置好，剩下的等以后有需求再慢慢探索即可。
真正值得调整的，我觉得主要还是设置里面的重试策略。
如果你的渠道配置了优先级，那么我比较推荐选择自适应策略。这样它会优先尝试优先级最高的渠道，当请求失败时，再自动切换到后面的渠道，并结合粘性路由，在保证缓存命中率的同时，尽可能减少不同渠道之间的切换次数，这样既能降低成本，也能够保证整体稳定性。
下面的重试次数就按照自己的实际情况来配置即可，不过这里有一个地方需要特别提醒一下，那就是流式首字超时。
如果你的部分渠道响应速度本身就比较慢，那么开启这个配置之后，很容易出现还没来得及返回第一个字，就已经被系统判定为超时，从而不断进行重试，最终反而影响整体体验。所以如果没有特别明确的需求，我个人建议直接留空，不设置会更加省心一些。
请求存储
最后再说一下存储配置。
这里可以选择是否保存请求体和响应体，对于排查问题来说，这个功能还是非常有用的。当某个请求出现异常时，可以直接查看完整请求内容进行复盘，比单纯看日志方便得多。
不过这里也一定要提醒大家一句，如果不是临时排查问题，千万不要长期开启。
曾经我连续开启了一天，请求量大概只有2000次左右，结果直接把服务器30GB的磁盘全部塞满了，喵的当时看到的时候我还以为我被打了。。。。
所以我的建议是，把它当成一个排障工具，而不是日常功能。需要排查的时候打开，用完之后及时关闭，这样既不会占用大量磁盘空间，也能够在真正出现问题的时候发挥作用，另外，注意配置定时清理时间。
剩下的配置其实都比较容易理解，按照自己的使用习惯慢慢调整即可。每个人的渠道数量、预算、模型偏好都不一样，所以最终也没有一套所谓的”标准答案”。多折腾几天，相信足智多谋的你，一定能够配置出一套最适合自己的调度策略！
中转站推荐
这里再推一波一些我正在用的中转站吧，都是我个人打流之后，感觉不错，并且价格也能接受的（0.1以内）一些站点。
本文所有涉及到的推广均没有收费，仅为个人推荐的便宜实用站点，方便组建负载均衡池，请注意自行辨别，本站不对中转站的稳定性做保证。
如果需要免费，建议在LinuxDo上多转转，有很多佬友不定时发福利，可以更低成本的建立起更稳定的API池。
总结
芜湖，这篇文章终于写完啦！
前前后后历时五天，从周天开始，一直写到周四晚上。其实中途也摸了不少鱼，比如修了修博客、迁移了一下服务器，当然，更多的时间还是贡献给了王者（笑）。
上班之后才发现，晚上的时间真的特别珍贵。不想睡觉，也不想起床，睡了的话，晚上的时间就不属于我了；醒了的话，第二天就又得去上班了。现在越来越能理解为什么大家都喜欢熬夜了，虽然知道不好，但总感觉只有深夜那几个小时，才是真正属于自己的时间。
这篇文章主要介绍了AxonHub，目前它已经在我的服务器稳定运行了数月有余，也陪着我一路写完了整个清羽认证服务。虽然期间也踩了不少坑，还有一些小Bug没有完全解决，但是整体已经达到了可以稳定使用的状态。基础的认证、登录、注册、二次验证以及各种授权流程，目前都已经能够正常运行，我个人还是比较满意的。
这也是我第一次几乎完全依赖AI，独立完成一个中大型项目的开发。（十万行代码……应该算中大型了吧🤔）虽然绝大部分代码并不是我亲手写出来的，但是整个架构设计、需求拆分、功能实现、调试、部署以及后续优化，我几乎全程都参与了进去。相比于”写代码”，我更多承担的是产品经理、架构师、测试以及Reviewer的角色，这种开发方式和以前相比完全不一样，但确实让我学到了很多东西。
体验最深的一点就是，目前的AI面对这种规模的项目，实际上还远远做不到完全放手。不要说256K上下文，就算给它1M上下文，如果没有合理地拆分任务、控制上下文以及不断引导方向，它依旧很容易陷入死循环，甚至开始一本正经地胡说八道。所以至少现阶段，我并不认为AI能够完全代替开发者，它更像是一个能力非常强、执行力非常高，但是需要不断引导的搭档。
也正因如此，我一直觉得，AI终归还是用于解放生产力的工具，而不是取代人类的存在。它可以帮你完成大量重复性的工作，可以帮你快速验证想法，也可以帮你补齐很多知识盲区，但真正决定项目方向、架构设计以及最终效果的，依然还是人。
前段时间，我还注意到我司的招聘简章里新增了一项要求：熟练运用AI Agent，理解其底层原理。 后面那句”理解底层原理”可能和我们部门的业务方向有关，但是前半句其实已经很能说明问题了——熟练使用AI，正在逐渐成为一项基础能力，而不是加分项。
所以也不用因为AI的发展而感到焦虑，更不要因此自暴自弃，觉得以后找不到工作了。
AI很强，但它依然缺少很多属于人的东西，例如跳脱性的思维、真正的创造力，以及将不同领域知识联系起来的能力。也许在知识广度上，我们确实很难比得过它，但是在人类最擅长的创新、创造以及解决开放性问题这些方面，我们依然拥有自己的优势。
与其担心被AI替代，不如努力成为那个能够驾驭AI的人。
毕竟，未来真正拉开人与人差距的，也许不是谁会不会写代码，而是谁更懂得如何与AI协作，让它真正成为自己的生产力，而不是反过来被工具牵着走。
每日一图
图片来自哲风壁纸
