Hermes实战：用Agent智能体重构自动化代码审查流程

做代码评审这活儿，干了几年的人多少都有点矛盾心理。一方面它确实是质量保障里绕不开的一环，另一方面，每次打开 PR 列表看到几十个待审请求，尤其是那种改动 30 个文件、夹杂着格式化调整和逻辑修改的巨型 PR，心里是真的会咯噔一下。我一直在找一种方式，能把“人”从重复性的、低信息密度的审查劳动里解放出来，让工程师把精力集中在真正需要判断力的地方。最近把一套叫Hermes的自动化审查方案完整跑通了，接在 GitHub 的 PR 流程里当“第一道过滤器”，用了大概一个月，感觉值得专门写一篇复盘。

这玩意儿不是那种花架子式的“机器人评论员”——只会丢一句“LGTM”或者把 CI 日志复读一遍。Hermes 是一个可以自托管的 Agent 智能体，它会真正去读你的代码 diff，结合你仓库的上下文、历史提交记录和自定义规则，给出带严重级别、带修改建议、甚至带参考代码片段的审查意见。这篇文章我会从方案设计、部署配置、核心实现到问题排查，把整套实战路径完整过一遍，也会把我踩过的坑和调参思路一并分享，希望能给正在折腾自动化代码评审的同学一些参考。

1. 为什么我要把 PR 审查交给一个 Agent 去干

先说一个比较现实的问题：很多团队对自动化代码评审的印象还停留在“静态检查工具 + 门禁”的阶段。ESLint、Go Vet、SonarQube 这些工具确实能抓出一批低级错误，但它们的缺陷也很明显——它们不读业务逻辑，不理解改动意图，也看不出来“这个函数实现本身没毛病，但和隔壁模块的既有约定相冲突”这种问题。

1.1 人工审查的三大痛点

我统计过自己参与过的几个项目的审查数据，发现人工 PR 审查的低效主要来自三个方面。

第一是上下文切换成本过高。一个后端工程师白天可能要在三个仓库之间来回切，每个 PR 都需要重新熟悉相关模块的代码结构、历史决策和编码风格。这种成本在小团队里尤其致命，因为每个工程师基本都是一人多职。

第二是低质量评论淹没了关键问题。很多评论其实集中在“这里命名不太好”“建议抽个函数”“补个注释”这类颗粒度很细的观感类意见。不是说这些没用，而是当一次 review 里 80% 的信息都是这种“格式层面”的反馈时，作者真的很难注意到其中那个真正可能导致线上故障的逻辑漏洞。

第三是异步审查的等待成本。跨时区协作的时候，一个 PR 等关键 reviewer 看一眼可能要耗掉一整天。这还是在 reviewer 没有忘记的前提下。久而久之，大家就会养成“先合进去，后面再 refactor”的坏习惯，技术债就是这么滚起来的。

1.2 Hermes 的定位：它不是一个“评论机器人”

我在调研自动化评审方案的时候，先试过一些比较成熟的 SaaS 产品，比如 CodeRabbit 和 Sourcery，都还不错，但有两个绕不开的问题：一是代码仓库的数据要传到第三方服务，很多企业内部的安全策略不允许；二是自定义规则和提示词模板的灵活性受限，想深度绑定自己团队的技术规范会比较痛苦。

后来注意到 Hermes，是因为它提出了一个方向：“Code Review Copilot”，更符合 agent 的定位——你可以把它当作一个能“自己思考”的开发者，而不是一个只能触发预设规则的脚本。它执行任务的流程大致是这样的：

• 监听 GitHub 上的 PR 事件（opened、synchronize、labeled 等）；
• 根据事件类型拉取本次 PR 的元数据、diff、关联的 issue 或 commit 信息；
• 结合仓库的审查规则配置文件，把代码变更和项目规范一起丢给底层大模型；
• 让模型输出结构化的审查结果——包括问题定位、严重程度分级、修复建议乃至参考代码；
• 通过 GitHub App 或 GitHub Actions 回写到 PR 评论区，或者在 checks 中生成报告。

