magicrew-auth 0.3.26 → 0.3.29

package/src/keys.mjs

@@ -2,21 +2,16 @@
 //
 //   登录成功  → issueAndStore()  签一把放进「另一个槽」，切过去
 //   loader    → ensureKey()      快过期就把新的签到另一个槽，切过去；旧的留着当回退
-//   refresh   → ⚠ **不经过本模块**。src/hooks/refresh.mjs 自己调
-//               api.refreshGatewayKey(auth.refresh)，magpie 拿到的不是这一把。
+//   refresh   → renewViaStore()  续期、写回 store；magpie 拿到的就是 store 里这一把
 //
 // **每个账号一套槽，互不干扰** —— 同站点登两个账号时，第二个人登录不会碰第一个人的 key。
 // 账号标识用 `org`（组织码），拿不到才退回 accountId。
 //
-// ⚠ 上面那条 refresh 是「唯一出口」这个设计里**唯一没落地的口子**（2026-10-27 核对）：
-//   refresh_token 是一次性轮换的，两条路径各用各的那份会分叉 ——
-//   ensureKey 轮换后 store 里是新值，refresh.mjs 手里 magpie 的还是旧值，
-//   再调就是 401 → magpie 判定「登录已失效」→ 让用户重新登录。
-//
-//   目前不会触发，因为 **store 从来没被写过**（本机 magicrew-key-*.json 一个都没有，
-//   说明 ensureKey 从没执行过 —— 没发过模型请求）。但这意味着：
-//   **若将来要给 checkin 补 ensureKey，必须先把这个钩子也收敛进来**，
-//   否则就是亲手把「一条路」掰成两条，用「多写一句文档」换「用户莫名掉登录」。
+// ⚠ refresh 这条口子曾经是「唯一出口」设计里唯一没落地的地方（2026-10-27 核对）：
+//   refresh.mjs 自己调 api.refreshGatewayKey(auth.refresh)，拿到的 key 只交给 magpie，
+//   与 store 各存一份 —— refresh_token 一次性轮换，两条路径必然分叉。
+//   0.3.29（PR #12）起已收敛到 renewViaStore()：与 ensureKey 共用 renewOnce 锁和
+//   同一个 key-store，refresh_token 也只从这里轮换出去。
 
 import { issueGatewayKey, refreshGatewayKey } from "./api.mjs"
 import {
@@ -84,6 +79,150 @@ export function accountFor(c, auth) {
   return direct
 }
 
+/**
+ * 这个账号**所有**可能能用的 key，按到期时间从晚到早排。
+ *
+ * 为什么需要「多把」：key 有两条签发路径 —— magpie 的 `auth.refresh` 一条
+ * （src/hooks/refresh.mjs）、本模块的 `ensureKey` 一条，两边各写各的。
+ * api_key 只活 2 小时，两条路各自什么时候续、续到哪把，本地并不一致 ——
+ * 静态「只挑一把」必然有一半概率踩空。
+ *
+ * 2026-10-29 实测（5 个国际站账号，逐把打 /v1/chat/completions）：
+ *
+ *   magicrew-intl          auth.access ✅   store 槽 b ❌
+ *   magicrew-intl#z983c8   auth.access ✅   store 槽 b ❌
+ *   magicrew-intl#3oqx5z   auth.access ❌   store 槽 a ✅
+ *   magicrew-intl#h2mcxi   auth.access ❌   store 槽 b ✅
+ *   magicrew-intl#8amjca   auth.access ❌   store 槽 a ❌  ← 两把都死
+ *
+ * **5 个里 3 个两路状态不一致，方向还各不相同** —— 先 store 或先 auth 都救不了。
+ *
+ * ⚠ 不要读成「服务端同一账号只认最新签发的那把」。2026-10-28 的受控实验已经
+ * 推翻过这个说法：同账号相隔 67 秒签的两把同时有效；12 把逐把探活，403 全部
+ * 对应 `expiresAt` 已过。真正的原因是**手里那把过期了**，而两条路径让本地
+ * 不知道自己手里的是哪把。逐把试解决的就是这个「不知道」。
+ *
+ * 到期越晚 = 签发越晚 = 越可能是活着的那把，所以按 expiresAt 倒序试。
+ *
+ * @param {object} c               站点上下文
+ * @param {Function|object} getAuth magpie 的取账号函数，或直接给 auth 对象
+ */
+export async function keyCandidates(c, getAuth) {
+  let auth = null
+  try {
+    auth = typeof getAuth === "function" ? await getAuth() : getAuth
+  } catch {}
+  const account = accountFor(c, auth)
+  const st = readStore(c.id, account)
+
+  const out = []
+  const byKey = new Map()
+  const add = (k) => {
+    if (!k?.apiKey) return
+    const rec = { apiKey: k.apiKey, expiresAt: Number(k.expiresAt) || 0 }
+    const prev = byKey.get(rec.apiKey)
+    if (prev) {
+      // 同一把 key 从两路拿到时，保留更晚的到期时间 —— 否则可能被排到死 key 后面
+      if (rec.expiresAt > prev.expiresAt) prev.expiresAt = rec.expiresAt
+      return
+    }
+    byKey.set(rec.apiKey, rec)
+    out.push(rec)
+  }
+  add(currentKey(st))
+  add(st?.keys?.[otherSlot(st.current)])
+  if (auth?.access) add({ apiKey: auth.access, expiresAt: Number(auth.expires) || 0 })
+
+  return out.sort((a, b) => Number(b.expiresAt || 0) - Number(a.expiresAt || 0))
+}
+
+/** 把实测能用的那把写回 store —— 下次直接命中，不再逐把试错 */
+export function adoptKey(c, auth, apiKey, expiresAt) {
+  try {
+    const account = accountFor(c, auth)
+    const st = readStore(c.id, account)
+    if (currentKey(st)?.apiKey === apiKey) return
+    const slot = otherSlot(st.current)
+    writeStore(c.id, account, {
+      current: slot,
+      // 空 store 首次接管时 refresh_token 只在 magpie 手里 —— 这里必须接住，
+      // 否则 2 小时后没人能续，用户被要求重新登录。
+      refreshToken: st.refreshToken || auth?.refresh || "",
+      keys: { ...st.keys, [slot]: { apiKey, expiresAt: Number(expiresAt) || 0 } },
+      at: st.at,
+    })
+  } catch {}
+}
+
+/**
+ * 续期并**写回 store** —— 给 src/hooks/refresh.mjs 用。
+ *
+ * 收敛成一条路径的原因：refresh.mjs 原来自己调 `refreshGatewayKey`，
+ * 拿到的 key 只交给 magpie，插件 store 里还是旧的。两条路径各存一份，
+ * 哪把是新签的、哪把已经过期，本地说不清 —— 2026-10-29 实测 5 个账号里
+ * 3 个两路状态不一致，就是这么来的。
+ *
+ * ⚠ refresh_token 是一次性的：谁续谁负责写回，不能让两边各存各的。
+ */
+export async function renewViaStore(c, auth) {
+  const account = accountFor(c, auth)
+
+  // 与 ensureKey 共用同一把锁（renewOnce 按 siteId+account 去重）——
+  // refresh_token 一次性，两条路径同时续期会让后到的那次用废 token → 误判掉登录。
+  let err = null
+  const rec = await renewOnce(c.id, account, async () => {
+    try {
+      const st = readStore(c.id, account)
+
+      // refresh_token 也可能有两份：store 里的（ensureKey 续过）与 magpie 手里的
+      // （0.3.29 之前的 refresh.mjs 续过）。两把都是一次性，只有一把还活着 ——
+      // 升级上来的第一次尤其：store 那份可能早被轮换废了，auth.refresh 才是活的。
+      const tokens = []
+      const seen = new Set()
+      for (const t of [st.refreshToken, auth?.refresh]) {
+        if (!t || seen.has(t)) continue
+        seen.add(t)
+        tokens.push(t)
+      }
+      if (!tokens.length) throw new Error("没有 refresh_token")
+
+      let lastErr = null
+      for (const refreshToken of tokens) {
+        try {
+          const k = await refreshGatewayKey(refreshToken, c.host)
+          const next = { apiKey: k.apiKey, expiresAt: toEpochMs(k.apiKeyExpiresAt) }
+          const slot = otherSlot(st.current)
+          const nextRefresh = k.refreshToken || refreshToken
+          writeStore(c.id, account, {
+            current: slot,
+            refreshToken: nextRefresh,
+            keys: { ...st.keys, [slot]: next },
+            at: st.at,
+          })
+          return { ...next, refreshToken: nextRefresh }
+        } catch (e) {
+          lastErr = e
+        }
+      }
+      throw lastErr ?? new Error("续期失败")
+    } catch (e) {
+      err = e
+      throw e
+    }
+  })
+
+  if (!rec) throw err ?? new Error("续期失败")
+  // 并发时可能复用 ensureKey 的 rec（它只返回 apiKey/expiresAt）——
+  // 从 store 补上最新 refresh_token，免得 magpie 那份落后一轮。
+  if (!rec.refreshToken) {
+    try {
+      const st2 = readStore(c.id, account)
+      if (st2.refreshToken) rec.refreshToken = st2.refreshToken
+    } catch {}
+  }
+  return rec
+}
+
 /**
  * 拿到这个账号一把能用的 key。**永不抛** —— 续不上就交出手里那把（哪怕不新鲜），
  * 让请求自己去撞上游的错误，比在这里抛更能说明问题。

package/src/vision.mjs

@@ -128,49 +128,107 @@ function lastClock(text) {
 }
 
 async function askClock(base, model, imageDataUrl, variant) {
-  const res = await fetch(`${base}/chat/completions`, {
-    method: "POST",
-    headers: { "content-type": "application/json" },
+  const body = {
+    model,
+    // ⚠ 这个上限是**给推理 token 留的**，不是给答案留的。
+    //
+    //   实测（2026-10-28，`workbuddy/deepseek-v4.1-flash`）：max_tokens=400 时
+    //   `finish_reason:"length"`、`reasoning_tokens:400`、**`content` 是 null** ——
+    //   推理过程把额度吃干净，答案一个字都没输出。判官拿到空串 ⇒ 判成
+    //   「不可信」⇒ 整条无头登录挂掉。给到 6000 时 reasoning 用 899 就收尾，
+    //   `content` 正常回 "10"。
+    //   ⇒ 别按「答案就一个数字」去估这个值；它买的是模型的思考空间。
+    max_tokens: 6000,
+    // ⚠ `reasoning_effort: "low"` —— 实测有据的省法（2026-10-29，同一模型同一批图，
+    //   每个配置各跑 6 轮）：
+    //
+    //     |            | 出数字 | 平均耗时 | 平均 tokens | 平均 reasoning |
+    //     | 不传        |  5/6  | 20.6 s   |   2343      |    3581 字     |
+    //     | low         |  6/6  |  8.4 s   |   1007      |    1646 字     |
+    //
+    //   更快、更省、而且**更稳**（不传的那一组有一次把 6000 token 全烧在思考上、
+    //   `content` 交白卷）。判出来的角度两者一致。
+    //
+    //   ⚠ 别指望「彻底不思考」——这个模型在网关侧关不掉，实测 12 组参数：
+    //     `enable_thinking:false` / `thinking_budget:0` → 思考**更长**且 content 空；
+    //     `reasoning_effort:"none"/"minimal"` → 比不传还长；
+    //     `thinking:{type:"disabled"}` / `chat_template_kwargs` / `extra_body` /
+    //     `reasoning:{enabled:false}` → 都只是小幅缩短，没有一个真的关掉。
+    //     要真不思考，只能换一个**非推理**的视觉模型（那由用户在 magpie 设置里选）。
+    //
+    //   ⚠ 它**不是** OpenAI 规范字段：下面 send() 里有一层兜底，被 400 就退一步重发。
+    reasoning_effort: "low",
     // temperature 0 是为了同一张图两次问法之外的噪声尽量小；
     // 两次用不同措辞（variant）而不是靠随机温度，好复现
-    body: JSON.stringify({
-      model,
-      max_tokens: 400,
-      temperature: 0,
-      messages: [
-        {
-          role: "user",
-          content: [
-            { type: "text", text: CLOCK_PROMPT(variant) },
-            { type: "image_url", image_url: { url: imageDataUrl } },
-          ],
-        },
-      ],
-    }),
-    signal: AbortSignal.timeout(45_000),
-  })
+    temperature: 0,
+    messages: [
+      {
+        role: "user",
+        content: [
+          { type: "text", text: CLOCK_PROMPT(variant) },
+          { type: "image_url", image_url: { url: imageDataUrl } },
+        ],
+      },
+    ],
+  }
+
+  const send = (b) =>
+    fetch(`${base}/chat/completions`, {
+      method: "POST",
+      headers: { "content-type": "application/json" },
+      body: JSON.stringify(b),
+      signal: AbortSignal.timeout(90_000),
+    })
+
+  let res = await send(body)
+  if (res.status === 400 && Object.hasOwn(body, "reasoning_effort")) {
+    // 兼容兜底：识图模型是**用户自己选的**，不是我们能假设的（插件声明的模型目录里
+    // 什么都可能有，magpie 也允许自定义 provider）。有的 OpenAI 兼容端认出这个字段、
+    // 有的直接为未知字段回 400。宁可少省那几秒，也不要因为一个可选的优化把整条
+    // 无头登录打死 —— 去掉它重发一次，行为退回「不传」的那一档。
+    delete body.reasoning_effort
+    res = await send(body)
+  }
   if (!res.ok) throw new Error(`识图模型回 HTTP ${res.status}`)
   const j = await res.json()
-  const text = j?.choices?.[0]?.message?.content ?? ""
-  return { clock: lastClock(text), text: String(text).trim().slice(0, 200) }
+  const m = j?.choices?.[0]?.message ?? {}
+  const content = String(m.content ?? "").trim()
+  const reasoning = String(m.reasoning_content ?? "")
+  // ① 正常情况：答案在 content 里
+  if (content) return { clock: lastClock(content), text: content.slice(-200), from: "content" }
+  // ② 兜底：推理模型被截断、content 为空 —— 答案在 reasoning 的最后一段里
+  //    （实测尾巴就是「最终决定：10。」这种形状）。只看尾巴 300 字，
+  //    别把前面推理中间提到的钟点当答案。
+  if (reasoning) {
+    const tail = reasoning.slice(-300)
+    return { clock: lastClock(tail), text: tail.slice(-200), from: "reasoning" }
+  }
+  return { clock: null, text: "", from: "empty" }
 }
 
 /**
  * 让识图模型判断「该顺时针转多少度」。
  *
+ * @param {string} imageDataUrl 验证码图的 data URL
+ * @param {{model?:string}} [opts] `model` 可覆盖设置里那个（给对比脚本 / 测试用；
+ *   正常运行不传，读用户选的）
  * @returns {Promise<{ok:true, deg:number, clock:number, spread:number, model:string}
  *                  |{ok:false, reason:string, detail?:string}>}
  */
-export async function decideDegFromImage(imageDataUrl) {
-  const model = readVisionModel()
+export async function decideDegFromImage(imageDataUrl, { model: overrideModel } = {}) {
+  const model = overrideModel || readVisionModel()
   if (!model) return { ok: false, reason: "no-vision-model" }
 
   const base = await resolveGatewayBase()
   if (!base) return { ok: false, reason: "no-gateway", detail: "连不上 magpie 自己的网关（试过 3425/3426/8080）" }
 
   const img = await toPngDataUrl(imageDataUrl)
-  const a = await askClock(base, model, img, 0).catch((e) => ({ clock: null, text: String(e?.message ?? e) }))
-  const b = await askClock(base, model, img, 1).catch(() => ({ clock: null, text: "" }))
+  // ⚠ **两个判官并行**：串行等两次就把延迟叠成两倍（实测单次 5～20 秒），
+  //   而它们互不依赖 —— 一起发，耗时等于较慢的那一次。
+  const [a, b] = await Promise.all([
+    askClock(base, model, img, 0).catch((e) => ({ clock: null, text: String(e?.message ?? e) })),
+    askClock(base, model, img, 1).catch(() => ({ clock: null, text: "" })),
+  ])
 
   if (a.clock == null && b.clock == null) {
     return { ok: false, reason: "unparsable", detail: `${a.text} / ${b.text}` }