dsh-workbuddy2api

dsh-workbuddy2api

[!WARNING]

⚠️ 项目状态：已停止维护（2026-10-20）

本仓库不再积极维护。 不再开发新功能，不再响应 issue / PR。已安装的用户可以继续使用，但不再获得修复与适配。

原因：原始上游 Sliverkiss/workbuddy2api 已于 2026-09-24 从 GitHub 消失（API 返回 404，git ls-remote 报 Repository not found，并非改名重定向）。本插件的生命线直接绑在它身上 —— 网关二进制由本仓库 CI 从上游源码交叉编译，上游消失后，这条链路只能靠延续仓库续命。

我已改用 magpie 接入 WorkBuddy 账号：

• magpie 的社区插件 @magpie-community/opencode-workbuddy-auth 直接对接 WorkBuddy（国内版 workbuddy）与 WorkBuddy AI（国际版 workbuddy-ai）两个 provider，走浏览器 OAuth 登录，不需要自建网关、不需要 Go / Python / bash；
• magpie 是一套网关同时代理多家订阅（WorkBuddy / Trae / ZCode / …），账号池、熔断、冷却、用量统计由 magpie 统一负责，不再需要为每家订阅各养一个网关；
• 本机已切到 magpie 方案并弃用本插件的自动拉起链路。

给你的建议：

• 新用户：请直接用 magpie（magpie-community/plugins），本插件不再推荐安装；
• 已装用户：不影响继续使用。若日后遇到上游接口变动导致失效，可自行改用 magpie，或参考下方文档自行编译网关（go build 路径仍然有效）；
• 若你希望接手本插件的维护，欢迎提 issue 或直接 PR —— 但请先看下面的上游状态，接手前务必确认你要依赖的网关来源还活着。

下方内容全部保留，作为历史文档与自行构建的参考。

把 workbuddy2api 网关接进 DeepSeek Harness（dsh） 的插件。

装上之后：

• dsh 启动时自动拉起网关，退出时自动回收；端口上已有健康网关在跑则直接复用，不重复拉起，也不会去杀别人的进程。
• 模型目录自动同步 —— 模型列表、上下文窗口、输出上限、思考档位全部从网关 GET /v1/models 实时读取，不必再手写 settings.yaml 里的模型元数据。
• 6 条管理命令：/wb2api-setup · /wb2api-status · /wb2api-start · /wb2api-restart · /wb2api-login · /wb2api-account。
• 一条命令完成安装：/wb2api-setup 会取回网关可执行文件（校验 SHA256）、准备运行目录、引导登录、启动网关并同步模型 —— 不需要装 Go，也不需要 python3 / bash。

插件本身很薄：协议适配、账号池、加权选号、分级熔断、定时任务、登录与 token 刷新全部留在 Go 网关侧。它只负责两件事 —— 进程生命周期，和模型目录自动化。

---

它解决什么

直接用手工配置把 workbuddy2api 接进 dsh（在 ~/.dsh/settings.yaml 里写 llm-pi-ai.providers.workbuddy2api）也能用，但有几处手工负担：

字段映射

网关的 /v1/models 已经透出全部模型元数据（internal/server/handler.go 的 modelList()，对应上游 issue #84），因此插件无需内置静态兜底表：

内置的 openai-completions 栈不认这些非标准字段 —— 这正是当初必须手写元数据的根因，也是本插件的核心价值。

网关侧对 context_length / max_output_tokens 走四级查找链：上游动态值 → 静态种子表 → model.json 缓存 → models.dev 按需拉取；全未命中时窗口兜底 1M、输出上限省略。cn: 与 global: 两域同口径。

为什么不破坏上游的「按轮聚合」

本插件的请求序列化有两条硬约束：工具结果必须发成 role:"tool"、用户消息的内容与顺序在轮内逐字不变。破坏任一条，上游按对话轮聚合 RequestID 的兜底键就会在每个 step 漂移，用量明细重新碎片化 —— 且是静默的（网关照常回包）。

原理、实测截图与端到端证据：docs/turn-level-aggregation.md。

---

前置条件

⚠️ 上游仓库已删库（2026-09-30 确认，CI 已迁走）：原 Sliverkiss/workbuddy2api 现已 404（并非改名重定向）。 延续仓库为 HanawaBanana/workbuddy2api（MIT，描述明确写着"原 Sliverkiss/workbuddy2api 已删库"）。