这里面最关键的设计是：规则是配置化的，模型是插件化的。你可以在配置里决定哪些文件必须严查、哪些文件可以跳过，也可以为每种错误类型设定不同的提示词模板。底层的模型可以是云端 API，也可以是自建的本地推理服务。这一点对我们的内网部署场景非常友好。

1.3 预期收益与实际效果

我给自己定的目标是：拿到一个 PR，10 秒内能判断“这事有没有人到场看过”。Hermes 接入后，效果超出了预期。现在团队里的 PR 流程基本变成这样：提交者 push 代码后，Hermes 会在两到三分钟内先出一轮基础意见，把格式类、明显逻辑问题、危险 API 调用这类内容都标注出来。剩下的时间里，人工 reviewer 只需要看高风险文件和 Hermes 拿不准的内容，效率提升了至少一半以上。

2. 整体方案设计与技术选型

在这一节我会把整个方案的架构拆开，说说为什么我最终选择了这种组合。

2.1 Hermes 的架构拆解：一条从 GitHub 到模型的链路

从部署者的视角看，Hermes 主要由四个部件构成：

• 事件接入层：承担 GitHub Webhook 接收和事件过滤的工作。你可以选择把 Hermes 跑成独立服务并注册为 GitHub App，也可以直接放进 GitHub Actions 的工作流里。
• 核心调度器（Agent Core）：负责编排整个审查任务的执行顺序——拉取数据、调用模型、数据后处理、上报结果。它同时也是规则解析器，决定哪些文件触发哪个审查策略。
• 模型接入层：统一了 OpenAI、Anthropic、DeepSeek、本地 Ollama 等推理后端的接口。这里说的 DeepSeek 是因为我们自己测试时发现它对代码理解的中文语境支持比较友好，如果你团队主要用英文写注释，也可以用其他模型。
• 结果回写层：把审查结果转换成 GitHub PR Review Comment 或 Check Run 的格式，并管理去重和限流。

这四个部分打包在同一个进程里，部署时只需要配置好环境变量和一份 YAML 规则文件。相比需要搭一堆微服务的方案，这种单体应用对中小团队更友好。

2.2 部署形态选择：独立服务还是 GitHub Actions

我先把两种主流形态的利弊说清楚，再做选择。

独立服务（GitHub App 模式）

• 优点：可以常驻后台，响应及时，支持长时间运行的异步任务；可以维护仓库级的状态，比如记住哪些文件以前已经被标记过 warning，不重复上报；支持更细粒度的权限控制。
• 缺点：需要一台能稳定访问 GitHub 的服务器，并配置 HTTPS 证书和 Webhook 路由；运维成本确实存在。

GitHub Actions 模式

• 优点：零服务器成本，直接复用 GitHub 托管的运行环境；每次 PR 事件触发一次工作流，天然隔离；权限模型由 Actions 的 token 控制，相对简单。
• 缺点：执行时间受限于 Actions 的时限；无法维护持久化的运行状态；如果并发 PR 较多，会消耗大量 Actions 额度。

我一开始先用 Actions 模式做了 POC（概念验证），发现效果不错，但后来因为团队内部有代码不出内网的要求，就把 Hermes 迁到了独立部署的形态。如果你是个人项目或者是团队没有严格安全限制的场景，我建议直接用 Actions 起步，省去自己维护服务的麻烦。

2.3 为什么选择 Hermes 而不是自己写脚本

肯定有人会问：这需求听起来也不复杂，用 GitHub API 取 diff 再调大模型接口，几百行代码就能搞定，为什么要用 Hermes？

我的回答是：前 80% 的功能确实这么简单，但后面的 20% 才是真麻烦。比如：

• 怎么在超大 diff（超过模型上下文窗口）中做增量切分，同时保证片段之间的逻辑连贯性？
• 怎么避免模型对同一文件的重复报错，做完一次 review 后如何记录状态？
• 怎么设计提示词模板，让模型既能给出具体建议，又不至于过度自信地“大改特改”？
• 怎么处理 GitHub API 的限流与评论的幂等性？

