把腾讯 CodeBuddy 账号变成 OpenAI 兼容 API 的多账号网关 · 附 Web 管理面板
Web 面板 · OAuth 浏览器登录 · 账号池轮转 · 熔断与冷却 · 会话粘性 · 定时签到 / 活跃 / 旅行 / 保活 · 成长任务一键完成（17/18） · 流式 / 非流式

本项目是 Sliverkiss/workbuddy2api 的增强分支（fork）。 上游仓库现已删除；本项目已同步至上游删库前的最后一次更新（ea8b1e5），此后由本分支独立维护演进。 在上游基础上重构了可视化运维层；差异概览见 与上游的差异，上游设计的精巧之处（账号池调度、错误分类、提示词体系）原样保留，详见下文。

⚠️ 本项目仅限自用账号（签到 / 保活 / 个人工具接入），不支持同时也是禁止批量小号分发额度、二次打包或收费售卖。 详见 使用声明（必读）。

本项目（含上游 Sliverkiss/workbuddy2api，下同）的开发初衷只有一个：方便个人管理自己的 CodeBuddy 账号——自动签到、保活、给自己的本地工具提供一个 OpenAI 兼容入口。它是免费、开源、按「原样」提供的个人自用工具。

近期我们发现有人将本项目用于以下行为：

• 批量注册小号 / 收购账号，对外提供付费 API、共享池、代充等业务；
• 二次加壳、捆绑卡密（授权码）售卖，或以「公益服」「低价中转」等名义变相收费分发。

我们对上述行为表达最强烈的反对，并声明如下：

1. 一切商用 / 售卖行为与本项目及作者无关。 本项目不授权、不支持、不参与任何面向公众的 API 售卖、账号池出租、卡密收费分发；行为人由此产生的一切后果（包括但不限于账号封禁、条款违约与法律风险）由其自行承担，与作者和贡献者无任何关系。
2. 批量注册与转售接口配额违反目标平台服务条款。 CodeBuddy / 腾讯系服务条款禁止批量注册账号及商业转售接口。上游仓库已删除、停止公开维护——我们无法断定具体原因，但此类滥用行为正在毁掉所有正常使用者的环境，请勿再消耗社区的善意。
3. 请勿购买任何「收费版」「卡密版」「公益中转版」。 本项目永远免费开源。任何加壳、加密、捆绑收费的「版本」都是他人篡改的产物，与本项目无关；且此类分发无法审计，存在被植入后门、回传并窃取你 CodeBuddy 凭证的风险（auths/ 中保存的是明文 accessToken / refreshToken）。你付钱买到的不是本项目，而是把自己账号交给陌生人的机会。
4. 关于开源协议的诚实说明。 本项目基于 MIT 协议开源，协议允许自由使用与修改源码——这是开源的本意，我们不会收回；但 MIT 赋予的是代码层面的自由，不赋予以本项目名义宣传、售卖、捆绑分发，或要求作者提供支持与背书的权利。作者不为任何第三方分发版本提供支持、更新承诺或安全保证。
5. 作者保留止损的权利。 若滥用行为持续，作者可能随时停止维护、关闭或删除仓库，且不另行通知。上游的今天可能就是本项目的明天，望自重。

如果你的用途是管理自己的账号，欢迎正常使用、反馈问题与提交 PR。

WorkBuddy2API 是一个自托管的 OpenAI 兼容反向代理网关，将腾讯 CodeBuddy（copilot.tencent.com）账号包装为统一的 /v1/chat/completions 服务。

• 官方不提供 OpenAI 形态的开放 API，本项目通过 OAuth 设备授权（面板「添加账号」或 login.sh）获取账号凭证，在网关侧做 token 自动刷新、账号池调度与流量治理；
• 面向 个人多账号 场景：多账号共享、单号故障自动换号、冷却 / 熔断防止雪崩、会话粘性保证多轮上下文不跳号；
• 对客户端只暴露 OpenAI 兼容接口，现有 SDK / 前端 / 工具 零改造接入。

⚠️ 合规须知：本项目是非官方网关，使用 CodeBuddy 账号作为上游，仅限本人授权账号、本机 / 私有环境测试。详细边界见安全与合规。

官方「成长计划」的 18 个成长任务中，17 个可在面板上一键纯 API 完成——无需安装官方客户端、无需人工交互，点一下「一键完成」即自动推进进度、等待异步计分落定并自动领奖。剩余任务展示操作指引。