• release-binaries 工作流已改为从延续仓库构建，并把 ref 钉死在 UPSTREAM_REF = 1c9aef9ab378217316ee2ddff7eace78381b46c0（2026-09-20）—— 这正是 已发布二进制内嵌的 vcs.revision（可用 go version -m wb2a-server.exe 复核）， 因此重新构建出的产物与既有版本同源、可复现。
• 升级上游时改工作流里的那一行即可；不要改回 Sliverkiss/...，那个仓库已不存在。
• 本机开发时若自行 git clone，同样应 clone 延续仓库。

2026-10-20 复核：延续仓库 HanawaBanana/workbuddy2api 仍在维护（当日 master 最新提交 af5e779，2026-10-16；未归档、无 Release）。因此"自己 go build 出来源"这条路目前仍走得通 —— 但 UPSTREAM_REF 钉在 2026-09-20 的快照上，已发布二进制比延续仓库落后约一个月。 想跟最新上游就自行 go build 并把 binaryPath 指向你的产物（插件不会覆盖它）。

1. dsh，全局安装：

   npm i -g @deepseek-ai/dsh
   

   本插件在 dsh 0.2.0-rc.2 上验证通过；package.json 声明的兼容区间是 >=0.1.2-rc.1 <0.2.0-0 || >=0.2.0-rc.1 <0.3.0-0（前一段覆盖 0.1.x，后一段覆盖 0.2.x）。

   装插件时 dsh 会拿运行时的 dsh 版本去比对这个区间（dsh-app-boot 的 evaluatePluginCompatibility，内部用 semver.satisfies(version, range, { includePrerelease: true })）。 因此 0.2.0-rc.2 这类预发布版本也能正确命中 —— 这一点很容易踩坑：若按普通 semver 语义 写 >=0.1.2-rc.1 <0.2.0-0，它反而匹配不上任何 0.1.7+ 预发布版，安装会被拒绝并回滚。

2. 一个 WorkBuddy 账号（国内外账号体系相互独立，选你有的那个）。

3. 网关二进制 —— 不用自己准备，/wb2api-setup 会自动下载并校验。

---

安装

⚠️ 先看顶部公告：本仓库已停止维护，新用户不建议安装。若你只是想用上 WorkBuddy 订阅， 直接上 magpie + @magpie-community/opencode-workbuddy-auth （浏览器 OAuth 登录，无需自建网关 / Go / Python / bash）更省事。 下面三种安装方式仅供已决定继续使用本插件的人参考。

方式一：一条命令直装（推荐）

不需要先下载文件 —— pnpm 支持直接以 Release 的 tarball URL 作为依赖（已实测：装出来是真实目录、非 link:）：

dsh plugin --profile web add https://github.com/tearslee/dsh-workbuddy2api/releases/download/v0.3.2/dsh-workbuddy2api-0.3.2.tgz

升级时把 URL 里的版本号换掉即可。

方式二：先下载再本地安装

在 Releases 下载 dsh-workbuddy2api-<版本>.tgz，然后：

dsh plugin --profile web add file:/绝对路径/dsh-workbuddy2api-0.3.2.tgz

方式三：从源码安装

git clone https://github.com/tearslee/dsh-workbuddy2api
cd dsh-workbuddy2api
npm install
node node_modules/typescript/bin/tsc -p tsconfig.json   # 必须先构建出 lib/
npm pack --pack-destination dist
dsh plugin --profile web add file:./dist/dsh-workbuddy2api-0.3.2.tgz

不要用 dsh plugin install <源码目录>：pnpm 会写成 link: 依赖，而 Windows 上工具进程创建的 junction 不可遍历，会导致 pnpm 全面失效。用 npm pack / pnpm pack 出的 tarball（解包成真实目录）可规避。

关于 npm registry（重要，别装错）：npm 上的 dsh-workbuddy2api 这个包名已被他人占用 —— 发布者是 Boiser，线上版本为 0.4.9 ~ 0.6.8（latest = 0.6.8）， 与本仓库（tearslee/dsh-workbuddy2api，当前 0.3.2）不是同一个项目。

因此：

• ❌ 不要执行 dsh plugin add dsh-workbuddy2api —— 它会装到那个同名包，而不是本插件；
• ✅ 请用上面三种方式之一，从本仓库的 GitHub Release 取 dsh-workbuddy2api-<版本>.tgz；
• 装完请核对来源与版本：本仓库的版本线是 0.1.x / 0.3.x（0.4.x 及以上均非本仓库产物）。

