所有已配置的模型能协作、能当众干活，而 token 消耗始终由用户把关——这是给 Nyral 设计"多模型协作"时的三个目标。方案演化到今天，落地成两种模式：讨论团和评审团。
起因：一次生图模型当主模型翻的车
Nyral 接入腾讯 TokenHub 聚合网关后，我一度把 hy-image-v3.5-preview（混元文生图模型）设成了主聊天模型，结果发一句"你好"就报 400 model not exist。
排查下来的原因很直白：混元多模态是独立的生成模型，没有对话能力，走 chat/completions 必然失败。它真正的调用端点是 POST {base}/v1/wand/hunyuan-image/v35-generation——一个聊天式结构的生成端点，支持 messages 数组、参考图，同步返回 choices[].delta.image.url。
顺手把生图工具和主链路都改到了这个端点，实测通过。但问题随之而来：
用户配了一堆模型（DeepSeek、GLM、小米 MiMo、TokenHub 混元），它们却彼此孤立。 对话靠一个主模型，生图靠工具写死当前 provider，生视频又是另一套。能力是有的，但"各干各的"，谁也不认识谁。
想法：让所有模型互相可见
那天凌晨，我说了一句：能不能让所有模型互相看到？DeepSeek 可以直接调用 GLM，GLM 反过来也能用 DeepSeek，小米同样如此。每个模型都有完整能力，主模型甚至可以"偷懒"，让副模型去干活。
讨论下来，这个概念落地成三层：
模型注册表（所有已配置模型，按能力分组）
│ 能力路由
▼
主模型（主持人 + 决策者 + 汇总者）
│ model_delegate / 生成工具
▼
参与模型（顾问团：各抒己见，结果仅供参考）
▼
用户（最终决策者，可随时打断）
- 模型注册表：设置页里所有 provider + 勾选的模型，按能力标注分组（对话 / 生图 / 生视频）。配一次 TokenHub Key，对话选 hy4、生图选 hy-image、生视频选 hy-video，全部互相可见。
- 主模型当主持人：议题由它定，请谁参与由它提议，观点由它汇总收敛，结论由它呈现给用户。它自己也可以参与讨论——毕竟它掌握上下文和工具。
- 参与模型是顾问团：每次发言是一次独立调用，输出只是"顾问意见"，不是结论。
- 用户拍板：主模型给出"结论 + 分歧点 + 推荐"，用户一句话就能推翻。
演化：讨论团还是评审团？
初版文章发布后，我又和豆包推演了一版更工程化的设计——评审团。它保留了"多模型协作 + 用户拍板"的核心，但把"模型互相可见"改成了"模型完全隔离"，并补上了上下文传递规则、token 预算、状态机等细节。
两种模式摆在一起，一度像二选一：
| 维度 | 讨论团 | 评审团 |
|---|---|---|
| 模型间关系 | 互相可见，串行碰撞 | 完全隔离，互不可见 |
| 讨论形态 | 模型间你来我往 | 每轮独立发言 → 汇总 → 用户决定是否再投 |
| 收敛方式 | 主模型收敛 | 用户拍板 + 收敛检测提示 |
| 立场污染 | 有风险（汇总带倾向） | 强制"事实/倾向分离" |
| 成本控制 | 弹窗授权（开团前） | 弹窗授权 + 每轮用户确认 |
但想深一层：这不是单选题。两者的差异只是"信息流拓扑"——讨论团是全连接（每个人看得见别人的发言），评审团是星型（只有主模型全知，评审模型只见汇总）。中间还夹着"只传上轮事实性汇总"的半开放形态。把可见度做成参数，两种模式就统一成一个多模型协作框架了：ReviewOrchestrator 里一个 mode 字段的事，不是两套代码。
关键设计：信息流拓扑参数化
讨论团 = 全连接，串行。 讨论的本质是碰撞，后发言者要能看到前面的观点，所以讨论链必须串行——并行只会得到三份各说各话的独立答案，没有讨论价值。但"派发链"可以并行：互不依赖的子任务（比如先各查资料）主模型可以并行派发，结果回来后进入串行讨论阶段。干活的阶段并行，对话的阶段串行。
工程上这反而简单：Nyral 的本地引擎本来就是串行工具循环 + SSE 流式输出，讨论就是"主模型循环调 model_delegate，每调一个副模型就输出一条流式发言"，天然不会打架。
评审团 = 星型，并行。 评审模型之间永不互见，零锚定、零传话失真、零立场污染，每个模型永远从自己的盲区出发给意见。作为回报，评审天然适合并行——互不可见就没有串行依赖，一轮延迟 ≈ 最慢的那个模型。评审模型每轮只看到"问题 + 上轮事实性汇总 + 分歧点"，主模型是唯一全知者，持有完整历史。
评审团有个独立的价值：事实与倾向强制分离。主模型也是模型，汇总时必然掺入倾向。若混合呈现，用户（最终决策者）会被悄悄带偏——这是比模型间锚定更严重的污染。所以汇报格式严格分段：“各模型观点"只陈述、禁止任何评价性词汇，“主模型推荐"必须显式标注"这是主持人的倾向，不是事实”，用户有权展开查看任意模型发言原文。
成本控制：三重闸门
多模型协作的代价是 token 翻倍，不能默认放开。两个模式共用三道闸门：
- 弹窗授权：主模型要开团/开评审或调生图工具时，弹出候选模型让用户选、确认或拒绝。讨论团、评审团、生图、生视频共用同一套"选模型 + 确认"弹窗，候选列表不同而已。
- 每轮用户确认：评审团的"再投一轮"本身就是闸门——不点就不会产生下一轮成本；讨论团里用户随时可以打断。
- 模型级开关 + 轮数上限：单模型可单独禁用参与协作，
max_rounds默认 3 轮封顶。
另加 120 秒超时自动拒绝：没人点弹窗就自动拒绝（这个机制本来就存在），后台任务也不会卡死。
成本账也大致算过：3 个评审模型 + 1 个主模型跑一轮约 4800 token（池子快照策略，每轮只传小汇总），全量上下文共享要 3 倍以上，还会让模型观点趋同。把池子做小，是控制成本的核心。
交互：当众流式，随时打断
最初的想法是把协作放在后台，跑完甩个结论。但这样有两个问题：用户干等 N 倍时间；结论怎么来的像个黑盒。
后来想到一个更顺的形态——参考多 Agent 交接的剧场感：Marvis 调用 browser 子 Agent 时，小弟会"冒出来"说"我去看看”，干完再交接回来，用户全程围观，从不觉得在死等。
两种模式同理，都做成可见的流式对话：
用户：这需求怎么做比较好？
─────────────────────────────
[hy4-preview] 我的方案：先建索引再……
[deepseek] 我不同意，索引成本高，应该直接全量扫
[glm] 折中：先扫再按需索引，hy4 的方案更稳
[hy4-preview] 采纳，按我的方案，deepseek 的担忧兜底处理
─────────────────────────────
主持人收敛：结论如下……
每个模型发言是一个气泡（像子 Agent 冒出来），用户能看到谁在说话、观点怎么碰撞、怎么收敛，随时插一句"别争了，用第二个方案"。评审团模式下，各模型观点独立呈现，分歧点列成清单，最后给"执行推荐 / 再投一轮 / 拒绝修改"三个选项。等待感消失，黑盒变透明。
演进路径
- 第一步：
model_delegate单次委派——主模型"偷懒"让副模型干一件具体的事，成本可控，先解决"互相调用"。 - 第二步：讨论团——串行可见，先跑通信息流拓扑。它天然串行，实现就是"循环调用 + 上下文拼接"，比评审团便宜。
- 第三步：评审团——加并行调度 + 事实/倾向分离汇总，建立在前面两步的地基上。
风险清单
- 延迟：N 模型 × M 轮的串行讨论总时长不短，靠流式可见缓解"等待感"；评审团并行后延迟收敛到单轮。
- 成本：弹窗授权 + 每轮确认 + 模型级开关/轮数上限三重闸门。
- 稳定性：多模型输出格式不一致、某个模型挂了讨论卡住，需要重试和降级（超时跳过，全部失败则终止提示）。
- 路由准确性：模型能力标注靠启发式 + 分组勾选，跨 provider 路由可能指向无权限模型（TokenHub 那类 400/402 的坑），需要对照测试。
- 观点不收敛：评审团加收敛检测，连续两轮观点一致时提示"继续评审大概率不会产生新信息，建议拍板"——提示只是建议，用户有权无视。
结语
这个设计其实没造新轮子：模型注册表是现有配置的升级，弹窗和超时是现成机制，工具循环是 Nyral 本来就有的大脑，多模型协作只是把"单主模型驱动"扩展成"主模型主持、副模型顾问、用户拍板"。
讨论团适合发散（头脑风暴、创意激发），评审团适合收敛（方案评审、重大决策）——不是二选一，是同一个框架下的两种形态。
它想回答一个朴素的问题：用户都配了那么多模型了，为什么不能让它们一起干活？ 现在至少有了一个不花冤枉 token、又能当众协作的答案。