全新账号一键全做完 ≈ +1950 credits +78 能量，其中仅数个任务涉及真实对话（Model_chat_GLM5.2 一条、expert_5/Expert_team_use_3/skill_1 各数条 fast-model 短对话），其余全部为行为事件上报，零对话消耗。

任务计分走 /v2/report 行为上报，但不同任务认不同客户端指纹：CLI 指纹（www.codebuddy.cn）、桌面指纹（copilot.tencent.com + WorkBuddy/5.5.6 UA + workbuddy-desktop 事件族）、web 指纹（www.workbuddy.cn + x-client-platform: web）。网关为每类任务构造对应指纹的判据事件链（internal/upstream/desktop.go）；专家类任务额外要求真实专家 id 与真实对话回执（internal/upstream/streak.go 之外的 expert 序列）。上报 200 ≠ 计分——面板在执行后轮询任务进度，达标即自动调用 Web 域领奖接口。

⚠️ 行为事件按天幂等：重复点「一键完成」不会重复扣资源，已达标的任务自动跳过。

「任务中心」视图把散落的任务能力收拢成一处：

• 全账号任务扫描：一键拉取每个账号的成长任务（未完成且可自动化的 19 项，含小程序口径的「校园日」与「小程序首对话」）+ 开学季待办，列表一目了然
• 执行队列：把待办按账号排队执行——账号内串行（与单任务/一键完成共用互斥锁），账号间可选并发（1-3）；执行进度实时更新到每个条目
• 开学季独立状态卡：每账号 5 任务（分享/桌面/对话×3/专家/学生认证）的状态矩阵 + 剩余抽奖次数，一键触发全账号闭环
• 日志分频道：运行日志按「任务 / 对话 / 系统」三个频道筛选——对话流量再大，任务结果也不会被冲掉；日志条目带频道徽标与时间

成长中心连登档位（连续登录 7/14/28 天）兑换后发放积分 / 能量 / 补签卡 / 抽奖次数，抽奖次数只能从兑换获得。网关把它挂在每日签到排程末尾自动跑闭环（见定时任务）：档位解锁当天自动兑换、有抽奖次数自动抽完，全程无需人工盯。

本分支相对 上游 master 的增量（均已在真实多账号环境验证）：

第一轮（fork 基线 53ee3a1 → 9a87758，34 个提交）：四类任务独立排程、pool 文件拆分、12153 连续计数才禁用、429 code=6004 模型级限流收窄、11101 不罚号、请求体 413、DeepSeek 思维链、reasoning_content 回填、Codex 指纹脱敏、系统提示词体系、出站 UA 可配等。

第二轮（9a87758 → ea8b1e5，2026-09-14，只吸收底层）：

未吸收（明确不做）：脚本体系（task_runner/school 脚本—我们已有更完整的纯 API 实现）、governance/CI workflow、成本账本选号（依赖 usage.credit 观测，收益待验证）。

上游仓库此后已删除，上述第二轮（ea8b1e5）即其删库前的最后一次更新，本分支已完整吸收。此后本仓库与上游不再有同步关系，演进以本仓库为准。

flowchart LR
    Client["客户端 / SDK\nOpenAI 兼容请求"] --> H

    subgraph GWI["WorkBuddy2API 网关 :7863"]
        H["HTTP Handler\n鉴权 · 请求体上限 · 提示词改写 · 轮转"] --> P
        H --> S
        P["账号池\n最早到期优先 · 成本分层 · 熔断 · 冷却 · 租约"] --> U
        S["会话粘性路由"] -.绑定镜像.-> REDIS
        T["定时调度\n签到 09/21 · 旅行 09/21 · 活跃 10 · 保活 22"] --> P
        U["上游 Client\nChatHTTP 流式 · 短 RPC"]
    end

    P -. "读凭证 (0600)" .-> AUTH[("auths/*.json")]
    P -. "状态镜像" .-> REDIS[("Upstash Redis\n可选")]
    U -->|"chat/completions (SSE)"| CB["CodeBuddy\ncopilot.tencent.com"]
    U -->|"billing / auth / growth"| CB

上游请求在出站前经历统一的改写管线（internal/upstream/payload.go）：强制 stream:true、developer 角色归一、tool_choice 归一、image_url 字符串兼容为 OpenAI 对象形态、DeepSeek 思维链注入、reasoning_effort 档位降级、reasoning_content 回填、指纹脱敏。

