如果你们团队还在靠人肉翻PR那么接下来的内容值得你花十分钟看完。我个人把Hermes Agent引入到日常代码评审流程里有大半年了从最初的半信半疑到现在它已经成为合并代码前的一道必备关卡整个过程踩了不少坑也总结出了一套可以照搬的玩法。这篇文章就围绕Hermes做GitHub PR自动化审查这件事把方案设计、搭建步骤、提示词编写、常见坑点一次性讲清楚希望能给正在做同样尝试的人一些参考。1. 为什么要把PR审查交给机器1.1 人工审查的三个死穴先聊聊我在实际维护几个仓库过程中的感受。代码评审这件事理论上人人都知道重要但真到了执行层面问题特别多。第一个问题是响应速度。一个PR提上来如果刚好赶上大家下午都在写代码经常要等两三个小时才有人看。如果涉及跨时区协作那更糟一个PR挂一整天不合并是很正常的事。我印象很深的一次一个修复线上Bug的PR因为reviewer在开会硬是从上午11点等到了下午5点才被批准部署时间整整推迟了一个晚上。第二个问题是注意力分散。就算reviewer打开了PR页面他也很难保证全程专注。我自己就有体会看一个几百行的PR时经常会看到一半被IM消息打断回来之后不得不从头再看一遍。反复几次之后耐心就没了后面的代码基本上是在“扫”而不是在看一些夹在中间的不规范代码就这么混过去了。第三个问题是标准不稳定。人工审查很难保证每次的尺度完全一致。状态好的时候能揪出并发问题状态差的时候连明显的命名不规范都会漏掉。不同reviewer之间的风格差异就更大了有的人只关心功能逻辑有的人死盯命名风格结果就是PR的审查质量完全取决于“轮到谁看”。你会发现人工审查的三个死穴本质上都是资源问题专家时间有限、注意力有限、精力不稳定。而机器恰恰在这三点上都有天然优势——它不需要休息不会走神只要规则一致每一次审查的严格程度都完全相同。1.2 自动化评审不是一个“噱头”很多人一听“AI自动审PR”第一反应是“这玩意儿能替代人吗”。我的观点很直接它替代不了人但它能把80%的重复性、规则性工作吃掉让人把精力放在真正需要判断力的事情上。常规的静态检查工具比如ESLint、Checkstyle只能抓到语法、格式、明显的坏味道它们对“这个接口设计是否合理”、“这段逻辑是否在多线程下有问题”、“这个改动会不会影响另一个模块”这类需要理解上下文的问题毫无办法。LLM驱动的Agent就不一样了。它能把PR的diff、相关文件的内容、仓库的目录结构、甚至项目的历史提交信息都拉进来一起看然后以一个“有经验的工程师”的身份给出评估。它不是在做文本匹配而是在做一定程度的语义理解和逻辑推理。比如它能看出“这个函数加了锁但调用路径上已经有另一个锁可能造成死锁”也能指出“你改了A模块的接口但B模块里还有三个地方在用旧签名需要一起改”。我用Hermes跑了小半年它抓出的问题里有不少是人工review时确实漏掉的。所以我说这套东西不是玩具是能为团队真实省时间、提质量的生产力工具。2. Hermes Agent能干什么先把架构看懂2.1 Agent和普通CI脚本的本质区别在决定用Hermes之前我也考虑过自己写脚本调OpenAI API把PR的diff拉下来拼一个prompt然后拿返回结果去PR下面评论。这方案听着简单但实际写起来会撞上一堆墙diff太大导致token超限怎么办需要看相关文件内容的时候怎么优雅地拉取多个文件要不要拆分请求并行请求怎么管理这些问题的本质是代码评审不是一个单轮的“输入diff、输出评论”的过程而是需要按需获取上下文、多步推理、动态决策的复杂任务。脚本写出来是死板的线性流程而Agent的核心是一个循环——它先观察当前情况思考下一步该做什么读文件看commit历史检索代码然后执行动作再观察结果直到它认为信息足够了才给出最终结论。这个“思考-行动-观察”的循环就是ReAct范式。Hermes Agent内置了这套机制所以你不需要自己去设计调度逻辑只需要告诉它“你的目标是审查这个PR”它会自己去决定怎么完成。2.2 Hermes Agent的核心组成我用的Hermes AgentGitHub上的开源项目主要由几个部分组成Agent Core负责管理整个循环也就是上面说的ReAct逻辑。它调度所有的工具调用并在每轮调用之间维护一个“当前状态”的记忆。工具集Agent能干活的“手”。它可以调用Shell命令、读写文件、发起HTTP请求还能连接GitHub API、Slack、Notion等外部服务。做PR审查时捏得最死的是GitHub工具集。模型后端Agent的“大脑”。它不绑定某一家模型既能接OpenAI也能接DeepSeek、本地运行的Ollama模型等。这一块完全可以按预算和效果来选。规则/技能系统通过写Markdown形式的Skill文件来定义Agent在不同场景下的行为。比如你可以告诉它“遇到Go并发代码时重点检查哪几类问题”它会在实际审查时遵循这些指导。2.3 为什么选Hermes而不是自己写脚本我前面说了自己写脚本的复杂度这里再补充一个更关键的维度可维护性。团队里的代码风格不是一成不变的审查标准也会随项目阶段调整。脚本方案下每次想改审查策略都要改代码、重新部署。而Hermes这类Agent框架把“行为逻辑”和“执行引擎”解耦了修改审查规则只需要编辑对应的Skill文件或者提示词改完让Agent重载配置就行。另外Hermes本身就在持续迭代它的仓库里对GitHub集成的支持已经很成熟像PR评论、提交状态更新这些操作都有现成的工具方法不需要自己造轮子。注意我这里说的是我实际使用的Agent框架。如果你用的是别的Agent框架比如Hugging Face的Transformers Agents或者AutoGen思路也一样——重点是“循环工具模型”这三件套。3. 搭建一套可用的PR审查机器人3.1 环境准备Python环境与Hermes安装Hermes Agent官方推荐的安装方式是pip。不过我在装的时候踩了一个坑这里提前说建议在干净的虚拟环境里安装避免和系统Python包冲突。# 创建并激活虚拟环境 python3 -m venv ~/hermes-venv source ~/hermes-venv/bin/activate # 安装Hermes pip install hermes-agent # 验证安装 hermes --version我的环境是Ubuntu 22.04Python 3.10装的是当时最新的Hermes版本。如果你用的是macOS安装方式也一样只是虚拟环境的路径不同。Windows下建议用WSL2跑纯Windows PowerShell下跑Agent的话一些Shell类工具调用容易出问题我试过一次果断放弃了。安装完成后Hermes第一次初始化会创建配置目录默认在~/.hermes/里面会生成一个config.yml主配置文件和skills/子目录。这个目录结构后面会常用到先记住它。3.2 创建GitHub Token并配置权限要让Agent能读取PR、发表评论需要给它一个GitHub Personal Access Token。注意这个Token的权限配置是很关键的给多了有安全风险给少了Agent干活时会不断报403。我用的Token权限如下权限项值用途repo勾选Full control读取私有仓库代码、提交PR评论read:org勾选读取组织内部仓库信息workflow不需要不涉及Actions的写入创建好Token后把它配置到Hermes的环境变量中。我习惯在~/.bashrc里加一行export GITHUB_TOKENghp_你的token export GITHUB_REPO你的组织名/仓库名这里的GITHUB_REPO是可选的后面也可以在配置文件里指定但先设置好环境变量能省不少事。3.3 编辑config.yml接入模型API这一步是整个搭建过程中最关键的一环。Hermes需要一个LLM作为推理引擎我最初的方案是直接用OpenAI的API但跑了一个月下来成本确实有点吃不消——一个中等规模的PR评审大概要消耗1.5万到2万tokens仓库活跃的时候每天十几个PR账单蹭蹭往上涨。后来我把后端切到了DeepSeek成本直接降了一个量级。效果方面DeepSeek的代码理解能力对于评审场景完全够用尤其在中英文混合的PR描述、注释理解上表现得还很自然。如果你对模型能力要求极高保留OpenAI的GPT-4系列作为可选后端也未尝不可。配置方式很简单在config.yml里指定模型提供商和模型名llm: provider: deepseek model: deepseek-chat api_key: sk-你的DeepSeek密钥 temperature: 0.2temperature我建议设成0.2或更低。代码审查是个需要严谨性的场景温度太高会让模型“发挥过度”时不时编造一些不存在的问题出来温度太低则显得机械只做表面检查。0.2是我反复试下来比较平衡的值。3.4 配置GitHub工具集下一步是让Agent能真正操作GitHub。Hermes的GitHub工具集在配置里是作为一组Skill存在的需要在skills/目录下放一个github_skill.md之类的文件内容大致描述“你有能力执行以下GitHub操作拉取PR信息、查看diff、发表评论、更新审查状态”Agent会在需要时自动加载这个技能描述。实际配置中我建议把这些能力写进一个单独的文件然后给Agent一个总入口提示告诉它审查PR时该用哪个技能。直接上硬编码的方式写死会很笨拙Agent自己会去调用它觉得合适的工具。3.5 验证连接是否通畅配置完以后先跑一个最简单的指令验证Agent能正常连上GitHubhermes 请查看当前仓库最新PR的标题和作者如果Agent能正确返回PR信息说明Token、网络、工具集全部正常。这一步我强烈建议别跳过我折腾过一下午排查“Agent能说话但干不了活”的问题最后发现就是Token权限漏勾了。环境通了后面的流程才能顺下去。4. 从“能审”到“审得准”规则与提示词设计4.1 定义评审维度和输出模板Agent连上GitHub之后你让它“审一下PR”它确实能给出评论但一开始的效果大概率是不尽人意的——因为它不知道你的团队到底关心什么。这里必须做一件事把评审标准显式地告诉Agent。我参照团队Code Review规范给Hermes写了一套明确的评审维度放在系统提示词里维度关注点举例功能正确性逻辑是否完整边界条件有没有处理代码安全SQL注入、XSS、硬编码密钥、越权访问并发与性能锁使用是否正确有没有明显的O(n²)操作可维护性命名是否清晰有没有重复代码函数是否过长接口兼容性改动是否破坏其他调用方同时要求Agent的输出格式固定按“问题级别-文件-行号-问题描述-修改建议”五段式来写。格式固定的好处是便于人工扫读也方便后续接入自动化统计工具。4.2 写一份能落地的系统提示词这里我直接放一份自己用过且效果比较好的提示词你可以根据自己的项目情况改你是仓库的高级代码审查工程师。你的任务是审查给定的GitHub PR并输出结构化评论。 第一步阅读PR的标题、描述和变更文件列表理解本次改动意图。 第二步逐个查看关键文件的diff重点关注 - 新增的业务逻辑是否有边界条件遗漏 - 是否存在明显的安全问题注入、硬编码密钥、未授权访问 - 并发相关改动是否可能引入死锁、竞态条件 - 是否破坏已有接口的向后兼容性 第三步对于可疑的地方如果diff信息不足以判断请通过工具查看相关文件的完整内容或相关调用点。 第四步输出审查结论包含: 1. 总体评价1-2句话 2. 按严重程度分级Critical / Warning / Suggestion的问题列表 3. 每个问题给出精确的文件路径和行号并给出修改建议 注意 - 宁可漏报不要编造问题。没有充足依据的问题不要写进报告。 - 评论使用中文术语可保留英文原词。这个提示词有两个设计细节很有用一是明确要求“先读意图再读代码”避免Agent一上来就看diff看蒙了二是加了“宁可漏报不要编造”这一条大幅减少了误报率。4.3 不同语言类型的差异化审查默认的提示词是通用型的覆盖任何语言。但如果你的仓库是某一种特定语言为主我强烈建议在Skill里追加针对性的审查要点。比如我负责的一个后端服务是Go写的我会在Skill里加一段# Go语言重点检查项 - 检查error是否被吞掉err被忽略但应该处理的地方 - 检查goroutine的生命周期是否有泄漏可能select是否处理了ctx.Done - 检查锁的使用范围是否过大是否可能阻塞关键路径 - 检查slice/map的并发读写而另一个前端仓库是TypeScript/React重点就变成# TypeScript/React重点检查项 - 检查useEffect的依赖数组是否完整是否存在闭包陷阱 - 检查是否有不必要的useMemo/useCallback - 检查key属性是否稳定 - 检查样式类名是否有拼写不一致这事的本质是给Agent“喂”行业知识。模型本身就懂这些语言的最佳实践但你要明确告诉它“在这个仓库里哪些是容易出问题、需要重点盯的地方”它的审查才会贴合真实场景。4.4 审查策略与增量优化的思路一开始跑通后别急着一刀切全仓库强制启用。我的做法是先在两个非核心仓库里跑两周每周花半小时翻一遍Agent给的评论把“有明显问题”和“明显误报”的案例攒下来然后调整提示词和Skill内容。这样迭代几轮之后审查质量会稳定很多。对于非常大型的PR比如几百个文件那种建议给Hermes配置“增量审查”策略——只审查本PR变更涉及的文件和直接关联的调用点不展开全仓库扫描。全仓库扫描不仅慢而且容易跑偏。5. 实战让Hermes审查一个真实PR5.1 准备一个演示PR的内容理论讲完了看一个实际运行的例子。我特意构造了一个包含典型问题的PR来演示Hermes的审查效果。这个PR往一个电商后端服务里加了一个“批量查询订单状态”的接口代码大概长这样# order_service.py (新增) def batch_query_orders(order_ids: list[int]) - list[dict]: orders [] for oid in order_ids: order db.query_one( SELECT * FROM orders WHERE id %s, oid ) if order: orders.append(order) return orders一眼看去这个函数功能是实现了。但它同时存在至少三个潜在问题一是循环内查询数据库明显有N1问题二是用了字符串拼接的SQL方式虽然这里是%s参数化但如果是拼接就有注入风险三是没有对order_ids为空列表的情况做短路处理。5.2 Hermes实际执行审查的流程我把这个PR推上去之后用命令行触发了Hermeshermes 请审查PR #37把结论发到PR评论里它开始执行后我观察了它的执行日志大致流程是读取PR #37的元信息和diff识别出变更涉及order_service.py文件拉取该文件的完整内容发现batch_query_orders里的循环查询又进一步检查了调用方是怎么使用这个函数的最终组装评论并POST到PR下方整个过程大概花费40秒token消耗约9000。这个“拉取文件完整内容”和“检查调用方”的动作很有价值——如果只是看diff它只能停留在“代码风格”层面而拉取相关信息后它才能做出更贴近上下文的判断。5.3 Hermes给出的评审报告样本Hermes在PR下方的评论如下总体评价本次改动实现了批量查询功能但当前实现存在明显的性能隐患不建议直接合并。Criticalorder_service.py:18-22循环内逐条查询数据库存在N1查询问题。当order_ids数量较大时例如100个会产生100次数据库往返。建议改用WHERE id IN (...)一次查询或使用批量查询工具。Warningorder_service.py:20使用%s参数化是正确的但建议确认该函数只能接收内部信任的调用方参数。若未来被HTTP层直接调用order_ids中的异常值可能造成非预期查询。Suggestionorder_service.py:15当order_ids为空列表时函数仍会执行空循环并返回空列表。建议在函数入口提前判断并返回减少无意义调用。说实话第一次看到它给出这样质量的报告时我是有点惊讶的。这三条评论的命中率、准确度已经接近一个认真看代码的初级工程师的水平而它只用了40秒。5.4 人工复核与角色定位有一点必须说清楚不要无脑信任机器的审查结果。我现在的流程是Hermes先审一遍把报告挂在PR下面然后让负责这个模块的开发者也就是PR作者自己先看一遍机器评论能改的改掉觉得不合理的可以在评论下回复。最后合并前的正式review还是由真人来做。这个流程的核心价值在于真人reviewer不再需要花时间去看那些“低垂的果实”明显的性能问题、命名、遗漏处理可以把时间集中在架构设计、潜在的业务逻辑缺陷、以及机器难以判断的“设计合理性”上。团队的实际体验是一次人工评审的时间平均缩短了约30%而且评审质量没有下降。6. 常见问题与排障实录这大半年的使用过程中我积攒了不少问题排查经验挑几个典型且容易复现的写在这里。6.1 API限流与重试策略用第三方模型API做自动化任务首先要面对的就是限流。DeepSeek和OpenAI都有限流策略PR一多或者任务复杂时很容易触发429 Too Many Requests。我的处理方法是两层第一层是Agent框架层面的重试。在config.yml里把重试次数调大llm: max_retries: 5 retry_backoff: 3 # 指数退避基准秒第二层是任务排队。我给Hermes接了一个简单的队列脚本每次只允许一个评审任务运行避免同一时间发多个并发请求。6.2 Token过期与权限不足这是新手最容易踩的坑。几个特征性的报错报错401 Unauthorized——Token过期或直接不对报错403 Resource not accessible by personal access token——Token权限不够比如没勾repo范围有一次我排查了很久最后发现是当时创建Token时只勾了public_repo对私有仓库的评论权限就没有。这种情况只能回到GitHub设置里重新生成Token没有别的办法。建议把Token失效日期写在日历上GitHub的Token是可以设置过期时间的。我一开始为了方便设了永久有效后来安全策略要求改成90天结果忘记更新日期某个周六早上整个流水线瘫了教训深刻。6.3 PR描述过于简短导致评审方向跑偏实际使用中还会遇到一种情况PR的标题和描述写得太简单比如就写“fix bug”然后附一句话简介。这种信息量不足时Hermes很容易对改动的意图理解错误审查方向和实际需求对不上。我的解决办法是在提示词里加了一条规则——“如果PR描述信息不足无法明确理解改动意图则在评论开头明确标注‘本次改动的意图尚不明确建议补充PR描述’然后仍基于代码本身做有限度的检查。”6.4 模型输出格式不稳定的处理即便temperature设了0.2模型偶尔还是会输出非标准格式比如漏掉行号、没按Markdown格式输出、多了几句题外话。解析这种评论会有点烦。后来我干脆让Hermes的Skill里定义一个“评论模板文件”把所有评论按固定JSON结构输出然后由一个小脚本转成Markdown再发到PR。这样既统一了格式还方便把每次评审结果结构化入库后续可以做统计分析和趋势观察。7. 一些实操心得和扩展思路用Hermes做GitHub PR自动化审查这件事做到最后你会发现它带来的其实不只是一个“自动化工具”而是一套更健康的代码协作习惯。几个小体会第一审查标准显性化是最大的隐性收益。为了让Agent按照我们的标准审查团队必须把以前只可意会不可言传的code review规范写清楚。这套规则Agent在用新人也跟着学整个team的代码规范意识都提升了。第二Agent的误报本身也有价值。有时候它会给出一条看起来很离谱的建议比如指出某个函数的错误处理不一致你看了一眼觉得“这个函数就是故意这么设计的”但下意识会琢磨一下为什么Agent会这么判断。有一回就是因为一条“误报”我们认真讨论后发现那段代码确实对异常情况处理得不统一顺手就修了。机器的误报有时候是“提问”而不是“断言”能推动人去重新审视自己的假设。第三这个模式可以扩展。PR评审只是我使用Hermes的一个场景。同一条Agent链路改一下Skill就能做很多其他事每周自动生成仓库周报、检测依赖安全更新、为新PR自动打标签分类、生成变更日志CHANGELOG。我已经把“自动生成PR release notes”跑起来了效果也相当省时。如果你正准备在一个存量仓库里推这套流程我的建议是从小处开始先让Agent审查“新增代码”而非“存量代码”因为存量问题太多评论刷屏反而让开发者产生对抗情绪。先把新增代码的质量关卡守住再逐步扩大范围。自动化PR审查这个方向目前还处在快速迭代期。工具链会变模型会变但“把重复劳动交给机器、把时间留给判断”这个大方向我相信是没错的。希望这篇分享能帮你在自己的团队里少走一些弯路。