GitHub Actions on Svtter's Blog

Multi-Review：多 Agent 并发代码审查的工程实践

Fri, 29 May 2026 10:00:00 +0800

在上一篇文章中，我介绍了 opencode-actions——一个基于 OpenCode 构建的 GitHub Action，用来做自动化的 PR 代码审查。那个版本的 review action 用的是一个模型、一个 prompt，针对整个 PR diff 做一次综合审查。

这个方案能用，但有个明显的问题：一个 prompt 要同时关注代码质量、安全漏洞、性能问题和架构设计，每一项都不够深入。 就像让一个工程师同时扮演 QA、安全审计、DBA 和架构师——每个角色都能说两句，但都不专业。

Cloudflare 在今年四月发了一篇博客，详细介绍了他们用 OpenCode 构建的多 Agent 并发代码审查系统。他们用了 7 个专业 reviewer 加 1 个 coordinator，在 5169 个仓库上跑了 13 万次审查。核心思路是：不要让一个模型什么都看，而是让多个专业模型各看各的，最后用一个 coordinator 统一汇总。

看完这篇文章，我决定在 opencode-actions 中实现类似的能力。这篇文章就是 multi-review action 的设计记录。

为什么需要多 Agent 并发审查？

单模型审查的问题不只是"不够深入"。实际使用中有几个具体的痛点：

维度冲突：安全审查要求严格（宁可误报不能漏报），性能审查要求务实（关注可测量的指标而非理论风险）。一个 prompt 很难同时表达两种截然不同的审查哲学。
上下文稀释：当 prompt 中塞了太多"你要检查 A、B、C、D、E"时，模型的注意力被分散，每个维度的审查质量都打折扣。
结果模糊：一个模型输出的"有条件合并"到底是因为安全问题还是性能问题？很难区分。

Cloudflare 的做法是把审查拆成独立的维度，每个 reviewer 只关注自己擅长的领域。他们的 security reviewer 有明确的 “What to Flag” 和 “What NOT to Flag” 指令——告诉模型什么该忽略，比告诉它什么该检查更重要。

架构：并发 Reviewer + Coordinator

multi-review 的核心架构用一句话概括：N 个专业 reviewer 并发审查，1 个 coordinator 汇总去重。

整个流程是这样的：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


PR 触发 → 获取 diff
 ↓
 启动 OpenCode Server（单实例）
 ↓
 ┌───────────┼───────────┐───────────┐
 ↓ ↓ ↓ ↓
Quality Security Performance Architecture
(reviewer) (reviewer) (reviewer) (reviewer)
 └───────────┴───────────┴───────────┘
 ↓ (Promise.all)
 Coordinator
 (去重 + 交叉验证)
 ↓
 PR Comment

关键设计选择：

单 Server 多 Session：只启动一个 OpenCode Server 实例，所有 reviewer 和 coordinator 共享。这样避免了 N 个 reviewer 各自冷启动 MCP server 的开销。
Promise.all 并发：所有 reviewer 通过 Promise.all 同时启动，不排队。实际运行时间取决于最慢的那个 reviewer，而不是所有 reviewer 的总和。
全局超时 + 自适应余量：一个全局 deadline，每个 reviewer 的剩余时间 = max(30s, deadline - now)。先完成的 reviewer 不影响后面的，后面的 reviewer 自然获得更少的时间。

四个专业 Reviewer

默认启动四个 reviewer，每个有独立的 YAML 定义：

Reviewer	关注领域	决策标签
Quality	代码质量、bug、逻辑错误、风格一致性、错误处理	可合并 / 有条件合并 / 不可合并
Security	输入验证、认证授权、注入漏洞、数据暴露、OWASP Top 10	安全无虞 / 存在风险 / 高危漏洞
Performance	算法复杂度、内存模式、N+1 查询、缓存、并发	性能良好 / 性能有疑虑 / 性能问题严重
Architecture	耦合度、模块划分、分层、接口设计、霰弹式修改	架构合理 / 架构有疑虑 / 架构有问题

