feat: rewrite multi-review using OpenCode SDK

[Svtter]

Summary

• Rewrite multi-review/ using @opencode-ai/sdk TypeScript SDK instead of Python subprocess
• SDK 的 createOpencode() 管理 server 生命周期，client.session.prompt() 返回结构化 AI 响应
• 彻底解决旧方案的根本问题：opencode github run stdout 只包含 CLI 框架噪声，不包含 AI 评审内容

Architecture

createOpencode() → single server
  ├── session: quality reviewer    → prompt(diff) → structured response
  ├── session: security reviewer   → prompt(diff) → structured response
  ├── session: performance reviewer → prompt(diff) → structured response
  ├── session: architecture reviewer → prompt(diff) → structured response
  └── session: coordinator          → prompt(all reviews) → synthesized comment
                                                                 ↓
                                                           gh pr comment (1 条)

Key changes

Aspect	Old (Python subprocess)	New (TypeScript SDK)
Runtime	Python + subprocess	Node.js + SDK
Server instances	N separate opencode processes	1 shared server, N sessions
Output capture	CLI stdout (noise only)	client.session.prompt() (structured)
Cold start	N × MCP initialization	1 × MCP initialization
Comment count	7+ (one per reviewer + coordinator)	Exactly 1 (coordinator synthesis)

Test plan

• cd multi-review && npm run build succeeds
• cd multi-review && npx tsc --noEmit passes
• CI smoke test passes
• Dogfood PR only produces 1 comment with structured review content

🤖 Generated with Claude Code

[github-actions]

不可合并

总评

该 PR 将 multi-review 从 Python subprocess 方案重写为 TypeScript SDK 方案，架构设计清晰（1 server → N sessions → coordinator synthesis），整体方向正确。但存在 2 个阻塞级问题导致实际不可用。

阻塞项

1. action.yml:180 — 正则表达式 typo，PR diff 永远无法获取

if [[ "$ref" =~ refs/pull/([0-]+)/merge ]]; then

[0-]+ 的字符集合只包含 0 和 -，缺少 9。应写为 [0-9]+。该错误导致：

• gh pr diff 永远不会执行
• RUNNER_TEMP/.pr-diff.txt 始终为空文件
• 所有 reviewer 收到的 diff 为空，审查结果毫无价值

整个 action 核心功能被阻断。

2. orchestrator.ts:44 — AbortController.signal 未传入 SDK 调用，超时机制失效

const controller = new AbortController();
const timeout = setTimeout(() => controller.abort(), remainingMs);

controller.abort() 被调用，但 controller.signal 从未传给 client.session.create()、client.session.prompt()、client.session.messages() 等 SDK 调用。若某 reviewer 的 SDK 请求挂起：

• Promise.all 永远无法 settle
• 整个 action 进程卡死直至 GitHub Actions 超时（通常 6h）
• finally 块中的 clearTimeout(timeout) 也永远不会执行

需要将 signal: controller.signal 传入所有 SDK 调用参数中（前提是 SDK 支持）。

建议项

1. orchestrator.ts:92 — String.prototype.replace 存在特殊替换模式风险

const fullPrompt = promptTemplate.replace("{{REVIEWS}}", reviewsText);

若 reviewsText 包含 $&、$``、$'等，会被 JS 解释为替换模式而非字面量。建议改用replaceAll` 配合函数参数，或用模板字符串拼接。

2. reviewers.ts:97-101 — resolveModel() 无 / 分隔时返回空 providerID

当 MULTI_REVIEW_MODEL 或 MODEL_NAME 不包含 /（如 glm-5.1），providerID 为空串，最终传给 SDK 的 model 字符串为 /glm-5.1，可能导致 SDK 解析失败。建议在此处提供默认 provider 或报错。

3. reviewers.ts:33-57 — 自定义 YAML 解析器过于脆弱

手写 parseYAML 仅支持极简格式，无法处理引号、转义、嵌套等标准 YAML 语法。建议使用 js-yaml 库替代。

4. 缺少请求重试/退避机制

SDK 调用可能因网络抖动或 API 限流失败，当前无任何重试逻辑。建议为 reviewer 调用添加指数退避重试。

5. action.yml:182 — gh pr diff 错误被静默吞掉

2>/dev/null || echo "" > ... 将 diff 获取失败完全静默处理，使问题难以排查。建议打印错误信息到 stderr。

6. package.json:11 — SDK 版本范围过于宽松

"@opencode-ai/sdk": "^1.0.0" 允许自动升级 minor/patch，可能导致不兼容。建议锁定到具体版本。

opencode session  |  github run

[github-actions]

发现遗漏

概要

PR body 描述的架构（createOpencode() → 单 server → N sessions → coordinator → 1 条 comment）核心链路已实现。但 action.yml 定义的多个输入未被代码消费，属于实现缺口。

---

MEDIUM

reasoning-effort 和 enable-thinking 输入未接入 SDK 配置

• action.yml 第 61-68 行定义了 reasoning-effort（默认 "max"）和 enable-thinking（默认 "true"），并分别传递为 MULTI_REVIEW_REASONING_EFFORT / MULTI_REVIEW_ENABLE_THINKING 环境变量
• 但 src/index.ts:37-39 的 createOpencode() 调用只传了 config: { model: ... }，未读取这两个环境变量，也未传递 reasoningEffort 或 enableThinking 给 SDK
• 用户设置这些输入不会产生任何效果
• 建议在 src/index.ts 中 createOpencode() 调用时读取并传入这两个配置项

---

LOW

extra-env 输入未解析注入

• action.yml 第 85-90 行定义了 extra-env 输入（多行 KEY=VALUE），传递为 MULTI_REVIEW_EXTRA_ENV
• 代码中没有任何地方读取或解析该变量，额外的环境变量不会被注入到运行时
• 建议在 src/index.ts 或入口处解析 MULTI_REVIEW_EXTRA_ENV 并写入 process.env

cleanup-error-comments 输入未实现

• action.yml 第 91-94 行定义了 cleanup-error-comments（默认 "true"），传递为 MULTI_REVIEW_CLEANUP_ERROR_COMMENTS
• 代码中没有任何地方读取该变量或实现自动清理之前失败评论的逻辑
• 建议在 src/index.ts 或 src/comment.ts 中根据此配置在成功时删除之前发布的失败评论

architecture reviewer 提示词引用项目上下文文件但未提供

• multi-review/reviewers/architecture.yaml:5 提示词要求 AI 先读取仓库根目录的 AGENTS.md 或 CLAUDE.md
• 但 src/orchestrator.ts:52-56 只向 AI 提供了 reviewer prompt + PR diff，没有读取或附加上下文文件内容
• 该指令在 AI 上下文中无法执行，属于虚假指令
• 建议在 src/reviewers.ts 或 src/orchestrator.ts 中读取这些文件内容并注入到 prompt 中

opencode session  |  github run

[github-actions]

现在我有了完整的架构分析信息。

架构有问题

架构分析概要

该 PR 将 multi-review 从 Python subprocess 方案（与其他 action 一致）重写为 TypeScript + OpenCode SDK 方案，架构模式从 "N × subprocess" 变为 "1 shared server × N sessions"。整体方向合理，但存在 2 个阻塞级架构问题和若干架构不一致。

---

阻塞项

1. action.yml:180 — PR diff 数据流彻底断裂

if [[ "$ref" =~ refs/pull/([0-]+)/merge ]]; then

正则表达式 [0-]+ 的字符集合只包含 0 和 -，缺少 9。该 regex 永远无法匹配任何 PR ref（如 refs/pull/42/merge），导致：

