用 GLM + OpenClaw 打造你的 AI PR Review Agent — 让龙虾帮你审代码

前言

在开始阅读之前有一个问题想问问大家：你的团队是怎么做 Code Review 的？是大家互相看看代码，留几个"LGTM"就合并了？还是每次 Review 都认认真真、逐行检查架构设计、Compose 的 recomposition 优化、协程的 Dispatcher 注入？

我猜大部分人可能和我一样，理想很丰满，现实很骨感。有时候 PR 积压了几十个，光看 diff 就头大，更别说系统性地审查安全漏洞、性能问题了。

那如果有一个 AI Agent，你只需要给它一个 PR 链接，它就能自动读完所有代码变更，按照 Now in Android 的架构标准和 Compose 最佳实践帮你审查，然后在聊天里给你一份结构化报告，同时还能直接在 GitHub PR 上提交 review 评论呢？

如果上面的场景让你觉得"这也行？"，那请继续往下看。今天我来分享一下如何用国产大模型 GLM + 开源工具 OpenClaw 搭建一个专属的 PR Review Agent。

第一步：安装 OpenClaw

OpenClaw 是一个开源的 AI Agent 框架，可以理解为一个"AI 管家平台"。你可以在上面运行多个 Agent，每个 Agent 有自己的身份、技能和工作空间，互不干扰。

偷懒绝招：直接找 AI 给你配置 🦞 就好了。 如果你用 cursor 或者其他 AI 工具 安装 🦞，跳过第一步，直接进入第二步。

安装很简单，确保你有 Node.js 22+，然后一行命令搞定：

npm install -g openclaw@latest

安装完成后运行初始化向导：

openclaw onboard --install-daemon

这个向导会引导你配置 Gateway（本地服务）、工作空间和模型。我这里选择的是智谱 AI 的 GLM-4.7 作为主力模型，因为它支持 204800 的超大上下文窗口，对于审查大型 PR 非常友好，而且免费额度非常慷慨。

配置完成后的 ~/.openclaw/openclaw.json 里面的模型配置大概长这样：

{
  "models": {
    "providers": {
      "zai": {
        "baseUrl": "https://open.bigmodel.cn/api/coding/paas/v4",
        "api": "openai-completions",
        "models": [
          {
            "id": "glm-4.7",
            "name": "GLM-4.7",
            "reasoning": true,
            "contextWindow": 204800,
            "maxTokens": 131072
          }
        ]
      }
    }
  }
}

看到这里你会不会发出感叹：就这？别急，模型配好了只是第一步，接下来才是重头戏。

第二步：创建隔离的 PR Review Agent

OpenClaw 支持多 Agent 架构，每个 Agent 有独立的工作空间和身份。这很重要 ------ 你不会想让你的 PR Review Agent 和日常聊天的 Agent 混在一起。

openclaw agents add pr-reviewer --model zai/glm-4.7

一行命令，一个名为 pr-reviewer 的独立 Agent 就创建好了。它有自己的工作空间目录 ~/.openclaw/workspaces/pr-reviewer/，和 main Agent 完全隔离。

第三步：定义审查规则 ------ SOUL.md 是灵魂

这一步是整个方案的核心。OpenClaw 的 Agent 通过工作空间里的 Markdown 文件来定义行为，其中 SOUL.md 就是 Agent 的"灵魂"------ 它决定了 Agent 是谁、怎么做事。

我参考了 Google 官方 Now in Android 项目的架构规范、Compose 性能最佳实践、协程最佳实践 和 架构建议，定义了 10 个审查维度：

维度	关注什么
架构与模块化	层级违规、循环依赖、Convention Plugin 一致性
Compose UI	State Hoisting、recomposition 优化、Modifier 顺序、LazyList key
协程与 Flow	主线程阻塞、Dispatcher 注入、repeatOnLifecycle
ViewModel 与状态	UiState sealed interface 设计、事件处理
依赖注入	Scope 管理、@Binds vs @Provides
安全性	硬编码密钥、日志泄露、SQL 注入
测试	TestDispatcher、Compose UI 测试
无障碍	contentDescription、48dp 触摸目标
性能	ANR 风险、ImmutableList、Baseline Profile
代码质量	Kotlin 惯用法、命名规范

每个维度下面又按严重程度分为三级：

• 🔴 阻塞性问题 ------ 有这类问题就直接 Request Changes
• 🟡 建议修改 ------ 强烈建议改，但不阻塞
• 🟢 优化建议 ------ 锦上添花