每个 reviewer 的 prompt 都遵循同一个约束：第一行必须是决策标签，然后是总结、阻塞项和建议项。这让 coordinator 能结构化地解析每个 reviewer 的输出。

和 Cloudflare 的做法一样，每个 reviewer 的 prompt 都明确告诉它只看当前代码中存在的问题，不要重复早期版本的问题，不要建议修改未变更的代码。

Team 配置

reviewer 的组合通过 default-team 参数配置，格式是 persona:count：

1
2
3
4
5
6
7
8


# 默认：每种角色各一个
default-team: "quality:1,security:1,performance:1,architecture:1"

# 自定义：加强安全审查
default-team: "quality:1,security:2,performance:1"

# 极简：只看质量和安全
default-team: "quality:1,security:1"

当 count > 1 时，同角色的 reviewer 会带上编号（如 security-1、security-2），用同一个 prompt 但独立运行。相同 prompt 的多次运行可以起到交叉验证的效果——如果两个 security reviewer 都发现了同一个漏洞，可信度自然更高。

Cloudflare 有个类似的"风险分层"机制：trivial 改动（≤10 行）只跑 2 个 agent，full 改动（>100 行）跑全部 7 个。multi-review 目前靠用户手动配置 team，未来可以加入自动分层。

Coordinator：去重和交叉验证

并发审查带来的直接问题是多个 reviewer 可能发现同一个问题。比如一个 SQL 注入，quality reviewer 可能从 bug 角度报告，security reviewer 从安全角度报告。如果不处理，最终报告会有重复。

coordinator 的工作就是整合：

跨 reviewer 去重：同一问题只报告一次
交叉验证：至少 2 个 reviewer 同意的问题标记为"已确认"
冲突处理：意见不一致时取多数意见
保留领域见解：安全发现即使只有一个 reviewer 提到，也要保留
最严重决策：如果任何一个 reviewer 认为不可合并，最终决策就是不可合并

coordinator 的 prompt 模板支持自定义，通过 {{REVIEWS}} 占位符注入各 reviewer 的输出：

1
2
3
4
5
6
7
8


你是一个代码审查协调员。以下审查由独立的专家 reviewer 生成。
你的任务是整合为一个去重后的综合报告。

规则：
1. 跨 reviewer 去重（同一问题只提一次）
2. 交叉验证：至少 2 个 reviewer 同意的问题标记为"已确认"
3. 冲突时取多数意见
...

最终生成的 PR comment 包含两部分：coordinator 的综合报告在上，各 reviewer 的详细审查结果折叠在 <details> 标签中。

和 Cloudflare 方案的对比

两者使用了相同的思路——多 Agent 并发 + Coordinator 汇总——但在规模和复杂度上有明显差异：

维度	Cloudflare	multi-review
Agent 数量	7 个专业 agent + coordinator	4 个（可配置） + coordinator
并发模型	SDK 多 session，circuit breaker + failback	SDK 多 session，Promise.all + 全局超时
模型路由	按任务复杂度分配不同模型（Opus/Sonnet/Kimi）	单一模型，通过 `model` 参数指定
弹性	三级 circuit breaker，provider 级别的 failback chain	超时 + fallback comment（coordinator 失败时直接展示原始结果）
风险分层	自动（trivial/lite/full）	手动配置 team
扩展性	插件架构，7 个 plugin 组合	YAML persona 定义，内置 4 种
Token 优化	共享 context file，7x 的 MR 上下文不重复	每个 reviewer 独立接收完整 diff
适用场景	内部 GitLab，5169 仓库，企业级	GitHub/Gitea，开源项目，开箱即用

最核心的差异在弹性上。Cloudflare 的 circuit breaker 和 failback chain 是为生产环境设计的——7 个并发 AI 调用，provider 限频和宕机是必然事件。multi-review 的规模小得多，4 个并发的失败概率可控，用超时 + fallback comment 就够了。