这些问题不是不能自己解决，而是要花大量时间去打磨。Hermes 的好处在于它把这些工程问题都沉淀成了配置项，让我这种“只需要写好规则”的用户少走了很多弯路。

2.4 动手前的准备工作清单

在正式部署之前，我建议你把以下东西准备好：

• 一台能访问 GitHub 的服务器（最低 2C4G 即可，因为 Hermes 本身占用不高，真正的压力在模型 API）；
• 一个 GitHub App 的注册权限（或者选择 Actions 模式则不需要）；
• 一个模型 API Key（OpenAI / DeepSeek / Anthropic 都行，本地推理则要准备 GPU 或足够强的 CPU）；
• 仓库的编码规范文件，或者至少一份你自己平时 review 时常用的检查清单；
• 一个测试用的仓库，别直接在生产仓库上调试，血的教训。

3. 实操部署与配置全流程

接下来进入正题，我会把独立部署形态下从零到一跑通 Hermes 的完整过程写下来。

3.1 安装 Hermes Agent

Hermes 官方提供了两种安装方式：一种是直接拉 Docker 镜像运行，一种是用 Python 的安装包跑。我推荐 Docker 方式，因为环境隔离干净，升级也方便。

docker pull hermesreview/hermes-agent:latest mkdir -p /opt/hermes/{config,data,logs} docker run -d \ --name hermes-agent \ -p 8080:8080 \ -v /opt/hermes/config:/app/config \ -v /opt/hermes/data:/app/data \ -v /opt/hermes/logs:/app/logs \ -e HERMES_LOG_LEVEL=info \ -e HERMES_MODEL_PROVIDER=deepseek \ -e HERMES_MODEL_NAME=deepseek-coder \ -e HERMES_API_KEY=your_model_api_key_here \ --restart unless-stopped \ hermesreview/hermes-agent:latest

这里几个环境变量说明一下：

• HERMES_MODEL_PROVIDER：模型提供方。我用的是 DeepSeek，因为它在代码 diff 理解方面表现比较稳定，而且对中文注释的识别也不错。如果你用 OpenAI 就写openai，用 Anthropic 就写anthropic，用本地 Ollama 就写ollama。
• HERMES_MODEL_NAME：具体的模型名。比如 DeepSeek 用deepseek-coder，OpenAI 用gpt-4o-mini也行，看你对成本和效果的权衡。
• HERMES_API_KEY：模型提供方的 API Key，注意别写进 docker-compose 文件里直接提交到 Git。

启动完成后，先用docker logs -f hermes-agent确认日志里没有报错，再进入下一步。

3.2 配置 GitHub 接入

独立服务模式下，我们需要在 GitHub 上注册一个自己的 GitHub App（不是 OAuth App），过程比较繁琐但对后续权限管理很重要。

在 GitHub 的 Settings -> Developer settings -> GitHub Apps 里点 New GitHub App，关键配置项如下：

• GitHub App name：全局唯一，建议用hermes-review-bot这种一眼能看懂的名字；
• Webhook URL：填你部署服务器的地址，比如https://review.example.com/webhook；
• Webhook secret：先生成一个随机字符串，后面配置 Hermes 时会用到；
• Permissions：至少需要Pull requests: Read & write、Checks: Read & write、Issues: Read & write、Metadata: Read-only；
• Subscribe to events：勾选Pull request和Pull request review。

注册完成后，GitHub 会给你生成一份App ID和一份Private Key（.pem 文件）。把 Private Key 下载到服务器/opt/hermes/config/目录下，然后在 Hermes 的配置文件里指定这些信息。

Hermes 的主配置是/opt/hermes/config/config.yaml，我贴一个精简版：

server: host: 0.0.0.0 port: 8080 github: app_id: 123456 private_key_path: /app/config/hermes-review-bot.private-key.pem webhook_secret: your_webhook_secret_here installation_id: 987654321 model: provider: deepseek model_name: deepseek-coder api_key: ${HERMES_API_KEY} temperature: 0.2 max_tokens: 4096 review: enabled: true min_diff_lines: 1 max_files_per_run: 50 ignore_paths: - "*.lock" - "package-lock.json" - "pnpm-lock.yaml" - "dist/**" - "build/**"

