跨厂商会审

一句话：不可逆的动作，先让两个不同厂商的模型各审一遍，再按「共识 / 分歧」合并 —— 不许挑顺耳的。

0. 先判断值不值得审（省钱铁律）

会审是闸门，不是流程。默认不审：

• 提会审时先报预计花费（双厂商一次 ≈ 几毛钱；上下文越大越贵）。
• 用户不在场（定时任务 / 无人值守）不得花钱。

1. 硬规则（五条）

1. 每次会审必须 ≥2 个不同厂商同时参与（默认 Claude + GPT）。单厂商审查不算会审， 它的结论只能当"半份意见"，不许据此做不可逆动作。 ⚠️ provider: claude|gpt 只是配置里的标签，不等于背后真的是不同厂商的上游 （中继可以两边都转同一家）。别把"配置里有两个 provider"当成"已跨厂商" —— 第一次用某种组合时，跑一遍并留档（看两边回答的模型标识/风格）再当既成事实。
2. 第三家（Gemini 等）是加分项：用于「两家结论相反」「只有一家提到」时裁决，不替代前两家。
3. 同题：所有通道拿完全相同的一份 prompt（产物 + 公共问题清单 + 同一组额外侧面）。 提示只要有一处不同，两份答案就不能严格比较，共识/分歧也算不准。
4. 多元化靠"同一组侧面"而不是"各问各的"：把下面两句都放进每条通道的 prompt， 让每家都回答两个侧面（而不是给 GPT 只问反例、给 Claude 只问结构）：
   • 反例与边界条件是什么？什么情况下这个结论会不成立？
   • 结构性缺陷 / 表述过头 / 可执行性问题在哪？
5. 收尾必须报账：由合并那一步的执行者（不是子 agent）统计并写进最终报告 —— 用了哪几条通道 + 各自花费（拿不到实价就写"标称 / 未知"）+ 共识 / 分歧。

2. 三步流程

① 体检（不花钱，先做）

NODE=$(command -v node || echo "$DSH_HOME/../runtime/bin/node")
$NODE <本技能目录>/scripts/review-channels.mjs            # 列出可用厂商与模型（读你自己的配置）
$NODE <本技能目录>/scripts/review-channels.mjs --gate     # 体检默认会审通道：全 green → 退出码 0

• <本技能目录> 通常是 $DSH_HOME/skills/dsh-review。
• --gate 退出码：0 = 全绿；1 = 默认通道里有非 green（换同源回退或升档，不要盲调用）；2 = 网络 / 配置读不到。
• 输出里有「解析：N 个 provider / M 个模型」。N 或 M 是 0 就是格式变了（脚本按"每层 2 空格"解析 YAML）， 不是"模型不在清单里"—— 别按后者去排查。
• 查不到状态 ≠ 通过：只有明确 green 才算过；没配监控站时只是「静态通过」，结论里必须写明 「模型能不能真的调用、provider 能不能真的路由到不同厂商，都还没验证」。
• ⛔ "这家站卖什么"（价目 / 目录）≠ "我有什么"（授权清单）： 能调用的模型 = 你自己配置里的清单。清单里没有的模型，无论多便宜都调不通， 别去猜协议 / 分组 / 上游。

② 并行审（花钱，这一步）

用 workflow 工具（它支持 provider / model 覆盖）跑 scripts/review-workflow.template.js： 把它读出来、按里面的 TODO 填好产物与问题，再一次提交。要点：

• 每条通道一个 subagent(...) 调用（或 workflow 里的 agent(...)），同一份产物 + 同一份问题清单，各自独立上下文；
• 换厂商靠 subagent 的三件套：provider + model + reasoning_effort（snake_case）。reasoning_effort 必须显式写：只换 route 不给 effort，会清掉继承来的档位、退回该模型默认档，等于偷偷降智。k3.1-pro 支持 low/high/max，glm-5.3-flash 支持 off/low/medium/high/max。
• 路由受白名单约束：cordis.patch.yml 的 subagent-model-selection-settings.allowedModels。不在表里会直接报 child LLM route "<provider>/<model>" is not allowed for this Session——先查表再派活，别硬试。
• ⛔ workflow 的 agent(prompt, opts) 只有 provider / model / label / phase / schema，没有 reasoning_effort。要多通道并行 + 显式推理档，就用逐个 subagent 并发；要它一口气跑几十个用例，才用 workflow。
• 便宜通道报问题=强信号，它沉默不等于通过：glm-5.3-flash 曾两次只回一句交接话、正文空着，且历史盲测只过 1/10 —— 拿它复检逻辑要另配一条贵通道兜底。