另一个差异是 token 优化。Cloudflare 把 MR diff 写到一个共享文件，7 个 reviewer 读同一个文件而不是各拷一份。注意这里共享的是原始 diff（输入数据），而不是 reviewer 之间的审查结论。每个 reviewer 的审查过程仍然是完全独立的。这个优化在 7 个 reviewer 的情况下能省 85% 的重复 token。multi-review 目前每个 reviewer 都接收完整 diff，在 4 个 reviewer 的规模下重复还能接受，但如果 team 配置到 7+ 就需要考虑类似优化了。

Reasoning Effort 和 Thinking

multi-review 支持 reasoning-effort 和 enable-thinking 两个参数，直接传递给 OpenCode SDK 的 agent 配置：

1
2
3
4
5


- name: Run Multi-Review
 uses: sun-praise/opencode-actions/multi-review@v1
 with:
 reasoning-effort: max  # low / medium / high / max
 enable-thinking: true # 启用思维链

默认 reasoning-effort: max 和 enable-thinking: true，这意味着每个 reviewer 和 coordinator 都会用最大推理力度并输出思维链。对于代码审查这种需要深度分析的任务，这个默认值是合理的。

Cloudflare 也有类似的分层：coordinator 用 Opus（最强推理），code quality 和 security 用 Sonnet（平衡速度和能力），文档审查用 Kimi（便宜）。multi-review 暂时没有按角色分配不同模型的能力，但这是一个明确的优化方向。

使用方式

在 .github/workflows/ 中添加：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


name: Multi Review

on:
 issue_comment:
 types: [created]

jobs:
 multi-review:
 if: |
 github.event.issue.pull_request &&
 contains(fromJSON('["/multi-review", "/mr"]'), github.event.comment.body)
 runs-on: ubuntu-latest
 steps:
 - uses: sun-praise/opencode-actions/multi-review@v1
 with:
 github-token: ${{ secrets.GITHUB_TOKEN }}
 zhipu-api-key: ${{ secrets.ZHIPU_API_KEY }}
 # 可选配置
 default-team: "quality:1,security:1,performance:1,architecture:1"
 reasoning-effort: max
 enable-thinking: true

这段配置的效果是：在 PR 中评论 /multi-review 或 /mr，就会触发多 Agent 并发审查。

代码实现

核心实现在 orchestrator.ts 中的两个函数。

并发审查——runParallelReviewers：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


const promises = reviewers.map(async (reviewer) => {
 let sessionId: string | undefined;
 try {
 const remaining = () => Math.max(30_000, deadline - Date.now());

 // 1. 创建独立 session
 const sessionResult = await withTimeout(
 client.session.create({ throwOnError: true }),
 remaining(), reviewer.name,
 );
 sessionId = sessionResult.data.id;

 // 2. 发送 persona + diff
 await withTimeout(
 client.session.prompt({
 path: { id: sessionId },
 body: {
 parts: [{ type: "text", text: reviewer.prompt + "\n\nPR Diff:\n```\n" + prDiff + "\n```" }],
 },
 }),
 remaining(), reviewer.name,
 );

 // 3. 提取结果
 const messages = await withTimeout(
 client.session.messages({ path: { id: sessionId } }),
 remaining(), reviewer.name,
 );
 return { reviewer: reviewer.name, content: extractText(messages.data), success: true };
 } catch (err) {
 return { reviewer: reviewer.name, content: "", success: false, error: err.message };
 } finally {
 // 4. 清理 session
 if (sessionId) await client.session.delete({ path: { id: sessionId } });
 }
});

return Promise.all(promises);

Coordinator 汇总——runCoordinator：

1
2
3
4
5
6
7


// 把各 reviewer 的结果拼接成 {{REVIEWS}}
const reviewsText = reviews
 .map(r => `## ${r.reviewer}\n${r.success ? r.content : `（失败: ${r.error}）`}`)
 .join("\n\n---\n\n");