installation_id这个怎么拿？GitHub App 安装到你所在的仓库或组织之后，在仓库的 Settings -> Integrations 里能看到一个 Install 状态，点击 Configure 或者通过 API 可以查到具体的安装 ID。我当时第一次没配这个值，结果 Webhook 收到了但 Hermes 拉着不到仓库数据，排查了半天才发现是权限没对上。

3.3 初始化项目级审查规则

这是整个配置里最核心的部分。Hermes 的规则设计思路是“文件夹级策略 + 文件通配符”，也就是说你可以针对不同目录的代码行为定义完全不同的审查重点。

比如我的测试仓库里同时有 Python 后端和 React 前端，这两个目录的审查关注点肯定不一样。我会在仓库根目录放一份.hermes/config.yaml，部分内容如下：

rules: - name: python-backend-security paths: - "backend/**/*.py" severity: high checks: - "检查是否存在 SQL 注入风险，特别是使用字符串拼接 SQL 的地方" - "检查敏感信息是否被硬编码，如密钥、密码、token" - "检查异常处理是否合理，是否吞掉了关键异常" model_context: - "后端使用 Django 框架，ORM 默认参数化查询" - "敏感配置必须通过环境变量注入，禁止写在代码里" - name: frontend-performance paths: - "frontend/src/**/*.{ts,tsx}" severity: medium checks: - "检查是否存在不必要的 re-render，比如 useCallback/useMemo 的依赖项是否准确" - "检查组件拆分是否合理，单个组件是否过于臃肿" - "检查 API 调用是否有竞态问题" model_context: - "前端使用 React 18 + TypeScript" - "组件库使用 Ant Design 5" - name: general-code-quality paths: - "**/*" severity: low checks: - "检查明显的命名不规范问题" - "检查是否有调试代码残留，如 console.log、debugger" - "检查是否有重复代码片段可以抽取"

注意到model_context这个字段了吗？这是我觉得 Hermes 最聪明的设计——它允许你把仓库级的知识沉淀成上下文片段，在每次审查时注入到模型提示词里。比如后端那条规则里的“敏感配置必须通过环境变量注入”，光靠模型自己猜是猜不出来的，这就是项目约定和通用知识的差异所在。

规则配置好之后，还需要在 GitHub Actions（或 Hermes 的 webhook 配置里）启用仓库级规则读取。如果使用 Actions 模式，需要在工作流里加一个 checkout 步骤来拉取包含.hermes/config.yaml的分支。

3.4 接入 GitHub Actions 触发审查

虽然我的最终形态是独立服务，但在开发调试阶段我还是先用了 GitHub Actions 来跑通端到端流程。这里也贴一下我的 workflow 配置，给大家一个参考。

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

name: Hermes Code Review on: pull_request: types: [opened, synchronize, reopened] pull_request_review_comment: types: [created] permissions: contents: read pull-requests: write checks: write jobs: hermes-review: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0 - name: Run Hermes Review uses: hermesreview/action@main with: github_token: ${{ secrets.GITHUB_TOKEN }} model_provider: deepseek model_name: deepseek-coder api_key: ${{ secrets.DEEPSEEK_API_KEY }} config_path: .hermes/config.yaml comment_mode: inline min_severity: medium

关键点说明：

• comment_mode: inline表示审查意见以逐行评论的形式附加到具体代码行上。如果你觉得太吵，可以改成summary，只输出一个总评。
• min_severity: medium表示只有中等级别以上的问题才会被当成评论上报，低级别的只出现在检查报告的日志里。
• fetch-depth: 0很重要，它确保克隆的是完整历史代码，Hermes 才能正确对比分支之间的差异。如果只拉浅层克隆，diff 信息可能不完整，审查效果会大打折扣。

我一开始踩的第一个坑就是没设置这个 fetch-depth，结果 Hermes 对新增文件的识别完全错乱，以为每个文件都是全部重写，报了一堆不存在的“重复代码”问题。后来看了官方文档才发现是这个参数的问题。