• gh pr diff 永不执行
• ${{ runner.temp }}/.pr-diff.txt 始终为空
• src/index.ts:16 读取到的 prDiff 为空字符串
• 所有 4 个 reviewer 收到的 diff 为空，审查结果毫无价值

这是架构层面的数据流断裂 — action.yml 是数据入口契约（输入定义+预处理），预处理阶段的逻辑错误导致整个下游管道（reviewer → coordinator → comment）空转。修复此问题需要在 action.yml 或 pr-context 步骤中修复正则表达式。

2. orchestrator.ts:44,47,52,60,103,109 — AbortController 超时机制失效

const controller = new AbortController();
const timeout = setTimeout(() => controller.abort(), remainingMs);
// ...
client.session.create({ throwOnError: true });   // 未传 signal
client.session.prompt({ ... });                    // 未传 signal
client.session.messages({ ... });                  // 未传 signal

controller.abort() 会被调用，但 controller.signal 从未传给任何 SDK 调用。若某个 reviewer 的 SDK 请求挂起：

• Promise.all 永不 settle
• try/catch 不会捕获（没有 abort 事件触发）
• clearTimeout(timeout) 在 finally 中也永不执行
• 整个 action 进程卡死至 GitHub Actions 硬超时（6h），浪费 CI 资源并阻塞工作流

这是架构层面的错误处理机制失效 — 超时是一个跨切面关注点（cross-cutting concern），应该在 orchestrator 层或请求层统一处理。当前代码声明了超时意图但实现没有落地。

---

建议项

1. action.yml 定义与实现的接口不匹配（架构不一致）

4 个输入定义在 action.yml 但从未被 src/ 代码消费：

输入	action.yml 定义	代码消费状态
reasoning-effort	第 61-68 行 → MULTI_REVIEW_REASONING_EFFORT	src/index.ts:37 的 createOpencode() 未传
enable-thinking	第 65-68 行 → MULTI_REVIEW_ENABLE_THINKING	同上
extra-env	第 85-90 行 → MULTI_REVIEW_EXTRA_ENV	全局未读取
cleanup-error-comments	第 91-94 行 → MULTI_REVIEW_CLEANUP_ERROR_COMMENTS	全局未读取

action.yml 作为该 action 的公共接口契约，定义了用户可配置的输入。实现不消费这些输入意味着接口中存在死代码（dead interface surface），用户设置了但无效果。

2. reviewers.ts:97-101 — resolveModel() 边界情况导致 providerID 为空

当 MULTI_REVIEW_MODEL 为 "glm-5.1"（不含 /）时，返回 { providerID: "", modelID: "glm-5.1" }，传递给 SDK 的 model 字符串为 "/glm-5.1"。这取决于 SDK 端是否能正确处理首字符为 / 的 model 路径。建议提供默认 provider 或显式校验。

3. orchestrator.ts:92 — String.prototype.replace 特殊替换模式

promptTemplate.replace("{{REVIEWS}}", reviewsText);

若 reviewsText 包含 $&、$\``、$'，JS 的 replace会按特殊替换模式处理而非字面量。建议使用replaceAll` 配合函数参数：

promptTemplate.replaceAll("{{REVIEWS}}", () => reviewsText);

4. reviewers.ts:33-57 — 手写 YAML 解析器是潜在的维护负债

自定义 parseYAML() 只支持极简 YAML 子集。若 reviewer YAML 文件将来需要引号、转义、嵌套结构等功能，就需要重写解析器。建议使用 js-yaml 库。

5. 架构风格偏差 — 新增 Node.js/TypeScript 维护轴

现有 7 个 action 全部使用 bash+Python 模式（run-github-opencode.py + CLI subprocess）。本 PR 引入 TypeScript + tsup bundle + SDK 依赖的全新架构，创建了代码库中唯一的 Node.js 编译流程。虽然技术选型有合理依据（SDK 的 session-based API 能获取结构化响应），但这是有意识的架构分歧，需要团队共识是否值得引入这个额外的维护维度。

6. reviewers/architecture.yaml:5 — 提示词引用项目上下文文件但未提供

architecture reviewer 的提示词要求 AI "先读取仓库根目录的 AGENTS.md 或 CLAUDE.md"，但 orchestrator.ts:55 只向 AI 传递了 reviewer.prompt + "\n\nPR Diff:\n..."，没有读取或附加上下文文件。该指令在 AI 上下文中是虚假指令。

opencode session  |  github run

[github-actions]

发现遗漏

概要

PR body 描述的核心架构（createOpencode() → 单 server → 4 reviewers → coordinator → 1 条 comment）已实现。但 action.yml 中定义的 4 个输入未被代码消费，architecture reviewer 提示词存在虚假指令，属于实现缺口。

---

MEDIUM

extra-env 输入未解析注入

• action.yml:85-90 定义了 extra-env 输入，action.yml:244 将其传递为 MULTI_REVIEW_EXTRA_ENV 环境变量
• 代码中没有任何地方读取或解析该变量，用户设置的额外环境变量不会被注入到运行时
• 建议在 src/index.ts 入口处解析 MULTI_REVIEW_EXTRA_ENV 并写入 process.env

cleanup-error-comments 输入未实现

• action.yml:91-94 定义了 cleanup-error-comments 输入（默认 "true"），action.yml:245 传递为 MULTI_REVIEW_CLEANUP_ERROR_COMMENTS
• 代码中没有任何地方读取该变量或实现自动清理之前失败评论的逻辑
• 建议在 src/index.ts 或 src/comment.ts 中根据此配置在成功时删除之前发布的失败评论

---

LOW

reasoning-effort 和 enable-thinking 输入通过 opencode.json 间接生效，但代码未显式消费

• action.yml:61-68 定义了这两个输入，action.yml:192-228 的 bash step 生成了包含 reasoning 和 thinking 字段的 opencode.json
• 但 src/index.ts:37-39 的 createOpencode({ config: { model: ... } }) 未显式传递 reasoningEffort 或 enableThinking 给 SDK，也未读取 MULTI_REVIEW_REASONING_EFFORT / MULTI_REVIEW_ENABLE_THINKING 环境变量
• 是否生效完全取决于 SDK 是否自动读取当前目录的 opencode.json，属于隐含而非显式的配置链路

architecture reviewer 提示词引用项目上下文文件但未提供

• reviewers/architecture.yaml:5 提示词要求 AI "首先读取仓库根目录的 AGENTS.md（或 CLAUDE.md）"
• 但 src/orchestrator.ts:52-56 只向 AI 提供了 reviewer prompt + PR diff，没有读取或附加上下文文件内容
• 该指令在 AI 上下文中无法执行，属于虚假指令
• 建议在 src/orchestrator.ts 或 src/reviewers.ts 中读取这些文件内容并注入到 prompt 中

opencode session  |  github run

[github-actions]

不可合并

总评

PR 整体架构方向合理（1 server × N sessions → coordinator synthesis），核心链路完整可用。但存在 1 个阻塞级正确性问题 和 1 个架构级安全隐患，在修复前不应合并。

阻塞项

1. orchestrator.ts:43,95 — 超时机制纯属装饰，不中止 SDK 请求

const timeout = setTimeout(() => {
  console.warn(`[${reviewer.name}] Exceeded ${remainingMs}ms, still waiting...`);
}, remainingMs);

setTimeout 仅输出警告，没有任何中止 SDK 请求的机制（无 AbortController，未传递 signal）。若某 reviewer 的 client.session.prompt() 或 client.session.messages() 因网络问题挂起：