const fullPrompt = coordinatorPrompt.split("{{REVIEWS}}").join(reviewsText);
// 创建 session、发送 prompt、提取结果...

如果 coordinator 本身失败了，还有个 fallback：

1
2
3
4


export function buildFallbackComment(reviews: ReviewResult[]): string {
 // coordinator 挂了，直接把各 reviewer 的原始输出拼起来
 return "**Multi-Review (fallback — coordinator failed)**\n\n" + parts.join("\n\n---\n\n");
}

这确保了即使汇总环节出问题，审查结果也不会丢失。

和单模型 Review 的关系

multi-review 和之前单模型 review action 不是替代关系，而是互补：

	review	multi-review
定位	快速审查，适合每次 PR 都跑	深度审查，适合关键 PR 或手动触发
模型数	1 个	4+ 个（可配置）
耗时	1-3 分钟	3-8 分钟
Token 消耗	低	中（N 倍于单模型）
触发方式	PR 创建/更新自动触发	手动评论触发
适合场景	日常迭代，快速反馈	重要功能、安全相关、大型重构

日常开发用 review 做快速检查，关键 PR 用 multi-review 做深度审查。两个 action 可以共存于同一个仓库。

未来优化方向

参考 Cloudflare 的经验和当前实现的局限，有几个明确的优化方向：

自动风险分层：根据 diff 行数和文件类型自动决定跑几个 reviewer。typo 修改变动不需要 4 个 agent 并发审查。
共享上下文：把 diff 写到文件而不是每个 reviewer 都拷贝一份，减少 token 消耗。但需要注意一个微妙的问题：共享的边界在哪里？ 共享原始 diff（输入数据）是安全的，但如果过早共享 reviewer 之间的中间结论，会导致严重的偏差问题——确认偏差、锚定效应、同质化审查。正确的设计是：reviewer 阶段完全隔离，只共享输入；coordinator 阶段才汇总结论。这不仅是 token 优化的问题，更是一个审查独立性的架构决策。
模型路由：coordinator 用强模型，文档审查用轻量模型，按角色分配不同 provider。
增量审查：push 新 commit 后，只审查变更的部分，不从头开始。

总结

multi-review 的核心思路来自 Cloudflare 的文章：把一个复杂任务拆成多个专业子任务，并发执行后统一汇总。这比一个全能模型覆盖所有维度更有效，因为每个子任务的 prompt 更聚焦，模型的注意力更集中。

实现上，multi-review 用 OpenCode SDK 的多 session 能力做并发，用 Promise.all 做编排，用全局超时做兜底，用 coordinator 做去重和交叉验证。这是一个在开源项目规模下足够实用的架构——没有 circuit breaker 和 failback chain 的复杂度，但覆盖了并发审查的核心需求。

opencode-actions — GitHub Action 仓库
Cloudflare: Orchestrating AI Code Review at Scale — 设计灵感的来源
opencode-actions - 一个 coding review agent — 单模型 review action 的介绍
OpenCode 配置之外的优化 — opencode-review 插件的设计，session 内的代码审查

OpenCode 的 GitHub Actions 自动化体系：27 个 Workflow 背后的工程实践

Fri, 22 May 2026 10:00:00 +0800

opencode 是一个 16 万 star 的 AI 编码工具，它的 .github/workflows/ 目录下有 27 个 workflow 文件。这个数量在开源项目里不算少，但真正有意思的不是数量，而是这些 workflow 覆盖的范围：从常规的 CI/CD 到 AI 驱动的社区治理，几乎把 GitHub Actions 能做的事情都做了一遍。

这篇文章逐类分析这些 workflow 的设计，讨论这种自动化程度的利弊，以及对我们自己项目的启示。

总览

27 个 workflow 可以分成四类：

类别	数量	作用
CI/测试	4	typecheck、单元测试、e2e、Nix 构建
发布/交付	5	CLI 发布、容器构建、VS Code 插件、GitHub Action 发布
自动化/Bot	16	issue 治理、PR 合规、AI code review、文档更新
文档/其他	2	统计、Discord 通知