举个例子，Compose 维度下的阻塞性问题包括：

- 在 composable 函数体内直接修改 MutableState / MutableStateFlow
- 在 Composition 中发起网络请求或数据库操作，未使用 LaunchedEffect
- 在 composable 中持有 Activity/Context 引用

这些是 Compose 开发中最容易踩的坑，如果 Agent 发现了，它会直接 Request Changes。

而像"使用 @Stable 注解标记自定义数据类以优化 recomposition 跳过"这种属于 Nice to Have，Agent 只会温和地建议。

第四步：配置工作流 ------ 让 Agent 学会用 gh CLI

Agent 怎么读 PR 内容呢？OpenClaw 的 Agent 可以执行 Shell 命令，所以我让它使用 GitHub 官方的 gh CLI。工作流在 SOUL.md 里定义得非常清晰：

1. gh pr view <PR_NUMBER> --repo <OWNER/REPO> --json title,body,files,state
2. gh pr diff <PR_NUMBER> --repo <OWNER/REPO>
3. 按 10 个维度分析代码变更
4. 在聊天中回复审查摘要
5. gh pr review <PR_NUMBER> --repo <OWNER/REPO> --body "<REVIEW>" --approve/--request-changes/--comment

通俗意义上的话来说，Agent 会先把 PR 的信息和 diff 全部读完，然后用 GLM 的超长上下文能力分析代码，最后同时做两件事：在聊天里给你一份中文摘要，在 GitHub 上提交一份英文 review。

第五步：输出格式 ------ 结构化审查报告

我对 Agent 的输出格式也做了严格定义，这样每次审查报告的结构都是一致的：

## PR 审查报告: <PR 标题>

**仓库**: owner/repo | **PR**: #123 | **变更**: +X / -Y

### 📋 概要
<1-2 句话总结>

### 🔴 阻塞性问题 (X 个)
- [ ] `file.kt:L42` --- [架构] 问题描述 + 修复建议

### 🟡 建议修改 (X 个)
- [ ] `file.kt:L18` --- [Compose] 问题描述

### 🟢 优化建议 (X 个)
- `file.kt:L55` --- [性能] 建议

### ✅ 亮点
<值得肯定的代码实践>

### 🏁 结论
APPROVE / REQUEST_CHANGES --- 理由

是不是看起来比"LGTM"专业多了😄

第六步：验证 ------ 跑起来看看效果

所有文件配置好之后，重启 Gateway：

openclaw gateway restart

然后确认 Agent 在线：

openclaw health
# 输出: Agents: main (default), pr-reviewer, writer, knowledge

使用方式也很简单：

# 命令行直接发 PR 链接
openclaw agent --agent pr-reviewer -m "https://github.com/owner/repo/pull/123"

# 或者进入交互式聊天
openclaw chat --agent pr-reviewer

当然，在使用之前别忘了先完成 gh CLI 的 GitHub 认证：

gh auth login

踩过的坑

在搭建过程中有几个值得注意的点分享给大家：

1. Node.js 版本问题 ：OpenClaw 的 Gateway 服务是通过 macOS 的 LaunchAgent 管理的，如果你用 nvm 切换过 Node.js 版本，LaunchAgent 里的路径可能指向旧版本导致启动失败。解决方法是更新 ~/Library/LaunchAgents/ai.openclaw.gateway.plist 里的路径。

2. MCP 插件方案行不通 ：一开始我尝试用 @modelcontextprotocol/server-github 作为 MCP 插件集成 GitHub API，但发现这个 npm 包并不是 OpenClaw 的原生插件格式，而且 OpenClaw 的 config 也不直接支持 mcp.servers 配置键。最终改用 gh CLI 方案，反而更简单可靠。

3. GLM 上下文优势：选择 GLM-4.7 的一个重要原因是它 204800 token 的上下文窗口。对于大型 PR（几十个文件变更），很多模型可能会截断 diff，而 GLM 可以把完整 diff 全部塞进去分析。

结尾

从安装到跑通整个流程大概花了半小时，但这半小时的投入可以省下未来无数个 Review 的时间。当然，AI Review 并不是要取代人工 Review，而是帮你先过一遍基础检查 ------ 架构合不合规、有没有安全漏洞、Compose 有没有性能雷区，这些机械性的检查让 Agent 来做，你就可以把精力集中在业务逻辑和设计决策上。

如果你也受够了积压的 PR 和敷衍的"LGTM"，不妨试试让一只龙虾帮你审代码🦞

谢谢观看😄