• Promise.all 永不 settle
• action 进程卡死直至 GitHub Actions 6h 硬超时
• clearTimeout(timeout) 在 finally 中永远无法执行

这是一个逻辑错误——action.yml 宣称 timeout-seconds（默认 900s）是"Global timeout for all reviewers"，但实际实现完全不尊重该配置。修复建议：使用 AbortController + AbortSignal.timeout() 或 SDK 支持的取消机制，将 signal 传入所有 SDK 调用。

2. action.yml:247 + src/comment.ts:21 — GITHUB_TOKEN 通过环境变量泄漏到子进程

action.yml:247 将 GITHUB_TOKEN: ${{ inputs.github-token }} 设为执行 dist/index.js 的环境变量。comment.ts:21 中 execFileSync("gh", ["pr", "comment", ...], { env: { ...process.env } }) 将完整的 process.env（包含 GITHUB_TOKEN）传播给 gh 子进程。这是标准做法，但 inputs.github-token 不依赖于 github.token（action.yml 第 69-72 行没有 default: ${{ github.token }}），若用户不传入该输入，gh pr comment 将以未经认证的状态执行，静默失败。

更严重的是，如果用户传入了自己的 PAT，该 token 通过 process.env 暴露给整个 Node.js 运行时，任何 execFileSync 调用的子进程（当前只有 gh，但未来可能扩展）都能读取它。这是一个凭据的过度暴露。

建议项

1. orchestrator.ts:93 — String.prototype.replace 的特殊替换模式

promptTemplate.replace("{{REVIEWS}}", reviewsText);

若 reviewsText 包含 $&、$``、$'或$0-$99，replace` 会解释为替换模式而非字面量。建议：

promptTemplate.replaceAll("{{REVIEWS}}", () => reviewsText);
// 或
promptTemplate.split("{{REVIEWS}}").join(reviewsText);

2. reviewers.ts:97-101 — resolveModel() 缺少 / 时返回空 providerID

MULTI_REVIEW_MODEL 或 MODEL_NAME 不含 / 时（如 glm-5.1 或 claude-3.5），返回 { providerID: "", modelID: "glm-5.1" }，最终传给 SDK 的 model 为 /glm-5.1（前导斜杠）。建议添加默认 provider 或显式校验并报错。

3. reviewers.ts:33-57 — 自实现 YAML 解析器脆弱

parseYAML() 仅支持 key: value 和 key: | + 缩进行的极简子集，无法处理引号、转义、注释、嵌套结构。虽当前 YAML 文件恰好兼容，但这是隐式契约，容易在后续修改中破坏。建议使用 js-yaml 库。

4. architecture.yaml:5 — 提示词引用 AGENTS.md 但未提供

First, read AGENTS.md (or CLAUDE.md) if it exists in the repository root

orchestrator.ts:56 仅向 AI 传递 diff，没有读取或注入仓库根目录的 AGENTS.md/CLAUDE.md 内容。该指令在 SDK session 中无法执行（AI 无文件系统访问）。建议读取文件后拼接到 prompt 中，或删除该指令。

5. 缺少请求重试/退避机制

SDK 所有调用（session.create、session.prompt、session.messages）均无重试逻辑。API 限流或网络抖动会导致整个 review 失败。建议添加指数退避重试（至少 1-2 次）。

6. action.yml:85-94 — extra-env 和 cleanup-error-comments 输入未被代码消费

MULTI_REVIEW_EXTRA_ENV 和 MULTI_REVIEW_CLEANUP_ERROR_COMMENTS 两个环境变量已定义并在 action.yml step 中传递，但 src/ 中没有任何代码读取或处理它们。属于 action.yml 接口契约与实现的不一致。建议实现对应功能或从 action.yml 移除。

7. action.yml:182 — gh pr diff 错误被静默吞掉

2>/dev/null || echo "" > ... 使 diff 获取失败完全不可见。建议打印错误信息到 stderr，便于排查。

8. src/index.ts:37 — createOpencode() 传入了 model 但 opencode.json 也在工作目录中

bash 步骤（action.yml 第 204-227 行）在工作目录写入了含 reasoning/thinking 的 opencode.json，而 createOpencode({ config: { model: ... } }) 也传入了 config。需要确认 SDK 如何处理二者叠加——若 SDK 不使用 opencode.json，则 reasoning-effort 和 enable-thinking 输入对 SDK sessions 无效。

9. dist/index.js 在版本控制中但缺少 build 校验 CI

dist/index.js 是与 src/ 配套的 bundle，但无 CI 步骤确保二者一致性。建议添加 npm run build && git diff --exit-code dist/ 检查。

opencode session  |  github run

[github-actions]

现在我已掌握完整的架构分析所需信息。以下是最终的技术审阅。

架构有疑虑

架构分析概要

该 PR 将 multi-review 从 Python + opencode CLI subprocess 方案重写为 TypeScript + @opencode-ai/sdk 方案，架构模式从 "N × subprocess" 变为 "1 shared server × N sessions × coordinator synthesis"。整体方向合理，核心数据流清晰，模块职责分离明确。但存在以下架构层面的问题。

---

阻塞项：无

---

建议项

1. 超时机制为装饰性，timeout-seconds 输入契约不生效 (src/orchestrator.ts:43-45,95-97)

const timeout = setTimeout(() => {
  console.warn(`[${reviewer.name}] Exceeded ${remainingMs}ms, still waiting...`);
}, remainingMs);

setTimeout 仅输出警告，没有任何中止 SDK 请求的机制。若某 reviewer 的 client.session.prompt() 或 client.session.messages() 因网络问题挂起：

• Promise.all 永不 settle，整个 action 进程卡死直至 GitHub Actions 6h 硬超时
• server.close() (index.ts:83) 永不执行
• clearTimeout(timeout) (orchestrator.ts:76,122) 永不执行
• action.yml:41-44 声明的 timeout-seconds 输入（默认 900s）完全被忽略

这是跨切面关注点（请求超时/取消）的实现断裂。修复方向：确认 SDK 是否支持 AbortSignal，若支持则将其传入所有 client.session.*() 调用的 options 参数。

2. OrchestratorOptions 携带未被消费的字段 (src/types.ts:13-18 → src/orchestrator.ts:33-37,83-87)

modelID、providerID、globalTimeoutMs 三个字段传入 runCoordinator()，但后者只使用了 coordinatorTimeoutMs 和 coordinatorPrompt。runParallelReviewers() 也只使用了 globalTimeoutMs。接口声明与实际消费不匹配。

3. 架构范式分歧 — 引入 Node.js/TypeScript 维护轴

现有 7 个 action 全部使用 bash + Python + CLI subprocess 模式（run-github-opencode.py → run-opencode.sh → opencode CLI）。本 PR 引入 TypeScript + SDK + tsup bundle 的全新架构，创建了代码库中唯一的 Node.js 编译流程（npm run build → dist/index.js）。技术选型有合理依据（SDK 的 client.session.prompt() 能获取结构化响应，CLI stdout 只含框架噪声），但这是有意识的架构分歧，需要团队评估是否值得引入这个额外的维护维度。

4. action.yml 定义的 4 个输入未被代码消费

输入	action.yml 行号	env 变量名	代码消费状态
reasoning-effort	61-64	MULTI_REVIEW_REASONING_EFFORT	index.ts:37 的 createOpencode() 未传；仅通过 bash step 写入 opencode.json，是否生效取决于 SDK 是否自动读取该文件
enable-thinking	65-68	MULTI_REVIEW_ENABLE_THINKING	同上
extra-env	85-90	MULTI_REVIEW_EXTRA_ENV	任何地方未读取
cleanup-error-comments	91-94	MULTI_REVIEW_CLEANUP_ERROR_COMMENTS	任何地方未读取