16 个自动化 workflow 占了总数的 60%。opencode 不只是用 Actions 来跑测试和发布，而是把社区治理和代码质量审查也交给了自动化系统。

CI/测试：扎实但克制

四个测试相关的 workflow：

typecheck.yml — PR 和 push 到 dev 时跑 bun typecheck。简单直接，没有多余动作。

test.yml — 跨平台测试矩阵（Linux + Windows），跑单元测试和 Playwright e2e。有 concurrency 控制，同一个 PR 的新 commit 会取消旧运行。测试结果生成 JUnit 报告上传为 artifact。

nix-eval.yml — 验证 Nix flake 在四种架构（x86_64-linux, aarch64-linux, x86_64-darwin, aarch64-darwin）下的构建。必选包失败会阻断，可选包失败只是警告。

storybook.yml — UI 组件的 Storybook 构建，只在 storybook/ui 相关文件变更时触发。路径触发避免了不必要的运行。

几个值得注意的设计选择：

concurrency group + cancel-in-progress：多个 workflow 都用了这个模式，同一个 PR 不会堆叠多次运行。对于一个接受大量社区 PR 的项目，这能省下不少 CI 资源。
路径触发：containers.yml 只在容器文件变更时运行，storybook.yml 只在 UI 变更时运行。不是所有东西都全量跑。
混合 Runner 策略：大部分 workflow 使用 Blacksmith 提供的第三方托管 runner（blacksmith-4vcpu-ubuntu-2404、blacksmith-4vcpu-windows-2025）。Blacksmith 是一个兼容 GitHub Actions API 的加速 runner 服务，底层用自建基础设施，比 GitHub 免费 runner 快不少。只有轻量级 bot 任务（close-issues、close-prs、compliance-close、pr-standards、deploy）留在 GitHub 原生的 ubuntu-latest 上。计算密集的编译、测试、发布全走 Blacksmith，简单的脚本任务用 GitHub 原生 runner，按任务负载分配资源。

发布/交付：全平台覆盖

publish.yml 是最复杂的 workflow，一个文件处理了完整的发布流程：

版本号计算
CLI 构建矩阵（多平台多架构）
Windows 代码签名（Azure Signing）
macOS 代码签名（Apple Developer）
Electron 应用构建
npm 发布
GitHub Release 创建
AUR（Arch Linux）发布

一个 workflow 覆盖了 CLI、桌面应用、npm 包、Linux 包的分发。这种"全平台一次发布"的模式对用户友好——无论什么平台都能在同一天拿到新版本。

其他发布 workflow 按产物类型拆分：

publish-github-action.yml — 监听 github-v* tag，发布 GitHub Action 到 Marketplace
publish-vscode.yml — 监听 vscode-v* tag，同时发布到 VS Code Marketplace 和 Open VSX
containers.yml — 多架构容器镜像构建，推送到 GHCR
release-github-action.yml — dev 分支有 github 目录变更时创建预发布

tag 触发是一个好的实践：发布是显式动作，不会因为误推代码就触发。publish.yml 会在 push 到 ci/dev/beta/fix 分支时自动构建 snapshot，但正式发布需要手动 dispatch 或 tag。

自动化/Bot：AI 驱动的社区治理

这是 opencode 最有特色的部分。16 个自动化 workflow 中，多个直接调用了 opencode 自己的 AI 能力来处理社区事务。

Issue 管理

triage.yml — 新 issue 创建时，用 opencode AI 自动分流，添加标签和分类。

duplicate-issues.yml — 新 issue 创建/编辑时，用 opencode AI 分析是否与已有 issue 重复。同时检查是否遵循了三种 issue 模板之一，是否包含 AI 生成内容。不合规的会被加上 needs:compliance 标签。