本仓库未在 npm 发布，也无意与同名包竞争该名称 —— 安装时认 URL / 认 tarball，不要只认包名。

装完必须重启一次 dsh（为什么）

dsh plugin add 只做两件事：把包装进 ~/.dsh/profiles/<profile>/node_modules/，以及把包名加进该 profile 的 dsh.profile.bundles。正在运行的 dsh 进程不会重新读取这个列表 —— bundles 只在启动时解析一次，插件的代码是那时被 import 进进程的。

所以：装完请重启 dsh（关闭再启动），插件与它的 workbuddy2api provider 才会出现。这不是本插件的缺陷，而是 dsh 加载模型决定的 —— 新代码还没进进程，插件自己也没有机会运行。

重启后执行 /wb2api-setup 完成初始化。

关于免重启安装

dsh 的 profile 补丁层本身是热重载的（web profile 的 patchReload 为 live），已有插件能通过宿主的热挂载能力在运行中生效。但新装的包不行：dsh plugin add 是纯磁盘操作，而运行中的进程里没有任何存活代码会去 import 这个新包。

若你的 profile 里装了 dshmarket，它具备在运行中热挂载插件的能力（hotMount）—— 前提是该插件已在其收录的 registry 里（它的安装入口只接受收录过的来源，不接受任意 URL）。本插件暂未收录，因此目前请按上面的方式安装并重启一次。

让本插件支持免重启安装是可行的（把插件提交到 dshmarket 的收录列表，或做适配），但那是另一项工作。

---

dsh 起来之后，在对话里执行：

/wb2api-setup

它会依次：① 定位或下载网关可执行文件（校验 SHA256）→ ② 准备运行目录（生成 config.json，随机 api_key，仅监听 127.0.0.1）→ ③ 引导你完成账号登录 → ④ 启动网关并同步模型目录。每一步的结果都会逐条汇报，失败会停在那一步并说明原因。

首次执行会问你要登录国内版还是国际版，也可直接指定：/wb2api-setup cn 或 /wb2api-setup global。

---

配置

插件配置写在 profile 的 cordis.patch.yml 里（或任何引用 id: workbuddy2api 的补丁）。全部字段都可省略：

- insert:
    - id: workbuddy2api
      name: 'dsh-workbuddy2api'
      config:
        baseURL: http://127.0.0.1:7863/v1
        binaryPath: /path/to/workbuddy2api/wb2a-server.exe
        repoPath: /path/to/workbuddy2api
        autoStart: true
        realmPrefixPolicy: strip-cn

网关二进制与运行目录

/wb2api-setup 会把东西装在这些位置（都在插件自己的目录下，不碰你的其它文件）：

产物来自本仓库的 Releases（GitHub Actions 从上游源码原样交叉编译，未改一行上游代码），下载后会与 SHA256SUMS.txt 比对，不匹配就拒绝安装。

生成的 config.json 有两处刻意选择：

• 只监听 127.0.0.1（上游示例的 :7863 会绑 0.0.0.0，等于把带账号池的网关暴露到局域网）；
• 随机 api_key（网关在 api_key 为空时完全不鉴权，而 /status 会暴露账号与积分）。

已存在的 config.json 绝不会被覆盖 —— 你改了池参数、冷却策略或 auth_dir 都会被保留。

autoDownloadBinary 为什么默认关

隐式时机的联网下载在离线/内网环境只会刷报错，而用户从未要求联网。显式执行 /wb2api-setup 时无视该开关（那是明确意图）。想彻底零步骤的话把它设为 true。

apiKey 的解析顺序

1. dsh 凭据库（~/.dsh/.credentials.yaml 的 refs.WORKBUDDY2API_API_KEY）
2. 同名环境变量
3. 网关自己的 config.json 里的 api_key（含插件自动生成的那份）

同机部署时第 3 条即可命中，通常无需任何额外配置。

子进程环境会被 dsh 清洗（凭据形名称与 DSH_* 全部移除），所以网关需要的变量必须经上面的 env 显式传入。

realmPrefixPolicy：模型 id 的前缀策略

网关的模型 id 带 realm 前缀（cn:deepseek-v4.1-flash / global:gpt-5.4）。

• strip-cn（默认） —— 剥掉 cn:，保留 global:。模型 id 与你手工配置时期一致，历史会话与预设无需迁移。
• keep —— 原样透出 cn: / global:。双域账号并存时可显式路由到国际版账号。