• Docker + Docker Compose（服务端部署方式，镜像内已含低权限用户与全部工具脚本）——或
• Windows / macOS / Linux 直接跑单文件二进制（无需 Docker，见下方「Windows 单文件运行」）
• 一个或多个已注册的 CodeBuddy 账号，用于 OAuth 登录
• 宿主机 Go ≥ 1.22（仅从源码构建时需要）

CI 会自动构建多架构镜像（amd64 / arm64）并发布到 GHCR，git clone 之外的部署路径：

# 1. 准备配置与数据目录
mkdir -p auths data && cp config.example.json config.json
#    建议编辑 config.json 设置 api_key（或留空由程序自动生成随机密钥）

# 2. 拉取并运行
docker run -d --name workbuddy2api \
  -p 7863:7863 -e TZ=Asia/Shanghai \
  -v ./auths:/app/auths -v ./data:/app/data -v ./config.json:/app/config.json \
  ghcr.io/linguo2625469/workbuddy2api-panel:latest

# 3. 健康检查（无可用账号时返回 503）
curl -s http://localhost:7863/healthz

首次发布后须将包设为公开：GitHub 仓库页 → Packages → workbuddy2api-panel → Package settings → Change visibility → Public，否则拉取需要 docker login ghcr.io。

镜像 tag 规则：main 分支推送 latest / main / sha-xxxxxx；打 v* tag 额外发布 1.2.3 / 1.2 / 1 语义化版本；PR 仅构建验证、不推送。

# 1. 克隆
git clone https://github.com/linguo2625469/workbuddy2api-panel.git
cd workbuddy2api-panel

# 2. 准备配置（compose 挂载此文件，缺失会导致容器启动失败）
cp config.example.json config.json
#    建议编辑 config.json 设置 api_key（或留空由程序自动生成随机密钥）

# 3. 启动（首次会构建镜像，约 1-2 分钟）
docker compose up -d --build

# 4. 健康检查（无可用账号时返回 503）
curl -s http://localhost:7863/healthz
# {"healthy":0,"total":0,"service":"workbuddy2api"}

启动后打开 http://localhost:7863/panel/，用面板「添加账号」完成登录（见下节）。

常用运维命令：

docker compose logs -f          # 跟踪日志
docker compose restart          # 重启
docker compose down             # 停止并移除容器（数据在 ./auths 与 ./data，不受影响）

# 1) 下载 Release 中的 wb2api.exe，或从源码构建
go build -trimpath -ldflags="-s -w" -o wb2api.exe ./cmd/server

# 2) 直接运行：首次启动自动生成 config.json（含随机 api_key，日志打印一次）
.\wb2api.exe -config config.json

# 3) 浏览器打开面板添加账号
#    http://127.0.0.1:7863/panel/

exe 为单文件自包含（前端资源已 embed 进二进制），拷到任意 Windows 机器即可运行，只需保证 auths/（凭证）与 data/（状态）目录可写。

go build ./...
go vet ./...
go test ./...                      # 完整测试套件
go run ./cmd/server -config config.json

构建全部二进制：

CGO_ENABLED=0 go build -trimpath -ldflags="-s -w" -o wb2api ./cmd/server
CGO_ENABLED=0 go build -trimpath -ldflags="-s -w" -o signin_bin ./cmd/signin
CGO_ENABLED=0 go build -trimpath -ldflags="-s -w" -o login ./cmd/login
CGO_ENABLED=0 go build -trimpath -ldflags="-s -w" -o credit ./cmd/credit

方式 A：Web 面板（推荐，各平台通用，免命令行）

打开 http://127.0.0.1:7863/panel/，点右上角「添加账号」：面板展示授权链接 → 浏览器完成登录 → 自动检测并落盘凭证 → 热加载进池（无需重启），顺带完成首次签到。

方式 B：命令行脚本（仅 Linux / macOS，依赖 bash + python3）

./login.sh
# 按提示在浏览器打开授权链接 → 回到终端确认 → 凭证落盘 auths/workbuddy-<uid>.json

login.sh 内置授权 URL 获取 + 浏览器登录 + token 轮询 + 首次签到 + 凭证落盘 + 容器重启，全程无 PKCE（state 由服务端签发）。账号池在容器启动时用 auths/ 目录自动对齐，新增凭证文件即自动发现。

Windows 用户请用方式 A（或 WSL）；login.sh 需要 python3。

# 模型列表
curl -s http://localhost:7863/v1/models -H "Authorization: Bearer your-api-key"

# 账号状态（汇总 + 每账号详情，disabled 账号透出 disabled_reason）
curl -s http://localhost:7863/status -H "Authorization: Bearer your-api-key"

