Code Review 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 配置之外的优化 — 基于插件的优化

Tue, 19 May 2026 10:00:00 +0800

之前我写过一篇 OpenCode 配置优化记录，解决的是 token 消耗和上下文管理的问题。但配置优化管的是"模型怎么跑"，而"代码写到一半质量怎么样"——这件事配置管不了。这篇文章从我开发 opencode-review 插件的过程出发，聊聊 opencode-review 如何在一个 session 内帮助 agent 审查并改进自己的代码，让最终进入 PR 的代码质量更高。

问题：session 内的代码质量谁来把关？

用 OpenCode 写代码时，一个典型的工作流是：agent 在一个 session 内完成编码，然后我 review diff、创建 PR。但我发现一个反复出现的问题：agent 写完的代码经常带着"第一次草稿"的质量问题就进入 PR 了。

这些问题包括：缺少错误处理、安全漏洞、性能不佳的查询、缺失的测试。如果能在 session 内——也就是代码还没提交到 PR 之前——让 agent 自行审查一轮，很多问题在 PR 阶段就不存在了。

这和 CI 阶段的 code review 是不同层次的事情。CI 审查我已经通过 opencode-actions（之前写过一篇介绍文章）实现了——它发生在 PR 创建之后，由 GitHub Actions 触发。后来 Cloudflare 也在工程博客中分享了类似思路：用 OpenCode 构建大规模 AI code review。而 opencode-review 要解决的是更早的阶段：在 session 内、在 PR 之前，让 agent 在写完代码后主动审查并修复问题。两者互补：opencode-review 提升进入 PR 的代码质量基线，opencode-actions 则作为最后一道关卡。

具体来说，有三个需要解决的子问题：

审查覆盖不全：agent 生成的代码可能引入安全漏洞、性能问题，但它自己不会主动检查这些
缺乏系统性的审查框架：没有结构化的维度来评估代码，容易只关注功能正确性而忽略安全和性能
发现问题和修复之间缺乏闭环：即使 agent 发现了问题，也需要一个机制来自动修复，而不是等人来指出

opencode-review 的设计

基于这三个问题，我设计了 opencode-review：一个结构化的代码审查插件。

多维度分析

第一个设计决策是为什么分五个维度，而不是一个笼统的"好不好"的评价。

代码质量不是一个单一维度。一段代码可能功能正确、性能优秀，但存在 SQL 注入漏洞；也可能安全无害，但缺少测试覆盖。把它们混在一起评估，结果必然模糊。

学术上，Modern Code Review (MCR) Survey 收集了 2013-2025 年间的代码审查研究，提出了一个分类体系，涵盖缺陷检测、安全审查、性能分析、可维护性评估等多个任务维度。Ericsson 的研究团队在 Automated Code Review Using Large Language Models at Ericsson 中也验证了：按维度拆分的审查比笼统审查在工业场景中更有效。

opencode-review 的五个维度——code-quality、security、performance、testing、documentation——对应的就是这些研究中识别出的核心审查维度。每个维度可以独立开关，因为不同项目关注的重点不同：一个内部工具可能不需要文档审查，但一个安全敏感的服务不能跳过 security 维度。

严重性分级

第二个设计决策是为什么分三级严重性（critical / suggestion / highlight）。

这来自静态分析工具领域的经验教训。安全工具和 linter 长期面临一个问题：alert fatigue（告警疲劳）。当所有问题都被标记为同等重要时，开发者会开始忽略它们。Veracode 的研究指出，告警疲劳导致的直接后果是真正的严重问题被淹没在噪音中。

分三级的逻辑是：

critical：必须修复（安全漏洞、逻辑错误、资源泄漏）
suggestion：建议改进（代码可读性、性能优化、更好的实践）
highlight：值得注意（风格一致性、潜在的改进空间）

这样开发者可以优先处理 critical，而不会在一堆 “consider refactoring” 中错过一个 SQL 注入。

自动修复链

第三个设计决策是为什么 critical 问题要自动触发修复，而不是仅仅报告。

这是一个有争议的设计。传统的审查工具通常是"只报告不修复"，把修复留给开发者。但 opencode-review 的场景不同——它审查的代码本身就是 AI agent 刚写完的，让另一个 agent 去修复合情合理。

学术上这属于 Automated Program Repair (APR) 的范畴。A Survey of LLM-based Automated Program Repair (arXiv 2506.23749) 综述了 2022-2025 年间的 63 个 LLM-based APR 系统，分为四种范式。其中"分析增强"（analysis-augmented）范式——先用静态分析定位问题，再用 LLM 生成修复——被证明是最有效的。opencode-review 的 auto-fix chain 本质上就是这个范式：reviewer 发现 critical issue → 定位问题位置 → spawn fixer sub-agent → 生成最小化修复。

ICSE 2025 的一篇论文也指出，LLM 在 APR 中的关键挑战是目标对齐（objective alignment）——修复的目标不是"生成看起来合理的代码"，而是"精确解决报告的问题"。这也是为什么 opencode-review 的 fixer 被设计为 minimal fix——只做最小的修改来解决问题，不重写、不重构、不"顺手"做其他改动。

自动审查的隐性收益：代码质量基线的持续提升

上面三个设计解决的是"发现问题"和"修复问题"。但自动审查还有一个容易被忽略的好处：它在不经意间持续提升了代码质量的基线。

这个效果来自两个机制：