只有 CN 账号时两种策略行为一致：网关的 resolveModel 对无前缀名一律判为 cn 域。

线格式与展示是两件事：无论哪种策略，插件发出请求前都会把无前缀 id 补成 cn:<id>，避免 realm 解析歧义。

---

命令

关于「复用外部网关」

启动前插件会先探 GET /healthz（该端点无需鉴权）：

• 端口上已有健康网关 → 直接复用，状态记为 external，插件不会再拉一个进程。这正是「以前手工常驻了一个 wb2api」的迁移场景：装完插件一切照旧可用，但那个进程仍归你管 —— dsh 退出时不会去杀它（插件不杀自己没启动的进程）。
• 端口空闲 → 解析可执行文件并 spawn，此后它的生命周期归 dsh，dispose 时一并回收。
• 端口被非网关程序占用 → 明确报错，而不是静默失败。

所以：想让网关真正由 dsh 托管，先停掉你手工启动的那个进程，再重启 dsh。/wb2api-status 的 状态: 一行会告诉你当前是哪种情形。

登录

/wb2api-login 会向 WorkBuddy 申请一条授权链接并弹窗给你打开；你在浏览器里完成授权后，它自动取回凭证、写入 auths/ 并重启网关加载。

这套流程与上游 login.sh + cmd/login 同款端点、同款凭证格式（插件用 Node 复刻，因此不需要 bash 与 python3）。国内版会顺手做一次每日签到，失败不影响登录。

不带参数时会问你要登录国内版还是国际版；也可直接写 /wb2api-login cn 或 /wb2api-login global。想固定下来就设配置项 defaultRealm。

切换账号

/wb2api-account 决定网关能看见哪些账号。不带参数时弹出可点选列表（当前选择 + 每个账号的昵称、realm、积分、冷却状态），带参数则直接切：

/wb2api-account auto            # 恢复全部账号参与加权轮换（默认）
/wb2api-account 2               # 只启用列表里第 2 个账号
/wb2api-account oneid_3000      # 只启用 uid 以该前缀开头的账号（前缀必须唯一命中）

机制：重命名凭证文件，不改网关一行代码。 网关只加载匹配 workbuddy*.json 的文件（internal/auth/auth.go 的 AuthFileGlob），因此把其余文件改名成 workbuddy-<uid>.json.disabled 就等于「它们不存在」。上游升级零冲突。只改名、从不删除，auto 即把后缀去掉 —— 所以状态即文件：重启 dsh、换机器、用户手工改名，读出来的选择都一致。

为什么走「停网关 → 改名 → 启网关」（所以命令不用 supervisor.restart()）：网关运行中会因 token 临近过期把凭证原子写回，落点取自它内存里的旧路径 —— 可能把刚改名的文件重新创建出来，于是切换「看着成功，一分钟后又变回去」。先停进程，写回就不会发生。

较新的网关（含本插件 Release 的二进制）已加入 auths/ 目录热加载（每 5 秒轮询），改名本身也会被感知；但上面这个顺序仍然保留 —— 它对旧版自编译二进制是必需的，对新版也消除了改名与 token 刷新的竞态窗口。代价只是一次 1~3 秒重启。

复用外部网关时不支持切换。 此时进程不归插件管（/wb2api-status 的 状态: 一行显示 复用外部已运行的网关），停不掉 ⇒ 必然踩上面那条。命令会直接拒绝并提示：先停掉那个进程让插件托管，或改用 /wb2api-login 加号。

取舍与风险：

• 被禁用的账号不参与轮换，也不再刷新 token。长期禁用后其 refresh_token 可能失效；恢复时若报会话失效，重跑 /wb2api-login 即可（同一 uid 覆盖同一份凭证文件）。
• 被禁用的账号不再出现在网关 /status 里，因此列表里它的积分显示为「未知」（昵称与 realm 仍从文件读出）。
• 「只启用一个号」不等于「优先用这个号」：池里只剩它一个，网关无从回退。它正在冷却时请求可能 429 或 503 —— 这是「没有别的号可换」的必然表现，不是切换失败。要恢复自动兜底就 /wb2api-account auto。
• 切换只影响网关的账号集，与你在 WorkBuddy 桌面端登录的是哪个账号无关（那是另一条路线，见 Python 版 codebuddy2api）。

---

已知限制