# 流式聊天
curl -sN http://localhost:7863/v1/chat/completions \
  -H "Authorization: Bearer your-api-key" \
  -H "Content-Type: application/json" \
  -d '{"model":"deepseek-v4-flash","messages":[{"role":"user","content":"hi"}],"stream":true}'

# 非流式聊天（本地聚合）
curl -s http://localhost:7863/v1/chat/completions \
  -H "Authorization: Bearer your-api-key" \
  -H "Content-Type: application/json" \
  -d '{"model":"deepseek-v4-flash","messages":[{"role":"user","content":"hi"}],"stream":false}'

config.example.json 是配置项最完整的参考：每个字段、默认值与结构都能在其中找到，示例值一律是 test_key 之类占位符，不含任何真实密钥。下表为字段含义速查。

聊天流（stream true / false 均同）没有总时长上限：聊天使用 Timeout=0 的专用 client，长思考 / 长输出不会被掐断。

加载顺序：JSON 文件 → WB2A_* 环境变量（变量非空才覆盖）：

WB2A_LISTEN · WB2A_API_KEY · WB2A_AUTH_DIR · WB2A_STATE_FILE · WB2A_MAX_BODY_MB · WB2A_SOFT_RATE(duration) · WB2A_SOFT_RATE_MAX(duration) · WB2A_TIMEOUT_SECONDS · WB2A_HEADER_TIMEOUT_SECONDS · WB2A_IDLE_TIMEOUT_SECONDS · WB2A_USER_AGENT · WB2A_SANITIZE_FINGERPRINTS(bool) · WB2A_PROMPT_MODE · WB2A_PROMPT_FILE

客户端（Claude Code / Codex 等 CLI）会在 system prompt 注入固定模板句，上游内容审核按逐字精确匹配误杀合法流量（HTTP 400 + 审核文案）。网关提供两层防护，互不替代：

1. 提示词体系（解决 system / developer 来源的误报）：由 prompt.mode 控制
2. 指纹脱敏（兜底 用户 / assistant 消息里的指纹串）：由 features.sanitize_blacklist_fingerprints 控制

内置默认提示词约 2KB（internal/prompt/defaultprompt.md，嵌入二进制）。prompt.file 指向自定义提示词文件（自定义人格 / 人设）即整体替换内置默认；留空 = 内置默认，路径非空但不可读 → 启动报错（fail fast，不会静默回落到内置默认）。

passthrough 模式请求被上游内容策略拦截（HTTP 400 + blocked by security policy / unapproved channel / illegal api invocation 文案）时，判定为 system 指纹误报：同请求内换 Degraded 中性提示词重试一次；第二次仍被拦（用户内容本身触发审核）→ 走既有错误路径返回客户端，并如实报给调用方。

• 触发降级后持续到次日 00:00 CST（Asia/Shanghai）重置；降级期内 passthrough 请求直达中性提示词，不再先撞 400
• 降级状态是进程内存态，重启清零
• 内容问题非账号问题：ErrContentBlocked 不罚账号（无冷却 / 熔断 / 计错），由网关降级重试消化

上游错误由 Classify 统一分类（判定优先级：余额耗尽 → session 失效 → 限流文案 → 状态码兜底），账号处置如下：

请求体解析失败（11101）与内容拦截一样不罚账号：问题在请求内容而非账号健康。网关不做请求体截断与预拦截，11101 均为客户端发来的畸形 JSON。

熔断器：所有冷却入口与 5xx 共用唯一连续失败计数器 fails；累计达 breaker_threshold（默认 3）触发熔断，退避 breaker_cooldown × 2^retryCount，封顶 6h；成功清零。

软冷却指数退避（与熔断器并存的第二条升级线）：软限流的冷却时长本身也按连续次数退避——同一账号连续触发软冷却时 soft_rate × 2^(连续次数-1)，封顶 soft_rate_max。计数 soft_streak 独立于熔断器的 fails，只在成功或签到解冻时清零，随 state.json 持久化。

1. 过滤：禁用 / 冷却 / 熔断 / 在途占满账号不参与

2. 按模型实测成本分层，只保留当前最优层

3. 默认开启最早到期优先：

   • 在模型成本最优层内，筛选 expiring_soon 窗口内仍有积分的账号。
   • 按最近到期时间升序排序；同到期时间按该批次剩余积分降序。
   • 已过期、零余额、无有效到期时间的账号不进入优先集。