3.5 端到端验证：跑一个真实的 PR

配置完成后，我来做一次完整的验证。打开测试仓库，创建一个新分支，故意埋几个典型问题：

• 一段拼接 SQL 的代码，直接把用户输入拼进去；
• 一个 React 组件的 useEffect 里遗漏了依赖；
• 一个硬编码的数据库密码。

提交并创建 PR 后，观察三个地方：

1. Hermes 的日志（或 Actions 的日志），确认 Webhook 被正确接收、diff 被正确拉取；
2. 模型 API 的调用记录，确认请求参数和响应时长；
3. 最终 PR 页面的评论，确认审查意见是否按预期上报。

实际测试结果大致长这样（我简化了原文）：

High:backend/api/user.py, line 42— 检测到 SQL 拼接风险。当前代码将user_input直接放入 SQL 字符串，存在注入风险。建议改用 ORM 的查询构造器或参数化查询：

# 不建议 cursor.execute(f"SELECT * FROM users WHERE name = '{user_input}'") # 建议 cursor.execute("SELECT * FROM users WHERE name = %s", (user_input,))

Medium:frontend/src/components/List.tsx, line 18— useEffect 缺少fetchData依赖，可能导致闭包捕获过期数据。建议：

useEffect(() => { fetchData(); }, [fetchData]);

这条 High 和这条 Medium 都命中了我的预期。最让我惊讶的是，它给出的修复代码是符合项目当前的框架写法的，不是套模板式的空泛建议。

4. 审查策略与报告设计的核心经验

工具跑通之后，真正让它“好用”而不是“能用”的，是后面这一层调优工作。

4.1 严重级别分级与上报策略

我建议所有问题都必须有严重级别，并且上报策略要遵循“宁缺毋滥”的原则。最理想的状态是：每条评论都值得读，每条评论都允许被忽略但值得思考。

默认的严重级别建议分为三档：

设定min_severity时，起步阶段建议设为medium，跑两周后再根据团队反馈决定是否上调或下调。一开始就开low的话，PR 评论会炸锅，团队很快会养成“忽略 Hermes 评论”的习惯，那就废了。

4.2 Prompt 模板的写法：让它更像“同事”而不是“杠精”

模型输出的风格其实很大程度取决于你怎么写 check 描述。我试过两种写法，效果差异明显。

第一种，比较抽象的写法：

检查代码质量，发现问题就指出

这种写法会让模型变成“杠精之王”，什么问题都能给你挑出来，还包括许多“感觉这样写不够优雅”的主观意见。

第二种，我在生产中使用的写法：

你是一名资深工程师，正在对一个 Python 后端的 PR 做代码评审。当前项目使用 Django 框架，数据库操作必须走 ORM 参数化查询。请重点检查以下内容：

1. SQL 注入风险，特别是字符串拼接查询
2. 硬编码的密钥、密码、token
3. 异常是否被吞掉或者 catch 后无日志
4. 逻辑分支是否覆盖边界输入（如空列表、None 值）

输出格式要求：每个问题包含三部分：问题代码的具体位置、问题描述、修复建议。修复建议需要给出实际的代码片段，不要空泛地说“请使用参数化查询”，而是直接给出改好的代码。

注意这里的关键在于给模型注入两个层面的信息：项目背景知识（用的什么框架、什么规范）和输出结构约束（要什么样的反馈格式）。背景知识是模型说对话的基石，输出约束是确保结果“可用”的保障。两者缺一不可。

4.3 结果回写与通知机制的优化

Hermes 支持将审查报告以 Check Run 的形式呈现。相比直接在评论区刷一堆评论，我发现 Check Run 更适合做“门禁”，因为 GitHub 的 Branch Protection 规则可以直接引用 Check Run 的状态。也就是说，你可以在分支保护规则里要求hermes-review这个 check 通过后才能合并 PR，从而强制保证高风险问题必须先被处理。

我当时的配置是：High 级别问题存在时，Check Run 标记为action_required状态；Medium 及以下只标记为neutral。这样一来，CI 不会因为低质量意见阻塞合并，但真正严重的问题绝对无法悄悄溜走。