• 窗口/输出上限是「上游实际值 + 本地估计」的混合。 网关对 context_length 走四级查找链：上游动态值权威 → 静态种子表 → model.json 缓存 → models.dev 按需拉取；全未命中时兜底 1M。因此冷门模型的窗口可能是兜底值而非真实值。max_output_tokens 同理，未收录时网关不下发该键，此时插件不声明 defaultMaxTokens，由网关自行决定。
• 无账号时网关「启动 ≠ 可用」。 进程起来但 /healthz 报 healthy: 0，插件会把状态标为「运行中（无可用账号）」而不是假装成功。
• 切换账号仍会重启网关。 切换靠重命名凭证文件实现（见上）。较新的网关有 5 秒热加载能自行感知，本插件仍走一次重启以确保新旧二进制行为一致，代价是中断正在进行的请求 1~3 秒。
• 预编译产物来自本仓库的 CI，可能与上游最新提交有延迟。 想紧跟上游就自行 go build（把 binaryPath 指向你的产物，插件不会覆盖它）。上游若改动凭证格式或路由，本插件的适配可能滞后。
• 模型不出现在「设置 → 模型」页，只在聊天窗口的模型选择器里。 这是 dsh 的既定设计，不是本插件的缺陷：设置页本质是配置文件编辑器，dsh-client-ui-settings-models 只认 llm-deepseek 与 llm-pi-ai 两个 settings namespace，其余不渲染 provider 行；而本插件的 provider 是代码注册的运行时路由，模型目录来自网关 /v1/models，本就不属于那个界面管辖。要确认模型可用：看聊天窗口的模型选择器，或执行 /wb2api-status。

---

常见问题

网关起不来，日志只有 load config: read config: open config.json: ...

网关在找不到 config.json 时直接退出（上游那段「缺配置就用默认值+环境变量」的兜底因为 os.IsNotExist 判不透包装错误而永远进不去 —— 见「为什么有几处写法看起来多余」）。

先跑 /wb2api-setup：它会补建运行目录并生成配置。若你希望自己管这份目录，就把插件配置的 repoPath 指到网关源码目录（那里有你的 config.json），插件即不会再碰 ~/.dsh/wb2api/。

网关起来了但 /healthz 一直是 healthy: 0

进程没问题，是没有可用账号。执行 /wb2api-login 登录一个账号；若已有账号，用 /wb2api-status 看它是不是正在冷却（单一账号时冷却就等于全部请求失败，见下）。

启动日志出现 provider 注册被拒（DUPLICATE_ADAPTER）

插件注册 workbuddy2api 路由后，如果 ~/.dsh/settings.yaml 里还留着同名 provider，会看到：

[workbuddy2api] provider 目录注册被拒：configurable provider "workbuddy2api" is already declared
[workbuddy2api] 适配器注册被拒（DUPLICATE_ADAPTER）：an adapter for provider "workbuddy2api" is already registered

dsh 仍会正常启动（插件故意不把冲突抛出去，避免把一个本来可用的环境弄成起不来），但此时模型请求走的是 settings.yaml 里那份手工配置，自动元数据不生效。/wb2api-status 也会显示这条警告。

处理：从 ~/.dsh/settings.yaml 删除整段 llm-pi-ai.providers.workbuddy2api（连同它下面那批模型元数据），然后重启：

llm-pi-ai:
  providers:
    workbuddy2api:      # ← 从这一行删到该 provider 段的末尾

其余引用保持不变 —— provider id 没变，这些无需改动：

agent-default-model:
  provider: workbuddy2api       # 保持不变
subagent-model-selection:
  allowedModels:
    - provider: workbuddy2api   # 保持不变

仓库自带脚本 scripts/migrate-settings.ps1 可按缩进精确摘除该段并自动备份（不重写整个文件，dsh 自己的注释与键顺序都保留）：

# 先预览要删什么
pwsh -File scripts/migrate-settings.ps1 -WhatIf

# 确认后执行（请在 dsh 已关闭时做）
pwsh -File scripts/migrate-settings.ps1

脚本会打印回滚命令（把自动备份拷回来即可）。

为什么必须在 dsh 关闭时执行：settings.yaml 是被热监听的（dsh-settings-file 用 chokidar 监视）。在 dsh 运行中删掉该段会立刻生效，而插件那份 provider 要等重启才会注册 —— 中间窗口里模型会不可用，正在进行的会话可能直接失败。

---

合规声明