第一，审查反馈对写代码者的塑造。 FSE 2022 的研究在两年的工业实践中发现，当开发者知道自己的代码会被自动审查时，他们会在写代码阶段就更有意识地遵循规范——因为事后被指出来的成本变低了，提前写好的收益变高了。这是一种 nudge effect（助推效应）。在 AI agent 的场景下，这个效应更强：agent 在一个 session 中写了代码、被 review 指出问题、修复、再次被审查——这个循环在同一 session 内就能完成多轮。每一轮反馈都在修正 agent 的输出倾向，相当于一个隐式的 fine-tuning 过程。

第二，自动修复的直接质量累积。 critical issue 被自动修复意味着每一轮提交的代码质量都比没有审查时更高。这不是一次性的改进，而是持续的。就像代码库中的 lint 规则一样——一开始只是禁止明显错误，但随着规则积累，代码库的整体风格和质量在不知不觉中被拉高了。auto-fix chain 做的事情类似：安全漏洞被自动堵上、资源泄漏被自动修复、缺失的测试被自动补充。时间一长，代码库的质量基线自然高于没有自动审查的情况。

简单说：审查不是目的，质量提升才是。自动审查把"事后检查"变成了"过程中提升"。

Cooldown 机制

还有一个小的设计细节：cooldown_seconds。

auto-review 在 session idle 时触发，但 idle 事件可能频繁触发（比如 agent 在等待用户确认时也会 idle）。没有 cooldown 的话，同一份代码可能被审查好几次，浪费 token。120 秒的默认冷却期是一个经验值——足够让一轮修改完成，又不会等太久。

opencode-froggy：另一种思路

opencode-froggy（85 Stars，昨天刚发 0.12.0）提供了另一种思路。它不做结构化的多维度审查，而是提供 6 个专用 agent（architect、code-reviewer、code-simplifier、doc-writer、partner、rubber-duck）和一套灵活的 hooks 系统。

Froggy 的 code-reviewer 是一个通用的只读审查 agent，不区分维度和严重性。但它的 hooks 系统很强——你可以配置 session.idle 事件自动跑 lint、自动格式化、甚至在写入敏感文件时拦截：

1
2
3
4
5
6
7
8


---
hooks:
 - event: session.idle
 conditions: [hasCodeChange, isMainSession]
 actions:
 - bash: "npm run lint --fix"
 - command: simplify-changes
---

这是一种"开发者自己编排流程"的思路，和 opencode-review 的"开箱即用的结构化审查"形成互补。

对比

	opencode-review	opencode-froggy
审查方式	结构化多维度分析	通用 code-reviewer agent
严重性分级	critical / suggestion / highlight	无
自动修复	critical issue → fixer sub-agent	code-simplifier，需手动触发
触发方式	session idle + cooldown	hooks 配置
自定义规则	custom_rules 支持项目规范	无
其他功能	无	6 agent + hooks + gitingest + 区块链

两个不冲突，可以一起装。我的建议是：opencode-review 做日常自动审查，froggy 的 hooks 做流程编排。

插件安装

两个插件的安装方式不同。

opencode-froggy 支持通过 npm 直接安装，在 opencode.json 中添加即可：

1
2
3


{
 "plugin": ["opencode-froggy"]
}

opencode-review 目前 npm 安装尚未上线，需要 clone 后本地链接：

1
2
3
4
5
6
7
8
9


# clone 到任意位置
git clone https://github.com/sun-praise/opencode-review.git /path/to/opencode-review

# 项目级安装（推荐）
mkdir -p .opencode/plugins
ln -s /path/to/opencode-review/src/index.ts .opencode/plugins/opencode-review.ts

# 或全局安装
ln -s /path/to/opencode-review/src/index.ts ~/.config/opencode/plugins/opencode-review.ts

opencode-review 还需要创建 .opencode/review.json 来配置审查行为：

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


{
 "language": "zh",
 "dimensions": ["code-quality", "security", "performance", "testing", "documentation"],
 "trigger": {
 "auto_on_idle": true,
 "cooldown_seconds": 120
 },
 "custom_rules": [
 "All API endpoints must have error handling",
 "Database queries must use parameterized statements"
 ]
}

其他值得关注的插件

生态已经超过 70 个插件了，再推荐几个：

opencode-worktree：零摩擦的 git worktree 管理
opencode-notify：任务完成时发送系统通知
dynamic-context-pruning：自动裁剪过时的工具输出，优化 token 使用
envsitter-guard：阻止 agent 读取 .env 敏感文件

完整列表见 awesome-opencode。

参考文献

Modern Code Review (MCR) Survey — 2013-2025 代码审查研究综述
Automated Code Review Using LLMs at Ericsson — LLM 辅助代码审查的工业实践
A Survey of LLM-based Automated Program Repair — LLM 自动修复综述，覆盖 63 个系统
Aligning the Objective of LLM-Based Program Repair (ICSE 2025) — LLM 修复的目标对齐问题
Understanding Automated Code Review Process (FSE 2022) — 两年工业环境自动审查的经验总结
AI-Assisted Assessment in Modern Code Review (AIware 2024) — AutoCommenter 的部署与评估
Code Review Agent Benchmark (c-CRAB) — AI agent 代码审查基准测试
opencode-actions - 一个 coding review agent — 基于 OpenCode 构建的 GitHub Action，CI 阶段的 code review
Cloudflare: Orchestrating AI Code Review at Scale — Cloudflare 用 OpenCode 构建大规模 AI 审查

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 凭据问题