同时，比较适合人工关注的渠道还是评论。如果 Hermes 在 PR 里发现了 High 级别的问题，它除了在评论区发消息之外，还可以通过 GitHub App 的 webhook 转发到团队的 IM 工具（比如飞书、钉钉、企业微信），让对应模块的负责人能立刻收到提醒。这个我在使用中感觉非常有用，因为不是所有人都会一直盯着 GitHub 的通知。

5. 实际运行中踩过的坑与排查技巧

工具运行得好好的，不代表你不会遇到问题。我罗列几个我印象深刻的坑，给大家提供排查思路。

5.1 GitHub API 限流与重试机制

独立服务模式下，Hermes 需要调用 GitHub API 拉取 PR 元数据和 diff。当一个仓库短时间内有大量 PR 并发时，很容易触发 GitHub API 的限流（默认是每小时 5000 次请求，但按 App 的安装维度可能会低一些）。

我遇到的典型现象是：PR 已经推上去了，但 Hermes 迟迟不出现评论，日志里一堆403 rate limit exceeded。排查思路是：

• 检查 Hermes 日志里有没有 HTTP 403 响应；
• 在 GitHub App 的设置里看 API 使用量是否已经打满；
• 如果确实打满了，优化方向是减少每秒请求数，或者开启 Hermes 内置的 rate limit 自动退避设置。

YAML 里可以这样配置：

github: api: retry_times: 3 retry_after_seconds: 10 max_concurrent_requests: 4

我把并发请求数从默认的 10 降到 4 之后，限流问题几乎没再出现过。

5.2 模型误报率高企的三个根源

误报率高了，团队信任度就没了。我遇到过三种典型的误报场景。

一是上下文窗口不足导致的“断章取义”。当 PR 改动非常大，diff 被切分成多段喂给模型时，模型可能只看了一部分代码就下了结论。解决办法是调整max_files_per_run，大 PR 拆成多次小任务处理，或者在规则里对特定目录设置“必须跳过上下文截断”的标记。

二是模型对旧代码的“怒气迁移”。假设一个文件本来就有历史遗留问题，但这次 PR 只改了一行。模型在审查时可能把历史问题也翻出来报一遍。解决方式是在规则里加一条only_changed_lines: true，让 Hermes 只上报本次 diff 中实际修改的行的问题。

三是项目约定没写进配置。模型不知道你们团队对某个 lib 的使用规范，自然会出现“建议用 A 但项目里全是 B 的写法”这种尴尬评论。这不是模型笨，是你背景知识没喂够。优化方向是持续维护model_context字段，把它当作一份活的团队约定文档。

5.3 超大 PR 导致的分析超时

有一次同事往测试仓库里推了一个 6000 多行的“重构型”PR，Hermes 处理了很久也没出来评论。我去看日志，发现模型 API 调用超时了。原因是 Diff 太大，超过了单次模型请求的上下文窗口。

Hermes 对此有内置的 diff 切分机制，但切分策略默认是“按文件切分”，对于超大文件未必有效。后来我调整为“按 hunk 切分”，并给模型设置了一个max_tokens的上限。效果比较明显，虽然会出现跨片段的问题遗漏，但至少不会整个任务卡死。

如果你想提高大 PR 的覆盖率，可以在规则里单独对超大文件设置一条精简审查策略，只检查高风险类别（安全、逻辑、性能），跳过风格类检查。

5.4 分支过期导致的“伪冲突”与评论错位

这个坑挺隐蔽的。当 PR 分支落后于目标分支很多 commit 时，GitHub 会显示“This branch has conflicts”，Hermes 拉取的 diff 未必是 PR 最终合并后的结果。有时候它评论的是一个已经在新分支里被删除的代码行，这在 Git 的 context 对不上的时候尤其明显。

我当时的处理策略是：在触发审查前先让仓库 CI 执行一遍git merge-base相关操作，把分支 rebase 或 merge 到最新目标分支，然后再触发 Hermes 审查。如果你的 CI 有类似流程，建议把 Hermes 触发放在 rebase 之后，而不是在 PR 刚刚发起时。

