multi-review: 支持为 reviewer 和 coordinator 分配不同模型

[Svtter]

背景

当前 multi-review action 只有一个 model 输入，所有 reviewer（quality、security、performance 等）和最后的 coordinator（总结合成）共用同一个模型。

当前架构：

  model: X ──┬──> Reviewer sessions (quality, security, ...)
             └──> Coordinator session (synthesis)
             
  全部使用同一个 SDK client → 同一个模型

需求

增加两个独立的模型输入，允许用户分别指定：

1. reviewer 使用的模型 — 用于各 reviewer 的代码审查
2. coordinator 使用的模型 — 用于最终总结合成

使用场景

• Reviewer 使用廉价/快速模型（如 deepseek/deepseek-v4-flash）做大量并行审查
• Coordinator 使用更强的模型（如 zhipuai-coding-plan/glm-5.1）做高质量总结
• 反之亦然：强模型审查，快速模型总结
• 成本优化 + 质量控制的灵活组合

预期 API

- uses: sun-praise/opencode-actions/multi-review@v3
  with:
    model: deepseek/deepseek-v4-flash          # reviewer 模型
    coordinator-model: zhipuai-coding-plan/glm-5.1  # coordinator 模型

向后兼容：

• coordinator-model 不设置时，coordinator 继续使用 model（当前行为）
• model 不设置时，保持现有默认值

SDK 调研结果

@opencode-ai/sdk 的 session.prompt() 支持 per-prompt 模型覆盖：

// types.gen.d.ts — SessionPromptData
export type SessionPromptData = {
  body?: {
    model?: {
      providerID: string;
      modelID: string;
    };
    parts: Array<...>;
  };
  path: { id: string };
};

这意味着 方案 B（单 server 实例 + per-prompt override）完全可行，无需启动额外的 opencode server 进程。

实现方案：

  createOpencode({ config: { model: "reviewer-model" } })
  │
  ├── session 1: prompt({ model: undefined })     → reviewer-model (默认)
  ├── session 2: prompt({ model: undefined })     → reviewer-model (默认)
  └── coordinator: prompt({ model: { providerID, modelID } })  → coordinator-model

单 server 进程 ✓ 无额外开销 ✓ SDK 原生支持 ✓

实现计划

涉及的文件

文件	改动
multi-review/action.yml	新增 coordinator-model 输入 + 环境变量传递
multi-review/src/types.ts	OrchestratorOptions 加 coordinatorModel 可选字段
multi-review/src/reviewers.ts	新增 resolveCoordinatorModel()，fallback 到 reviewer model
multi-review/src/orchestrator.ts	runCoordinator() 的 prompt() 调用传入 model 参数
multi-review/src/index.ts	解析 coordinator model 并传入 orchestrator options
multi-review/README.md	文档更新

具体改动

1. action.yml — 新增 input coordinator-model（description: 为 coordinator 合成步骤指定不同模型），传递 MULTI_REVIEW_COORDINATOR_MODEL 环境变量
2. reviewers.ts — 新增 resolveCoordinatorModel():

   export function resolveCoordinatorModel(): { providerID: string; modelID: string } | undefined {
     const raw = env("MULTI_REVIEW_COORDINATOR_MODEL");
     if (!raw) return undefined;  // fallback: coordinator 用 reviewer model
     const idx = raw.indexOf("/");
     if (idx === -1) throw new Error(...);
     return { providerID: raw.slice(0, idx), modelID: raw.slice(idx + 1) };
   }

3. types.ts — OrchestratorOptions 加:

   coordinatorModel?: { providerID: string; modelID: string };

4. orchestrator.ts — runCoordinator() 中 prompt 调用加 model:

   client.session.prompt({
     path: { id: sessionId },
     body: {
       ...(opts.coordinatorModel ? { model: opts.coordinatorModel } : {}),
       parts: [{ type: "text", text: fullPrompt }],
     },
   })

5. index.ts — main() 中解析并传递:

   const coordinatorModel = resolveCoordinatorModel();
   // ...传给 runCoordinator 的 opts

[Svitter]

Good proposal. Here's a technical feasibility analysis based on the current codebase.

Architecture constraint

model is set at server config level in buildSdkConfig() → passed to createOpencode() → bound to the single server instance. Neither session.create nor session.prompt in the SDK accept a per-session model override (multi-review/src/orchestrator.ts:65, 73). So session-level switching (option 2 from your proposal) is not viable today without upstream SDK changes.

Viable path: dual SDK instances

The practical approach is option 1 — two createOpencode() calls:

1. Reviewer server — createOpencode({ config: buildSdkConfig(reviewerModel) })
2. Coordinator server — createOpencode({ config: buildSdkConfig(coordinatorModel) })

This is straightforward to wire. The orchestrator already isolates reviewers and coordinator into separate runParallelReviewers() / runCoordinator() calls that each take a client parameter. We'd just pass a different client for the coordinator step.

Tradeoffs:

• Two opencode server processes in the runner (extra ~50-100MB memory, ~2-3s startup). Acceptable for CI runners.
• Signal/cleanup handlers need to close both servers.
• cleanupAllSessions() already works per-client, so no issue there.

Open questions for maintainer

1. Input naming — coordinator-model (your proposal) vs coordinator_model — both work with GitHub Actions. The existing codebase uses kebab-case in action.yml input names (e.g. timeout-seconds, coordinator-timeout-seconds), so coordinator-model is consistent.

2. Backward compatibility — Your proposed behavior (fall back to model when coordinator-model is unset) is the right default. No breaking change.

3. reasoning-effort and enable-thinking — These are also set in buildSdkConfig() and applied globally. Should the coordinator get its own coordinator-reasoning-effort and coordinator-enable-thinking inputs, or should those stay shared? Not blocking, but worth deciding now to avoid a second round of additions.

If this gets accepted, the implementation is well-scoped: ~4 files changed (action.yml, index.ts, reviewers.ts, README.md), ~50-80 lines of diff.