linguo2625469/workbuddy2api-panel

把腾讯 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 不罚账号（无冷却 / 熔断 / 计错），由网关降级重试消化

上游（DeepSeek 系）的工具调用原生语法不是 OpenAI 的 JSON tool_calls，而是一段带全角竖线（U+FF5C）分隔符的标记文本：

<PIPE>DSML<PIPE> calls>
<PIPE>DSML<PIPE> invoke name="exec_command">
<PIPE>DSML<PIPE> parameter name="cmd" string="true">ls -la<PIPE>DSML<PIPE> parameter>
</PIPE>DSML<PIPE> invoke>
</PIPE>DSML<PIPE> calls>

（上面用 <PIPE> 占位，真实分隔符是两个全角竖线。）

上游只在请求声明了 tools 时才把这段标记解析成结构化 tool_calls。一旦某次请求没带上 tools——实测这在链路上是常态（协议转换丢字段、一次性 exec 探测、auto-review 复核回合等）——模型仍然想调工具，于是标记以纯文本落进 content。下游没有任何一层认识它：Codex 只执行 Responses API 的结构化 function_call 条目，于是把它当普通助手正文写进会话历史，回合直接 task_complete、工具一次都没跑。

网关在出站响应里做最后一道还原（internal/upstream/dsml.go），判定分两级：

名单有两个来源，二者会分别缺失，所以都要：本请求声明的工具（tools[].function.name / tools[].name / functions[].name）与会话历史里出现过的工具名（messages[].tool_calls[].function.name）。

还原还受三条硬性前提约束：本回合上游没有给出任何结构化 tool_calls（不覆盖真实调用）、块内除 invoke/parameter 与空白外不夹带正文、非流式额外要求 finish_reason 为 stop。任何一条不满足即原文逐字节透出——未闭合、参数畸形、超长（>256KB）一律回吐，修复层绝不吞字节。

命中与否各记一行日志，便于排障时区分「没识别到」与「识别到但判定不通过」：

INFO: [server] stream ...: repaired N native tool call(s) from assistant text (tool names known=K)
WARN: [server] stream ...: saw M native tool call block(s) but repaired none (tool names known=K)

上游错误由 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 窗口内仍有有效快过期批次的账号，选号权重 ×3（expiringVirtualSlots 虚拟实例展开，会话粘性路径同口径）。
   • 不按到期时间排序、与批次金额无关：14 天后到期与 3 天后到期、1 分与几千分，只要在窗口内待遇相同。
   • 该偏好弱于会话粘性（绑定号健康则直接使用）与模型成本分层（按实测成本硬过滤）；已过期、零余额、无有效到期时间的账号不进入加权集。

4. 同一候选池内加权随机（快过期命中账号在上面的基础上 ×3）：

   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）。

缺省 false：禁用账号被上述签到 / 活跃上报 / 保活 / 余额刷新四任务跳过，与选号过滤一致。

面板「禁用」的语义是「不再参与选号」，但这四类任务此前会一并跳过禁用号——被禁用的账号因此拿不到签到积分、不续 token、余额也不再刷新；而 ReenableIfCredits 明确不复活 disabled 账号，等于签到这条唯一的自动回血路径也断了，只能人工点「解冻」。

如果采用「一次只放开一个账号、用禁用做流量开关」的轮换方式（同 IP 多号怕触发风控），闲置待命的号恰恰是最需要签到的——把它设为 true，禁用号仍会签到 / 保活 / 刷新余额，但依旧不参与选号（pool 选号侧的 disabled 过滤不受本开关影响）。

该开关只覆盖调度器的这四类任务。猫猫旅行、夜猫子、连登管家（挂在签到末尾的 RunStreakBonusNow）与成长任务队列仍按原样跳过禁用账号——若也需要，请另行提出。

比上面的全局开关更常用的账号级入口：面板账号行的「暂停选号」按钮。暂停的账号：

• 退出选号（含全冷却兜底），状态显示「已暂停选号」，点「恢复选号」即刻回池——不清冷却域、无需解冻或重登；
• 无条件照常保号：签到 / 活跃上报 / 保活 / 余额刷新四任务照跑（不依赖 include_disabled_in_tasks）；
• 其余任务体系照常：猫猫旅行（纯 RPC：状态/派出/领奖）、连登管家、成长任务队列与任务中心扫描/执行都照常参与——这些走的是上报/领奖接口，不发模型对话（个别任务动作自带一次真实短对话，如 Model_chat_GLM5.2，影响可控）；失败照常记错误行，不特殊处理；
• 唯一跳过的是夜猫子：RunNightChats 逐条发真实 glm-5.2 对话，是任务体系中唯一「整任务都是模型对话」的，与「让位防风控」正面冲突。