4. 优先集为空时退回普通加权随机：

   weight = credits 比例 ×10 + idleWeight

   • credits 比例 = 该号积分 / 候选集最大积分
   • idleWeight = min(闲置小时 × idle_weight_per_hour, idle_weight_max)，从未使用给满分

5. 防惊群：跳过 100ms 内刚被选中的账号；全冷却时从非禁用、非余额耗尽的软冷却 / 熔断账号中选最早到期者顶班

同一会话尽量复用同一账号，多轮对话不跳号：

• 会话键提取顺序：metadata.conversation_id → metadata.conversationId → metadata.user_id → 顶层 conversation_id → 顶层 conversationId（snake_case 优先于 camelCase）
• TTL 滚动续期（默认 30m），GC 周期 5m；绑定可镜像到 Redis（7 天 TTL）防重启丢失
• 请求失败自动解绑；成功后绑定跟随最终成功账号

五类任务各自独立排程、各有开关，互不影响。容器时区由 TZ 控制（compose 默认 Asia/Shanghai）。

成长中心的连登档位（连续登录 7/14/28 天）兑换后发放积分 / 能量 / 补签卡 / 抽奖次数，抽奖次数只能从兑换获得。管家在每日签到后自动跑一遍闭环（幂等，未解锁静默跳过）：

1. 查连登档位状态 → 已解锁（非 locked / 非 claimed）的档位自动兑换
2. 查抽奖次数 → 有次数自动全部抽完，奖品记日志（streak-bonus <uid>: 🎲 …）

无需配置，跟随签到排程；到天数那天自动完成「兑换 → 抽奖」，无需人工盯。

关闭定时任务：用 schedule.*_enabled: false 显式关闭（四个都设 false 则调度器不空转，直接阻塞等待退出信号）。注意两点语义：

• 空数组与 null 表示「未配置 → 回落默认」，不是「禁用」；真正关闭请用 *_enabled: false
• 禁用不会擦除小时配置：*_hours 原样保留，改回 true 即恢复原时点；小时值必须是 0-23，非法值启动即报错
• 关签到会把「余额恢复即解冻」一起关掉，被硬冷却的账号只能等次日 04:00 自然到期

对池内每个可用账号在 activity_hours（默认 [10] 整点）发送一条对话活跃上报（事件 chat_request_send，body 为数组，事件必须含 userId）：

• 一条上报同时点亮 growth 连登 + 解锁 first_buddy 任务（领养前置）
• 每号每天 1 次即可（单时点）：日活跃奖励按天去重，重复上报无额外收益
• conversationId 由网关生成（wb2api-<ms>），无需真实会话
• 限速：账号间间隔 800ms（与旅行同口径）
• streak 自检：上报成功后回读连登天数（只读 oracle），日志每号一行可 grep：activity <uid>: streak days=N。days=0 记 warn（report OK but streak.days=0 (silent drop?)，对应上游「200 但静默丢弃」）；回读失败记 warn 但不影响主流程（上报按天幂等，不重试，只观测）
• 手动诊断 / 补跑用 python3 scripts/probe_active.py（只读探测；写操作默认 dry-run，需 --yes）

对池内每个可用账号在 travel_hours（默认 [9, 21] 整点）单趟推进一次，每趟只做一个动作，不轮询不等待。默认两趟闭环：9 点领昨日到站奖励并派出，21 点领当日到站奖励（daily_limit_reached 自动挡住二次派出）。

• 领养门槛未达标时上游返回 HTTP 400，每账号每自然日只尝试一次（跨日重试，记录仅存内存）；门槛可用活跃上报解除
• 限速：账号间间隔 800ms
• 每自然日 1 次派出：按 CST（Asia/Shanghai）自然日重置，与容器 TZ 无关
• 失败隔离：单账号失败只跳过该账号当趟；401 不强刷（token 刷新交保活时点）

余额后台刷新（schedule.balance_refresh_enabled，缺省开启）：每 balance_refresh_minutes（缺省 5）分钟并发查询全部账号余额并更新池内积分——两次签到时点之间 credits 保持新鲜，余额恢复的冷却账号也会自动解冻（语义同签到，但不做签到不刷 token）。面板「立即刷新」按钮也是全量刷余额；5 秒自动轮询只读内存，不打上游。

内嵌式管理面板（internal/panel，前端 go:embed 单文件打进二进制，无外部构建依赖），服务启动后访问：

http://127.0.0.1:7863/panel/