compliance-close.yml — 每 30 分钟检查一次，带有 needs:compliance 标签的 issue/PR 如果 2 小时内没有修正，自动关闭。关闭时会根据是 issue 还是 PR 给出不同的提示信息。

close-issues.yml — 每天凌晨 2 点 UTC 关闭过期的 stale issue。

这四层形成了完整的 issue 生命周期管理：

1

新 issue → AI 分流(triage) → 重复/合规检查(duplicate) → 合规宽限期(compliance) → 过期清理(close)

PR 管理

pr-standards.yml 是最长的 workflow 之一，做了两件事：

标题格式检查：强制 conventional commits 格式（feat/fix/refactor/…）
模板合规检查：PR 描述必须包含 issue 引用、变更类型、验证方法等必要章节

不合规的 PR 会被加上 needs:compliance 标签，2 小时后自动关闭。team 成员和 bot 豁免。

pr-management.yml — PR 创建时查重，并为社区贡献者添加标签。

close-prs.yml — 每天晚上 10 点 UTC 关闭超过 1 个月且点赞数不够的 PR。默认阈值是 2 个 reaction，可配置。

AI Code Review

review.yml — 在 PR 评论中输入 /review，opencode AI 会分析代码并在具体的行上留下 review 评论。只对 repo owner/member 开放。

opencode.yml — 在 issue 或 PR 评论中输入 /oc 或 /opencode，触发 opencode AI 进行更通用的交互。

这两个 workflow 展示了"AI 作为协作者"的思路：不是全自动的 code review，而是按需触发，人在回路中做最终决定。

文档与维护

docs-update.yml — 每 12 小时检查最近的 commit，用 opencode AI 判断是否需要更新文档。

generate.yml — push 到 dev 时运行代码生成脚本，自动提交变更。

beta.yml — 每小时同步 beta 分支。

stats.yml — 每天更新下载统计到 STATS.md。

值得借鉴的设计模式

1. 分层治理

opencode 没有把所有自动化塞进一个 workflow，而是按职责拆分。issue 从创建到关闭经过了四个 workflow 的接力处理。每个 workflow 只做一件事，组合起来形成完整的治理链。

这种设计的好处是：

单个 workflow 可以独立修改、禁用，不影响其他环节
每个 workflow 的触发条件、权限范围都是最小化的
出问题时容易定位是哪个环节

2. 合规宽限期

compliance-close.yml 不是检测到不合规就立即关闭，而是给 2 小时的宽限期。这对全球不同时区的贡献者来说是合理的——你可能正好在睡觉的时候提交了一个 issue，醒来发现有时间修正。

3. AI 用在决策点而不是执行点

triage、duplicate 检测、code review 这些都是 AI 做初步判断，人做最终决定。而代码构建、发布这些执行层面的事情完全不用 AI。这是一个务实的分工：AI 擅长模式识别和初步分类，但不擅长精确执行。

4. 显式触发 vs 自动触发

发布用 tag 触发，日常维护用 schedule 触发，社区治理用事件触发。三种触发方式对应三种不同的自动化信任等级：发布需要人工确认，维护可以定时自动，治理需要即时响应。

过度自动化的风险

opencode 的自动化体系很完善，但也有需要注意的地方：

社区门槛：新贡献者提交 issue 需要遵循特定模板，PR 需要符合 conventional commits，否则 2 小时后自动关闭。对于一个 16 万 star 的项目，这种严格是合理的——它能过滤掉大量低质量贡献。但对于小项目，这种程度的自动化会吓跑潜在贡献者。

维护成本：27 个 workflow 意味着 27 个需要维护的自动化脚本。opencode 有专门的自定义 runner 和专用脚本。如果某个 workflow 的逻辑需要调整，维护者需要在 GitHub Actions 的 YAML + 自定义脚本之间来回切换。

AI 的不确定性：duplicate-issues 和 triage 用 AI 做判断，但 AI 可能误判。一个合理的 issue 被标记为 duplicate 并关闭，对贡献者的体验是负面的。opencode 用宽限期和人工复核来缓解这个问题，但风险依然存在。