action.yml 作为该 action 的公共接口契约，定义了用户可配置的输入。实现不消费这些输入意味着接口中存在死代码（dead interface surface），用户设置了但无效果。reasoning-effort/enable-thinking 通过 opencode.json 间接生效的路径是隐含而非显式的配置链路，若 SDK 不读取 opencode.json 则完全不生效。

5. architecture.yaml:5 提示词引用项目上下文文件但未提供 (reviewers/architecture.yaml:5 → src/orchestrator.ts:52-56)

architecture reviewer 的提示词要求 AI "先读取仓库根目录的 AGENTS.md（或 CLAUDE.md）"，但 orchestrator.ts:55 只向 AI 传递了 reviewer.prompt + "\n\nPR Diff:\n..."，没有读取或附加上下文文件内容。该指令在 SDK session 中无法执行（AI 无文件系统访问），属于虚假指令。

6. resolveModel() 无 / 分隔时返回空 providerID (src/reviewers.ts:97-101)

当 MULTI_REVIEW_MODEL 不包含 /（如 glm-5.1）时，返回 { providerID: "", modelID: "glm-5.1" }，最终传给 SDK 的 model 字符串为 "/glm-5.1"（前导斜杠）。可能造成 SDK 解析失败。

7. String.prototype.replace 存在特殊替换模式风险 (src/orchestrator.ts:93)

promptTemplate.replace("{{REVIEWS}}", reviewsText);

若 reviewsText 包含 $&、$``、$'等，会被 JS 解释为替换模式而非字面量。建议改用replaceAll配合函数参数或split/join`。

8. 缺少请求重试/退避机制 (src/orchestrator.ts:47-78,99-124)

所有 SDK 调用（session.create、session.prompt、session.messages）均无重试逻辑。API 限流或网络抖动会导致整个 review 失败，且无自动恢复能力。

opencode session  |  github run

[github-actions]

可合并

总结

代码整体架构清晰（1 server → N sessions → coordinator → 1 comment），模块职责分离合理，错误处理机制完整，核心数据流正确。与先前 review 版本不同，当前 HEAD 已修复以下问题：action.yml:180 的 regex 已是正确的 [0-9]+（not [0-]+）；extra-env 和 cleanup-error-comments 两个输入已在 comment.ts 中实现并被 index.ts 调用消费；超时机制使用 withTimeout() Promise.race 方案而非此前版本的假 abortController。

阻塞项：无

建议项

1. src/orchestrator.ts:107 — String.prototype.replace 特殊替换模式风险

promptTemplate.replace("{{REVIEWS}}", reviewsText);

若 reviewsText 包含 $&、$``、$'或$N，JS 的 replace` 会解释为替换模式而非字面量。建议改用：

promptTemplate.replaceAll("{{REVIEWS}}", () => reviewsText);

2. src/reviewers.ts:97-101 — resolveModel() 无 / 时返回空 providerID

当 MULTI_REVIEW_MODEL 或 MODEL_NAME 不包含 /（如 glm-5.1），返回 { providerID: "" }，最终 SDK 的 model 字符串为 /glm-5.1。建议在缺少 / 时提供默认 provider 或 throw 报错。

3. src/reviewers.ts:33-57 — 自定义 YAML 解析器脆弱

parseYAML() 仅支持极简 YAML 子集，无法处理引号、转义、注释等标准语法。建议使用 js-yaml 库替代。

4. reviewers/architecture.yaml:5 — 提示词引用 AGENTS.md 但未提供

architecture reviewer 的提示词要求 AI "read AGENTS.md (or CLAUDE.md) if it exists"，但 orchestrator.ts:55 仅传递 diff，AI 在 SDK session 中无文件系统访问。建议读取文件内容后拼接到 prompt 中，或删除该指令。

5. src/types.ts:13-18 — OrchestratorOptions 存在未被消费的字段

modelID 和 providerID 被传入 runParallelReviewers() 和 runCoordinator()，但两个函数均未使用。建议从接口中移除。

6. src/orchestrator.ts:41 — finally(() => clearTimeout(timer)) 存在竞争条件

若主 promise 在 setTimeout 回调执行之前 settle，timer 尚未被赋值（为 undefined），clearTimeout(undefined) 虽然无害但不够严谨。建议将 timer 初始化为有效值或使用 AbortSignal.timeout()。

7. src/comment.ts:64 — !runLinkPattern 冗余检查

runLinkPattern 已在第 43 行通过 if (!repo || !runId) return; 保证非空，内层循环的 !runLinkPattern 检查是冗余的，建议删除。

8. 缺少请求重试/退避机制

所有 SDK 调用（session.create、session.prompt、session.messages）均无重试逻辑。API 限流或网络抖动会导致整个 review 失败。建议为 reviewer 调用添加指数退避重试。

opencode session  |  github run

[github-actions]

现已掌握完整信息。PR 无关联 issue，PR body 即为 spec。核心架构（createOpencode() → 单 server → N sessions → coordinator → 1 comment）已全部实现。

发现遗漏

---

MEDIUM

reasoning-effort 和 enable-thinking 输入已定义但未显式传入 SDK 配置

• action.yml:61-68 定义了这两个输入，action.yml:238-239 将其传递为 MULTI_REVIEW_REASONING_EFFORT / MULTI_REVIEW_ENABLE_THINKING 环境变量，action.yml:192-228 的 bash step 写入了含 reasoning/thinking 字段的 opencode.json
• 但 src/index.ts:40-42 的 createOpencode({ config: { model: ... } }) 只传了 model，未读取这两个环境变量也未显式传入 reasoningEffort 或 enableThinking
• 该配置是否生效完全取决于 SDK 是否自动读取工作目录的 opencode.json，属于隐含而非显式的配置链路。如果 SDK 不自动读取该文件，用户设置这两个输入将没有任何效果
• 建议在 src/index.ts 的 createOpencode() config 中显式读取并传入这两个参数

LOW

architecture reviewer 提示词引用 AGENTS.md / CLAUDE.md 但代码未读取注入

