misakano7545/workbuddy2api-panel

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

本项目是 Sliverkiss/workbuddy2api 的增强分支（fork）。 在上游基础上重构了可视化运维层，并同步了上游全部功能更新。 差异概览见 与上游的差异；上游设计的精巧之处（账号池调度、错误分类、提示词体系）原样保留，详见下文与上游 README。

感谢 linguo2625469/workbuddy2api-panel，以及原仓库删库后的延续 HanawaBanana/workbuddy2api。

WorkBuddy2API 是一个自托管的 OpenAI 兼容反向代理网关，将腾讯 CodeBuddy（copilot.tencent.com）账号包装为统一服务。入站支持 chat_completions（POST /v1/chat/completions）、codex_responses（POST /v1/responses）与 anthropic_messages（POST /v1/messages，同样接受 POST /messages）。

• 官方不提供 OpenAI 形态的开放 API，本项目通过 OAuth 设备授权（面板「添加账号」或 login.sh）获取账号凭证，在网关侧做 token 自动刷新、账号池调度与流量治理；
• 面向 个人多账号 场景：多账号共享、单号故障自动换号、冷却 / 熔断防止雪崩、会话粘性保证多轮上下文不跳号；
• 对客户端暴露 chat_completions、codex_responses 与 anthropic_messages。模型名原样交给上游，不把 claude-* 改写成别的模型。

⚠️ 合规须知：本项目是非官方网关，使用 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 域领奖接口。

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

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

• 全账号任务扫描：一键拉取每个账号未完成且可自动化的成长任务（含小程序口径），列表一目了然
• 执行队列：把待办按账号排队执行——账号内串行（与单任务/一键完成共用互斥锁），账号间可选并发（1-3）；执行进度实时更新到每个条目。同一队列也可按排程每日自动跑（schedule.growth_hours，默认 11 点；排程轮次账号间固定串行）
• 日志分频道：运行日志按「任务 / 对话 / 系统」三个频道筛选——对话流量再大，任务结果也不会被冲掉；日志条目带频道徽标与时间

任务中心扫描会合并小程序口径待办（Sequential_Tasks_*，默认列表不可见）。accept 带登记回读：上游有过 200 但没落账的情况，未生效会再试一次。

成长中心连登档位（连续登录 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 脚本—我们已有更完整的纯 API 实现）、governance/CI workflow、成本账本选号（依赖 usage.credit 观测，收益待验证）。

flowchart LR
    Client["客户端 / SDK / Codex / Claude\nchat_completions · codex_responses · anthropic_messages"] --> 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 回填、指纹脱敏。codex_responses 与 anthropic_messages 在 Handler 转成 chat_completions 再进这条管线，上游仍是 chat/completions SSE。

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

面向读到本文档后代为部署的 AI Agent。人类用户可直接前往下方任一方式。

Agent 可自动完成：克隆 / 拉镜像 → cp config.example.json config.json → 启动 → 轮询 GET /healthz。

只有人类能做（Agent 到此必须停下并交接，不得自行"想办法"）：

• OAuth 设备授权（面板 http://127.0.0.1:7863/panel/ 或 ./login.sh）——需要浏览器与账号持有人本人；
• api_key 的取值与保管。

硬性禁止：