注意：如果有多个开发者同时在一个 PR 上协作，rebase 操作本身也可能造成互相覆盖，这种场景下更适合让 Hermes 在synchronize事件触发时自动重新审查，而不是手动触发一次就完事。

6. 进阶优化：让 Hermes 更懂你的团队

到这一步，Hermes 已经能稳定工作了。但如果只是停在“能跑”的层面，说实话挺浪费的。我再分享几个我觉得性价比很高的进阶玩法。

6.1 多模型路由：按费用与效果动态选择

我们内部会有两类改动：一类是紧急 hotfix，需要快速给出审查意见；另一类是大规模重构，需要更深入的分析。

Hermes 支持按规则指定模型，比如在规则里加一个model_override字段：

rules: - name: hotfix-quick-review paths: - "hotfix/**/*" model_override: provider: openai model_name: gpt-4o-mini temperature: 0

这样 hotfix 目录下的 PR 会走轻量模型，审查速度快、费用低；而重构型 PR 可以默认走更强的大模型，多花点钱也无所谓。这就像团队里既有“快速看一眼”的新手，也有“逐行抠细节”的资深评审，各司其职。

6.2 构建仓库知识库：让模型记住历史决策

我有一个比较土的方案，但实测效果很好：在.hermes/config.yaml后面维护一个knowledge_base字段，存放那些经常被问到的项目决策记录。比如：

knowledge_base: - question: "为什么这个项目不用 TypeScript 的 enum？" answer: "团队约定使用字符串字面量联合类型，避免 enum 编译后的额外代码开销。审查时不要建议引入 enum。" - question: "数据库迁移文件需要人工 review 吗？" answer: "需要，重点检查是否包含不可逆的改动。建议在描述中注明回滚方案。"

这些内容会作为上下文片段注入每次审查的提示词中。一开始需要手动维护，但跑一段时间后，你可以定期把高频误报问题和团队答复整理进去，形成“越用越准”的正循环。

6.3 扩展到更多场景：不止 PR 审查

Hermes 的事件监听机制其实不限于 PR 审查。你可以通过配置增加其他工作流，比如：

• Issue 自动分类：当有新 issue 提交时，Hermes 自动阅读内容并打上标签、指派负责人；
• Commit Message 规范检查：在 push 事件上检查提交信息是否符合 Conventional Commits 规范；
• ** docs 自动校对**：当 Markdown 文档目录有改动时，自动检查文档里的代码示例是否和实际 API 一致。

这些扩展并不复杂，核心思路都是把“读取事件 -> 调模型 -> 输出结构化结果”这个链路复用到不同场景。我目前只接入了前两种，后续准备在文档审查上也跑起来。

7. 最后的个人经验与建议

整套 Hermes 方案跑下来，我最真实的感受是：它不会取代代码评审者，但会迫使你重新审视代码评审这件事的本质。以前很多人的评审习惯是“打开 PR 从头到尾看一遍，想到什么说什么”，这种模式效率低，而且依赖个人的临场状态。有了 Hermes 之后，我反而会更认真地思考：哪些检查项是值得自动化的，哪些判断必须留给人类？团队的知识沉淀应该怎么表达成模型能理解的语言？

如果你准备在自己的项目里尝试，我有几个具体建议：第一，一开始别追求大而全，找一个小而精的仓库先试点，规则控制在 5 条以内，跑通之后再慢慢加；第二，认真对待每一条被模型误报的问题，把它当成 Kubernetes 的日志去看，高频误报一般说明你的规则描述有不明确的地方，值得花时间去修改配置；第三，给团队留一个“关闭 Hermes 评论”的机制，比如标题里带[skip-review]就跳过审查，让开发者有控制感，而不是觉得自己被机器盯着。

自动化代码评审不是终点，它只是把代码评审的门槛降低了、覆盖面扩大了。真正有价值的，还是在这个过程中，你对你团队的技术规范、常见错误和好代码标准有了更清晰的定义。如果你也正在类似的路上折腾，希望这篇文章能帮你少踩几个坑。