这正是「一次只放开一个号、其余让位」轮换用法想要的粒度：让位的号不再承接选号流量，也避开夜间的对话补足；其余养号动作照常。与「禁用」的区别：禁用是终态（session/授权判死，需人工解冻，保号默认也停），暂停是运维临时态（账号健康，随时恢复）。状态持久化（state.json paused 字段），跨重启不丢；disable/revive 会一并清掉 paused。

auth 文件带非空 enterpriseId 的账号被识别为企业版（面板账号名旁显示「企业版」标签）。企业版没有个人成长体系——上游对这些端点一律拒绝（实测 2026-10-07，同一时刻与个人号 A/B 对照）：

因此网关对企业号不发起这五类调用（签到 / 活跃上报 / 猫猫旅行 / 夜猫子 / 连登管家），面板也不渲染「签到」「任务」按钮（只留「额度」）。判定（auth.Auth.IsEnterprise()）与既有 IsGlobal()（D4 门控）在同一批引用处并列书写，upstream 侧零改动。

企业版照常的能力：选号派发、保活（token 刷新仍必需——不刷新同样会过期失效）、额度查询。

企业额度不在个人「资源包」体系内（get-user-resource* 对 enterpriseId 账号恒返回空 Accounts，面板因此长期显示 0），故额度改走 POST /v2/billing/meter/get-enterprise-user-usage：上游 credit 是本周期已用（与个人口径「剩余」语义相反），limitNum 是分配给该账号的额度，网关据此换算 剩余 = limitNum - credit；limitNum = -1 为不限量（面板显示「不限」，且不参与周期分桶）。企业配额按周期重置（cycleResetTime），未用完即作废，故周期末会参与 prefer_expiring 优先消耗。

成员账号无权查询企业池总额度（实测：池端点在成员 token 下返回 403 not_authorized，/console/accounts 显示 isAdmin=false）。面板展示的只是该账号被分配的额度；企业池余额只有企业管理员在管理后台可见。

成长中心的连登档位（连续登录 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 记住）；为空则直接可用。 界面支持明暗主题切换（首次跟随系统偏好，点击按钮两态翻转并记住选择），左侧导航七个视图：

顶部另有「刷新」（向上游全量查询真实余额并回写；5 秒自动轮询只读内存，不打上游）与「添加账号」（浏览器内完成 OAuth 设备授权：显示授权链接 + 自动轮询，登录后凭证落盘并热加载进池，免重启，也支持导入 cockpit tools 导出的 JSON）。

「用量」与「运行日志 → 请求记录」共用同一个时间范围控件，预设 今天 / 近 24 小时 / 近 3 天 / 近 7 天 / 近 30 天 / 全部历史 / 自定义（自定义展开起止时间输入，精确到分钟；起止颠倒就地标红）：

• 「今天」与「自定义」的区间由浏览器按本地时区算好后发给服务端——服务端时区未必与浏览器一致（容器常挂 TZ=Asia/Shanghai），让服务端算"今天"会在跨时区时切错日子；
• 滚动预设走服务端的 hours 口径（当前整点往回 N-1 小时），与既有统计口径逐位一致（前端自己减 N 小时会在边界多算/少算一个桶）；
• 用量侧由 usage.Window 统一三种窗口口径，并在响应里回显实际生效区间（window_from / window_to），总览右上角因此会显示形如 9-30 00:00 → 9-30 15:02 · 14 个分桶 · 数据自 … 的口径说明；
• 请求记录的时间过滤在归档侧完成（reqlog.Filter.From/To，而不是筛已拉取的条目），所以区间落在更早时段时也能取到记录。

请求记录表会显示每次调用的来源：IP 取 X-Forwarded-For 首段 → X-Real-IP → 回落 TCP 对端（直连部署下这是唯一线索）；User-Agent 截断 200 字节入库，stdout 流水行同时追加压缩后的客户端标签（src=203.0.113.7 ua="Chrome/120.0.0.0"，浏览器 UA 不会整段铺开）。

来源信息比 token 计数敏感（IP 属个人信息），因此由 logging.request_client_info 控制，缺省开启、热生效、面板「配置 → 日志」可关；关闭后归档与面板都不再出现来源字段（老归档里没有该字段的条目显示 —）。

配置热生效：保存配置后，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） 保存后会提示"需重启进程生效"。配置写入采用「深合并且原子替换」：只更新面板表单覆盖的键， 用户手写的未知键与其余字段原样保留。

与页面同一 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）
• 正文里的原生工具调用标记在透传前还原为 delta.tool_calls（见「原生工具调用标记还原」）：命中时一帧会拆成「正文帧 + N 个调用帧 + 收尾帧」，上游的 finish_reason: stop 改写为 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 / 腾讯）接口或服务的权利；使用者仍需自行遵守上游服务条款