mirror of
https://gitcode.com/JianFeeeee/ModelRouter.git
synced 2026-11-12 04:07:25 +00:00
chore!: 移除厂商私有协议适配器与渠道业务插件（合规清理）
G-Star 合规要求下，把"模拟官方客户端、复刻私有协议、自动领取平台额度"这一类 能力整体移出仓库。这些实现依赖各平台未公开的端点、签名算法与官方 client id， 属于绕过客户端校验获取额度，风险高于普通协议适配。 移除（93 个文件）： - 适配器：opencodezen（伪装 UA 取免费池）、trae、buddy、kimicode - 插件：channels.lua（12 个平台登录/领额度/签到）、quota.lua（厂商额度探针） - 随之删除的 78 个渠道/额度专用测试与 3 份渠道文档 同时修掉的既有问题： - **硬编码第三方 OAuth client_secret**（Google Cloud Code 的 GOCSPX-…，两处） 随 channels.lua 一起消失。 - `deploy.sh` 的 `sync_plugins` 整段删除：它仍按"内置插件是发行物"的旧前提 把插件复制/覆盖进 plugin_dir，与"插件属运维资产、网关不安装不覆盖"的契约 冲突。现在部署脚本只同步适配器与二进制/配置。 - 适配器清单去掉已移除项；e2e 配置改用显式 `auto:` 链（`models.priority` 早已 移除，该测试此前已失效）。 保留（公开协议）：openai / anthropic / gemini / deepseek / github / groq / mistral / ollama / qwen38 / sensenova = 10 个适配器；插件示例 billing / usage。 验证：go build -tags luajit ./... OK；internal/lua 21.4s、provider、core 51s、 gateway 122.8s、e2e 9.0s 全绿。
This commit is contained in:
JianFeeeee
@ -47,14 +47,15 @@ return {
|
||||
|
||||
### 内置适配器
|
||||
|
||||
`openai` `deepseek` `anthropic` `gemini` `github` `groq` `mistral` `ollama` `kimicode`
|
||||
`openai` `deepseek` `anthropic` `gemini` `github` `groq` `mistral` `ollama` `qwen38` `sensenova`
|
||||
`qwen38` `sensenova` `trae`。
|
||||
|
||||
`anthropic`/`gemini`/`ollama` 适配器内置多模态转换（`image_url` → 各自上游格式）；
|
||||
推理开关由中立的 `thinking` 字段表达，`deepseek` 适配器把它映射为
|
||||
`thinking.type = "disabled"`。
|
||||
|
||||
**kimicode** 是展示 `build_headers` 的样例：云端校验调用方 app，需要按
|
||||
适配器可用 `build_headers(meta)` 注入签名头。示例见 `adapters/` 下任一脚本的
|
||||
`build_headers` 实现；云端校验调用方 app 时需要按
|
||||
`meta.app_secret` 对时间戳+URL+请求体哈希做 HMAC 签名并附 `X-App-Sign` 等头。
|
||||
配好 `sources[].meta.{app_id, app_secret, app_agent}` 即可。
|
||||
|
||||
|
||||
@ -1,125 +0,0 @@
|
||||
# 渠道问题清单（2026-10-19 晚生产实测）
|
||||
|
||||
> 逐项修复。每项标注：现象 / 根因 / 状态。
|
||||
|
||||
## P1 trae 非流式 500（unmarshal unified response: invalid character 'e'）
|
||||
- **现象**：`stream:false` 打 `channels-trae:*` 必现 500，body 以 `event:metadata data:{...}` 开头。
|
||||
- **根因**：trae SOLO 上游**对非流式请求也回 SSE**（且帧带 `event:` 前缀）。
|
||||
插件自装的 `channels-trae` 适配器 `transform_response` 直接 `__prelude.openai_response(raw_body)`，
|
||||
不识别 SSE；而内核只把 `data:` 行交给流式适配器，非流式路径把**整个 body**（含 `event:` 行）
|
||||
塞给 transform_response → json.decode 失败 → 原样返回 → Go 侧 unmarshal 报 `invalid character 'e'`。
|
||||
（`internal/lua/adapters/trae.lua` 有 SSE 聚合逻辑，但 channels 平台用的是**插件内嵌**
|
||||
`TRAE_SOLO_ADAPTER_SRC`（channels.lua:9744），两份代码不同步。）
|
||||
- **修法**：`TRAE_SOLO_ADAPTER_SRC.transform_response` 加 SSE 聚合（复用流式帧解析，
|
||||
聚合成一个非流式响应），并把 `internal/lua/adapters/trae.lua` 的聚合逻辑对齐。
|
||||
- **状态**：✅ 已修复（`aggregate_solo_sse`）并部署生产，实测非流式返回 200 正常内容。
|
||||
|
||||
## P2 buddy（CodeBuddy）非流式 400（11101 Non-stream not supported）
|
||||
- **现象**：`stream:false` 打 `channels-buddy:*` 上游 400 `11101: Non-stream chat request is currently not supported`。
|
||||
- **根因**：腾讯 codebuddy 网关**只支持流式**。适配器 `transform_request` 没有强制 `stream=true`，
|
||||
非流式请求原样透传被上游拒绝。buddy 的 `Accept: text/event-stream` 头已发，但 body.stream 仍是 false。
|
||||
- **修法**：`buddy.lua transform_request` 强制 `req.stream = true`；`transform_response` 增加
|
||||
SSE 聚合兜底（内核非流式路径收到 SSE 时聚合）。参考 opencodezen.lua 的既有做法（门禁第 4 条）。
|
||||
- **状态**：✅ 已修复并部署生产，实测非流式返回 200 正常内容。
|
||||
|
||||
## P3 buddy 偶发 provider busy（429）＋ 11133 参数拒绝
|
||||
- **现象**：连续请求 `channels-buddy` 间歇返回 `provider busy`（source 并发槽 max_concurrent=1
|
||||
被占满）与上游 `11133: the request parameters were rejected`。
|
||||
- **根因**：① max_concurrent=1 是**刻意的**（channels.lua:4332 注释：并发配额按模型计），busy
|
||||
是正常自保；② 11133 与空 tool_calls 修复（未提交的 buddy.lua 改动）相关，待部署后观察。
|
||||
- **状态**：观察项，非缺陷。
|
||||
|
||||
## P4 Qoder 领取失败（缺少凭据对象）——已修复
|
||||
- **现象**：`channels/claim` 报 `{"error":"缺少凭据对象"}`，而 account_test 正常。
|
||||
- **根因**：qoder 是 PKCE 设备码流且无 register 第二跳，落库凭据是**裸 token 字符串**；
|
||||
`qoderClaim` 硬要求 `type(cred)=="table"`。
|
||||
- **修法**：`qoderClaim` 兼容裸 token（非空时包 `{access_token=tok}`）；
|
||||
回归测试 `TestQoderClaimAcceptsBareTokenCredential`。
|
||||
- **状态**：✅ 已修复并部署生产（claim 现在返回真实上游业务结论）。
|
||||
|
||||
## P5 Qoder/OpenCode 渠道页账号串台（UI 渲染竞态）
|
||||
- **现象**：从 qoder 切到 opencode 详情页，qoder 的账号行闪现在 opencode 卡片下。
|
||||
- **根因**：`renderDetail()` 切渠道时不清空 `#ch-accts`，`renderAccounts` 是异步的，
|
||||
空窗期 DOM 仍挂旧渠道账号行；且慢的旧请求返回会覆盖新渠道数据。
|
||||
- **修法**：① renderDetail 立即清空账号/模型区并置"加载中"；② renderAccounts/renderModels
|
||||
加代际校验（`state.selected !== id` 时丢弃响应）。
|
||||
- **状态**：✅ 已修复并部署生产。
|
||||
|
||||
## P6 CodeArts「完全不可用」——多数模型实际可用
|
||||
- **现象**：用户报"codearts 完全不可用"。实测逐模型探测：
|
||||
- 可用：openpangu-2.0-flash/pro、GLM-5.2、glm-5.3、kimi-k2.6-vl、Qwen3-VL-235B、glm-5.2-sft-harmony
|
||||
- 429（限流非下架）：deepseek-v4.1-flash、deepseek-v4-flash、openpangu-2.0-pro（间歇）
|
||||
- 404（真下架，需标 disabled）：GLM-5.3 报 `InferHub.002002009.404: The model is not registered`
|
||||
- **附带发现**：`GLM-5.3`（大写变体）不在 deadModels 记录里——`recordDeadModel` 只被
|
||||
`__record_dead_probe` 调用，**request_end hook 没接 isModelGone**（583976f 引入的
|
||||
基础设施丢了挂接点）。需要把 on_request_end 补上 dead-model 记录。
|
||||
- **凭据**：expiresAt 已过期（15:05），`account/refresh` 续期成功（refreshable=true）。
|
||||
建议把「凭据到期自动续期」纳入定时任务检查。
|
||||
- **修法（2026-10-20 完成）**：
|
||||
- `on_request_end` 补上 `isModelGone` + `recordDeadModel` 挂接（P9 一并解决）；
|
||||
- **凭据自动续期失效的真根因**：`credentialExpiresAtMs` 把 ISO 过期时刻按**本地时区**
|
||||
解析，而 codearts 给的是 UTC ISO（`2026-10-19T16:42:43.06Z`）⇒ 本机 +08 下过期时刻
|
||||
虚早 8 小时 ⇒ `refresh_creds` 每 30 分钟都判"已过期"并对华为云真打一次 STS
|
||||
（token 本来还有 23 小时寿命）。已改为按声明时区解析（Z/±hh:mm/无后缀=UTC 三种形态
|
||||
同一 epoch），回归测试 `TestCredentialExpiresAtMsParsesISOAsUTC`。
|
||||
- **状态**：✅ 已修复并部署生产。
|
||||
|
||||
## P7 CodeBuddy 海外账号 / Qoder 国内账号
|
||||
- **现象**：CodeBuddy 登录只走国内（copilot.tencent.com），Qoder 登录只走国际
|
||||
（openapi.qoder.sh / qoder.com）。用户要求两边都能选区。
|
||||
- **根因**：平台表单区硬编码。buddy 的 state-poll 端点与 Qoder 的 PKCE 端点都锁死一个区域。
|
||||
- **修法（2026-10-20 已实施，账号级 region）**：
|
||||
- 凭据 JSON 增加 `region` 字段（`intl`|`cn`，缺省 = 历史行为）；
|
||||
- `start_login` 接受 `region`，会话带着它选端点；登录完成写进凭据；
|
||||
- **CodeBuddy**：cn = `copilot.tencent.com`（platform=ide），intl = `www.workbuddy.ai`
|
||||
（platform=`workbuddy-ai`，X-Domain/X-Product-Code/UA 按区域切换；实测
|
||||
`POST /v2/plugin/auth/state?platform=workbuddy-ai` 回 200 信封）；
|
||||
- **Qoder**：intl = `openapi.qoder.sh` + `qoder.com`（client_id e883ade2-…），
|
||||
cn = `openapi.qoder.com.cn` + `qoder.cn`（client_id **不同**：732aef47-…，
|
||||
照参考 QODER_CN；用国际版 id 授权页报「参数无效」）。CN 无公开 chat 端点
|
||||
（参考实测 503）⇒ CN 账号只做登录/领取，不产源；
|
||||
- UI：buddy/qoder 详情页多一个「＋国际区」按钮（默认国内/国际主区）。
|
||||
- **状态**：✅ 已实施并部署生产。
|
||||
|
||||
## P8 商汤（Raccoon）扫码登录「链接无效」——已修复
|
||||
- **现象**：用户点登录看到的链接打不开（404）。
|
||||
- **根因（两个，2026-10-20 实测定位）**：
|
||||
① 登录页 `/login/mp` **已被站点删除**（Next 路由 404，只有 404 页面返回）；
|
||||
② 旧实现**本地随机造 qrcode_code**，而上游早已不认自造码：旧端点
|
||||
`/api/web/auth/v1/login_with_qrcode_code` 对任意 code 恒回 `pending`
|
||||
（服务端根本没有该会话）⇒ 扫码永远完不成，账号一直空凭据。
|
||||
- **修法**：改为上游现行 IAM 流程（逐行对齐其网页客户端 auth chunk）：
|
||||
① `POST /api/iam/v1/auth/mp/qrcode` 由**服务端建会话**（返回 qrcode_code /
|
||||
scan_path / expires_in / poll_interval）；
|
||||
② 链接/二维码内容 = `https://xiaohuanxiong.com/login?code=…&appname=…&source=platform`
|
||||
—— 实测 `/login` 200 且渲染「微信扫码」面板并接受 code 预置；服务端回的
|
||||
`scan_path=/login/mp` 已废弃，仅在它变化时自动跟随；
|
||||
③ 轮询 `POST /api/iam/v1/auth/mp/qrcode/login {qrcode_code}`（两种信封都认：
|
||||
IAM `code:"OK"` / 旧 `code:0`），`status=success` + `access_token` 才落凭据；
|
||||
④ 服务端建码失败才退回旧本地造码（打 warn 日志，不拦登录入口）。
|
||||
- **状态**：✅ 已修复并部署生产。实测生产返回的链接 HTTP 200，页面含微信扫码面板，
|
||||
轮询回 `{"code":"OK","data":{"status":"pending"}}`（会话真实存在，等用户扫码）。
|
||||
|
||||
## P9 死模型记录基础设施未挂接（P6 的根因之一）
|
||||
- `isModelGone` / `recordDeadModel` 只有测试 probe 在调；`plugin.hooks = { request_end }` 的
|
||||
`on_request_end` 只处理 term_error（账号级），不记模型级死亡。
|
||||
- **修法**：on_request_end 失败分支里，取 payload.model + error message，
|
||||
`isModelGone(msg)` 为真时 `recordDeadModel(provider, model, msg)` 并重同步源。
|
||||
- **状态**：✅ 已修复并部署生产（真实 404 现在会进 deadModels）。
|
||||
|
||||
## 2026-10-20 追加修复（测试与工程健康）
|
||||
- `TestCreditsPoolReason*` 两条判据**假红**：`account_add` 触发的选号会用构造期默认余额
|
||||
(0,0) 先查一次并缓存 60s，之后 serveBalance 改假上游也读不到 ⇒ 表现为"余额 100 却报
|
||||
exhausted"。修法：harness 在改余额后清 TTL 缓存（`__ttl_reset_probe`，与生产同一实现）。
|
||||
- `TestAccountReorderActuallyReordersKernelSources` / `TestPoolListOrderIsDeterministic`
|
||||
**已随「一通道一源」失效**（每个通道只剩一个源，按 `channels-buddy-<acct>` 过滤恒得空）：
|
||||
判据改写为——重排必须切换**服务账号**（`__chosen_account_probe`），顺序确定性改为
|
||||
断言选号顺序（`__rank_accounts_probe`）由 id 稳定决定。
|
||||
- channels.lua 顶层 local 余量回归绿：区域表/适配器源码常量收进 `plugin.K`
|
||||
（`TestChannelsLuaHasLocalHeadroom` 需要 ≥10 槽位）。
|
||||
|
||||
## 部署注意事项
|
||||
- 工作树有未提交改动：buddy.lua / trae.lua（tool_calls 空 {} 过滤）、provider.go（stop→tool_calls 归一）、
|
||||
channels.lua（qoder 裸 token + UI 竞态）、provider_test.go、channels_qoder_claim_test.go。
|
||||
- 生产 channels.lua 哈希与仓库不同步是常态（deploy.sh 会 sync_plugins）。
|
||||
- 商汤账号：用户需在二维码有效期内扫码确认；当前账号 5a2ea34df521 无凭据属正常（未完成扫码）。
|
||||
@ -1,183 +0,0 @@
|
||||
# 渠道链路修复计划与现状
|
||||
|
||||
> 本文是 `plan.md` 中「渠道链路修复计划（2026-10-17 起）」章节的**可提交版本**。
|
||||
> `plan.md` 本身被 `.gitignore` 忽略（本地工作台账），故关键计划与现状单独落在这里，
|
||||
> 以便随代码一起进 git、供他人查阅。
|
||||
>
|
||||
> **写作原则：只写实测到的，标注"推断"的必须写明。** 每条缺陷都附可复现的观测。
|
||||
|
||||
> 记录 **2026-10-17 用户报障三连修**（模型不可用 / 额度异常 / 其他渠道同类）
|
||||
> 的现状与后续计划。上接 `plan.md` §9（v2 契约收尾）。
|
||||
|
||||
## 1. 现状快照（2026-10-17 14:00 实测，非推断）
|
||||
|
||||
### 1.1 生产实例
|
||||
|
||||
| 项 | 值 |
|
||||
|---|---|
|
||||
| 服务 | `active`，NRestarts=0 |
|
||||
| 二进制 sha256 | `56396f79bfc2433a`（与仓库逐字节一致） |
|
||||
| 插件 sha256 | `c15cb4bf5d5c0f21`（与仓库逐字节一致） |
|
||||
| 插件 | 4 个（billing/channels/quota/usage）**全部 loaded** |
|
||||
| 源 / 适配器 | 21 源 / 23 适配器 |
|
||||
| 账号池 | **仅 trae、buddy 各有 1 个有凭据账号**；其余 10 个平台**账号数 0** |
|
||||
|
||||
### 1.2 各渠道缺陷矩阵（本文件写入时的实测）
|
||||
|
||||
自装适配器（插件在加载时经 `__llmsproxy_adapters` 装入）：
|
||||
|
||||
| 适配器 | `build_headers` | 静态 `adapter.headers` | 流式转换 | 鉴权是否可能错 |
|
||||
|---|---|---|---|---|
|
||||
| `codearts` | 有 | 无 | 复合 openai | 有（SDK-HMAC 自签，已实现） |
|
||||
| `channels-trae` | **有（本次新加）** | 无 | **SOLO 自定义（本次新写）** | 已修 |
|
||||
| `channels-gemini` | **★ 缺** | 有 | 自定义 | 静态头 + Bearer，**待确认** |
|
||||
| `channels-zcode` | **★ 缺** | 无 | 无（继承 anthropic 基座） | **★ 高度可疑** |
|
||||
| `channels-cline` | **★ 缺** | 无 | 套 openai | **★ 可疑**（要 `Bearer workos:<jwt>`） |
|
||||
| `channels-qoder` | **★ 缺** | 无 | 套 openai | **★ 可疑**（头由 WASM 生成） |
|
||||
|
||||
内置适配器里 `build_headers` 只有 3 个有（buddy / kimicode / opencodezen），
|
||||
其余 11 个（含 **anthropic 基座**）靠静态头 + 内核兜底 `Bearer`。
|
||||
|
||||
> **★ anthropic 基座本身没有 `build_headers`**，而 anthropic 协议实际要
|
||||
> `x-api-key` 而非 `Authorization: Bearer`。`channels-zcode` 继承它 ⇒
|
||||
> 一旦有账号就会立刻暴露，与 trae 修复前完全同型。
|
||||
|
||||
### 1.3 已验证可用的通道（生产实测，不是单测）
|
||||
|
||||
| 模型（源限定名） | 结果 |
|
||||
|---|---|
|
||||
| `channels-trae-b8dd6b3df30e:Doubao-Seed-2.1-Pro` | ✅ 80 帧，正文 27 + 推理 299 |
|
||||
| `channels-trae-b8dd6b3df30e:glm-5.2` | ✅ OK |
|
||||
| `channels-buddy-buddy-main:hy4-preview` | ✅ OK |
|
||||
|
||||
| 端点 | 结果 |
|
||||
|---|---|
|
||||
| `channels/credits/status` (trae) | ✅ `active:true, dailyCredit:100, todayCheckedIn:true` |
|
||||
| `channels/credits/balances` (trae) | ✅ `total:598.516 credits` |
|
||||
|
||||
### 1.4 本轮已修（代码已部署生产，**尚未提交 git**）
|
||||
|
||||
**① 网关解不开 `源名:模型名` 限定名**（`internal/provider/registry.go`）
|
||||
|
||||
- 根因：`ResolvePinned` 用 `strings.IndexAny(model, "-:/")` 找**第一个**分隔符。
|
||||
渠道源名形如 `channels-trae-b8dd6b3df30e`（**含 `-`**）⇒ 切成 `src="channels"`
|
||||
⇒ 永不匹配 ⇒ `Resolve()` 返回 nil ⇒ `model "..." is not configured`。
|
||||
- 为什么必须支持：本实例 **44 个模型被多源同时提供**（`glm-5.2` 由 6 个源提供），
|
||||
WebUI 下拉框用 `源名:模型名` 作 option value 是**有意设计**。
|
||||
- 修法：抽 `splitPinned()`，**按已知源名做最长前缀匹配**（源名是已知集合，
|
||||
唯一可靠办法），保留旧 `-:/` 兜底。`EffectiveModel` 同步修。
|
||||
- 判据：`internal/provider/registry_pinned_name_test.go`（4 用例，变异 1/1 咬住）。
|
||||
|
||||
**② trae 适配器三连错**（`internal/lua/plugins/channels.lua`，逐层剥开）
|
||||
|
||||
1. **没有 `build_headers`** ⇒ 内核兜底发 `Bearer`，而 trae 推理端点要
|
||||
`Cloud-IDE-JWT` + 设备身份头 ⇒ 401「not able to authenticate you」。
|
||||
→ 与「额度不可用」是**同一根因的两个出口**（额度端点当轮修了、推理端点漏了）。
|
||||
2. **header 常量值是错的**：`X-App-Id` 抄成 `6eefa6c9`（真实
|
||||
`6eefa01c-1036-4c7e-9ca5-d891f63bfcd8`）、`app_version_code` 用 `0.1.52`
|
||||
（真实是**日期式** `20260811`）⇒ 上游 `4001 binding: expr_path=app_version_code,
|
||||
cause=parameter type does not match binding data`。
|
||||
3. **流式转换完全不对**：TRAE 是 **SOLO 自定义 SSE**
|
||||
（`event:output` → `data:{"response":"###","reasoning_content":...}`）。
|
||||
套 `openai_stream_chunk` ⇒ 无 `choices` ⇒ `empty stream`；
|
||||
改成 OpenAI 外壳 `{choices:[{delta}]}` **仍不对** —— 内核
|
||||
`json.Unmarshal(unified, &UnifiedChunk)` 解的是**扁平结构**，外壳字段全丢。
|
||||
⇒ 必须输出扁平 `{content, reasoning_content, usage, done, finish_reason}`。
|
||||
- 判据：`channels_trae_chat_headers_test.go`(3)、`channels_trae_solo_sse_test.go`(2)，
|
||||
变异 2/2 咬住。
|
||||
|
||||
**③ 余额恒为 0**（同文件 `balance.total_fn`）
|
||||
|
||||
- 根因：读 `p.credits_limit`（pack **顶层**）—— 该字段**根本不存在**。
|
||||
真实路径是 `pack.entitlement_base_info.quota.credits_limit`
|
||||
（参考 `trae-credits.ts:341`）+ `pack.usage.credits_amount`。
|
||||
- 实测上游：`免费`(无 credits_limit) / `每月登录赠送`(500) / `签到奖励`(100) = **600**。
|
||||
- 修法：读嵌套路径 + 保留顶层兼容 + `usage_summary.{total,consumed}_amount` 兜底。
|
||||
- 判据：`channels_trae_credits_hdr_test.go`(1)。
|
||||
- 修后余额 **600 → 实测 598.516**（真实扣减）。
|
||||
|
||||
**④ 附带**：`channels_trae_test.go` 夹具从**扁平** `{"Token":...}` 改为真实
|
||||
`{"Result":{"Token":...}}` —— 原来夹具形状与生产不一致，**判据必然虚假通过**
|
||||
（这是 ExchangeToken 缺陷藏了很久的原因）。
|
||||
|
||||
## 2. 后续计划
|
||||
|
||||
### P0 — 提交本轮修复（必须先做）
|
||||
|
||||
代码已部署生产但**未进 git**。必须：
|
||||
1. 在 `release/v2.0.x` 上提交（含 3 个源文件 + 6 个判据文件）
|
||||
2. 打 tag `v2.0.40`（**这是内核 Go 改动**：`registry.go` ⇒ 真核心版本）
|
||||
3. 回流 main（cherry-pick，不 merge）
|
||||
4. 复核 tag 落点 + release vs main 零差异 + 生产 sha256 一致
|
||||
|
||||
> 判据：`git tag --points-at <release HEAD>` 非空；`git diff release/v2.0.x main` 为空。
|
||||
|
||||
### P1 — 其余渠道的同类缺陷（**账号 0，验证不了**）
|
||||
|
||||
按"风险 × 可验证性"排序。**核心限制：这 4 个平台账号数均为 0，
|
||||
无法做生产实测** —— 只能靠静态对齐参考 + 装好适配器后看 `__adapter_install_probe`。
|
||||
|
||||
| 优先 | 项 | 缺陷 | 修法 | 可验证性 |
|
||||
|---|---|---|---|---|
|
||||
| P1-1 | `channels-zcode` | 走 anthropic 基座，而**基座无 `build_headers`**，anthropic 要 `x-api-key` 不是 Bearer | 给基座补 `build_headers`（`x-api-key` + `anthropic-version`），zcode 继承即得 | 静态可验；运行需账号 |
|
||||
| P1-2 | `channels-cline` | 参考要 `Bearer workos:<jwt>`，我们的 token 无 `workos:` 前缀 | 登录/续期处拼前缀，或适配器 `build_headers` 补 | 静态可验；运行需账号 |
|
||||
| P1-3 | `channels-gemini` | 有静态头 + Bearer（参考注释也说 Cloud Code 用 OAuth Bearer）⇒ **可能本来就对** | 只需确认，不改 | 静态可验 |
|
||||
| P1-4 | `channels-qoder` | 头由 **WASM 生成必须原样透传**，我们拿不到 `.wasm` | **阻塞**：二进制不在仓库任何位置 | 不可验证 |
|
||||
|
||||
### P2 — 内核对"限定名"的契约收口
|
||||
|
||||
`ResolvePinned` / `EffectiveModel` 现在各自调 `splitPinned`。建议：
|
||||
- 把"源名可含哪些字符"写进 `docs/`，并加判据：新增源名若含 `:` 或 `/` 必须报警
|
||||
（否则限定名会歧义）。
|
||||
- 现状：源名由插件生成 `channels-<platform>-<accountId>`，只含 `-`/字母数字，安全。
|
||||
|
||||
### P3 — 判据防回归（防"夹具与生产不一致"再犯）
|
||||
|
||||
本轮最大的教训不是某个 bug，而是**夹具形状错 ⇒ 判据虚假通过**（trae 活了两轮）。
|
||||
|
||||
建议加一条**通用**判据：`TestAdaptersFixturesMatchRealUpstreamShape` ——
|
||||
对每个有夹具的渠道，把夹具响应体与
|
||||
`/tmp/pi-github-repos/.../vendor/channel-pack/src/*.ts` 里注释记录的真实响应形状
|
||||
做**结构对照**（键集合），不一致即报红。做不到全自动，至少把已知的
|
||||
"Result 信封 / SOLO SSE / 嵌套 quota" 三类钉住。
|
||||
|
||||
### P4 — 待用户决策
|
||||
|
||||
| 项 | 需要什么 |
|
||||
|---|---|
|
||||
| zcode 真实登录 | 用户点授权（身份块 + init-poll 流已就绪） |
|
||||
| cline / qoder / gemini / codearts / minimax / lobsterai / opencode | 需各平台账号；`device-poll` 系列要用户去官方页输码 |
|
||||
| raccoon / loomy | 需扫码 |
|
||||
| qoder WASM | 用户提供 `.wasm` |
|
||||
|
||||
## 3. 风险与纪律（本轮新增）
|
||||
|
||||
1. **`luac -p` 对长字符串内的适配器代码无效**（只看外层）⇒ 会得到假绿。
|
||||
**必须**用 `__adapter_install_probe` 看真实装载结果。本轮我因此把 TRAE 的
|
||||
SSE 代码误塞进 CODEARTS 适配器，导致 codearts 装载失败而 `luac` 一直通过。
|
||||
2. **Python 字符串替换会静默不生效**：锚文本缩进不符 ⇒ 匹配 0 次。
|
||||
规矩：① 先 `cp` 备份 ② **行号定位** ③ 写后 `luac -p` + `grep -c` 双确认
|
||||
④ 长字符串内的改动必须验装载。
|
||||
3. **`function` 是 Lua 关键字**：`cc.function` 是语法错误，必须 `cc["function"]`；
|
||||
但批量替换时别把 `cc.function_call` 一起改坏（本轮踩过，导致
|
||||
`')' expected near '_call'`）。
|
||||
4. **判据要咬被测对象**：本轮 `channels_trae_credits_hdr_test.go` 第一版造 HTTP 假上游，
|
||||
因 URL 覆盖/凭据 ref/路径匹配任一环错，"没发请求"伪装成"头不对"（耗了三轮）。
|
||||
改成直接咬 `spec.headers_fn` 的真实产出，一轮就准。
|
||||
5. **只改插件不必换二进制**；改内核 Go 必须换。混着发会把"插件改动"记成"核心版本"
|
||||
（v2.0.21–v2.0.39 有 18 个 tag 是这么来的，见 §4）。
|
||||
6. **`/tmp` 是 8.8G tmpfs**，Go 链接失败常见于它满（`no space left on device`）。
|
||||
元凶通常是 `/tmp/gocache`（可安全清）。
|
||||
|
||||
## 4. 账务实况（必须记住）
|
||||
|
||||
| 事实 | 值 |
|
||||
|---|---|
|
||||
| 内核 Go 代码自 v2.0.20 起的**全部**改动 | 仅 `internal/lua/adapter_prelude.go`、`internal/provider/provider.go`、`internal/provider/registry.go` |
|
||||
| 只改插件却发了核心 tag 的版本 | v2.0.21–v2.0.39 中的 **18 个** |
|
||||
| 当前最新 tag | `v2.0.39`（`091f790`），落点正确 |
|
||||
| main | `56ea269`（与 release 内容零差异） |
|
||||
| **未提交的改动** | 本轮三个修复（见 §1.4），已部署生产 |
|
||||
|
||||
> ⇒ **版本号语义教训**：以后"改插件不打核心 tag"，插件自身维护版本；
|
||||
> 内核版本只在 Go 代码变更时递增。
|
||||
@ -1,540 +0,0 @@
|
||||
# channels 插件与参考插件的三线对齐表
|
||||
|
||||
参考仓：`Ebony-Vinyl/dsh-our-free-model`（本地克隆
|
||||
`/tmp/pi-github-repos/Ebony-Vinyl/dsh-our-free-model`），关键实现位于
|
||||
`vendor/channel-pack/src/`（144 个 TS 文件）。
|
||||
|
||||
命名规律（照它逐厂商对齐的三条线）：
|
||||
|
||||
| 后缀 | 职责 | 我们要对齐的东西 |
|
||||
|---|---|---|
|
||||
| `X-auth.ts` / `X-oauth.ts` / `login.ts` | **登录** | 登录流程、端点、参数、凭据形状 |
|
||||
| `X-product.ts` / `models.ts` | **模型获取** | 远端端点、解析路径、兜底表 |
|
||||
| `X-adapter.ts` / `llm-adapter.ts` | **接入模型服务** | chat 端点、载荷转换、鉴权头 |
|
||||
|
||||
## 一、登录（line ①）
|
||||
|
||||
| 平台 | 参考流程 | 我们的 flow | 状态 |
|
||||
|---|---|---|---|
|
||||
| trae | OAuth 17 参数 + 设备身份派生 | callback | ✅ 逐字节对齐（含 login_trace_id / machine_id / x_device_*） |
|
||||
| minimax | device-poll | device-poll | ✅ |
|
||||
| cline | device-poll | device-poll | ✅ |
|
||||
| buddy | state-poll（**无回调**） | state-poll | ✅ |
|
||||
| gemini | OAuth + client_secret | callback | ✅（含 client_secret、localhost 主机、6 scope） |
|
||||
| lobsterai | 本地回调 + authCode 换 token | callback | ✅（含动态版本号、3 步活动领取） |
|
||||
| opencode | paste | paste | ✅（参考本身即粘贴凭据） |
|
||||
| **codearts** | **PKCE + DPoP ES256 + STS 换 AK/SK** | **callback** | ✅ **本轮修复**（此前误标 paste） |
|
||||
| qoder | device-poll + 设备身份 | device-poll | ✅（含 Cosy-MachineToken/Type 成对） |
|
||||
| zcode | init-poll | init-poll | ✅ |
|
||||
| loomy | 微信扫码 poll | wechat-poll | ✅ |
|
||||
| raccoon | 二维码 poll | qr-poll | ✅ |
|
||||
|
||||
### codearts 登录（本轮修复的重点）
|
||||
|
||||
此前标成 `flow="paste"`（手填凭据）是**错的**。参考 `login.ts` / `oauth.ts`
|
||||
默认走**新式 IAM OAuth**：
|
||||
|
||||
1. 起本地回调服务器，端口须 **≥10000**（`MIN_CALLBACK_PORT`，低于此 portal 拒绝），
|
||||
路径 `/oauth/callback`
|
||||
2. 打开 `https://codearts.huaweicloud.com/portal/authorize`，参数逐项：
|
||||
`theme=2`、`locale=zh-cn`、`uri_scheme=codearts-agent`、`client_id=codearts-agent`、
|
||||
`code_challenge_method=**SHA-256**`（不是 RFC 的 S256 —— 错值会让 portal
|
||||
**回退旧 ticket 流程**，看起来"也能用"但不是 OAuth）、`ticket_id`、
|
||||
`plugin-name=snap_AIIDE`、`plugin-version=5.2.0`；
|
||||
**不得**含 `auth_callback_url`（会被判异常并回退）
|
||||
3. 回调收到 `code` 后，带 **DPoP 证明**向
|
||||
`https://sts.cn-north-4.myhuaweicloud.com/v1/oauth2/tokens` 换
|
||||
`credentials{access_key_id, secret_access_key, security_token, expiration}`
|
||||
+ `refresh_token`
|
||||
4. 凭据持久化须含续期材料：`refresh_token` / `code_verifier` / `dpop_private_key_jwk`
|
||||
|
||||
DPoP 细节：ES256 JWS，`header={alg,typ:dpop+jwt,jwk}`、
|
||||
`payload={htm,htu,iat,jti}`；**签名是 raw r||s 64 字节**，而 openssl 输出 DER
|
||||
——必须转换格式，否则服务端验签失败而字符串看起来完全正常。
|
||||
|
||||
终态判定只认 `invalid_grant` / `ErrorCode 含 ExpiredRefreshToken`；
|
||||
**不认** `InvalidDPoPHeader`（那是一次请求层面的拒绝：时钟偏差、proof 重放、
|
||||
网关抖动都会触发，当终态会把完好账号一步标死）。
|
||||
|
||||
旧 ticket 流程（`CODEARTS_LOGIN_BASE` + `/snap-manager/v1/login/ticket` 轮询）
|
||||
保留作回退。
|
||||
|
||||
## 二、模型获取（line ②）
|
||||
|
||||
远端优先、兜底补位的机制已具备（`models_remote` + `effectiveModels`）。
|
||||
本轮把**兜底表**逐平台补成参考全量：
|
||||
|
||||
| 平台 | 参考来源 | 兜底数 | 状态 |
|
||||
|---|---|---|---|
|
||||
| trae | `TRAE_FALLBACK_MODELS` | 28 可见 + 4 hidden | ✅（hidden 单列 `models_hidden`） |
|
||||
| minimax | `GET /mavis/api/v1/models?region=cn&buildEnv=prod` | 4 | ✅ |
|
||||
| cline | `GET /api/v1/models` + `recommended-models` | 3 | ✅ |
|
||||
| buddy | （无独立表） | 7 | ✅ |
|
||||
| gemini | — | 2 | ✅ |
|
||||
| lobsterai | `GET /api/models/available`（**须带 model_flag**） | 19 | ✅ |
|
||||
| opencode | `GET /v1/models` | 14 | ✅（含 `models_free`） |
|
||||
| codearts | opengw `gateway/config` + `/v1/model/builtin` | 3 | ⚠️ 见下 |
|
||||
| qoder | `/api/v2/model/list`（需 WASM 签名） | 19 | ✅（含 CN 独有 q37fmodel/gm51model） |
|
||||
| zcode | `GET /api/v1/client/configs` | 2 | ✅ |
|
||||
| loomy | `GET /api/v1/models`（取 `type==='chat'`） | 8 | ✅ |
|
||||
| raccoon | 远端 + 兜底 | 6 | ✅ |
|
||||
|
||||
**trae 的 `isHidden` 语义**：`browser_use_subagent` / `explore_sub_agent_v13` /
|
||||
`explore_sub_agent_v2` / `summary` 是内部子 agent，不进用户可选列表。
|
||||
`model_list` 已按此过滤（`models_hidden`）。
|
||||
|
||||
**opencode 的 `isFree`**：参考明确标注 7 个模型匿名可用、其余需付费 key。
|
||||
此前 `model_list` 把 `isFree` 硬编码为 false，等于把官方免费模型标成付费。
|
||||
|
||||
### codearts 模型获取（未闭环）
|
||||
|
||||
参考 `models.ts` 从两个端点拉：
|
||||
- `OPENGW_GATEWAY_CONFIG_URL`（`opengw.developer.huaweicloud.com/api/v1/gateway/config`）
|
||||
→ `result.models`，这是 **benefit（免费额度）模型**权威来源
|
||||
- `SNAP_MODEL_BUILTIN_URL`（`/v1/model/builtin`）→ `builtinModels`，常规模型
|
||||
|
||||
两者都要 **AK/SK 的 SDK-HMAC-SHA256 签名**。另有 `normalizeModelId`
|
||||
（去尾部 `-NNNN` 日期版本）与 `isCodeArtsBenefitModel`（决定 chat 是否带
|
||||
`maas_type: benefit`，不带则 404 `model is not registered`）。
|
||||
**这部分尚未实现**——我们的 codearts 目前只有 3 个硬编码模型名。
|
||||
|
||||
## 三、接入模型服务（line ③）
|
||||
|
||||
**本轮发现的最严重问题**：源注册时 `base_url + adapter.endpoint` 拼出的
|
||||
chat URL **全部缺路径前缀**，11 个平台里 11 个都不对。已逐个修正：
|
||||
|
||||
| 平台 | 正确 chat 端点 | 修正前 |
|
||||
|---|---|---|
|
||||
| trae | `…/api/agent/v3/llm_utils_chat` | `…/chat/completions` |
|
||||
| cline | `api.cline.bot/api/v1/chat/completions` | `api.cline.bot/chat/completions` |
|
||||
| lobsterai | `…/api/proxy/v1/chat/completions` | `…/chat/completions` |
|
||||
| qoder | `api2-v2.qoder.sh/model/v1/chat/completions` | `…/chat/completions` |
|
||||
| buddy | `copilot.tencent.com/v2/chat/completions` | `…/chat/completions` |
|
||||
| codearts | `…/api/v2/chat/completions` | `…/chat/completions` |
|
||||
| opencode | `opencode.ai/zen/v1/chat/completions` | `opencode.ai/zen/chat/completions` |
|
||||
| raccoon | `…/api/web/llm/v2/chat/completions` | `…/chat/completions` |
|
||||
| loomy | `loomy.xunfei.cn/chat/completions` | `loomy.xunfei.cn` |
|
||||
| zcode | `zcode.z.ai/api/v1/zcode-plan/anthropic/v1/messages` | `zcode.z.ai/v1/messages` |
|
||||
| gemini | `/v1internal:generateContent`（私有动词） | `/v1beta/models/{model}:generateContent`（公开，凭据不匹配） |
|
||||
|
||||
### ✅ 已闭环：三个私有协议平台改用**插件自装适配器**
|
||||
|
||||
这是"为什么参考正常、我们不正常"的正面修复。参考每个平台是继承宿主
|
||||
`LlmAdapter` 的真类；我们此前把平台协议差异当成适配器名差异（全塞 openai）。
|
||||
内核其实**早已实现** `__llmsproxy_adapters.install`（含归属校验/冲突仲裁/
|
||||
测试），但 channels 插件对该全局的引用数是 **0**。现已第一次真正使用：
|
||||
|
||||
| 平台 | 自装适配器 | 解决的协议差异 |
|
||||
|---|---|---|
|
||||
| codearts | `codearts` | 华为云 SDK-HMAC-SHA256 **AK/SK 签名**（canonical/string-to-sign 逐字节） |
|
||||
| trae | `channels-trae` | **SOLO 载荷**：config_name 双字段、function 通道、tool_calls→function_call、parameters→JSON 字符串、tool_choice 归一化 |
|
||||
| gemini | `channels-gemini` | 私有 `/v1internal:` **信封** + 身份五头 + 字母序序列化 + 响应剥一层 |
|
||||
|
||||
命名说明：trae 用 `channels-trae` 而非 `trae`，因为内置 `trae.lua` 服务的是
|
||||
**运维自建的 trae-local-api 反代**（`127.0.0.1:19900`，生产 config.yaml 在用），
|
||||
与本插件的直连通道是两回事。重名会被内核冲突仲裁挂起（正确的护栏）——
|
||||
判据里专门断言内置 `trae` 未被顶掉。
|
||||
|
||||
**新增能力：`credential_shape`**。签名平台需要**完整凭据 JSON**（适配器自己
|
||||
解 AK/SK），其余平台交裸 access token。此前 `syncAccountSource` 一律用
|
||||
`credentialOf` 取 `access_token`，于是 codearts 凭据（只有
|
||||
`access_key_id`/`secret_access_key`/`security_token`）取不到 token →
|
||||
**静默 return、不出源**。现已按 `plat.credential_shape` 区分。
|
||||
|
||||
**另一处静默失败已修**：`syncAccountSource` 拿到内核 `add_source` 的失败
|
||||
（权限未授、形状不符）时不记日志，表现为"账号加了但不出源"，排查零线索。
|
||||
现补失败日志（区分内核 err 与 `json.ok==false`）。
|
||||
|
||||
### 仍未闭环：gemini 的 sigstore（明确不做）
|
||||
|
||||
参考 `gemini-sigstore.ts`（268 行）持久化 tool-call 签名，供跨请求回填。
|
||||
我们推理走**无状态适配器**，插件侧缓存会成为死代码。签名缺失时上游会拒，
|
||||
适配器如实透传错误。理由与结论已记在此处，避免反复讨论。
|
||||
|
||||
## 四、明确不做的（附理由）
|
||||
|
||||
| 参考模块 | 行数 | 为什么不做 |
|
||||
|---|---|---|
|
||||
| `gemini-sigstore.ts` | 268 | 推理走无状态适配器，插件侧缓存会成为死代码。签名缺失时上游会拒，适配器如实透传 ⛔ |
|
||||
| `qoder-wasm.ts` | 1442 | 需随插件分发 298KB wasm 二进制；B 类，待立项 |
|
||||
| `zcode-captcha.ts` | 2212 | 阿里云滑块，需真实浏览器/验证码链路；B 类 |
|
||||
| `captcha-*.ts` | 1223 | 同上 |
|
||||
|
||||
## 五、本机实测踩到的坑（都已修）
|
||||
|
||||
1. **`xxd` 不存在** —— `command -v xxd` 为空，用它取十六进制会**静默得到空串**。
|
||||
改用 `od -An -tx1`。
|
||||
2. **`openssl ec -text` 会截断 32 字节 priv**（实测只给 30 字节）→ `d` 必须用
|
||||
`openssl asn1parse` 的 `[HEX DUMP]`；`tail -c 32` 拿到的是 SEC1 结构里
|
||||
**公钥的 y**，不是 `d`。
|
||||
3. **Lua local 前向引用**：`local function` 只从定义处向后可见。`hexToBin` /
|
||||
`b64url` / `b64urlRaw` 被 CodeArts 的 PKCE/DPoP 调用，必须移到 CodeArts 块
|
||||
**之前**（本文件累计踩过 6 次）。
|
||||
4. **`min_port` 参数读到 `argv[2]`** 与 `out_path` 冲突 —— 回调脚本的第 5 个
|
||||
参数才是 minPort。
|
||||
5. **Lua 双引号串里的 `\1`** 是转义坑（`sed 's/…/…/\1/'` 会报
|
||||
invalid escape sequence）→ 改用 `awk -F': ' '{print $NF}'`。
|
||||
|
||||
---
|
||||
|
||||
# 为什么参考插件是"正常"的：架构差异（2026-10-13 查证）
|
||||
|
||||
用户问「为什么他们就正常」。查完参考仓的架构后，答案是**三层结构差异**，
|
||||
不是某一个端点的笔误。
|
||||
|
||||
## 参考的架构：一个平台 = 一个适配器类
|
||||
|
||||
参考依赖宿主 SDK 的 seam：`import { LlmAdapter } from '@deepseek-ai/dsh-llm'`。
|
||||
每个平台有一个**继承基类的真类**，同时拥有登录、模型目录、推理三件事：
|
||||
|
||||
| 文件 | 类 | 干什么 |
|
||||
|---|---|---|
|
||||
| `trae-adapter.ts` | `TraeAdapter` | SOLO 协议转换（`config_name`/`function`，非 OpenAI 兼容） |
|
||||
| `llm-adapter.ts` | `CodeArtsAdapter` | 华为云 AK/SK 签名 + `maas_type: benefit` 判定 |
|
||||
| `zcode-adapter.ts` | `ZcodeAdapter` | Anthropic Messages 协议（非 OpenAI） |
|
||||
| `qoder-adapter.ts` | `QoderAdapter` | WASM 加密端点 + 信封剥离 |
|
||||
| `gemini-adapter.ts` | `GeminiAdapter` | `/v1internal:` 私有动词 + 字母序信封 |
|
||||
|
||||
注册方式是 `registerAdapterIdempotent(ctx.llm, [PROVIDER], adapter)`
|
||||
（`llm-adapter.ts:2080`）。
|
||||
|
||||
**但它不重复**：共享层是 `src/openai-compat.ts`（1196 行）——
|
||||
`serializeMessages`（消息序列化）、`consumeOpenAiSse`（SSE 消费）、
|
||||
`httpErrorCode` / `isTransportError`（错误归类）、`userContentParts`（多模态）。
|
||||
12 个 adapter 里有 8 个 `import from './openai-compat'`。
|
||||
|
||||
即：**公共协议逻辑一份，平台差异各自一个类**。
|
||||
|
||||
## 我们的架构：内核是 proxy，插件只注册源
|
||||
|
||||
- 适配器是 Lua 文件（12 个），通过 4 个钩子参与：
|
||||
`transform_request` / `transform_response` / `transform_stream_chunk` /
|
||||
`transform_error`，外加 `build_headers`（动态签名，见下）。
|
||||
- 声明面：`endpoint` / `endpoint_stream` / `ingress` / `headers`。
|
||||
- 插件通过 `__llmsproxy_kernel.call("add_source", {source={...}})` 把平台
|
||||
注册为上游源，`source.adapter` 引用适配器名。
|
||||
|
||||
## 关键发现：机制早就有，但 channels 插件从没用过
|
||||
|
||||
内核**完整实现了**插件自装适配器：
|
||||
|
||||
```
|
||||
internal/lua/plugin_adapter_bridge.go
|
||||
func (ps *Plugins) InstallAdapter(plugin, name, code string) (string, error)
|
||||
registerAdapterBridge → Lua 全局表 __llmsproxy_adapters.install / .update / .remove
|
||||
```
|
||||
|
||||
- 有归属校验（`adapterOwnership`：只能改自己装的）
|
||||
- 有冲突仲裁（影子内置/他人所有 → 挂起等运维裁决，不是硬拒）
|
||||
- 有测试证明可用：`TestPluginInstallsAdapterFromLua`（PASS）
|
||||
|
||||
**但 `grep -c '__llmsproxy_adapters' internal/lua/plugins/channels.lua` = 0。**
|
||||
channels 插件一个适配器都没装过 —— 它只会注册 `adapter = "openai"` 的源。
|
||||
这就是"为什么我们不正常"的直接原因：**平台协议差异被当成适配器名差异**。
|
||||
|
||||
## 我们还缺的一层：共享协议模块
|
||||
|
||||
参考有 `openai-compat.ts`；我们没有对应物。`openai.lua` 自己写明
|
||||
「Lua adapters have no shared prelude」，`safe_tool_id` 在 `openai.lua` 与
|
||||
`anthropic.lua` 里**各复制了一份**（各 6 处引用）。
|
||||
|
||||
所以正确做法是两层：
|
||||
1. 抽一个 Lua 共享前导（消息序列化 / SSE 消费 / 错误归类），
|
||||
或内核在加载时注入 —— 消掉复制粘贴
|
||||
2. channels 插件为需要真协议转换的平台（trae SOLO、gemini 信封、
|
||||
codearts AK/SK 签名）**装自己的适配器**，而不是硬塞给 `openai`
|
||||
|
||||
### 所需的适配器能力（crypto + 出站 + 流式）
|
||||
|
||||
已核实内核提供：
|
||||
- `sha256_hex` / `hmac_sha256_hex`（`vm.go` setupGlobals）
|
||||
- `build_headers(meta)` 收 `{url, method, body, api_key, timestamp,
|
||||
client_session, source{name,meta}}` —— CodeArts 的 AK/SK 签名用它
|
||||
（与参考 `signRequestHuawei` 同构，但 AK/SK 要从 `api_key` 里解出）
|
||||
- `transform_stream_chunk` 逐 chunk 调用（`provider.go:1295`）
|
||||
- 插件有完整 OS 能力（`io.popen`/`os.execute`）→ 可用 openssl 做 EC 签名
|
||||
|
||||
### 未验证的风险
|
||||
|
||||
- 适配器 VM 能否访问 `__llmsproxy_secrets`（AK/SK 要解出 SK 才能签名）
|
||||
- 流式转换能否跨 chunk 保持状态（trae 的 SSE 需要跨帧累积 tool_calls）
|
||||
|
||||
这两条是下一步落地前必须先探的。
|
||||
|
||||
---
|
||||
|
||||
# 插件自装适配器：机制与判据（2026-10-13）
|
||||
|
||||
## 机制（内核早已具备，本轮才开始使用）
|
||||
|
||||
```
|
||||
internal/lua/plugin_adapter_bridge.go
|
||||
InstallAdapter(plugin, name, code) # 含归属校验、冲突仲裁（影子内置 → 挂起等裁决）
|
||||
registerAdapterBridge → Lua 全局 __llmsproxy_adapters.install / .update / .remove
|
||||
```
|
||||
注册点在 `bootPluginState`，**先于** `DoString(code)` —— 所以插件在脚本执行期
|
||||
就能装适配器。适配器装在**适配器 VM**（与插件 VM 分离，各自独立）。
|
||||
|
||||
## 三条能力（实测，不是推断）
|
||||
|
||||
`internal/lua/plugin_adapter_capability_test.go` 锁死：
|
||||
|
||||
| 能力 | 结论 | 为什么关键 |
|
||||
|---|---|---|
|
||||
| 拿凭据 | 适配器**能**经 `build_headers` 的 `meta.api_key` 拿到（`url`/`method`/`body` 也在） | AK/SK 签名的前提；同时**验不到** `__llmsproxy_secrets`（只注入插件 VM，安全边界完好） |
|
||||
| 流式状态 | `transform_stream_chunk` **跨 chunk 保持同一 Lua 状态**（表地址恒定） | SOLO 跨帧累积 tool_calls、gemini 跨帧剥信封的前提 |
|
||||
| 加密原语 | 适配器可用内核 `sha256_hex` / `hmac_sha256_hex`（用标准向量校验） | 签名不需要外部进程 |
|
||||
|
||||
## 踩过的坑（都是"静默失败"类，值得记）
|
||||
|
||||
1. **`function` 是 Lua 关键字** —— 写 `body.function = x` 是**语法错误**
|
||||
（`'<name>' expected near 'function'`），必须 `body["function"]`。
|
||||
插件脚本本身能编译通过，**只在适配器 `load()` 时才暴露**。
|
||||
2. **Lua 长字符串里不能有字面 NUL 字节** —— 报
|
||||
`unfinished long string near '<eof>'`，且**报在文件末尾**，完全指不到现场。
|
||||
3. **本 Lua 构建不支持按位异或 `~`**（`unexpected symbol near '~'`）。
|
||||
4. **装载失败只回"源码无法编译"、不给行号** —— 三个自装适配器现统一加
|
||||
**本地预编译护栏**（先 `load` 一次拿行号）。上面三个坑都是靠它定位的。
|
||||
5. **抽公共代码要抽最全的实现**。前导重构时我先抽了 `transform_error` 的
|
||||
最小版（只认 `{error:{message}}`），打挂 6 个既有测试 —— 最小版丢掉了
|
||||
HTML 错误页、裸文本、扁平 `{code,message}`、FastAPI `{detail}`。
|
||||
抽最小实现是**静默降级**：不报错，只是少认几种错误体。
|
||||
6. **判据必须能看见真实函数的返回值**。我一度用 `kernelTestCore` 裸加载插件
|
||||
（没授 `add_source` 权限）测源注册，源一直不出；直到把内核原始返回
|
||||
（`kernel action add_source is not granted to plugin channels`）带出来才
|
||||
定位。**黑盒断言只在失败时告诉你"不对"，不告诉你"为什么"**。
|
||||
|
||||
## 判据清单
|
||||
|
||||
| 文件 | 锁死什么 |
|
||||
|---|---|
|
||||
| `internal/lua/plugin_adapter_capability_test.go` | 三条能力（凭据/流式状态/加密原语） |
|
||||
| `internal/lua/adapter_prelude_test.go` | 前导注入 + 语义值正确 + 旧适配器行为不变 |
|
||||
| `internal/lua/adapter_prelude_equivalence_test.go` | 重构前后逐字节等价（含反向断言） |
|
||||
| `internal/lua/channels_trae_solo_test.go` | SOLO 7 条规则 + 三处反向断言 |
|
||||
| `internal/lua/channels_gemini_adapter_test.go` | 身份五头逐值 + 不得发 google key/Accept + 字母序 + 响应剥信封 |
|
||||
| `internal/core/channels_codearts_adapter_test.go` | 装机/归属 + **Go stdlib 独立复算 HMAC 验签** |
|
||||
| `internal/core/channels_private_adapter_wiring_test.go` | 三平台的**源真的引用了**自装适配器 |
|
||||
|
||||
---
|
||||
|
||||
# 生产实测：不可用的真相（2026-10-14）
|
||||
|
||||
## 症状与根因
|
||||
|
||||
用户报"完全不可用"。实测（`/api/plugins/http/channels/account/list` 逐平台）：
|
||||
|
||||
| 平台 | 账号数 | **有凭据的** |
|
||||
|---|---|---|
|
||||
| buddy | 2 | **1** |
|
||||
| trae | 3 | 0 |
|
||||
| minimax | 1 | 0 |
|
||||
| lobsterai | 1 | 0 |
|
||||
| codearts | 5 | 0 |
|
||||
| 其余 7 平台 | 0 | 0 |
|
||||
|
||||
**13 个账号里只有 1 个真有凭据**，其余全是**占位壳子**（`has_credential: false`）。
|
||||
占位账号不是"已登录"，它只是为「先建账号行、登录后填凭据」这个两步流程预留的
|
||||
行。此前的判断只看「12 平台 0 个 manual」，那是**错的判据** —— manual 是
|
||||
flow 类型，不是"登录成功"。
|
||||
|
||||
## 排除项（都实测过，不是猜）
|
||||
|
||||
| 检查 | 结果 |
|
||||
|---|---|
|
||||
| 服务状态 | `active`，`NRestarts=0` |
|
||||
| 部署一致性 | 4 个插件 sha256 与仓库**全部一致**；关键标记（installCodeartsAdapter / installTraeAdapter / installGeminiAdapter / sorted_json / sign_parts）全部在位 |
|
||||
| **推理链路** | `POST /v1/chat/completions` 实测返回 `"OK"`（走 buddy 源、deepseek-v4.1-flash）—— **网关本身完全可用** |
|
||||
| 登录机制 | minimax 真实返回 `user_code=T49S-RC7G` + 验证地址；trae 起了服务端浏览器 + 回环回调 |
|
||||
| 设备码轮询 | 5 次全部 `pending`（未授权时**不误判**为失败或成功 —— 这是正确行为） |
|
||||
|
||||
## 结论：不是代码坏了，是**授权没完成**
|
||||
|
||||
剩下的 12 个平台都需要**人工动作**才能走完登录：
|
||||
|
||||
- **device-poll**（minimax / cline / qoder）：把 `user_code` 拿到
|
||||
`account.minimax.cn/oauth-authorize` 之类的**官方页面**输入
|
||||
- **callback**（trae / gemini / lobsterai）：在 **VNC 窗口**里点授权
|
||||
（回环回调只能由本机解析，远程浏览器永远接不住）
|
||||
- **qr-poll / wechat-poll**（raccoon / loomy）：扫码
|
||||
- **init-poll**（zcode）：授权页 + 可能的验证码
|
||||
|
||||
这些**按设计就必须人工**，assistant 无法独立端到端完成。
|
||||
|
||||
## B 类：实测结论
|
||||
|
||||
| 项 | 行数 | 结论 |
|
||||
|---|---|---|
|
||||
| qoder-wasm + envelope | 706 + 226 | **二进制不在仓库**（`find -name '*.wasm'` 为空，属构建产物）。没有 `qoder-auth-wasm.wasm` 无法实现；拿到才有意义 |
|
||||
| zcode-captcha + carrier | 2119 + 93 + 280 + 206 | 阿里云滑块。且**登录本身不需要它** —— captcha 只用于**签到/领取**环节（`zcode-auth.ts:22-23`：claim 时每个 plan 单独 mint captcha）。登录闭环不受阻，受阻的是自动领取 |
|
||||
| captcha-pool | 280 | 同上，服务于领取环节的验证码供给 |
|
||||
|
||||
**修正判断**：B 类不是"登录闭环的拦路虎"。zcode 的登录（`/api/v1/oauth/cli/init`
|
||||
→ poll）不需要验证码；captcha 只在**自动领取**时出现。所以 B 类的真实价值是
|
||||
"让领取全自动"，而不是"让平台可用"。
|
||||
|
||||
---
|
||||
|
||||
# 真实数据事故：测试覆盖了生产账号池（2026-10-14）
|
||||
|
||||
## 症状
|
||||
|
||||
用户报「完全不可用」。逐平台 `account/list` 后发现：**13 个账号里只有 1 个有凭据**，
|
||||
其余是占位壳子；再查发现**账号池被清空了**（`pool` 全为空 `{}`），
|
||||
而保险库 `.secrets/channels.json` 里的凭据**还在**。
|
||||
症状正是「账号凭空消失」。
|
||||
|
||||
## 根因（实测输出，非推断）
|
||||
|
||||
channels 插件用 `storeDir()` 决定存储位置，它有多级兜底：
|
||||
|
||||
```
|
||||
env MODELROUTER_PLUGIN_DIR → settings.store_dir → 读 /etc/llmsproxy/config.yaml 的 plugin_dir → 硬编码
|
||||
```
|
||||
|
||||
测试台没设 `MODELROUTER_PLUGIN_DIR`，**后两级直接命中生产**：
|
||||
|
||||
```
|
||||
测试插件目录 = /tmp/TestXXX/002/plugins
|
||||
storeDir 结果 = /etc/llmsproxy/plugins ← 探针实测输出
|
||||
```
|
||||
|
||||
于是测试加载真 `channels.lua` 时**读的是生产存储、写的也是生产存储**。
|
||||
一次全量 `go test ./internal/lua` 就把
|
||||
`.channels-store.json` 从 1730 覆盖成 1986 字节、账号池清空（inode 都换了）。
|
||||
|
||||
只有 `internal/lua` 复现，`internal/core` 不复现 —— 因为 core 的测试台
|
||||
（`kernelTestCore`）设了 `MODELROUTER_PLUGIN_DIR`。**这是隔离做得不一致**的代价。
|
||||
|
||||
同类前科：曾把 26 个测试账号写进生产 store。两次同一类错误。
|
||||
|
||||
## 为什么 `DisableStatePersistence` 不够
|
||||
|
||||
第一版修复给 `runtimePlugins` 关了持久化，**仍然复现**：插件声明了 `schedule`
|
||||
时内核会自动起调度器（`plugins.go: p.Runtime = ps.startRuntime(...)`），
|
||||
真 channels 的 `refresh_models` 会在 5s 后（first_due_now）跑一轮并
|
||||
`logEvent → markDirty`。那是**后台 goroutine，比 `t.Setenv` 的生命周期长** ——
|
||||
测试结束后它仍可能落盘，此时环境变量已还原。
|
||||
|
||||
## 修法（两层，第二层才是根治）
|
||||
|
||||
1. **内核把插件的真实目录交给插件**（ground truth，不再靠猜）：
|
||||
新增 `__llmsproxy_plugin_dir` 全局（`registerPluginDirBridge`），
|
||||
`storeDir()` 优先用它。**即使没有环境变量也不会落到生产路径** ——
|
||||
实测：撤掉 env 后 `storeDir` 仍落在临时目录。
|
||||
2. 测试台补隔离：`runtimePlugins` 设 env + `DisableStatePersistence()`。
|
||||
|
||||
## 判据 + 变异验证
|
||||
|
||||
`internal/lua/store_dir_isolation_test.go`：
|
||||
`storeDir` 绝不能是 `/etc/llmsproxy` 前缀、必须落在临时目录、env 必须真的被设。
|
||||
**变异验证**：把隔离设成生产路径 → 判据变红并打印「storeDir 指向了**生产**目录」；
|
||||
恢复 → 变绿。
|
||||
|
||||
全量回归：9 个包全绿，且 `go test ./...` 后生产存储**未被改动**（此前必被改）。
|
||||
|
||||
## ⚠️ 修复过程中我自己踩的坑
|
||||
|
||||
恢复账号时我把**保险库文件里的密文**当成明文，喂给 `account/add` 的
|
||||
`credential` —— 保险库 `loadSecretsLocked` **会在读取时解密**，于是那份凭据被
|
||||
**二次加密**（1971 → 2965 字符），该账号的推理开始返回空
|
||||
（`codebuddy_*` 源失效，而非池路径 `channels:buddy` 正常）。
|
||||
|
||||
教训：**凭据只能由登录/续期路径写入，绝不要手工把密文塞回 API**。
|
||||
要复用既有凭据，应走「让插件自己读保险库」的路径，或者重新登录一次。
|
||||
|
||||
---
|
||||
|
||||
# 逐模块对照的当前状态（2026-10-14 更新）
|
||||
|
||||
穷尽对照参考仓 **143 个 .ts 模块 / 77,720 行**。约定：
|
||||
✅ 已对齐 · ⚠️ 部分/简化 · ❌ 未实现 · ⛔ 明确不做
|
||||
|
||||
## 本轮（第 2 批）新补的
|
||||
|
||||
| 模块 | 参考规模 | 补了什么 / 为什么 |
|
||||
|---|---|---|
|
||||
| `dead-model-store` | 708 | 上游下架的模型仍显示且标"免费"，一点就 404。**判据只用阳性 404 证据，绝不拿远端目录反推**（buddy 那类平台目录残缺，反推会删可用模型） |
|
||||
| `remote-catalog-gate` | 114 | 参考点名"不能省"：目录拉不到会放大成「一次请求 × 每个模型」，首屏卡死 |
|
||||
| `buddy-balance-rank` + `loomy-balance-rank` + 两个 selector | ~1000 | **余额分档选号**：优先用「15 天内到期」的号，否则积分白白作废；锁定时只剩永久的号等同不可用 |
|
||||
| `account-probe` | 568 | `account_test` **此前一个网络请求都不发**（恒返回 ok:true/ms:1）—— 假阳性 |
|
||||
| `model-gate` | 218 | 源改**串行 + 按模型节流**（并发发起必然浪费一个配额；串行不保证间隔） |
|
||||
| `ttl-cache` / `serial-queue` | 291 | 抽成通用件，消掉三处各自手写的缓存/冷却逻辑 |
|
||||
| `opencode-capability` | 423 | isFree 改由 models.dev 的 `cost` 权威决定（不再是硬编码快照）。**受内核 4 MiB 上限约束不可用**，已如实降级为可选增强 |
|
||||
|
||||
另修 3 个**静默失败**：`account_test` 不发请求、业务级错误（HTTP 200 + body 带
|
||||
error）被当成功、`pcall` 只取 ok 不看返回值（把诊断信息扔了）。
|
||||
|
||||
## 仍未实现（按影响面排序）
|
||||
|
||||
| 模块 | 行数 | 为什么不做的理由 / 阻塞 |
|
||||
|---|---|---|
|
||||
| `zcode-captcha` + 6 个 captcha-* | ~3345 | 阿里云滑块。**登录不需要它** —— captcha 只在签到/领取环节（`zcode-auth.ts:22-23`）。真实价值是"让领取全自动"而非"让平台可用" |
|
||||
| `qoder-wasm` + `qoder-envelope` | 932 | **wasm 二进制不在仓库**（`find -name '*.wasm'` 为空，属构建产物）。拿不到就无法实现 |
|
||||
| `zcode-identity` / `transport` / `diagnostics` | 1104 | 设备身份 + 传输层 + 错误诊断。与 captcha 链路耦合 |
|
||||
| `account-pool` / `channel-pack-store` | 1912 | 我们已自建（形态不同，非缺口） |
|
||||
| `opencode-proxy` / `opencode-rpc` | 530 | 多出口代理（NAT 后多机共享出口时按 IP 限流才需要） |
|
||||
| `message-shape` | 146 | **不适用**：那是 DSH 宿主的消息形状迁移（0.1.5→0.1.7）。我们的适配器直接透传 OpenAI 形状，无此问题 |
|
||||
| `loop-recovery` | 346 | **前提不存在**：它做的是"循环守卫中止后自动续跑"，而我们的内核**没有循环守卫** |
|
||||
| `reasoning-ladder` | 182 | 需要内核支持 `efforts` 字段（`Model` 结构只有 id/priority/kind/meta）。属内核改动，按纪律不做 |
|
||||
| `badge-*` / `image-budget` / `ttl-cache`(已补) | ~500 | 徽标订阅、图片预算 —— 宿主 UI 特性 |
|
||||
| `raccoon-login-page` / `raccoon-qr` | 1124 | 登录页与二维码的完整实现（我们走简化版） |
|
||||
| `zcode-carrier-page` | 93 | 内部载体页（依赖 DSH Desktop 的 webview guest，我们没有那个壳） |
|
||||
| `cline-*` 4 个 / `gemini-project` / `gemini-sigstore` / `loomy-sign`(部分) | ~900 | 平台细节与签名持久化 |
|
||||
|
||||
## 一句话结论
|
||||
|
||||
**平台登录/凭据/源注册这条主线已打通且逐平台对齐**（12 平台零 manual、三平台
|
||||
自装适配器、SOLO/信封/AK-SK 签名逐字节验证）。
|
||||
**未实现的部分集中在两类**：(1) 需要**真实浏览器/验证码**的领取全自动
|
||||
（captcha 系 ~3300 行）；(2) **二进制缺失**（qoder wasm）。
|
||||
其余是宿主 UI 特性或前提不存在的模块。
|
||||
|
||||
---
|
||||
|
||||
# 第三批（2026-10-14 晚）—— 逐模块对照的**新发现**
|
||||
|
||||
## ★ 本轮新补的三个真缺陷
|
||||
|
||||
### ① 自动领取每天静默漏领（`credits.ts` / `auto-checkin.ts`）
|
||||
活动刷新时刻**各平台不同**（Qoder 每日 10:00 UTC+8），而我们只在 08:00 跑一次
|
||||
⇒ 上午看到昨天那条 `CLAIMED`、报 `already-claimed` 并记账 ⇒ 当天再不去领。
|
||||
**修法照参考**：不配"时刻表"（必然漂移），让**产出方声明 `covers_today`**，
|
||||
记账方只数"有几条能证明今天已处理"。两层都要：频率提高 + `first_due_now`。
|
||||
|
||||
### ② 凭据续期此前是假的（`refresh.ts` / `expiry-sync.ts`）
|
||||
`account_refresh` **一个换 token 的请求都不发**却恒返回 `ok:true`
|
||||
⇒ `refresh_creds` 打「已续期 N 个」而什么都没续 —— **日志在说谎**。
|
||||
这是本轮第三次遇到同形态（前两次：`account_test` 恒 ok、业务级错误被当成功）。
|
||||
|
||||
### ③ `isFree` 与声明自相矛盾（`cline-models.ts`）
|
||||
cline 的免费模型声明在 `models` 里 ⇒ 被标成收费。
|
||||
★ 关键认识：**两个参考用的是不同机制** —— cline 用远端 `free[]`，
|
||||
opencode 用 models.dev 的 `cost`。混成一条 OR 链会与既有判据正面冲突。
|
||||
⇒ 加 `free_source` 由**平台声明**权威来源。
|
||||
|
||||
## 插件自装适配器（第 3、4 个）
|
||||
| 适配器 | 解决的问题 |
|
||||
|---|---|
|
||||
| `channels-qoder` | 错误信封**双层编码**；`10605`(排队) 与 `110`(额度耗尽) 语义**相反**，必须分开说（参考实测：110 原被归成通用服务端错误 → 白重试 5 次 ≈15.5 秒） |
|
||||
| `channels-cline` | 429 **无 retry-after 头**、等待时长写在英文句子里（`Try again in 19h 39m`）。解析不出 ⇒ 内核按 30 秒短冷却 ⇒ **每 30 秒猛敲上游**（比参考的「永远 60 分钟」更糟） |
|
||||
|
||||
现共 4 个：`channels-trae` / `channels-gemini` / `channels-qoder` / `channels-cline`。
|
||||
|
||||
## 对照后判定「不适用」的（附理由，不是"没做"）
|
||||
|
||||
| 模块 | 为什么不需要 |
|
||||
|---|---|
|
||||
| `account-pool` 并发写竞态 | 我们的落盘是**同步** tmp+rename（Lua 无异步），每次写序列化**当前** state。参考的缺陷是"异步后端 + 共享可变快照"的产物。**已加判据钉住**（已删账号不复活、新增不丢失、内存/磁盘不分叉） |
|
||||
| `gemini-messages` SSE 末帧丢失 | 我们的 `bufio.Scanner` 对无尾换行的最后一行**照样产出**（已实测自证）。参考那是在 `while(!done)` 里按行处理所致 |
|
||||
| `cline-rate-limit` 的 30 分钟策略冷却 | 我们**每账号一个源**（`channels-<plat>-<acct>`）⇒ 某账号被拦只冷却它自己，下个请求自然换源。参考是"一个池里换号"，才需要长冷却挡住同一轮里的连续重撞 |
|
||||
| `message-shape` | DSH 宿主的消息形状迁移；我们直接透传 OpenAI 形状 |
|
||||
| `loop-recovery` | 前提不存在（我们的内核没有循环守卫） |
|
||||
| `reasoning-ladder` | 需要内核支持 `efforts` 字段（属内核改动，按纪律不做） |
|
||||
| `retry-after.ts` | 参考那份实现**自己就是死代码**（grep 无消费者）；我们的固定 30s 冷却有明确理由（429 是"太快"不是"坏了"，走指数退避会让额度充沛的源被锁 30 分钟） |
|
||||
| `image-budget` | 实际缩放委托给宿主的附件服务，我们无对应物 |
|
||||
|
||||
## 运行环境的一条教训（不是代码缺陷）
|
||||
全量 `go test` 曾出现 `TestConcurrentPluginAdapterUpdates` **挂 59 分钟**、
|
||||
看着像死锁。单独跑 **0.058s 通过** ⇒ 真因是 **`/tmp`（8.8G tmpfs）被 Go 构建
|
||||
缓存占满 100%**。教训：构建/测试挂住时先 `df -h /tmp`（`/` 空闲不代表 `/tmp` 够）。
|
||||
@ -57,7 +57,7 @@ sudo journalctl -u modelrouter -f
|
||||
tar 包内只有：`modelrouter`、`config.example.yaml`、`modelrouter.service`、
|
||||
`migrate-to-modelrouter.sh`、`adapters/`。
|
||||
|
||||
**发行包不含业务插件**（`channels` / `billing` / `quota` / `usage` 等）。
|
||||
**发行包不含业务插件**（仓库只保留 `billing` / `usage` 两个与厂商无关的示例）。
|
||||
它们保留在仓库中作为可选扩展，需要时手工放入 `plugin_dir`，网关不会自动安装、
|
||||
覆盖或删除。这是有意的：插件属于运维资产，生命周期不与内核绑定。
|
||||
|
||||
@ -72,7 +72,7 @@ key 打印在启动日志里。发行包不预置任何可用 key（历史上曾
|
||||
- `master.key` 必须 0600。当前 unit 以 root 运行：降权到普通用户需要先把
|
||||
`master.key` 交给该用户并统一目录属主，否则服务会"带着明文落盘继续跑"，
|
||||
失败只留一行日志——这是独立变更，不要和加固混在一起。
|
||||
- `plugin_dir` 由运维维护；插件自带的状态文件（如 `.channels-store.json`）也在其中。
|
||||
- `plugin_dir` 由运维维护；插件自带的状态文件也在其中。
|
||||
|
||||
## 4. 从 llmsproxy 迁移
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@ Groq、Mistral、Ollama、KimiCode…）通过 **Lua 适配器** 做协议转换
|
||||
一个标准 `OpenAI Chat Completions` 接口（`/v1/chat/completions` + `/v1/models`），
|
||||
支持单次结算、SSE 流式、**AUTO 模型路由**与**多模态**透传。
|
||||
|
||||
从 [HomeAgent](https://gitcode.com/JianFeeeee/HomeAgent) 的多源 LLM 适配层
|
||||
从上游多源 LLM 适配层
|
||||
（`internal/agent/api/provider.go` + `internal/lua/adapters/*`）抽离而来并独立演进。
|
||||
|
||||
## 特性
|
||||
|
||||
@ -134,7 +134,7 @@ git push origin vX.Y.Z
|
||||
make core-dist VERSION=X.Y.Z
|
||||
|
||||
# 5. create GitCode Release + upload
|
||||
# https://gitcode.com/JianFeeeee/ModelRouter/releases
|
||||
# https://atomgit.com/HeNanMU-EEA/ModelRouter/releases
|
||||
# upload MUST use PUT --http1.1, otherwise the OBS callback fails and the
|
||||
# file never lands in the release; replacing artifacts = delete the tag
|
||||
# (release disappears with it) then recreate.
|
||||
|
||||
@ -124,7 +124,7 @@ git push origin vX.Y.Z
|
||||
make core-dist VERSION=X.Y.Z
|
||||
|
||||
# 5. 创建 GitCode Release + 上传安装包
|
||||
# 见 https://gitcode.com/JianFeeeee/ModelRouter/releases
|
||||
# 见 https://atomgit.com/HeNanMU-EEA/ModelRouter/releases
|
||||
# 上传注意：必须 PUT --http1.1，否则 OBS 回调失败文件不进列表；
|
||||
# 替换旧版附件 = 删 tag（release 随 tag 一起消失）后重建。
|
||||
```
|
||||
|
||||
@ -61,7 +61,7 @@ rpm 需系统 `rpmbuild`。每次打包后都会跑 `packaging/verify-dist.sh`
|
||||
|
||||
- 构建镜像：`cmd/gui/docker/win-builder/Dockerfile`（`golang:1.25` + mingw-w64 +
|
||||
node + wine32/wine64 + 预编译 LuaJIT windows 版 `lua51.dll` 与 import lib）。
|
||||
LuaJIT 源码取自 gitcode 镜像（国内可达），github 兜底；Go 依赖走 `https://goproxy.cn`。
|
||||
LuaJIT 源码取自国内镜像，上游兜底；Go 依赖走 `https://goproxy.cn`。
|
||||
- 一键发布：`cmd/gui/scripts/dist-win-docker.sh` —— 核心编译 + electron-builder
|
||||
NSIS 全部在容器内执行（`USE_SYSTEM_WINE=true` 走镜像内的 wine）；electron-builder
|
||||
的 ~400MB 工具链缓存挂到 docker volume，二次构建增量复用。
|
||||
|
||||
@ -332,13 +332,13 @@ PUT /api/plugins/{name}/state 替换状态（admin）
|
||||
|
||||
### 5.4 定时任务（`PLUGIN.schedule`）—— 浏览器关着也会跑
|
||||
|
||||
要求插件做“随时间发生”的事（自动签到、token 轮换、额度轮询）时，声明一个
|
||||
要求插件做“随时间发生”的事（定时刷新、token 轮换、指标采集）时，声明一个
|
||||
调度表：
|
||||
|
||||
```lua
|
||||
plugin.schedule = {
|
||||
{ fn = "refresh_token", every = 3600 }, -- 每小时（秒）
|
||||
{ fn = "daily_checkin", every = 86400, at = "03:30" }, -- 每天固定时刻（本地时间）
|
||||
{ fn = "daily_refresh", every = 86400, at = "03:30" }, -- 每天固定时刻（本地时间）
|
||||
{ fn = "poll_quota", every = 300, jitter = 30 }, -- 首次触发加 0-30s 抖动
|
||||
}
|
||||
function plugin.refresh_token()
|
||||
|
||||
Reference in New Issue
Block a user