对我们项目的启示

不是每个项目都需要 27 个 workflow。但 opencode 的分层治理和"AI 在决策点"的思路值得参考：

从 issue 模板开始：如果项目开始收到大量重复或低质量 issue，先加模板和 duplicate 检查，而不是手动处理每一个。
合规检查用宽限期：自动关闭不合规贡献时，始终给一个宽限期。
AI 用于分类不用于执行：让 AI 帮你分流 issue、检查 PR 格式，但不要让 AI 自动合并代码或发布版本。
发布用 tag 触发：这是最安全的做法。自动发布的 snapshot 可以接受，正式版本需要人工确认。
按需添加：先有痛点再加自动化。opencode 的 27 个 workflow 不是一天建成的，是随着社区规模增长逐步增加的。

总结

opencode 的 GitHub Actions 体系展示了大型开源项目的自动化实践：CI/CD 覆盖全平台发布，社区治理用多层 workflow 接力处理，AI 被用在分流和审查等决策环节。这套系统的核心不是技术复杂度，而是"分层、宽限、显式触发"这三个原则。对于自己的项目，不需要照搬 27 个 workflow，但这些原则可以直接用上。

opencode-actions - 一个 coding review agent

Thu, 23 Apr 2026 11:36:34 +0800

为了方便引入 opencode 来做 code review，我构建了一个 github action repo。和 opencode 一起编程来做这个事情不难。

目前主要提供两个功能，一个是 review，另一个是借助 runner 来执行 opencode （也就是直接用 runner 跑 opencode 的 prompt），来跑一下其他的功能。例如改代码，创建新的 issue，根据 issue 创建 PR 等。

稳定性怎么样？

这个 repo 已经经过多个项目的验证，release 的版本是可靠的。
但是要注意 main 分支的版本是快速迭代版本。

如何引入？

在你的 .github/workflows/opencode-review.yml 下添加：

1
2
3
4
5
6
7
8


- name: Run OpenCode review
 uses: sun-praise/opencode-actions/review@v1
 with:
 github-token: ${{ secrets.GITHUB_TOKEN }}

 # only one is enough.
 zhipu-api-key: ${{ secrets.ZHIPU_API_KEY }}
 opencode-go-api-key: ${{ secrets.OPENCODE_GO_API_KEY }}

现在，这个 actions 主要支持的是 Z.AI，ZHIPU，以及 OPENCODE GO 订阅。因此，如果用 ZHIPU，那么在项目中的 secrets 加上自己的 ZHIPU_API_KEY 即可。如果用的是 opencode go 订阅，则需要加上 OPENCODE_GO_API_KEY。

其他的都可以根据默认配置来。默认模型是 zhipuai-coding-plan/glm-5-turbo。如果有更多的配置要求，建议去看原仓库的 README。

我之前在代码审查文章中也有讲过，这个快速地 review 脚本。

差异性

实际上 opencode 自己也有 actions，那么为什么我要再做一个呢？

与官方的差异主要体现在几个方面：

功能	上游状态	本仓库
Model 默认值 fallback	仅 required input	三级 fallback（input → MODEL_NAME → 硬编码默认）
Provider 便捷字段	无	`zhipu-api-key`、`opencode-go-api-key` 等
Review prompt 模板	无	中文格式化 review（可合并/有条件合并/不可合并）
Retry 逻辑	无	attempts / retry-profile / retry-on-regex / retry-delay
执行超时	无	timeout-seconds
版本检查	无	OPENCODE_MIN_VERSION
安装重试	无	install-attempts
XDG cache 缓存	仅缓存 bin	同时缓存 bin + XDG cache

在 sun-praise/opencode-actions#29 中有详细的说明。

review 效果

可以从 repo 本身的 PR 看到 opencode-actions#30

大概是这个效果：

未来