鉴权与 API 同口径：api_key 非空时面板要求输入一次密钥（浏览器 localStorage 记住）；为空则直接可用。 界面支持明暗主题切换（首次跟随系统偏好，点击按钮两态翻转并记住选择），左侧导航分四个视图：

配置热生效：保存配置后，api_key、cooldown.soft_rate、features.sanitize_blacklist_fingerprints、 logging.request_client_info、pool.*（熔断/在途/权重）、schedule.*（时点/开关/余额刷新间隔）立即生效，无需重启； 涉及进程装配期依赖的字段（listen、auth_dir、state_file、upstream.*、upstash.*、session_sticky.ttl） 保存后会提示"需重启进程生效"。配置写入采用「深合并且原子替换」：只更新面板表单覆盖的键， 用户手写的未知键与其余字段原样保留。

顶部「刷新」按钮 = 向上游全量查询真实余额并回写（5 秒自动轮询只读内存，不打上游）。

面板后端接口挂在 /panel/api/*（同一 Bearer 鉴权），可脚本化调用；账号运维操作均落到池既有入口（Revive/Disable/Remove 等），与 /status 观测口径一致。

安全响应头：面板页面与全部 /panel/api/* 响应统一带 Content-Security-Policy（default-src 'none'，脚本仅同源，frame-ancestors 'none' 禁嵌套）、X-Content-Type-Options: nosniff、X-Frame-Options: DENY、Referrer-Policy: no-referrer 等；前端脚本独立为同源 app.js，不含内联脚本与内联事件处理器。

鉴权实现：internal/httpauth 统一 server 与 panel 的 Bearer 校验，使用 SHA-256 摘要 + subtle.ConstantTimeCompare 常量时间比较（避免逐字节比较泄露密钥信息）；上游返回的 uid 经白名单校验（[A-Za-z0-9_-]，长度 ≤64）后才用于拼凭证文件名，防止路径穿越。

⚠️ 公网部署提示：服务自身只提供明文 HTTP，请务必置于 HTTPS 反向代理之后（Nginx/Caddy 等）并配置访问限流；仅本机或私有网络使用时可直接运行。

鉴权规则：仅当 api_key 非空才校验 Authorization: Bearer <api_key>；api_key 为空时上述端点直接放行；/healthz 恒无鉴权。

/healthz 响应示例（200 / 503 同结构，仅状态码与计数变化）：

{"healthy": 2, "total": 3, "service": "workbuddy2api"}

响应同时带 X-Service: workbuddy2api 头。这两个身份标识用于区分本网关与同端口上可能残留的其他服务——对方即使返回 2xx 也不会带该字段 / 头，宿主探测据此避免"假成功"。

宿主健康探测指引：强校验（推荐）用 /status + api_key——只有持有正确 api_key 的本网关返回 200，其他服务返回 401 / 404；弱校验（不适合持 key 的负载均衡器）用 /healthz + service 字段判据（/healthz 恒无鉴权，service == "workbuddy2api" 才算命中本网关）。容器自带 HEALTHCHECK 用的就是弱校验（仅进程内自检，够用）。

• 出站请求强制 stream:true；SSE 帧按 OpenAI 规范白名单重建（reasoning_content 保留、工具调用按 index 合并、未知字段剥离）
• 保证恰好一个 data: [DONE]（上游漏发时兜底补写）；空流先写一帧 error 再补 [DONE]
• 非流式请求由本地聚合完整 SSE 流为单 chat.completion 响应（含 reasoning_content / tool_calls）

上游接口均为 CodeBuddy 官方 CLI / 插件使用的非公开 / 逆向接口，未见公开 API 文档；路径及 Host 以代码内常量为准（见文末出处表）。两类 base：

• copilot.tencent.com：聊天补全（SSE）、token 刷新、OAuth、模型列表、growth 域（旅行 / streak）
• www.codebuddy.cn：每日签到、余额查询、活跃上报

出站请求统一携带 CLI/2.63.2 CodeBuddy/2.63.2 UA（可被 upstream.user_agent 覆盖）；聊天请求带账号头（X-User-Id 等），永不携带 X-Refresh-Token（该头只出现在 token 刷新请求）。领奖请求额外带 x-client-platform: web 与 workbuddy.cn 的 Origin/Referer。

每个 /v1/chat/completions 请求结束时输出一行表格日志（stdout）：

| #001 | 18:31:31 | deepseek-v4 | stream | 200 | uid=0851ce35 | TTFB=801ms | tok=60 | 23.5tok/s | total=2.6s |

敏感度：日志不含任何 token 明文（详见安全与合规），无落盘日志文件。

多阶段镜像（golang:1.23-alpine 构建 → alpine:3.20 运行）一次编译全部四个二进制并随镜像分发：

• wb2api（主服务）、signin_bin、login、credit + 脚本（login.sh / signin.sh / credit.sh / scripts/probe_active.py）
• 以 app 用户（uid 10001）运行，app/auths 与 app/data 预建
• 镜像内默认落 config.example.json 作为空配置（不含密钥），生产用挂载卷覆盖 /app/config.json
• 内置 HEALTHCHECK（wget /healthz，30s 间隔）

账号 / 数据通过 docker-compose.yml 卷挂载持久化：./auths、./data、./config.json。

二进制不在 git 中：脚本首次使用自动 go build 对应 cmd/*（Docker 镜像内已预编译）。

上游 /v3/config 里的 max_output_tokens 是声称值，普遍虚高：实测 16 个 CN 模型中 8 个被 静默钳制（请求 max_tokens 更大也不报错，输出到真实上限即截断），最狠的声称 1M 实际 32K。 「模型与档位」视图因此支持在最大输出列叠加实测标注：

• 🔴 32K ⚠ 钳制 12× —— 实测被截断于 32K，声称值的 1/12（finish=length 判据，可信）
• 🟢 48K ✓ / 64K ↑ —— 实测与声称一致 / 实际比声称更大
• ⚪ ≥40K / ? —— 满额未触顶（下界）/ 模型主动收尾未测出

实测值不写死在代码里——它来自探测工具写入的数据文件，上游调整后重跑一次即自动刷新：

# 在网关所在机器上（探测会真实消耗积分；单模型预算默认 600s，并行 4）
python3 scripts/probe_max_tokens.py   --base http://127.0.0.1:7863/v1 --key sk-xxx   --panel-out data/output_probes.json

# 断点续测 / 只测指定模型 / 预览计划
... --resume
... --models cn:glm-5.2 --panel-out data/output_probes.json
... --dry-run

文件落在 state 文件同目录（默认 data/output_probes.json，data/ 已被 gitignore），面板 GET /panel/api/model_probes 只读透传，写入后下次查询即生效，无需重启网关；未探测的 模型不受影响。探测判据（两种停止的区分 / 提示词量级匹配 / 并行与时间预算）的设计细节 见脚本头部注释。

• 多账号复制 auths/workbuddy-<uid>.json 即可，池启动时自动对齐目录
• Session 失效账号被禁用（disabled_reason 透出在 /status）后，可用 ./login.sh 重新登录覆盖凭证；已持久化 disabled=true 的账号可在源码侧调用 Pool.ReviveDisabled(uid) 复活（state.json 中清除 disabled 标志）
• 备份 = auths/（凭证）+ data/state.json（池状态：积分 / 冷却 / 计数）；配置 Upstash 后状态另镜像至 Redis（7 天 TTL）

• 位置：./auths（auth_dir 可配），文件名 workbuddy-<uid>.json
• 内容：明文 accessToken / refreshToken + 账号元信息（account.uid / enterpriseId / nickname）
• 权限：容器内以 app 用户（uid 10001）运行；token 刷新由 SaveAtomic 以 0600 原子写回（tmp + rename）；login.sh 首次落盘遵循登录 umask，建议手动 chmod 600 auths/*.json
• 切勿提交 git：.gitignore 已排除 auths/、data/、backups/、config.json、*.key、*.pem、*.env、docs/ 及除 README 外的全部 *.md 工作文档

• 默认监听 :7863，compose 暴露 0.0.0.0:7863，无内置 TLS；公网部署必须设置 api_key，建议前置反代 / 内网
• 请求日志字段：序号 / 模型 / 模式 / 状态码 / uid 前 8 位 / TTFB / token 数——不含 accessToken / refreshToken / api_key 明文（不读取 Authorization 头）
• 日志写 stdout / stderr（容器内进入 docker logs），代码无任何落盘日志文件

• 无预编译 release：仓库无 Release / tag，产物 = 源码自构建（Dockerfile 多阶段在本地构建时完成）
• 登录 / 签到 / 积分工具：./login.sh / ./signin.sh / ./credit.sh
• 无产物校验和：go.sum 仅约束 Go 模块依赖；Docker 镜像由本地 docker compose build 生成，未引用第三方镜像
• 上游 CodeBuddy 属腾讯系商业产品，本项目是其非官方 OpenAI 兼容网关；使用其账号做 API 网关涉及目标平台服务条款与账号风险，作者不对账号封禁、条款违约或使用结果负责

• 仅限本人授权账号、本机 / 私有环境测试
• 不得共享、转售、违规分发，或用于违反目标平台条款的用途；严禁批量注册账号做 API 业务、二次加壳或捆绑卡密售卖——详见顶部使用声明（必读）
• 遵守 CodeBuddy 平台服务条款与所在地法律
• 妥善保管 auths/（明文凭证）与网关端口

上游 429 + code 6004 是该模型的使用量超限（msg 通常带「将在 YYYY-MM-DD HH:MM:SS UTC+8 重置」），不是账号整体被限流。网关的处理：

• 冷却到上游重置时间：msg 带「将在 … 重置」时，账号冷却 until 精确等于该墙钟（按 UTC+8 解释），并封顶 soft_rate_max（默认 2h）
• 切模型立即可用：冷却由 6004 触发时会记录触发模型；同一账号改用其他模型请求时视为可用。同模型或未记录模型的冷却回到现状
• 退回指数退避：6004 无「将在 … 重置」文案，或非 6004 的普通软限流 → 仍是 soft_rate（600s 起，连续触发指数退避，封顶 soft_rate_max）

网关不再设请求体上限（server.max_body_mb 已移除，对齐上游）：任意大小的请求体都会完整读入并转发上游，超限类问题由上游自然返回错误——其响应信息量更大（能看到上游的真实策略），网关不再以 413 提前拦截。

• 多图/长上下文会话（历史图片每轮以 base64 重发，编码再膨胀约 37%）不会再撞网关侧 413
• 若上游真的返回 413/超限错误，网关按既有错误分类链路如实透传（不打码、不罚号——超限是请求侧问题）
• 客户端中途断流导致的半截 body 在读入阶段即报 400 invalid_request，不会把截断 JSON 喂给上游（issue #41 语义保留在读错误路径）

容器以 app 用户（uid 10001）运行，而宿主机挂载的 ./auths、./data 目录属主不是它——写凭证 tmp 文件被拒。三种解法任选（前两种均无需 root 容器）：

# 方案 1（推荐，非 root）：让容器以你自己的 uid 运行——挂载目录本来就是你建的
PUID=$(id -u) PGID=$(id -g) docker compose up -d --force-recreate
# 或写进 .env 文件长期生效（.env 已被 .gitignore 忽略）：
#   echo "PUID=1000" > .env && echo "PGID=1000" >> .env

# 方案 2：把挂载目录属主交给容器默认用户（需要 sudo）
sudo chown -R 10001:10001 ./auths ./data ./config.json

# 方案 3：compose 设 user: "0:0" 以 root 运行（NAS/群晖不便 chown 时用）

报错信息里自带这条指引；compose 的 user 已参数化为 ${PUID:-10001}:${PGID:-10001}。

• 用 ./login.sh 重新登录覆盖凭证，重启后自动回池；
• 或源码侧调用 Pool.ReviveDisabled(uid) 清除 disabled 状态（state.json 同步刷新）。

默认 prompt.mode=custom 已用网关自有提示词替换客户端 system，从源头消除大部分误报；用户 / assistant 消息中的指纹串由 features.sanitize_blacklist_fingerprints 清洗，两层叠加。passthrough 模式下首遇拦截会自动换 Degraded 中性提示词同请求重试一次。

官网「使用端」列按出站请求 UA 服务端归因。配置 upstream.user_agent: "WorkBuddy/2.x.x"（或环境变量 WB2A_USER_AGENT）即可改写全部出站请求的 UA；默认保持 CLI/2.63.2 CodeBuddy/2.63.2 现状（指纹净化考虑，可配而非改死）。

本项目仅供学习和研究使用。使用者需遵守 CodeBuddy 服务条款，自行承担使用风险（包括账号封禁、条款违约等）。作者不对任何因使用本项目产生的直接或间接损失负责。

本项目采用 MIT License 开源协议。

• 允许任意使用、复制、修改、合并、发布、分发、再授权及销售
• 再分发（源码或二进制形式）时，请保留原仓库的 MIT 版权声明与许可声明（如在 NOTICE 或 README 中注明原始出处 https://github.com/Sliverkiss/workbuddy2api）
• 本项目不授予任何上游（CodeBuddy / 腾讯）接口或服务的权利；使用者仍需自行遵守上游服务条款