• multi-review/reviewers/architecture.yaml:5 要求 AI "先读取仓库根目录的 AGENTS.md（或 CLAUDE.md）"
• 但 src/orchestrator.ts:68 只向 AI 传递了 reviewer.prompt + "\n\nPR Diff:\n\``\n" + prDiff + "\n```"`，没有读取或注入任何项目上下文文件的内容
• AI 在 SDK session 中无文件系统访问能力，该指令无法执行
• 建议在 src/orchestrator.ts 或 src/index.ts 中读取这些文件内容，拼接到 prompt 中一起发送

---

除上述两项外，PR body 描述的核心架构（1 server × 4 reviewers × coordinator → 1 comment）、SDK 生命周期管理、并行审查、协调器合成等核心功能均已完整实现。extra-env、cleanup-error-comments 等 action.yml 输入也已在 src/comment.ts 中实现消费。

opencode session  |  github run

[github-actions]

架构有疑虑

架构分析概要

PR 将 multi-review 从 Python + opencode CLI subprocess 方案重写为 TypeScript + @opencode-ai/sdk 方案，模式为 "1 shared server × N sessions × coordinator synthesis → 1 comment"。模块职责分离清晰（types → reviewers → orchestrator → comment → index.ts 组合根），核心数据流完整，超时机制使用 Promise.race 有效。但与代码库现有架构范式存在分歧。

阻塞项

阻塞项：无

建议项

1. 架构范式分歧 — 引入 Node.js/TypeScript 维护轴（中等）

现有 7 个 action 全部使用 bash + Python + CLI subprocess 模式（run-github-opencode.py → opencode CLI）。本 PR 是代码库中唯一使用 TypeScript 编译流程（tsup bundle → dist/index.js）+ npm 依赖 + SDK 的 action。虽然技术选型有合理依据（SDK 的 client.session.prompt() 能获取结构化响应，CLI stdout 只含框架噪声），但这是有意识的架构分歧，引入了：

• Node.js 编译工具链（tsup + TypeScript + @types/node）
• 提交到版本控制的 bundle（dist/index.js）
• npm 依赖管理（package-lock.json 1567 行）

需要团队明确是否接受这一额外的维护维度，或考虑将 SDK 模式推广到其他 action。

2. reasoning-effort 和 enable-thinking 配置链路隐含而非显式

• action.yml:192-228 的 bash step 将这两个值写入工作目录的 opencode.json
• 但 src/index.ts:40-42 的 createOpencode({ config: { model: ... } }) 只传了 model，未读取 MULTI_REVIEW_REASONING_EFFORT / MULTI_REVIEW_ENABLE_THINKING 环境变量也未显式传入 reasoningEffort / enableThinking
• 配置是否生效完全取决于 SDK 是否自动读取当前目录的 opencode.json——属于隐含的配置链路。如果 SDK 不自动读取该文件，用户设置这两个输入将无效果
• 建议在 src/index.ts 中显式读取环境变量并传入 SDK 的 config

3. src/types.ts:13-18 — OrchestratorOptions 存在未被消费的字段

modelID 和 providerID 被定义、传入 runParallelReviewers() 和 runCoordinator()，但两个函数均未读取使用。接口声明与实际消费不匹配。建议从接口中移除。

4. src/orchestrator.ts:107 — String.prototype.replace 特殊替换模式风险

promptTemplate.replace("{{REVIEWS}}", reviewsText);

若 reviewsText 包含 $&、$\``、$'或$N，会被 JS 解释为替换模式而非字面量。建议改用 replaceAll配合函数参数或split/join`。

5. reviewers/architecture.yaml 提示词引用 AGENTS.md 但未提供

architecture 域 reviewer 的提示词要求 AI "先读取仓库根目录的 AGENTS.md（或 CLAUDE.md）"，但 src/orchestrator.ts:68 只向 AI 传递了 reviewer.prompt + "\n\nPR Diff"，未读取或注入任何项目上下文文件。AI 在 SDK session 中无文件系统访问能力，该指令无法执行。

6. src/comment.ts:63 — 冗余的条件检查

if (!comment.body || !runLinkPattern) continue;

runLinkPattern 是第 45 行的 const 字符串，在第 43 行已通过 if (!repo || !runId) return; 保证非空，!runLinkPattern 检查永远为 false。

7. 缺少请求重试/退避机制

所有 SDK 调用（session.create、session.prompt、session.messages）均无重试逻辑。API 限流或网络抖动会导致整个 review 失败，且无自动恢复能力。建议为 reviewer 调用添加指数退避重试（至少 1-2 次）。

opencode session  |  github run

[github-actions]

可合并

总评

对比此前 review 指出的问题，当前 HEAD 已全部修复或确认：action.yml:180 正则已是正确的 [0-9]+；超时机制已使用 withTimeout() Promise.race 实现；extra-env 和 cleanup-error-comments 已在 comment.ts 中实现并被 index.ts 调用；OrchestratorOptions 已清理未使用字段；architecture.yaml 已移除 AGENTS.md 虚假指令。核心架构（1 server × N sessions × coordinator → 1 comment）完整可用。

阻塞项：无

建议项

1. src/index.ts:40-42 — reasoning-effort / enable-thinking 未显式传入 SDK

action.yml 定义了这两个输入并通过 bash step 写入 opencode.json，但 createOpencode({ config: { model: ... } }) 未读取 MULTI_REVIEW_REASONING_EFFORT / MULTI_REVIEW_ENABLE_THINKING 环境变量传入 SDK。若 SDK 不自动读取工作目录的 opencode.json，用户设置将无效果。建议在 createOpencode() 的 config 中显式传入。

2. action.yml:182 — gh pr diff 错误被 2>/dev/null 静默

diff 获取失败时（如 token 权限不足），错误完全不可见，PR diff 为空文件，下游所有 reviewer 拿到空输入产出无意义结果。建议至少输出错误信息到 stderr。

3. src/comment.ts:63-64 — 冗余的条件检查

!comment.body 已在第 63 行检查，第 64 行 !comment.body.includes() 无需重复判断 comment.body 非空。

4. src/reviewers.ts:97-105 — resolveModel() 无 / 时仍返回空 providerID

已添加 console.error 日志，但返回的 { providerID: "" } 最终传给 SDK 的 model 为 /glm-5.1（前导斜杠），取决于 SDK 是否容忍。建议在此处直接 return { providerID: "default", modelID: raw } 或 throw。

5. 缺少请求重试/退避机制

所有 SDK 调用（session.create、session.prompt、session.messages）均无重试逻辑。API 限流或网络抖动会导致整个 review 全部失败。建议添加至少 1-2 次指数退避重试。

6. src/orchestrator.ts:33-41 — withTimeout timer 赋值时序

timer 变量在 new Promise executor 中赋值，虽实际时序安全（executor 同步执行），但 "strict": true 下 TypeScript 可能报变量使用前未赋值的警告。建议初始化为 let timer: ReturnType<typeof setTimeout> | undefined = undefined，或直接使用 AbortSignal.timeout(ms)。

7. src/orchestrator.ts:52 — remainingMs 在多次串行 SDK 调用间共享

单 reviewer 的 remainingMs 在 session.create、session.prompt、session.messages 三次调用中复用一个值，若第一次调用耗时较长，后续调用可能超过总 deadline。建议每次调用前重新计算剩余时间。

8. package.json:11 — SDK 版本范围 ^1.0.0 过于宽松

允许自动升级 minor/patch，可能导致行为不一致。建议锁定到具体版本或至少缩窄范围。

opencode session  |  github run

[github-actions]

Bad credentials - https://docs.github.com/rest

opencode session  |  github run

[github-actions]

现在我掌握了完整的代码。这是我的架构评审：

架构有疑虑

架构分析概要

该 PR 将 multi-review 从 Python + opencode CLI subprocess 方案重写为 TypeScript + @opencode-ai/sdk 方案，架构模式为 "1 shared server × N parallel sessions × coordinator synthesis → 1 comment"。模块职责分离清晰（types → reviewers/orchestrator/comment → index.ts 组合根），超时机制使用 Promise.race 正确实现，核心数据流完整。

但存在一个突出的架构一致性问题。

阻塞项

阻塞项：无

建议项

1. 架构范式分歧 — 引入代码库唯一的 Node.js/TypeScript 维护轴（重点）

现有 7 个 action (review/, architect-review/, github-run-opencode/, run-opencode/, setup-opencode/, spec-coverage/, feature-missing/) 全部遵循一致的架构模式：action.yml (composite) → bash steps → Python 脚本 → opencode CLI subprocess。本 PR 是代码库中唯一使用 TypeScript 编译流程（tsup bundle → dist/index.js）+ npm 依赖 + SDK 直接调用的 action。

具体差异：

