把 WorkBuddy 多账号池接成 OpenAI 网关（workbuddy2api-hub）

腾讯的 WorkBuddy（国际版）和 CodeBuddy（国内版）按账号发放额度，一个桌面客户端同时只能挂一个号，额度用满，请求便开始失败，得手动切号。把这份额度接进自己的编辑器还会撞上第二道墙：Codex、Claude Code 这类客户端只认 OpenAI 或 Anthropic 的接口形状，原生服务不往里套。

WorkBuddy2API-Hub 是 Python 写的反代网关，把 WorkBuddy 与 CodeBuddy 的账号池转成 OpenAI 兼容接口，供 Codex、Claude Code 等客户端调用。

这个位置上还有别的选择。qoder2api-hub 做同一件事，上游换成 Qoder 订阅；wb2go 也面向 WorkBuddy 与 CodeBuddy，改用 Go 写、单文件分发；api-log 和 WindsurfAPI 服务于另外的体系。把它们并排看，能更快判断本项目的边界落在哪。

这几个项目分别在解决什么

WorkBuddy2API-Hub 在 main 分支上的最近一次提交是 2026-10-10，最新版本 v1.6.18。它对外提供三套协议：Chat Completions、Responses API（Codex）与原生 Anthropic Messages API（Claude Code / Anthropic SDK）。国际版与国内版有各自独立的配置和调度，看板顶部一键切换，状态落盘。

仓库的主要能力可以分成这几块：

• 三协议支持：Chat Completions、Responses API 与原生 Anthropic Messages 并存。
• 多账号调度与双区域路由：国际版（www.workbuddy.ai）与国内版（codebuddy.cn / copilot.tencent.com）分别配置，互不干扰。
• 身份与会话隔离：OAuth 免客户端登录，看板点链接完成授权即自动入库；也能直接读本机已登录的 WorkBuddy 桌面端账号，客户端加密存储的 token 就地解密；derive_id 以账号 UID 稳定派生机器码与会话标识，降低多号关联的风控风险。
• 多 API Key 与出口绑定：每个 Key 可固定走国际版或国内版，不绑定则跟随全局出口开关；可为每个 Key 填模型白名单（如 deepseek*、gpt-6-astra，支持 * 通配，多个用逗号分隔），留空表示不限制。不在名单内的请求在本机直接返回可读的 400，既不送达上游，也不消耗额度。
• 限额护栏：保留积分、每日 Token 限额、每日积分限额、按模型每日 Token 限额四条，收在看板同一张表里，默认全部关闭，次日 0 点解封。积分花超只停免费模型，单模型 token 用满只禁该模型。国际版与国内版可分别设阈值，留空继承全局。
• OpenRouter 价估算：把请求 token 按 OpenRouter 公布的模型价折算成等价花费，按条件定价的模型按每条请求的输入长度与时间取档，定价按版本留档，人民币与美元可切换。上游新增模型无需改代码即可自动进入取价。
• 后台定时调度器：09:00 / 21:00 跑国内签到旅行与国际版活跃打卡，22:00 保活，01:00 夜猫。
• Web 看板：指标卡片、模型性能与用量大表、按 API Key 的用量归属、实时请求流水，一屏可查。

国内版的自动化包含每日签到、成长任务与积分任务自动接取点亮领奖、猫猫日常旅行与连续打卡。国际版这边会自动建网页端会话，接上沙箱把这一轮真正跑完（ACP over HTTP+SSE），领满官方每日活跃的 30 / 50 积分。

启动方式有三种。Windows 双击 start-wb-proxy.bat，macOS 双击 start-wb-proxy.command，或者执行 ./start-wb-proxy.sh（默认 8788 端口，可在后面传端口号覆盖）。启动后接口地址是 http://127.0.0.1:8788/v1，看板是 http://127.0.0.1:8788/。看板默认密码 admin，首次登录后应当立刻改掉。运行需要 Python 3.9+，zip 解压后如果提示权限不足，先执行一次 chmod +x 那几个脚本。

容器部署提供 linux/amd64 与 linux/arm64 双架构镜像，发布在 GHCR 与 Docker Hub，不用克隆代码，也不用本地编译。最省事的是官方的一键脚本：

curl -fsSL https://raw.githubusercontent.com/ardeyouxipianyi/workbuddy2api-hub/main/quick-deploy.sh | bash

国内网络可以走带代理前缀的那一版。NAS 或面板用户能直接贴 compose 文件建项目，镜像名写 ghcr.io/ardeyouxipianyi/workbuddy2api-hub:latest，端口 8788，把 ./accounts 与 ./usage 两个目录挂出来做持久化，容器更新重建都不会丢账号和用量。想彻底不管更新，可以再起一个 Watchtower 只盯 wb-proxy，检查间隔设成 86400 秒。