尝试集成 gemini cli。现在 google 的 GEM 3.1 PRO 模型性价比很高，单位智能是最高的。
集成 MCP 插件功能。opencode review 的时候 MCP 如果有，可能会带来更好的 review 效果。
商业化的插件功能集成

使用 OpenCode + GLM-5 实现 GitHub PR 自动代码审查

Mon, 26 Jan 2026 00:00:00 +0000

大模型会磨洋工，需要另一个 agent 或 AI 来监督。

最近在项目中集成了 OpenCode 的 AI 代码审查功能，使用智谱 AI 的 GLM-5 模型自动 review PR 代码。本文记录完整的集成过程和踩过的坑。

背景

项目需要一个自动化的代码审查机制：

当 PR 创建或更新时，自动触发 AI 审查
AI 只提供 review 建议，不修改代码
将审查结果以 comment 形式添加到 PR 中

技术选型

OpenCode

OpenCode 是一个开源的 AI coding agent，支持：

多种 LLM 提供商（OpenAI、Anthropic、智谱等）
GitHub/GitLab 集成
在 CI 环境中运行

GLM-5 Coding Plan

选择智谱 AI 的 GLM Coding Plan 原因：

专为 AI 编程优化，支持 OpenCode
价格实惠（$3/月起）
国内访问稳定

TL;DR

如果只是想快速引入 code review，不需要处理权限、凭据等配置，可以直接使用封装好的 action。这是最快引入 code review 的方法，review 结果是中文：

1
2
3
4
5
6
7
8


- name: Run OpenCode review
 uses: Svtter/opencode-actions/review@v1
 with:
 github-token: ${{ secrets.GITHUB_TOKEN }}

 # only one is enough.
 zhipu-api-key: ${{ secrets.ZHIPU_API_KEY }}
 opencode-go-api-key: ${{ secrets.OPENCODE_GO_API_KEY }}

只需要配置对应的 secret 即可使用。

配置详解

1. 确定模型格式

OpenCode 的模型格式为 provider_id/model_id。对于智谱 GLM-5：

配置项	值
环境变量	`ZHIPU_API_KEY`
Model 格式	`zhipuai-coding-plan/glm-5`

2. 创建 Workflow 文件

创建 .github/workflows/opencode-review.yml：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44


name: OpenCode PR Review

on:
 pull_request:
 types: [opened, synchronize, reopened, ready_for_review]

jobs:
 review:
 name: AI Code Review
 # 仅在 PR 准备就绪时运行（跳过 draft PR）
 if: github.event.pull_request.draft == false
 runs-on: self-hosted
 permissions:
 id-token: write
 contents: read
 pull-requests: write
 issues: write
 steps:
 - name: Checkout repository
 uses: actions/checkout@v6
 with:
 persist-credentials: true
 token: ${{ secrets.GITHUB_TOKEN }}

 - name: Run OpenCode Review
 uses: anomalyco/opencode/github@latest
 env:
 ZHIPU_API_KEY: ${{ secrets.ZHIPU_API_KEY }}
 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 with:
 model: zhipuai-coding-plan/glm-5
 use_github_token: true
 prompt: |
 Review this pull request (read-only mode, DO NOT modify any code):

 Please check:
 - Code quality issues
 - Potential bugs or logic errors
 - Code style consistency
 - Security concerns
 - Performance issues
 - Suggest improvements

 Please respond in Chinese. DO NOT modify any code, only provide review comments.

3. 配置 GitHub Secrets

在仓库 Settings → Secrets and variables → Actions 中添加：

ZHIPU_API_KEY: 从 Z.AI Console 获取

踩坑记录

坑 1: 权限不足 (403 Forbidden)

错误信息：

1

Resource not accessible by integration - https://docs.github.com/rest/issues/comments#create-an-issue-comment

原因：permissions 配置为 read，无法写入 PR comment。

解决：将权限改为 write：

1
2
3


permissions:
 pull-requests: write  # 不是 read
 issues: write  # 不是 read

坑 2: Git 凭据问题