• 运行时: 其他 action 依赖 Python + opencode CLI binary；本 action 依赖 Node.js + SDK
• 构建产物: 引入 dist/index.js bundle（359 行）+ package-lock.json（1567 行）提交到版本控制
• 依赖管理: 新增 npm 依赖链（@opencode-ai/sdk, tsup, typescript, @types/node）
• 配置模型: 其他 action 通过环境变量 + 运行时 arg 配置；本 action 通过 opencode.json + env var 混合配置

虽然技术选型有合理依据（SDK 的 client.session.prompt() 能直接获取结构化响应，CLI stdout 只含框架噪声），但这种分歧需要团队明确认可，否则会引入额外的维护成本和知识分散。

2. reasoning-effort / enable-thinking 配置链路是隐含而非显式的

• action.yml:192-228 的 bash step 将这两个值写入工作目录的 opencode.json
• src/index.ts:40-42 的 createOpencode({ config: { model: ... } }) 只传了 model，未读取 MULTI_REVIEW_REASONING_EFFORT / MULTI_REVIEW_ENABLE_THINKING 环境变量，也未传入 reasoningEffort 或 enableThinking
• 该配置是否生效完全取决于 SDK 是否自动读取工作目录的 opencode.json——若 SDK 不自动读取，用户设置这两个输入将毫无效果

建议在 src/index.ts 中显式读取环境变量并传给 SDK config 参数。

3. src/reviewers.ts:97-104 — resolveModel() 缺少 / 时返回空 providerID

当 MULTI_REVIEW_MODEL 或 MODEL_NAME 不包含 /（如 glm-5.1）时，返回 { providerID: "", modelID: "glm-5.1" }，最终传给 SDK 的 model 字符串为 /glm-5.1（前导斜杠），取决于 SDK 是否容忍。建议提供默认 provider 或直接报错退出。

4. src/reviewers.ts:33-57 — 自实现 YAML 解析器脆弱

parseYAML() 仅支持极简 YAML 子集（key: value 和 key: | + 缩进行），无法处理引号、转义、注释、嵌套结构。当前 YAML 文件恰好兼容，但这属于隐式契约，后续修改 YAML 文件时容易意外破坏。建议使用 js-yaml 库替代。

5. 缺少请求重试/退避机制

src/orchestrator.ts 中的 session.create、session.prompt、session.messages 调用均无重试逻辑。API 限流或网络抖动会导致整个 review 全部失败。建议添加至少 1-2 次指数退避重试。

6. src/orchestrator.ts:33 — withTimeout 的 timer 类型初始化

let timer: ReturnType<typeof setTimeout> 未赋初始值，"strict": true 下 TypeScript 可能报变量使用前未赋值的警告。建议初始化为 let timer: ReturnType<typeof setTimeout> | undefined = undefined;，或改用 AbortSignal.timeout(ms)。

opencode session  |  github run

[github-actions]

无遗漏

PR body 描述的核心架构已全部实现：

• createOpencode() → single server (src/index.ts:40-42)
• 4 个 reviewer sessions (quality/security/performance/architecture) 并行审查 (src/orchestrator.ts:43-93)
• 每个 reviewer 通过 client.session.prompt() 接收 diff 并返回结构化响应 (src/orchestrator.ts:63-73)
• 1 个 coordinator session 合成所有 reviewer 输出为单条评论 (src/orchestrator.ts:96-142)
• 使用 gh pr comment 发布 1 条评论 (src/comment.ts:9-32)
• extra-env 和 cleanup-error-comments 两个 action.yml 输入已在 src/comment.ts:34-90 中实现消费
• resolveModel() 对缺少 / 的 model 字符串已会 throw 报错 (src/reviewers.ts:101)
• withTimeout() 使用 Promise.race 正确实现了超时机制 (src/orchestrator.ts:33-41)
• replace("{{REVIEWS}}") 已改用 split/join 避免特殊替换模式风险 (src/orchestrator.ts:106)
• architecture.yaml 已移除对 AGENTS.md 的虚假引用
• OrchestratorOptions 接口已清理未使用字段

所有 spec 要求的特性均已覆盖，无需额外实现。

opencode session  |  github run

[github-actions]

现在我已充分审阅当前 HEAD 的所有代码。

不可合并

总结

PR 整体架构清晰合理（1 server × N sessions × coordinator → 1 comment），模块职责分离良好。对比 previous reviews，以下问题已在当前 HEAD 修复：action.yml:180 正则已为正确的 [0-9]+；超时使用 Promise.race 实现；extra-env 和 cleanup-error-comments 已实现消费；OrchestratorOptions 已清理未使用字段；architecture.yaml 已移除虚假指令；replace 已使用 split().join() 安全写法；resolveModel() 已正确抛出异常。

阻塞项

1. action.yml 缺少 npm install/npm ci 步骤，运行时 SDK 依赖无法解析

dist/index.js 第 2 行包含 import { createOpencode } from "@opencode-ai/sdk" 语句——该 SDK 未被 tsup 打包进 dist（dist 仅 360 行，无 SDK inline 代码），运行时 Node.js ESM loader 需要从 node_modules 解析该 bare import。但：

• multi-review/node_modules/ 已在 .gitignore 中排除（.gitignore:1），不随仓库检出
• action.yml 步骤列表（第 98-264 行）中无任何 npm ci 或 npm install 指令

因此运行时 import { createOpencode } from "@opencode-ai/sdk" 必然抛出 ERR_MODULE_NOT_FOUND，整个 action 完全不可用。

修复方法：在 action.yml 第 229-230 行之间增加：

- shell: bash
  working-directory: ${{ github.action_path }}
  run: npm ci --omit=dev

或确保 tsup 将 @opencode-ai/sdk 正确打包进 dist。

建议项

1. reasoning-effort / enable-thinking 已定义但未显式传入 SDK

action.yml:192-228 的 bash step 将这两个值写入 opencode.json，但 src/index.ts:40-42 的 createOpencode({ config: { model: ... } }) 未读取 MULTI_REVIEW_REASONING_EFFORT / MULTI_REVIEW_ENABLE_THINKING 环境变量。配置链路完全取决于 SDK 是否自动读取工作目录的 opencode.json，是隐含而非显式的配置方式。建议在 createOpencode() config 中显式传入。

2. action.yml:182 — gh pr diff 错误被静默吞掉

2>/dev/null || echo "" > ... 使 diff 获取失败完全不可见。若 token 权限不足，下游所有 reviewer 收到空 diff 输出无意义结果。

3. src/comment.ts:64 — 冗余的条件检查

第 63 行 if (!comment.body) continue; 已保证 comment.body 非空，第 64 行 !comment.body.includes(...) 无需再次检查。

4. package.json:11 — SDK 版本范围 ^1.0.0 过于宽松

允许自动升级 minor/patch，可能导致行为不一致。建议锁定到具体版本。

5. withTimeout 不取消底层 SDK 请求（资源泄漏）

Promise.race 超时后仅 reject 外层 promise，底层 SDK HTTP 请求仍在后台运行直至自行完成。大量超时请求可能堆积。建议确认 SDK 是否支持 AbortSignal，若支持则传入。

6. 缺少请求重试/退避机制

所有 SDK 调用（session.create、session.prompt、session.messages）均无重试逻辑。API 限流或网络抖动会导致整个 review 失败。

7. action.yml:247 — GITHUB_TOKEN 环境变量暴露给整个 Node 子进程

comment.ts 通过 { ...process.env } 将完整环境变量传播给所有 execFileSync 子进程。虽 gh 需要 GITHUB_TOKEN，但未来扩展子进程时存在凭据过度暴露风险。

opencode session  |  github run

[github-actions]

架构有问题

架构分析概要