真实用户提交过的三个问题值得先知道。Claude Code 在新工作区开新会话时，模型只回一句就自动终止，旧会话不受影响，这条在 v1.1.8 上报出，目前状态是已解决。国际版出口下 gpt-5.6-luna / sol / terra 的缓存命中率长期为 0%，同网关下的 deepseek-v4.1-flash 却有 98% 左右，v1.6.10 上有人报过，也已解决。还有一条：网关设成统一走国内版出口、但网关内登录了国际版账号时，通过 happy 手机端远程调用会绕过出口设置，安卓端默认只有官方那几个模型，不到一分钟额度就见底，这条同样已解决。

同类项目里，qoder2api-hub 的定位与本项目几乎一一对应，只是订阅源换成 Qoder，同样做国际与国内双区、多账号、OpenAI 兼容网关，卖点写着 COSY 签名推理、稳定设备指纹防风控、OAuth 设备授权免客户端登录、每日签到与 Pro 福利，目前 101 star。

wb2go 面对的是同一批 WorkBuddy 与 CodeBuddy 用户，把订阅转成 OpenAI 兼容 API，做多账号池与国内 / 国际双区域，实现上选纯 Go、零依赖、单文件，当前 star 数为 0。api-log 是另一类东西，它记录经过网关的 LLM 调用链路，定位是 sub2api、CLIProxyAPI、new-api 这类网关上的一层透明 trace 记录器。WindsurfAPI 面向 Windsurf 与 Devin Desktop，把它们的 100 多个模型（Claude、GPT、Gemini、DeepSeek 等）转成 API，3071 star，与本项目的目标用户不重叠。

逐项对照

差距出现在哪

最明显的差距在部署形态。wb2go 用纯 Go 写，零依赖、单文件分发，拿到就能跑；本项目是 Python 项目，要求 3.9+，虽然绿色包自带精简 Python，也有预编译镜像免去本地编译，运行环境仍然比单文件重一截。对只想在一台机器上跑起来、不打算碰容器的人来说，这一点是实打实的劣势。

和 qoder2api-hub 之间，差距不在设计，而在上游订阅源。两者的产品描述几乎逐条对应，素材里没有给出两边在调度细节上的可比数据，所以在这一层分不出高下。真正的分水岭是 wb2go 那类单文件方案代表的路线：把功能压到最小、把分发成本压到最低。本项目走的是另一条路，三套协议、看板、价估算、限额护栏、定时调度全塞在一个仓库里，代价是体积，仓库 2013 KB，光看板前端 dashboard.html 就占 476.9 KB。

什么情况下选它

手上有多个 WorkBuddy 或 CodeBuddy 账号，想让 Codex、Claude Code 或标准 OpenAI 客户端共用它们，并且希望在某个账号额度耗尽时自动切号，这是本项目最直接的使用场景。需要国际版与国内版同时存在、还要给不同客户端分配不同出口和模型白名单，它也能覆盖。想要一块能看用量、积分与等价花费的看板，并且愿意跑 Python 或 Docker，同样合适。

反过来，只用单个账号、只想本机给一个客户端用一次，同类里更轻的单文件方案就够，没必要引入这套带看板的网关。目标是 Windsurf 或 Devin Desktop 的模型，那属于另一个项目的地盘。只想要调用链路的 trace 记录，不需要账号池和额度调度，api-log 那种定位更对口。Windows 之外还要折腾防火墙与本地网络权限、又不想碰容器的用户，也得先掂量一下前期的配置成本。

这类工具做的事包含把订阅额度转成 API、多账号调度、自动签到与活跃打卡，仓库里还涉及 derive_id 设备指纹隔离。它只应当用于你自己拥有或已获得明确授权的账号。拿来做批量注册、代领、额度转售，既可能违反上游服务条款，也可能带来平台封禁与法律层面的风险。具体的合规边界以你所在地法规与上游协议为准。

项目采用 MIT License，主要语言是 Python（占比 73.9%），仓库地址在 https://github.com/ardeyouxipianyi/workbuddy2api-hub。截至本文引用的数据，它的 star 数为 772，fork 180，开放 issue 5 个。

焚评：这个项目的量化评分

本项目的选题来自 焚.com（一个按公开公式给 GitHub 项目打分的站）。焚评当前总分 9.3 分（满分 10）。下表是各维度的得分：

评分口径、权重与计算方式见焚.com 的评分方法页；数据随 GitHub 指标刷新，具体数值以焚.com 当前页面为准。本文正文为诀.com 独立撰写，评分数据由焚.com 授权引用。