newapi-channel-manage#

为什么要做这个#

我在自己的服务器上搭了一个基于 new-api 的 API 聚合站——就是拿 one-api 的 fork 当网关，前面挂一堆上游渠道，统一对外暴露 OpenAI 兼容的 API。

维护这事，改渠道是日常。换 key、调 base_url、加新模型、禁用某个上游——频率不低，每次都要登后台手点。

我就想，能不能让 Agent 帮我干这事。

不美妙的事情#

我没钱用更强性能的模型，所以全程白嫖 workbuddy 里的免费 hy3。

免费的能有什么好货。

• 不知道改哪里：API 文档写得模棱两可，“该传 id 还是 channel_id”这种细节没有
• 改错地方：传错字段名、传错类型、被 server 端默默忽略或者报错
• 格式不匹配：JSON body 嵌套错位、base_url 多带了 /v1、模型名大小写不对

结果就是——改得慢、还可能改到重要的地方。有一次改完发现渠道全废了，回滚又花了一小时。

痛定思痛。

史诗巨作#

花费巨资用 ds v4flash 搓出了这个史诗巨作。

巨资大概就是两块钱一杯的咖啡钱。ds v4flash 性价比不错，配合精心写的 SKILL.md 之后，可以让不聪明的模型也能按照”使用说明书”做到了。

SKILL.md 是给 AI 助手读的。里面是：

• 10 条 gotcha：把 new-api 那些非直观的 API 行为全列出来（登录失败返回 200、PUT 不带 /:id、反代 307 丢 body……）
• 7 步工作流：登录 → 列渠道 → 改 → 实测 → 验证 → 收尾
• 故障排查路径：网关 → 渠道 → 代理层 mihomo → 日志/DB
• 安全约束：密码/token 怎么传、什么时候必须让用户确认

下游的 manage_channel.py 和 healthcheck.py 解决了 gotcha 提到的几个最容易踩的坑——base_url 自动 strip 掉 /v1、登录失败用退出码而不是 HTTP 200 区分、PUT 不带 /:id 走 PATCH 等等。

核心功能#

用法示例#

1
python scripts/manage_channel.py \
2
  http://<server>:3000 \          # 直连端口，绕 caddy 307
3
  root '<管理密码>' \
4
  '<上游key>' \
5
  https://api.example.com \       # 根地址，不要带 /v1
6
  https://gateway.example.com/v1 \
7
  'sk-网关key' \
8
  'Provider/Model-A,Provider/Model-B'

脚本：登录（密码错误不会误判）→ 列渠道 → 同名已存在则跳过（幂等）→ 创建 → 经网关实测首字延迟。

现状#

自己每天在用。自从有了 SKILL.md，免费 hy3 也能干活了——改渠道再也不用我盯着。

偶尔有新 gotcha 我就加进 references/api_notes.md 里。

伟大无需多言。