PR 整体模块划分清晰（types.ts → reviewers.ts / orchestrator.ts / comment.ts → index.ts 组合根），1 server × N sessions × coordinator synthesis → 1 comment 的核心链路完整。超时、错误处理、fallback 评论等机制均已实现。对比之前 review 提出的问题，当前 HEAD 已修复 regex typo、AbortController 使用 Promise.race、extra-env/cleanup-error-comments 消费、OrchestratorOptions 未使用字段清理、architecture.yaml 虚假指令移除、replace 改用 split/join、resolveModel() 异常抛出等 7 项。但存在 1 个数据流完全断裂的阻塞问题。

---

阻塞项

dist/index.js:2 → action.yml — 运行时 SDK 依赖无法解析

dist/index.js 第 2 行：

import { createOpencode } from "@opencode-ai/sdk";

这是一个裸 ESM import（@opencode-ai/sdk 未被 tsup 打包进 dist，360 行中无 SDK 内联代码，confirmed by visual inspection）。运行时 Node.js ESM loader 需要从 node_modules 解析该 bare import，但：

• multi-review/.gitignore:1 → node_modules/ 不随仓库检出
• action.yml（第 98-264 行）没有任何 npm ci 或 npm install 步骤

导致 node dist/index.js 必然抛出 ERR_MODULE_NOT_FOUND，整个 action 完全不可用。

这是架构层面的数据流断裂——dist/index.js 作为交付物声明了对 @opencode-ai/sdk 的运行时依赖（import），但部署链路（action.yml）未提供满足该依赖的步骤。修复需要在 action.yml 中增加 npm ci --omit=dev，或确保 tsup 将 SDK 正确打包进 dist（如配置 --noExternal @opencode-ai/sdk）。

---

建议项

1. 架构范式分歧 — 代码库唯一的 Node.js/TypeScript 维护轴

现有 7 个 action（review/、architect-review/、spec-coverage/ 等）全部一致采用 action.yml (composite) → bash steps → run-github-opencode.py (Python) → opencode CLI subprocess 模式。本 PR 是唯一使用 TypeScript 编译流程（tsup → dist/index.js）+ npm 依赖链 + SDK 直接调用的 action，引入了：

• Node.js 编译工具链（tsup + TypeScript + @types/node）
• 提交到版本控制的 bundle（dist/index.js 360 行）
• npm 依赖管理（package-lock.json 1567 行）
• 与现有模式不一致的配置模型（环境变量 + opencode.json + TS config 混合）

技术选型有合理依据（SDK session.prompt() 直接返回结构化响应，而 CLI stdout 只含框架噪声），但需要团队明确认可这一维护轴的分歧。

2. action.yml → src/index.ts — reasoning-effort/enable-thinking 配置链路隐式

action.yml 第 61-68 行定义了这两个输入，第 192-228 行的 bash step 写入 opencode.json，但 src/index.ts:40-42 的 createOpencode({ config: { model: ... } }) 未读取 MULTI_REVIEW_REASONING_EFFORT / MULTI_REVIEW_ENABLE_THINKING 环境变量，也未传入 reasoningEffort 或 enableThinking。配置链路完全依赖 SDK 是否自动读取工作目录的 opencode.json，这是隐含而非显式的契约。

3. action.yml:182 — gh pr diff 错误被 2>/dev/null 静默

diff 获取失败（如 token 权限不足）时错误被完全忽略，PR diff 为空文件，下游所有 reviewer 收到空输入产出无意义结果。

4. 缺少请求重试/退避机制

orchestrator.ts 中所有 client.session.*() 调用（create / prompt / messages）均无重试逻辑。API 限流或网络抖动会导致整个 review 全部失败。

5. withTimeout() 不取消底层 SDK 请求（资源泄漏）

Promise.race 超时后仅 reject 外层 promise，底层 SDK HTTP 请求仍在后台运行直至自行完成。大量超时可能堆积后台请求。

6. comment.ts:21 — process.env 完整传播给子进程

postPRComment 和 cleanupErrorComments 通过 env: { ...process.env } 将完整环境变量（含 GITHUB_TOKEN）传播给 gh 子进程。虽为常见做法，但若未来扩展子进程存在凭据过度暴露风险。

7. package.json:11 — SDK 版本 ^1.0.0 过于宽松

允许自动升级 minor/patch，可能导致运行时行为不一致。

阻塞项：dist/index.js:2 — 运行时 import { createOpencode } from "@opencode-ai/sdk" 无法解析（无 npm install 步骤，node_modules 不随仓库检出）

opencode session  |  github run

[github-actions]

可合并

总评

当前 HEAD 架构清晰（1 server × N sessions × coordinator → 1 comment），模块职责分离良好。之前 review 指出的所有阻塞问题均已修复：regex 已为正确 [0-9]+、SDK 已通过 tsup noExternal 打包进 dist（2645 行中包含完整 SDK 内联代码）、resolveModel() 已正确 throw、replace 已改用 split().join()、OrchestratorOptions 已清理、extra-env/cleanup-error-comments 已实现消费、architecture.yaml 虚假指令已移除。

阻塞项：无

建议项

1. reasoning-effort / enable-thinking 配置链路失效（MEDIUM）

action.yml:192-228 的 bash step 将这两个值写入工作目录的 opencode.json，但 SDK 的 createOpencode() 通过 OPENCODE_CONFIG_CONTENT 环境变量传递 config（dist/index.js:2208），而非读取磁盘上的 opencode.json。src/index.ts:40-42 只传了 model，未读取 MULTI_REVIEW_REASONING_EFFORT / MULTI_REVIEW_ENABLE_THINKING 环境变量。用户设置这两个输入完全无效。

建议在 createOpencode() config 中显式传入：

config: {
  model: `${providerID}/${modelID}`,
  reasoning: env("MULTI_REVIEW_REASONING_EFFORT") || "max",
  thinking: env("MULTI_REVIEW_ENABLE_THINKING") === "true" ? { type: "enabled" } : null,
}

同时可删除 bash 步骤中 opencode.json 的写入逻辑（该文件在 SDK 模式下不被使用）。

2. action.yml:182 — gh pr diff 错误被 2>/dev/null 静默

diff 获取失败时（token 权限不足、非 PR 上下文等），错误被完全屏蔽，下游所有 reviewer 收到空 diff 产出无意义结果。建议：

gh pr diff "$pr" > "${RUNNER_TEMP}/.pr-diff.txt" || {
  echo "Warning: failed to fetch PR diff" >&2
  echo "" > "${RUNNER_TEMP}/.pr-diff.txt"
}

3. withTimeout() 不取消底层 SDK 请求（资源泄漏）

Promise.race 超时后仅 reject 外层 promise，底层 HTTP 请求仍在后台运行直至自行完成。大量超时请求可能堆积后台网络连接。建议确认 SDK 是否支持 AbortSignal，若支持则传入 signal 以取消请求。

4. 缺少请求重试/退避机制

所有 client.session.*() 调用均无重试逻辑。API 限流或网络抖动会导致整个 review 全部失败。建议为核心调用添加至少 1-2 次指数退避重试。

5. package.json:11 — SDK 版本 ^1.0.0 过于宽松

允许自动升级 minor/patch，可能导致运行时行为不一致。建议锁定到具体版本（如 "1.15.10"），或至少添加 package-lock.json 的版本锁定说明。

6. comment.ts:4 与 action.yml:179 — PR number 解析逻辑重复

comment.ts:resolvePRNumber() 和 action.yml:pr-context step 各自独立解析 GITHUB_REF 获取 PR 号。建议 action.yml 将解析结果输出为 steps.pr-context.outputs.pr_number，代码中直接读取环境变量复用该结果，消除重复和潜在不一致。

