背景
基于 opencode-actions#80 的讨论，调研了 OpenCode 生态中类似的 AI 代码审查工具和相关项目，整理如下。
相关工作对比
直接相关：代码审查工具
| 项目 |
Stars |
核心思路 |
关键特性 |
| spencermarx/open-code-review |
179 |
多 agent 辩论式审查 |
28 个 reviewer 人设（Martin Fowler、Kent Beck 等）、Web dashboard、Mermaid 依赖图、需求文档对齐、GitHub PR 发帖 |
| calimero-network/ai-code-reviewer |
5 |
5 个专业 agent 共识评分 |
Security/Performance/Patterns/Logic/Style 五维度独立 agent、收敛检测（多次 push 后 findings 稳定自动停止）、增量审查、文档审查（零 LLM 成本） |
| hueyexe/opencode-ensemble |
110 |
通用多 agent 并行框架 |
Scout→Builder→Reviewer 编排、实时 dashboard、task board 依赖追踪、worktree 隔离、per-agent model 选择 |
| diffray.ai |
商业 SaaS |
10+ 专业 agent |
"调查而非推测"——trace callers、检查测试覆盖、87% 更少误报、SOC 2 合规 |
间接相关：Agent 编排与流程控制
| 项目 |
Stars |
核心思路 |
对审查的启发 |
| darrenhinde/OpenAgentsControl |
20+ |
Plan-first + approval gates |
可编辑 agent（纯 markdown）、MVI（最小可行上下文，token 效率）、context learning（学习项目编码模式）、approval gates（关键操作前人工确认） |
| zaxbysauce/opencode-swarm |
50+ |
18+ 专业 agent + 14-step pipeline |
hub-and-spoke 编排、PRM（5 种 agent 失败模式检测：repetition loop / ping-pong / expansion drift / stuck-on-test / context thrashing）、43 个 slash command、6000+ tests |
我们的优势（保持）
- idle 自动审查 + auto-fix 闭环：所有竞品都是手动触发或 PR webhook，只有我们支持 session idle 自动触发 + review:fixer sub-agent 自动修复
- 多 agent 并行审查：5 个维度 sub-agent（code-quality / security / performance / testing / documentation）并行跑，review agent 负责调度和合并
- 中英双语支持：所有竞品只有英文
- 零基础设施：一个文件 symlink 就能用，不需要 dashboard/SQLite/CI 配置
已实现 ✅
1. 多 agent 并行审查 → ✅ 已实现（v0.2.0）
5 个维度独立 sub-agent 并行跑，review agent 作为调度器收集结果并合并。支持 parallel: true/false 配置切换单/多 agent 模式。
差距与改进方向
2. "调查而非推测"（优先级：高）
目前审查只看 diff 内容。diffray 的做法是让 agent 主动 trace callers、检查测试覆盖、分析影响范围。
建议：在审查 prompt 中增加上下文采集步骤——拿到 diff 后，先分析涉及的函数/类的调用链和测试覆盖情况，再给出审查意见。可以把这个做成一个 pre-review 的工具。
3. 增量审查 / 收敛检测（优先级：中）
calimero 有一个不错的设计：追踪多次 push 的 findings 变化，当 findings 稳定（收敛）时自动停止审查，避免重复工作。
建议：结合 cooldown 机制，记录上一轮审查的 findings hash，如果代码没变或 findings 已修复则跳过审查。
4. GitHub PR 集成（优先级：中）
spencermarx 和 calimero 都能直接在 GitHub PR 上发评论。opencode-actions 已经做了 CI 侧的集成，但 opencode-review 插件本身没有 PR 发帖能力。
建议：考虑在插件中增加 github-pr 输出模式，将审查结果以 PR comment 的形式发到 GitHub，和 opencode-actions 形成互补。
5. Agent 失败模式检测（优先级：中）
参考 opencode-swarm 的 PRM（Process Remediation Model），审查 agent 可能陷入重复标记同一问题、在不确定代码上反复纠结等陷阱。
建议：记录每轮审查的 findings hash，连续 3 轮 findings 无变化时触发收敛停止，避免 token 浪费。检测 5 种失败模式：repetition loop、ping-pong、expansion drift、stuck-on-test、context thrashing。
6. 审查流程 pipeline 化（优先级：低）
参考 opencode-swarm 的 14-step pipeline 和 OAC 的 approval gates，将审查拆成更细的阶段。
建议：diff 解析 → 上下文采集（调用链/测试覆盖）→ 维度并行审查 → 结果去重与排序 → 报告生成 → （可选）人工确认
7. Approval gates（优先级：低）
参考 OAC 的设计，在高风险改动（安全相关、架构变更）时自动标记为"需要人工确认"，低风险改动才走自动 approve。
8. Context learning（优先级：低）
参考 OAC，让审查 agent 在首次审查时学习项目的 code style 和架构约定，后续审查时对偏离项目惯例的代码更敏感。
9. 可视化 / Dashboard（优先级：低）
spencermarx 有 Web dashboard 做审查结果的 triage，hueyexe 有实时 agent dashboard。锦上添花，非核心需求。
参考资源
背景
基于 opencode-actions#80 的讨论，调研了 OpenCode 生态中类似的 AI 代码审查工具和相关项目，整理如下。
相关工作对比
直接相关：代码审查工具
间接相关：Agent 编排与流程控制
我们的优势（保持）
已实现 ✅
1. 多 agent 并行审查→ ✅ 已实现（v0.2.0）5 个维度独立 sub-agent 并行跑，review agent 作为调度器收集结果并合并。支持
parallel: true/false配置切换单/多 agent 模式。差距与改进方向
2. "调查而非推测"（优先级：高）
目前审查只看 diff 内容。diffray 的做法是让 agent 主动 trace callers、检查测试覆盖、分析影响范围。
建议：在审查 prompt 中增加上下文采集步骤——拿到 diff 后，先分析涉及的函数/类的调用链和测试覆盖情况，再给出审查意见。可以把这个做成一个 pre-review 的工具。
3. 增量审查 / 收敛检测（优先级：中）
calimero 有一个不错的设计：追踪多次 push 的 findings 变化，当 findings 稳定（收敛）时自动停止审查，避免重复工作。
建议：结合 cooldown 机制，记录上一轮审查的 findings hash，如果代码没变或 findings 已修复则跳过审查。
4. GitHub PR 集成（优先级：中）
spencermarx 和 calimero 都能直接在 GitHub PR 上发评论。opencode-actions 已经做了 CI 侧的集成，但 opencode-review 插件本身没有 PR 发帖能力。
建议：考虑在插件中增加
github-pr输出模式，将审查结果以 PR comment 的形式发到 GitHub，和 opencode-actions 形成互补。5. Agent 失败模式检测（优先级：中）
参考 opencode-swarm 的 PRM（Process Remediation Model），审查 agent 可能陷入重复标记同一问题、在不确定代码上反复纠结等陷阱。
建议：记录每轮审查的 findings hash，连续 3 轮 findings 无变化时触发收敛停止，避免 token 浪费。检测 5 种失败模式：repetition loop、ping-pong、expansion drift、stuck-on-test、context thrashing。
6. 审查流程 pipeline 化（优先级：低）
参考 opencode-swarm 的 14-step pipeline 和 OAC 的 approval gates，将审查拆成更细的阶段。
建议：
diff 解析 → 上下文采集（调用链/测试覆盖）→ 维度并行审查 → 结果去重与排序 → 报告生成 → （可选）人工确认7. Approval gates（优先级：低）
参考 OAC 的设计，在高风险改动（安全相关、架构变更）时自动标记为"需要人工确认"，低风险改动才走自动 approve。
8. Context learning（优先级：低）
参考 OAC，让审查 agent 在首次审查时学习项目的 code style 和架构约定，后续审查时对偏离项目惯例的代码更敏感。
9. 可视化 / Dashboard（优先级：低）
spencermarx 有 Web dashboard 做审查结果的 triage，hueyexe 有实时 agent dashboard。锦上添花，非核心需求。
参考资源