③ 合并（这步是判断，不是拼接）

⚠️ 便宜 / 打折通道是"筛查器"，不是"证明器"：

• 它报出问题 → 强信号（挑出站得住的批评本身需要能力，编不出来）；
• 它说"没问题" → 弱信号（能力不足时它看不见，沉默可能只是没看出来）。 → 发现即当真；沉默不算通过。 越不可逆的决定，越要在"沉默"时补一条高保真通道。

3. 成本纪律（按次计费尤其重要）

按次一口价的通道：每个请求都收一次钱，所以分两种情况，别混着说：

• 产物已经在 prompt 里（推荐） → prompt 里写死：禁止调用任何工具（包括 read）， 一次请求直接给答案。
• 产物在文件里（太大塞不进 prompt） → 你自己把文件内容展开、复制进 prompt （路径写成展开后的绝对路径），不要让 agent 自己去 read： 一次 read = 多一个请求 = 多收一次钱（而且还可能读不全）。 实在必须让它读，就在 prompt 里写死「只允许调用 read 工具一次、不要多轮探索」。
• ⚠️ 模型名里的「次-0.04￥」是标称价，不是实价：它读自模型名，不含 token 量、 重试、失败请求、上游加价。报账时写「标称 ¥x/次」，别当精确金额。
• 送审上下文越小越便宜：先删无关日志，再送。

4. 隐私红线（第三方中继能看到全部内容）

⛔ 拦截必须发生在"组装 prompt 之前"，是调用方（本地）的责任 —— 内容一旦发出去，模型再听话也救不回来。

• 送审前先本地自查：产物里有没有 密钥 / token / 凭据、隐私数据、能定位到人的信息？ 命中就先把这些字段删掉或替换掉，再组装 prompt；删不干净就放弃送审， 改成人工审查（不要指望"让模型自己忽略"）。
• 绝不送审：密钥 / token / 凭据文件、用户隐私数据、带身份信息的个人内容。
• 会审产物本身若含上述内容 → 先脱敏再送；脱敏不了就跳过会审。

5. 配置（可选，个人数据，放在自己家里、不进包）

$DSH_HOME/review.json（defaults 两种写法都认：字符串 = 单通道；对象 = 同一 provider 挂多条线）：

{
  "monitor": "https://<状态监控站>",
  "window": "1h",
  "defaults": {
    "gemini":   { "provider": "opencode-go", "model": "gemini-4-argon",      "vendor": "Google" },
    "kimi":     { "provider": "opencode-go", "model": "kimi-k3.1-pro",       "vendor": "Moonshot AI" },
    "deepseek": { "provider": "opencode-go", "model": "deepseek-v4.1-flash", "vendor": "DeepSeek" }
  }
}

2026-10-26 起默认会审 = Gemini 4 Argon + Kimi K3.1 Pro（DeepSeek 留作第三视角）。 依据见 fact-review-model-policy。opencode-go 的模型来自 pi-ai 内置目录、patch 里没列清单， 所以 --gate 对它只能标「清单未列（需现测）」——真能不能调，以一次真实调用为准。

• monitor：可选。支持 New API 风格监控站的三条 embed 接口 （/api/model-status/embed/status/batch?window=1h、/config/selected、/token-groups）。 没配就只做"模型 id 还在不在我的授权清单里"的静态检查。
• defaults：--gate 要体检的默认通道（每条线一个）。没配则 --gate 会报错退出， 让你先挑好再体检 —— 不会替你瞎猜价格。
• 想省钱就把 defaults 指向同源的便宜通道，并在 SKILL.md 之外记下回退顺序 （例如换同来源的备用通道；只剩一家可用时照实说明，不要假装完成了会审）。

6. 常见坑（都踩过）

• catalog ≠ entitlement：价目表里有、自己配置里没有的模型，必然调不通。 排查"调不通"的第一步永远是核对自己的授权清单，不是猜协议。
• 输出为空 / 串味：有的通道会把上游 agent 的系统提示带进来（回复像"Understood…"）， 或经常返回空 —— 这类通道别用来做审查（宁可换一条）。
• 别把"两家说了同一类话"当共识：同厂多通道只增加可用性，不增加独立性； 真正的独立盲区靠换厂商。
• 报告别只贴两份原文：要给出共识 / 分歧表 + 你的裁决与依据。