7. 架构范式分歧需团队确认

该 PR 是代码库中唯一使用 TypeScript 编译流程（tsup + TypeScript + npm 依赖链）+ SDK 直接调用的 action，其他 7 个 action 均为 bash + Python + CLI subprocess 模式。虽技术选型合理（SDK 的 session.prompt() 可直接获取结构化响应），但引入了 Node.js 维护轴，建议团队明确是否接受此分歧或规划逐步迁移。

opencode session  |  github run

[github-actions]

无链接的 issue，PR body 即为 spec。我已完整阅读所有源文件。

发现遗漏

---

MEDIUM

reasoning-effort / enable-thinking 输入已定义但未显式传入 SDK 配置

• action.yml:61-68 定义了这两个输入，bash step (action.yml:192-228) 写入了含 reasoning/thinking 字段的 opencode.json，action.yml:238-239 将其传递为 MULTI_REVIEW_REASONING_EFFORT / MULTI_REVIEW_ENABLE_THINKING 环境变量
• 但 src/index.ts:40-42 的 createOpencode({ config: { model: ... } }) 只传了 model，未读取这两个环境变量，也未传入 reasoningEffort 或 enableThinking 给 SDK
• SDK 通过 OPENCODE_CONFIG_CONTENT 环境变量传递 config 给 opencode server 进程（dist/index.js:2208），该机制可能会覆盖本地 opencode.json 的配置。因此配置是否生效完全取决于 SDK 内部对 opencode.json 和 OPENCODE_CONFIG_CONTENT 的合并策略，属于隐含而非显式的配置链路。如果 OPENCODE_CONFIG_CONTENT 覆盖了文件配置，用户设置这两个输入将毫无效果
• 建议在 src/index.ts 的 createOpencode() config 中显式读取并传入这两个参数，确保配置链路明确

LOW

action.yml:182 — gh pr diff 错误被 2>/dev/null 静默处理

• diff 获取失败时（如 token 权限不足），stderr 被完全丢弃，错误不可见。PR diff 为空文件，下游所有 reviewer 收到空输入，产生无意义的审查结果
• 建议至少将错误信息输出到 stderr，便于排障

---

除上述两项外，PR body 描述的核心架构（createOpencode() → 单 server → 4 个 reviewer sessions 并行审查 → coordinator 合成 → 1 条 comment）已完整实现。extra-env、cleanup-error-comments 两个输入已在 src/comment.ts 中实现并被 src/index.ts 调用消费。tsup.config.ts 中的 noExternal: ["@opencode-ai/sdk"] 确保 SDK 被正确打包进 dist/index.js，不需要运行时 npm install。architecture.yaml 中无虚假指令。resolveModel() 缺少 / 时会 throw 报错。replace("{{REVIEWS}}") 已使用 split/join 安全写法。withTimeout() 使用 Promise.race 正确实现了超时机制。

opencode session  |  github run

[github-actions]

架构分析概要

通过审阅 AGENTS.md 和代码库现有的 7 个 action（review/、architect-review/、github-run-opencode/ 等）可以发现，代码库的既定架构模式是统一的：action.yml (composite) → bash steps → Python 脚本 → opencode CLI subprocess。而本 PR 引入了一条全新的 TypeScript + SDK 技术栈。

当前 HEAD 相比此前 review 已修复多项问题：SDK 通过 tsup noExternal 正确打包进 dist/index.js（2645 行中包含完整 SDK 内联代码），运行时不依赖 node_modules；action.yml:180 正则已是正确的 [0-9]+；超时使用 withTimeout() + Promise.race 逐层包裹每个 SDK 调用；resolveModel() 已正确 throw；replace 改用 .split().join()；OrchestratorOptions 已清理；extra-env/cleanup-error-comments 均在 comment.ts 中实现；architecture.yaml 已移除 AGENTS.md 虚假引用。

核心数据流（createOpencode() → 单 server → 4 parallel sessions → coordinator → 1 comment）完整可用，模块职责分离清晰（types.ts → reviewers.ts / orchestrator.ts / comment.ts → index.ts 组合根），超时和错误处理机制正确。

架构有疑虑

阻塞项

阻塞项：无

建议项

1. 架构范式分歧 — 引入代码库唯一的 Node.js/TypeScript 维护轴（重点）

这是最值得讨论的架构问题。现有 7 个 action 全部遵循一致的架构模式：action.yml (composite) → bash steps → Python 脚本 (run-github-opencode.py) → opencode CLI subprocess。本 PR 是代码库中唯一使用 TypeScript 编译流程（tsup + TypeScript + @types/node）+ npm 依赖 + SDK 直接调用的 action，引入了：

• Node.js 编译工具链（tsup、TypeScript、@types/node 等 devDependencies）
• 提交到版本控制的 bundle（dist/index.js 2645 行）
• npm 依赖管理（package-lock.json 1567 行）
• 与现有模式不一致的配置模型（环境变量 + opencode.json + TS config 混合）

虽然技术选型有合理依据（SDK 的 client.session.prompt() 可直接获取结构化响应，而 CLI stdout 只含框架噪声），但这是有意识的架构分歧，需要团队明确确认是否接受这一额外的维护维度。如果接受，建议考虑逐步将其他 action 也迁移到 SDK 模式，避免长期维护两条独立的技术栈。

2. reasoning-effort / enable-thinking 配置链路是隐含而非显式的

action.yml:192-228 的 bash step 将这两个值写入工作目录的 opencode.json。但 src/index.ts:40-42 的 createOpencode({ config: { model: ... } }) 未读取 MULTI_REVIEW_REASONING_EFFORT / MULTI_REVIEW_ENABLE_THINKING 环境变量，也未传入 reasoningEffort 或 enableThinking 给 SDK config。该配置是否生效完全取决于 SDK 内部是否自动读取工作目录的 opencode.json——若 SDK 不自动读取，用户设置这两个输入将无效果。

建议：在 createOpencode() 的 config 中显式读取环境变量并传入 reasoningEffort / enableThinking，同时考虑移除 bash step 中 opencode.json 的写入（该文件在 SDK 模式下可能不被使用）。

3. withTimeout() 不取消底层 SDK 请求（资源泄漏）

orchestrator.ts:33-41 的 Promise.race 超时后仅 reject 外层 promise，底层 SDK HTTP 请求仍在后台运行直至自行完成。在大规模超时场景下可能有后台请求堆积。建议确认 SDK 是否支持 AbortSignal，若支持则传入 signal 以实际取消请求。

4. action.yml:182 — gh pr diff 错误被 2>/dev/null 静默

diff 获取失败（如 token 权限不足、非 PR 上下文等）时错误被完全屏蔽，下游所有 reviewer 收到空 diff 产出无意义结果。建议至少输出错误信息到 stderr。

5. 缺少请求重试/退避机制

orchestrator.ts 中所有 client.session.*() 调用均无重试逻辑。API 限流或网络抖动会导致整个 review 全部失败。建议为核心调用添加至少 1-2 次指数退避重试。

6. comment.ts:64 — 冗余的条件检查

第 63 行 if (!comment.body) continue; 已保证 comment.body 非空，第 64 行 !comment.body.includes(...) 无需再次检查 comment.body。

7. package.json:11 — SDK 版本 ^1.0.0 过于宽松

允许自动升级 minor/patch，可能导致运行时行为不一致。建议在 package.json 或 package-lock.json 中锁定到具体版本。

opencode session  |  github run