• 不把 auths/、data/、config.json、API_KEY.txt 提交到 git 或任何公开位置；.gitignore 已排除，不得用 -f 绕过；
• 不在 api_key 为空时把 7863 暴露到 0.0.0.0 / 公网，默认只听 127.0.0.1；
• 不替他人登录非本人授权账号，不共享凭证、不转售；
• 不伪造 auths/*.json 或改上游域名来"跑通"。

验收标准（缺一不算成功）：人类添加 ≥1 个账号后，

curl -s http://127.0.0.1:7863/healthz                 # 200 且 healthy ≥ 1
curl -s -H "Authorization: Bearer <api_key>" http://127.0.0.1:7863/v1/models

未就绪时如实上报阻塞点（缺账号 / 挂载目录权限 / 端口占用），/healthz 返回 503 且 total:0 是预期中间态，不要重复重启刷状态。

CI 会自动构建多架构镜像（amd64 / arm64）并发布到 GHCR：

# 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/misakano7545/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。日期版 v2026.9.26.711 不是语义化版本，不会额外打 1.2.3 这种 tag。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。

方式 C：静态 API Key（ck_ / pt_ 前缀，免登录）

面板「添加账号」→ 切到「API Key」标签，粘贴 CodeBuddy 平台签发的静态 Key（ck_... / pt_...）。网关先用企业口径额度端点探测该 Key（无效即拒绝、不落盘），成功后落盘并热加载进池，可填昵称与自定义 uid（缺省由 Key 的 id 段派生为 apikey-<id>）。

静态 Key 与 OAuth 账号的差别是「没有个人账号身份」：不参与签到 / 活跃上报 / 连登 / 猫猫旅行 / 夜猫子 / 成长任务（上游对这些端点没有它的记录），照常参与选号派发、对话与余额查询；面板上不渲染「签到」「任务」按钮，余额走企业口径端点。

# 模型列表
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"

# chat_completions 流式
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}'

# chat_completions 非流式（本地聚合）
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}'

# codex_responses 流式
curl -sN http://localhost:7863/v1/responses \
  -H "Authorization: Bearer your-api-key" \
  -H "Content-Type: application/json" \
  -d '{"model":"deepseek-v4-flash","input":"hi","stream":true}'

# codex_responses 非流式
curl -s http://localhost:7863/v1/responses \
  -H "Authorization: Bearer your-api-key" \
  -H "Content-Type: application/json" \
  -d '{"model":"deepseek-v4-flash","input":"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，移植上游 PR #123），判定分两级：

名单有两个来源，二者会分别缺失，所以都要：本请求声明的工具（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 窗口内仍有有效快过期批次的账号按剩余时间加权（expiringUrgency：窗口边缘 1.5 → 逼近到期 20，形状 1 - √(T/W)；会话粘性路径同口径取整展开虚拟实例）。
   • 与批次金额无关，但按到期时间分档：14 天后到期拿 1.5 倍、明天到期拿接近 20 倍——越命悬一线越优先出清。
   • 窗口内紧迫度为主轴、余额为次轴（issue #140 第 2 点）：余额贡献降权 5 倍（credits 项 10 → 2），否则余量 500 分号的基数（11）恒压过 50 分号（2），到期时间再差也翻不过来——倍率对「1 天 vs 6 天」可达的比上限只有约 8.4 倍。实测：剩 1 天/余量 50 的号权重是剩 6 天/余量 500 的号约 1.8 倍（TestExpiringUrgencyFlipsHighCreditAccount）。
   • 倍率形状用 1 - √(T/W) 而非线性：窗口 168h 下线性会让「还剩 6 天」已走完 86% 行程、与「还剩 1 天」只差 1.16 倍，永远压不过余额基数；开方后 6 天→7% 行程、1 天→92%。
   • 已知边界：高余额号同时闲置满载（权重 +5）而低余额号刚用过时，仍可能压不过——要连这种也压过就调大 expiringUrgencyMax。
   • 该偏好弱于会话粘性（绑定号健康则直接使用）与模型成本分层（按实测成本硬过滤）；已过期、零余额、无有效到期时间的账号不进入加权集。

4. 同一候选池内加权随机（快过期命中账号在上面的基础上乘紧迫度倍率 1.5→20）；未注入窗口（SetPreferExpiring 只给一个参数）时退回旧的固定 ×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）。

growth_hours（默认 [11] 整点）到点时，网关对全部可用账号跑一遍面板「任务中心」执行队列的那条路径——不是另写一套执行逻辑，是同一个队列、同一把 per-account 锁：

1. 扫描每个账号未完成且可自动化的成长待办（默认口径 + 小程序口径去重合并，locked 不入队）
2. 按账号内 autoActions 顺序排队执行：批量 accept → 动作（对话 / 桌面事件链 / 模板 / 画布 / 专家等）→ 回读进度 → 达标即自动领奖
3. 进度写进面板队列状态，前端刷新即可看到本轮跑到哪一项

语义要点：

• 幂等：全部账号都没待办时只发了几个只读列表请求，日志一行 growth 队列：全部账号没有待办任务
• 不打架：与手动「执行队列 / 一键完成」共用队列状态与账号锁——排程在跑时手动点击会被 409 / 该账号跳过，不会同账号并发两轮动作
• 账号间并发：schedule.growth_concurrency（默认 1，上限 4，面板可改、热生效）。1 = 账号逐个跑（最保守，上游风控敏感），调高更快的代价是并发面对上游更大
• 默认 11 点：排在签到（9 点）与活跃上报（10 点）之后，当天新解锁的任务已被点亮，扫得到
• 结果汇总：排程轮次跑完写一行面板日志（第 N 轮 X 项：完成 a / 跳过 b / 失败 c · 领奖 p 分 +q 能 · 耗时 t · 失败项 CODE），并在 alerting.enabled 打开时推同一条到告警 webhook（event=notify）；未配 alerting 就只落日志。手动轮次不推送（界面在看，别刷通知）
• 手动补跑：面板任务中心的「执行队列」按钮，或 POST /admin/tasks/growth/run（需 admin.enabled）
• 关闭：schedule.growth_enabled: false（只关排程，任务中心手动入口照旧可用）

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

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

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

账号池回答「哪些号不能用」，模型锁池回答「哪些模型不能用、锁了几个号、还要锁多久」——上游按模型限流（6004 / 14003）时账号仍在池里、/status 的 healthy 也照样是绿的，此前只能发一次真实请求去试（而试错本身会刷新上游的冷却计时）。

一行 = 一个 (域, 模型)，状态三态：locked（该域参与选号的号全被这个模型挡住，换模型或等解锁才有用）、starved（此刻没号能服务，但不是模型冷却造成的——账号级冷却/熔断/在途占满，等一下就好）、partial（还有号能服务，只是部分被锁）。数据与 /status 的 model_locks 同源（池内现算，只读），与 ModelBlocked（请求失败时回 400 model_unavailable）互补。禁用与暂停选号的账号不计入分母，AuditOnly 台账与已过期的冷却不算锁——口径与选号严格一致。

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

账号行「暂停选号」＝ 运维临时让位：退出选号（含全冷却兜底），状态显示「已暂停选号」，点「恢复选号」即刻回池——不清冷却域、无需解冻或重登。与「禁用」的区别：禁用是终态（授权/session 判死，需人工解冻，保号默认也停），暂停是健康账号的临时态；状态落盘（state.json 的 paused），跨重启不丢，disable / revive 会一并清掉。

• 必须照常的：签到 / 活跃上报 / 保活 / 余额刷新（不依赖 include_disabled_in_tasks）；猫猫旅行（纯 RPC：状态 / 派出 / 领奖）；连登管家；成长任务队列与任务中心扫描 / 执行（绝大部分是上报与领奖 RPC，个别动作自带一次真实短对话，如 Model_chat_GLM5.2，影响可控）。
• 唯一跳过的：夜猫子。RunNightChats 逐条发真实 glm-5.2 对话，是任务体系里唯一「整任务都是模型对话」的，与「让位防风控」正面冲突。

这就是「一次只放开一个号、其余让位」想要的粒度：让位的号不再承接选号流量，也避开夜间的对话补足；其余养号动作照常。账号行「任务」按钮的手动执行不受限。

本仓说明：这是预留功能。 本部署没有企业版账号，因此企业版相关能力（能力门控 + 企业额度展示）在本仓未经真实企业号验证——代码路径与单测齐备，但下方实测数据来自上游 PR #129 作者 yuzunyue 的 A/B 对照，不是本仓的实测结论。

如果你有企业版账号可以提供给我测试，我愿意配合验证，实测结果会回填到本节。

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

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

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

企业切换会话（token_source=enterprise_switch）判定已删除：JWT 里的 token_source 只记本次授权走了哪条流程，不代表账号是企业形态——实测两个带该章的个人版号，enterpriseId 空、roles / resource_access / azp / aud 与 oneid_login 号逐字段相同（与 WorkBuddy 客户端显示的「个人版」一致）。原先按上游 PR #162 的 A/B 结论把该章当「企业上下文」，跳过行为类任务并在面板提示重登；实测证伪：这两个号的成长任务（含只能由 /v2/report 行为事件点亮的 expert_5、Library_read、Hp_Appearance）全部 claimed=true，行为事件照常计分。故企业形态一律以 enterpriseId 为准（auth.Auth.IsEnterprise()），不再读 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）

「国际版（www.workbuddy.ai）的每日 30 分拿不到」是常见疑问，也很容易误判成「必须走网页端 Agent 的完整 ACP/SSE 会话才算活跃」。本仓实测否证了这个结论：activity_hours 的活跃上报（POST /v2/report）本身就满足国际版的活跃判定，每日 30 分照发——网关里没有任何 ACP/SSE 沙箱代码。

依据（2026-09-30 → 10-09 本机生产部署，两个国际号，GET /panel/api/packages 的 Bonus Pack）：

• 隔夜批处理结算：行为发生在 D 日 → D+1 凌晨（约 02:00–04:30）批量发包，别期望上报当场到账。
• 判到账只认包/余额，不看连登回读：report OK but streak.days=0 是「视图与发放脱节」，不是没赚到（10-02 两号都打该告警，次晨照发）。
• 前提是活跃上报对国际号已放开（默认 schedule.activity_enabled，activity_hours [10] 整点）。
• 仍然成立的两条否定结论：桌面 chat/completions 对话不计活跃；只 POST /console/as/conversations/ 建会话也不够（会话停在 CREATING，无输出、不加分）。

灵感来自上游 issue #141（Xyloz3n：建议加 schedule.intl_active_script 外部钩子或内建 ACP 骨架）。本仓用生产数据核完认为该需求已经解决，故不引入钩子/骨架——那只是把已经到账的积分再赚一遍，还要多背上凭证外传与脚本维护成本。

对池内每个可用账号在 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 秒自动轮询只读内存，不打上游。

补领清扫（schedule.task_sweep_enabled，缺省开启）：每 task_sweep_minutes（缺省 15）分钟遍历可用账号，只做两件事——accept 掉 not_accepted 的任务（默认口径与小程序口径分开提交），claim 掉 progress 已达标但未领的任务（mp 专属码走 mp 领奖端点）。它不跑任何行为链路，与 autoActions 白名单无关，属于纯补领兜底。

为什么需要它：新号自动跑成长任务时，任务往往还没达标（awaiting_progress），而成长队列一天只跑一次（schedule.growth_hours 缺省 01:00）、白名单外的任务码永远进不了队列——于是「任务达标了、面板进度是满的、积分却不涨」没有任何补领路径。领奖判据只取 progress（Task.Claimable）而不是 accept_status：后者会在回读时短暂转 completed 随后被整体回滚，据此领奖会误领。领奖幂等（重复领返回 already_claimed → 0 分 0 能），所以宁可多跑一轮也不漏领。已禁用 / 国际区 / 企业版账号一个上游请求都不发；正在跑任务动作的账号本轮让位（与单任务 / 一键完成 / 成长队列共用 per-account 锁）。

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

http://127.0.0.1:7863/panel/

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

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

顶部「刷新」按钮 = 向上游全量查询真实余额并回写（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 等）并配置访问限流；仅本机或私有网络使用时可直接运行。

成功的 chat 响应带 X-Wb-Account（实际应答账号的 uid）。budget.daily_credit_limit 大于 0 时，当日已观测扣费到顶后 chat 回 429 daily_budget_exceeded。schedule.jitter_minutes 把排程从整点摊开，0 仍是整点。admin.audit_enabled 把 /admin 操作追加到 admin.audit_file。alerting.enabled 在健康账号数、熔断数或 WAF 拦截越界时 POST webhook。这四项改完要重启；budget.daily_credit_limit 和 jitter_minutes 保存后即生效。

鉴权规则：仅当 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 |

速率只在能测出「生成段」时报：非流式没有首个 data 帧，端到端耗时里混着提示处理 （实测 35 万 token 提示、60 输出 token 的请求只有 16~90 tok/s），报出来与流式行不可比， 所以留 -。think= 用来分辨「模型在想」与「模型真慢」——高推理档流量里思考常占 completion 的七到九成。

敏感度：日志不含任何 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），代码无任何落盘日志文件

• 预编译二进制：推送到 main 或手动运行时，Actions 按系统架构分开上传 artifact，名字是 wb2api-panel-<ref>-<os>-<arch>，里面是主程序、config.example.json、README.md。推送 v* tag 时同样构建，并各挂一个 wb2api-panel-<tag>-<os>-<arch>.zip 到 Release。Docker 仍由本地 docker compose build 构建
• 登录 / 签到 / 积分工具：./login.sh / ./signin.sh / ./credit.sh
• 无产物校验和：go.sum 仅约束 Go 模块依赖；Docker 镜像由本地 docker compose build 生成，未引用第三方镜像
• 上游 CodeBuddy 属腾讯系商业产品，本项目是其非官方 OpenAI 兼容网关；使用其账号做 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 / 腾讯）接口或服务的权利；使用者仍需自行遵守上游服务条款