• 本插件不包含、不转发 workbuddy2api 的任何源码。网关源码始终来自上游仓库。
• 本仓库的 Releases 提供由本仓库 CI 从上游源码原样交叉编译的可执行文件（构建过程见 .github/workflows/release-binaries.yml：先断言上游工作区未被修改，再校验产物内嵌的 vcs.modified=false）。上游不提供预编译产物，这些二进制是为了让用户不必自装 Go 工具链；许可证与免责声明仍归上游。介意第三方构建的话，请自行 go build 并把 binaryPath 指向你的产物。
• workbuddy2api 的许可与免责声明由其自身条款约束，使用前请自行阅读。
• 本插件以 MIT 许可发布，与上游无隶属关系。

---

开发

npm install
node node_modules/typescript/bin/tsc -p tsconfig.json   # 构建（不要用 pnpm build）
node node_modules/vitest/vitest.mjs run                  # 单元测试

集成测试会真实发起对话（消耗账号额度），需显式开启：

$env:DSH_WB2API_E2E='1'; $env:DSH_WB2API_E2E_CONFIRM='yes'
$env:DSH_WB2API_E2E_API_KEY='<网关 api_key>'
node node_modules/vitest/vitest.mjs run --config vitest.e2e.config.ts

代码结构

为什么有几处写法看起来"多余"

这些都有具体原因，改动前请先读对应注释：

• 工具结果必须发成 role:"tool" —— harness 把结果搭载在 user 角色消息里，原样发出会让网关的 TurnKey 取到工具输出、每个 step 换一个聚合键，RequestID 碎片化因此静默复发。详见 轮级聚合 与 tests/unit/turn-key-contract.spec.ts。
• Config 必须用 Schema.object({...}) 构造 —— settings.describe() 会对每个注册项调用 schema.toJSON()，传裸函数会抛 TypeError，连带让模型设置页、主题、sidebar 的 settings API 全部失效。
• SSE 按 \n 切行而不是 \n\n 切事件 —— 网关一帧 = 一行 data:。
• 工具 id 靠 Map 按 index 复用 —— 只有首个分片带 id。
• function.name 只在非空时更新 —— 后续分片带 ""（不是 undefined），直接覆盖会导致 unknown tool ""。
• 残缺工具参数报 max-tokens 而不是 tool-calls —— 报 tool-calls 会让 harness 执行半截 JSON 并把脏参数写进会话历史，报 max-tokens 才会丢弃并重试。
• readWithIdleTimeout 的 abort 分支也要 reject —— 只清定时器会让 Promise.race 永远悬空，generator 既不产出也不返回。
• provider 注册冲突只记日志、不抛错 —— 冲突意味着用户还没迁移旧配置，此时抛错会让 dsh 起不来，把一个可用环境变成完全不可用。
• 切换账号的顺序必须是「停 → 改名 → 启」 —— 网关运行中会用内存里的旧 FilePath 把凭证原子写回，改名会被它撤销。所以 /wb2api-account 刻意不用 supervisor.restart()（它无法在停与启之间插一步动作）；改名本身失败时也会把网关拉回来，不把环境留在「网关已停」。
• 自动下载必须同时生成 config.json —— 上游 main.go 写了「配置不存在就用默认值+环境变量」的兜底，但它用 os.IsNotExist() 判断一个已被 fmt.Errorf("read config: %w", …) 包装过的错误，永远为假，于是进程直接 log.Fatalf 退出（实测：二进制放进空目录执行，4 秒内退出，只留一行 load config: read config: open config.json: …）。所以插件必须自己写这份配置。
• 生成的配置只监听 127.0.0.1 且必带随机 api_key —— 上游示例的 :7863 会绑 0.0.0.0（实测 netstat 可见），而网关在 api_key 为空时完全不鉴权，/status 会暴露账号与积分。
• 装二进制前必须校验 SHA256，且拿不到校验和就拒绝安装 —— 下载的是会被执行的文件。校验和清单缺失时"下都下了就装"等于没有校验。
• auths/ 目录必须先于网关启动而存在 —— 网关只在启动时探测该目录，不可读就永久跳过 auths 热加载（实测日志：[watch] auths 目录 ./auths 不可读，跳过热加载监听（加账号后需手动重启）），之后新增账号不会再被自动加载。

---

延伸阅读

• 轮级聚合：让一次对话只有一个 RequestID —— 为什么要按现在的方式序列化请求
• 轮级聚合键的跨语言验证工具 —— 用上游真实 Go 实现验证适配器产出
• 方案与调研记录（2026-09-15） —— 设计取舍与上游能力调研

---

许可

MIT