组里PR越来越多之后不知道你们有没有一种感觉代码评审正在从“质量保障”慢慢变成“流程负担”。早上打开GitHub挂着十几个待review的PR每一条都要点开diff从头看到尾忙起来根本没时间细看只能粗略扫一眼就点Approve。可真正的问题往往不是评审人水平不行而是人的精力就那么多让一个后端开发连续看五六个PR之后后面几个基本就是走马观花。后来我把Hermes这类自动化代码评审agent接入到GitHub的PR流程里让机器先把低级问题、边界缺陷、安全隐患过滤掉再让人类评审专注于架构和业务逻辑整套流程才顺起来。这篇文章就以“Hermes”这个自动化代码评审agent项目为例讲讲它到底怎么工作、怎么接入GitHub的PR流程、配置里有哪些关键参数以及我在实际部署和使用中踩过的坑。如果你也想给团队的PR流程配一个“机器人评审员”这篇文章可以直接照着抄作业。1. 代码评审自动化Hermes解决的真实痛点1.1 人肉评审越来越不靠谱的过程代码评审最大的问题不是“没人看”而是“人看得不够准”。一个中型团队每天产生十几个PR很常见每个PR涉及几十个文件的改动跨语言、跨模块、还牵扯业务上下文。指望每个评审人都对所有代码了如指掌本来就不现实。我在好几个项目里观察下来人肉评审的质量曲线基本上是“前两个PR认真看中间的凭经验扫后面的直接LGTM”。这个锅不该让开发者背PR数量超过精力上限之后质量下降是必然结果。还有个更隐蔽的问题评审标准不一致。同一个项目的代码规范每个人理解都不一样。有人care命名有人care异常处理有人只关心自己的模块有没有被改坏。于是同一个PR有人Approve、有人Request Changes最后review feedback全靠PR作者运气。规则一直在那里但执行完全靠人人和人的神经敏感度差太多了。1.2 机器评审和人工评审的边界在哪里Hermes这类工具能做什么我先说清楚边界免得大家抱着不切实际的期待。它擅长处理的是可以被规则和上下文推断覆盖的问题明显的空指针风险、数组越界、资源未释放、错误处理缺失、危险函数调用、硬编码密钥、单测覆盖明显不足、代码风格偏离团队规范、重复代码等。这类问题本质上有迹可循大模型加上静态分析工具可以判断得比较稳。它做不到的是替人做产品决策和架构权衡比如“这个模块到底该不该拆成微服务”、“新方案和现有业务模型的兼容性该怎么取舍”这些需要业务上下文和长期项目经验机器读了diff也给不了靠谱答案。所以我把Hermes定位成“前置过滤器”而不是“终结评审者”——它先把60%的常规问题拦下来人类评审专家只需要集中精力看剩下的核心争议点。这比指望机器完全代替人类评审靠谱得多。1.3 Hermes项目的角色定位Hermes本质上是一个跑在服务端的自动化代码审查agent。它把自己挂在GitHub仓库上监听Pull Request相关事件每次有PR创建或更新的时候把这次的代码diff拉下来交给规则引擎和大模型一起分析然后把审查意见以评论、review summary、check run的形式回写到PR页面上。这样做的好处是所有动作都发生在PR界面里开发者不用切到别的平台就能看到机器人的意见。和传统的静态检查工具比如ESLint、SonarQube最大的区别是Hermes背后接了大模型能用自然语言理解代码的“意图”。传统的lint只能查格式和已知模式而Hermes能针对一段代码的逻辑缺陷说出“这里如果用户传入空数组会导致后续遍历越界”这个粒度完全不一样。2. Hermes的核心工作流程拆解2.1 一个PR从创建到审查完成的完整链路要理解Hermes的配置先得弄明白它处理一个PR时到底做了什么。我在部署前把这条链路完整梳理了一遍按顺序大概是这样的PR事件触发。有人创建PR或者push新的commit到已有PRGitHub把webhook事件推给Hermes服务或者Hermes通过轮询/定时任务的方式从GitHub API拉取状态变化的PR。获取并解析diff。Hermes调用GitHub REST API获取这个PR的.diff或.patch文件按文件解析出新增行、删除行和上下文行。这里有个很多AI评审工具忽略的点分析的范围应聚焦在“变更行”而不是整个文件否则大模型读的文件内容太多容易产生无关评论而且消耗的token量巨大。语言识别与规则匹配。按文件扩展名判断语言类型匹配对应的规则集。比如Python仓库重点检查异常处理、资源释放TypeScript重点检查类型安全、可选链使用Go重点检查错误返回和并发安全。静态分析前置处理。Hermes会先跑一轮基于AST的静态检查把能确定的问题直接提取出来这些问题不需要大模型判断速度快、准确率高。大模型深度分析。把代码diff片段、相关文件上下文、规则集、团队规范描述一起组装成prompt发给配置好的LLM服务OpenAI兼容接口都可以目前社区里比较多见的是接通用国产大模型或自建服务。大模型返回的分析结果是结构化的一般包含问题级别、文件位置、问题描述、修改建议代码。信息聚合与去重。把静态检查结果和大模型的结果合并同类型问题做归类整理同一文件重复报的问题只保留信息最全的一次。审查结果汇报。把最终结果以三种形式回写直接在PR的diff里对特定行发inline评论、在PR页面上提供一个汇总review summary、把conslusion写到commit的check run里作为CI状态的一部分。这七步里最容易被忽略的是第3步和第6步。没有规则匹配会拿到一堆不符合上下文的废话评论没有去重哪怕是同一个变量名在3个位置出现拼写问题机器人也会逐条刷屏开发者体验非常差。一个“好用”的Hermes部署例子里去重和分级这两层过滤是绝对少不了的。2.2 为什么选择“事件驱动”而不是“定时全量扫描”Hermes的接入形态有两种思路一种是在GitHub上安装一个App让它订阅pull_request事件实时响应另一种是起一个定时任务每隔几分钟扫一次未评审的PR。实际团队使用中我强烈建议用事件驱动。原因是评审及时性问题。代码评审的价值高度依赖“时间窗口”——PR刚提交的时候作者对代码的上下文记忆最清晰这时候给出review意见改起来的成本最低。如果等到定时扫描跑到才给反馈作者可能已经切去开发别的功能了回来再改这个PR光恢复上下文就要花不少时间。事件驱动的模式能做到“PR一更新机器人秒回评论”体验和真人评审基本同步。好在现在GitHub Actions天然支持事件触发的方式Hermes服务端只需要提供可调用的接口由workflow在pull_request事件时触发HTTP请求即可。这样你不用自己搭建常驻服务去接收webhook直接用GitHub的托管Runner跑流程运维成本低了很多。3. Hermes部署的完整实操从零到接入第一个PR3.1 部署前需要准备的东西Hermes的典型部署方式是“一个轻量级服务 LLM API GitHub凭证”。我先列一下全套清单然后逐项说每个组件的用途和选型建议运行时环境目前社区版本主要支持Node.js 18和Python 3.10。如果只是本地测试装好对应运行时就行如果放到服务器上长期跑建议用Docker方式部署它会把运行时依赖、配置文件、prompt模板都打进镜像里升级方便。一个大模型APIHermes不捆绑模型通过OpenAI兼容接口连接。你可以用GPT系列、Claude、DeepSeek或者其他任何提供OpenAI兼容API的服务。这个配置只影响审查质量不影响工具流程。GitHub Token或者GitHub App凭证用于读取PR内容和回写评审。如果是个人仓库测试直接用Fine-grained personal access token勾选Pull requests: Read and write和Contents: Read两个权限即可。如果是团队仓库强烈建议注册一个专用的GitHub App这样权限粒度更清晰也方便按仓库授权。Redis或数据库可选Hermes本身如果要做跨PR的重复问题检测比如同一个文件在最近的PR里刚刚提过同样的问题这次就不重复报了需要一个存储来记历史。小团队刚上手阶段可以先用SQLite跑得挺稳。3.2 CLI本地运行最快看到效果的方式我不建议团队一上来就把Hermes接到全仓库的CI上第一步应该是在本地跑起来先看看机器人对你代码的评审质量再决定要不要全量接入。Hermes提供了一套CLI命令最常用的是review。# 安装Hermes CLI假设项目支持npm全局安装 npm install -g hermes/cli # 登录配置GitHub Token和模型API Key hermes auth login --github-token ghp_xxx --llm-api-key sk-xxx # 指定目标仓库和PR编号执行一次本地评审 hermes review --repo owner/my-repo --pr 123执行完这个命令之后Hermes会在终端输出本次的分析摘要比如发现了几个错误级别问题、几个建议、分别在哪些文件的哪一行。确认输出质量符合预期之后再加--post参数把结果写到PR评论里。hermes review --repo owner/my-repo --pr 123 --post这里有个细节要注意本地执行时Hermes是用你当前登录的账号去发评论的所以评论作者会显示成你的账号而不是机器人账号。要解决这个问题得注册一个专门的GitHub账号或者GitHub App当作“机器人身份”。我建议从第一天就准备一个独立的账号不然后面审查记录里到处混着个人账号的消息很不好清理。3.3 用Docker部署常驻服务本地跑通了CLI之后就要把它升级成“团队公共设施”。服务器上用Docker部署的方式大致是这样把Hermes的代码仓库clone到服务器构建镜像然后把API key、GitHub凭证、模型endpoint作为环境变量传进去。git clone https://github.com/hermes-review/hermes.git cd hermes docker build -t hermes-review . # 创建配置文件目录准备挂载配置 mkdir -p /etc/hermes cp config.example.yml /etc/hermes/config.yml # 启动Hermes服务 docker run -d \ --name hermes \ -p 8080:8080 \ -e GITHUB_TOKENghp_xxx \ -e LLM_API_KEYsk-xxx \ -e LLM_BASE_URLhttps://api.your-llm-service.com/v1 \ -e LLM_MODELdeepseek-chat \ -v /etc/hermes/config.yml:/app/config.yml \ hermes-review启动之后Hermes服务默认会在8080端口监听GitHub的webhook事件。接下来去GitHub仓库的Settings - Webhooks页面新增一个webhookPayload URL填http://你的服务器地址:8080/webhook/githubContent type选application/json事件只勾选Pull requests即可。我可以直接说自己第一次配置webhook的时候漏掉了最重要的一步Secret。在GitHub创建webhook时填一个SecretHermes服务端会校验请求头的签名防止别人伪造webhook请求。很多公网上的Hermes服务被拿到仓库权限就是因为webhook没有配Secret攻击者可以直接给服务端塞伪造的PR事件。3.4 最小可用配置解析Hermes跑起来需要两套配置一套是服务端的连接配置已经通过环境变量传了另一套是每个仓库的代码评审规则文件名叫.hermes.yml放在仓库根目录。这个文件控制机器人在这个仓库里审什么、不审什么。我拆一个比较典型的最小配置# .hermes.yml 仓库根目录 version: 2 # 审查开关当PR满足任一ignore条件时跳过 ignore: paths: - package-lock.json - yarn.lock - *.min.js - dist/** - build/** - CHANGELOG.md title_matches: - ^docs\\(.*\\): - ^chore\\(release\\): # 触发审查的事件 on: pull_request: opened: true synchronize: true reopened: true # 按文件类型配置语言 language_map: .ts: typescript .tsx: typescript .js: javascript .py: python .go: go .java: java # 评审等级控制 severity: error: [blocking] # error级别的问题会阻止合入 warning: [critical, suggestion] # 大模型上下文窗口限制 analysis: max_diff_files: 20 # 单个PR最多分析文件数超过则截断 max_lines_per_file: 500 # 单文件最多分析行数超过部分跳过 max_comment_per_review: 15 # 单次review最多发表的评论数这个配置文件里的每一项都能展开讲不少我挑几个踩过坑的重点。ignore.paths这个配置非常实用。像package-lock.json、yarn.lock这种生成文件在依赖升级的PR里动不动就是上千行diff你不忽略掉Hermes每回都要拿几千行流水账给大模型分析钱花了评论还全是噪音。真实场景里这个ignore列表应该是慢慢长出来的——每被某个PR气到一次就加一条规则。severity决定了机器人评审的“严格程度”新接入的团队建议先全部用warning级别跑一两周统计一下机器人的报错准确率再逐步放宽对具体文件的分析。3.5 GitHub Actions作为事件触发器如果不想自己搭服务器接收webhook还有一个更轻的做法写一个GitHub Actions的workflow文件在pull_request事件触发时直接跑Hermes CLI。这种方式对中小团队特别友好因为跳过了一整层服务端部署。# .github/workflows/hermes-review.yml name: Hermes PR Review on: pull_request: types: [opened, synchronize, reopened] jobs: review: runs-on: ubuntu-latest permissions: contents: read pull-requests: write issues: write steps: - name: Checkout uses: actions/checkoutv4 - name: Set up Node.js uses: actions/setup-nodev4 with: node-version: 20 - name: Install Hermes run: npm install -g hermes/cli - name: Run Hermes Review env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} LLM_API_KEY: ${{ secrets.LLM_API_KEY }} LLM_BASE_URL: ${{ secrets.LLM_BASE_URL }} LLM_MODEL: ${{ secrets.LLM_MODEL }} run: | hermes review \ --repo ${{ github.repository }} \ --pr ${{ github.event.pull_request.number }} \ --post这套配置还需要到仓库的Secrets里添加LLM_API_KEY、LLM_BASE_URL和LLM_MODEL三个变量。GITHUB_TOKEN不需要额外新建workflow里直接用内置的就行但要注意权限在workflow文件里的permissions字段要显式声明pull-requests: write否则GitHub默认只给只读权限Hermes发评论会被拒绝。这个权限坑是我在配置Actions方案时遇到最多的报错来源报错信息长得像Resource not accessible by integration实际上就是权限没给够。4. 玩法升级规则定制、Prompt调优和review质量治理4.1 让Hermes懂团队规范规则文件不只是开关.hermes.yml里那套配置只是基础框架真正决定审查质量的是自定义规则。Hermes允许在配置里写custom_rules每一条规则其实是一段给大模型的指令。比如你的团队要求“所有Python函数必须带类型注解”你可以写一条这样的规则custom_rules: - id: PY_ANNOTATION_REQUIRED name: Python Typing Rules pattern: def .* message: 此函数的参数和返回值必须添加类型注解。Python文件里的每个def 函数如果参数或返回值没有类型注解请报告为warning级别。 上下文如果是需要在函数内部动态推导类型并且无法简单标注的场景 可以忽略本条规则并说明原因。 severity: warning applies_to: - **/*.py这种自定义规则的工作方式不是“正则匹配报错”而是把规则描述作为系统提示的一部分给到大模型让模型在阅读diff时判断是否命中。所以写规则的时候要注意不能只写“必须做什么”还要写清楚豁免场景。比如上面的类型注解规则如果遇到装饰器包了一层导致注解无法解析的情况模型如果没被告知豁免就会死板地报一大堆“假阳性”意见。我还强烈建议在配置里加入一个“自动带过”的规则白名单。像README修改、简单配置值调整这种改动Hermes默认还是要跑一轮LLM分析但这类PR真没什么好审的。配置一条skip_if: only_contains: - **/*.md - README* - .gitignore这样PR里的改动如果只涉及文档类文件仓库的workflow可以直接跳过Hermes省时省token。4.2 大模型review的提示词质量差异的根源Hermes虽然在部署上已经把大量逻辑做好了但有一个可变因素完全掌握在使用者手里——传给大模型的提示词。Hermes支持在.hermes.yml里配置system_prompt覆盖默认的审查指令。我一开始用默认提示词跑出来的结果偏“教科书式”——给出的建议倒是没错但很多不贴合实际项目场景怎么说呢太学术了。后来我把system_prompt改成了下面这个样子质量提了一截system_prompt: | 你是一个资深的前后端全栈代码评审专家正在审查GitHub上的Pull Request。 你的审查重点是 1. 只关注这个PR引入的实际变更不要对未修改区域的既有代码提意见除非这个PR逻辑会直接影响那部分代码的运行行为。 2. 优先报告会导致线上事故或功能异常的问题其次才是代码风格、可维护性、性能优化建议。 3. 对每个问题必须说明“为什么这是问题”、在什么输入或场景下会触发并给出最小修复建议。 4. 如果不确定或缺少上下文宁可不说也不要猜测性地丢一句“建议改成XX”。 5. 使用的语言跟随PR的commit message语言如果commit是英文评论用英文如果commit是中文评论用中文。这个提示词解决了两个核心痛点第一是上下文范围控制默认情况下大模型很容易对没改动过的老代码“指指点点”加了这个限制之后有效减少无关评论第二是确定性要求模型对没有把握的问题闭嘴不要瞎猜机器人review最烦的就是说了十个问题五个是误报开发者以后就不看它的评论了。准确性永远大于数量。4.3 三种审查输出的解读与配合Hermes把review结果写到PR上的时候是分三层的这三层的信息密度从高到低排列Inline comments挂在diff的具体代码行旁边的评论对应的是精确到代码行的问题。这类评论最适合开发者直接回复、讨论和修订。Review summary在PR详情页的“Files changed”标签页上方给出的整体评审意见包括对PR的综合评价好坏、是否有风险点、分类汇总的问题列表、以及优先处理的建议。这个建议很值得认真读它是模型对本次改动“大方向”的判断。Check run在PR底部的checks区域显示一个绿色的success或红色的failure。这个结果不会被普通开发者主动查看但它可以接入branch protection规则——当Hermes的检查为failure时PR就不能被merge。从团队运营的角度我建议把第三方human review和Hermes做任务切分Hermes负责在代码层面拦截低级bug和规范问题人类的approval负责业务正确性。在分支保护规则里把Hermes的check设置为“必须通过”同时保留至少1个human approver。这个双闸门模式团队接受度最高——没人会抱怨机器人太苛刻因为它挑出来的问题通常是真的问题同时人的权责也清晰毕竟最终拍板的是人。5. 真实部署中会遇到的问题和排查方法5.1 GitHub API连接与权限报错Hermes跑起来之后第一类大概率遇到的是权限问题。常见报错和排查路径我列个表报错信息出现原因解决办法Resource not accessible by integrationActions内置GITHUB_TOKEN权限不足在workflow的permissions字段里声明pull-requests: write403 Resource not accessible by integration个人访问令牌缺少repo或pull_requests权限检查Fine-grained token勾选Pull requests: Read and write404 Not FoundToken没有权限访问目标仓库确认token所属账号是否是该仓库的collaborator422 Unprocessable Entity评论的body内容格式非法触发GitHub限制检查评论中是否有违规markdown或超大行字符我遇到比较隐蔽的一个问题是用GitHub App的方式接入时虽然已经在App配置里给了权限但在安装App到仓库时没有勾选对应仓库或者仓库的settings页显示App已安装但实际上权限版本是旧的。这种问题排查起来最耗时间因为日志里权限都是正常的只是GitHub根本没把webhook推过来。检查的顺序应该是先看仓库Settings - GitHub Apps里App是否已安装再看App的Webhooks页面有没有最近一次的delivery记录。5.2 大模型API调用失败与超时Hermes这类AI评审工具依赖外部大模型API这一环出问题的方式五花八门timeout/Connection timed out服务器到模型API服务的网络不通。常见于自建机房部署、模型服务在国内而服务器在海外等场景。排查方法就是curl一下你配置的LLM_BASE_URL看看是否直接返回数据。401 Invalid API keyAPI密钥配置错误。检查环境变量有没有被正确加载在配置里用了特殊字符的话注意shell转义。429 Rate limit exceeded调用频率超限。这类最常出现在刚接入CI/CD、多个PR同时触发review的场景。缓解方案是把Hermes服务的内存缓存打开同一个PR短时间内的重复推送不要重复调用模型或者把workflow里加一个concurrency限制同一PR只允许一个review任务在跑。concurrency: group: hermes-review-${{ github.event.pull_request.number }} cancel-in-progress: false加了这个concurrency配置之后开发者连续往PR里push代码时GitHub不会同时启动多个Hermes任务节省了不少API配额也避免了一个PR瞬间收到好几轮评论的尴尬。5.3 审查质量相关的调优如果跑了一段时间你觉得机器人审得不好问题不一定要归因于Hermes本身很可能是配置的问题。排查思路按这个优先级来看是不是模型选型的问题。同样一段代码不同模型的代码理解能力差距非常大。如果用的是小型或偏对话的模型它擅长闲聊不一定擅长代码diff分析。换一个偏代码方向的模型试试往往效果提升最明显。看system_prompt是否约束住了模型。有没有明确要求模型只审变更行有没有告知项目语言风格没有这些约束模型“自由发挥”的空间就很广自然容易跑偏。看每次触发时传给模型的内容到底有多大。Hermes默认会把变更的代码包进prompt但部分语言如果函数体特别大模型在看到上下文的同时需要处理的代码行很多会超出它的注意力窗口。遇到超大函数时建议在analysis配置里把max_lines_per_file调低让模型聚焦在“变更的代码块”而不是“整个文件”。看review结果是否经过过滤。Hermes内置了一个基于规则的“评论分类器”它会根据大模型返回的消息格式、置信度评分、问题类型过滤掉低质量评论。这个分类器如果是开关状态试着打开如果已经打开可以调低confidence_threshold参数来减少误报。5.4 接入初期常见的“评论风暴”小组刚开始接Hermes的那一周最容易出现的场面就是一个PR进来机器人一次性发了15条评论开发者的PR通知都被刷屏了。这里要区分两种情况如果评论确实是“真问题”只是数量多那说明项目的存量技术债比较重要做的不是限流而是让开发者分批处理。我在团队里定了一条“机器人评论分级处理”的规则error级别的评论必须先解决才能mergewarning中critical的评论当周必须处理suggestion类的评论可以在PR描述里回复“已读暂不处理”并说明原因机器人在后续review中不会重复提。如果评论里混着大量的“假阳性”比如模型的建议不符合项目实际使用的设计模式那就要去补一条自定义规则告诉它“本项目约定所有仓库层方法都返回Result对象而非抛出异常如果代码中已经正确处理了Result不要建议改为异常捕获。”这个调优过程是持续的跑一个月之后机器人的评论数量和噪音量会明显下降。6. 实测效果用数据看看Hermes到底值不值接入Hermes两个月后我做了一次简单的数据分析把机器人review的数据导出来统计了一下。用的是GitHub API拉取的PR review时间线和评论数据大概看一下几个指标的变化趋势机器人平均每次review提出的问题数从初期的12.4个/PR降到5.7个/PR一方面是规则补全后误报减少另一方面开发者确实把规范性问题和潜在隐患提前解决了机器人能捞到的问题就少了。PR从“第一次提交”到“合并进主干”的中位时间从原来的18小时缩短到9.5小时。我分析主要原因不是代码改得快了而是“无效评审循环”减少了——以前人工review经常花两三天才给反馈现在机器人秒回大部分问题在提交当天就被堵住了不会到第二天才被review发现问题再打回修改。引入Hermes之前我们的bug中大概有一成是“历史代码回归导致”的即改了一处旧逻辑没注意到会影响别的调用点。接入之后这类bug明显减少了原因是机器人review会结合变更代码的调用方上下文对“疑似遗漏的调用方影响”给提示这在人肉review时经常被忽略。当然我也要泼一盆冷水Hermes不会神奇地把你们项目的bug清零。它更多的价值是把“一眼能发现的问题”自动化、常态化地处理掉让本来被这些琐碎评审工作占据的人力释放出来去认真思考真正的架构问题。建议把预期锚定在这上面而不要想着“人工review的成本全省了”然后砍掉代码评审制度。7. 一些给实操者的建议和避坑经验7.1 别急着全量接入先灰度跑两周我见过太多团队接了一个自动化评审工具第一天就打开全局分支保护结果机器人的误报把所有人的工作节奏都搅乱了第二天就被管理员下线。稳妥的方案是先在非核心仓库灰度跑或者用paths配置限定只review后端代码、先不review前端代码跑两周看看问题和规则库该怎么调。等误报率降到团队能接受的范围再扩展到核心仓库。7.2 规则库要有人维护不能只靠默认配置自动化评审工具和静态检查工具一样规则库是需要持续维护的资产。每个团队的项目特点、技术栈、编码约定的差异靠默认配置根本cover不住。我在团队里让CI负责人每个月花半天时间过一遍机器人近一个月的“假阳性”案例把集中的问题反映到规则库里。这样三个月后这个工具对你们项目的适配度会越来高而不是永远停留在“网上下的默认配置”。7.3 用review文档沉淀团队知识最后分享一个自己比较得意的小实践。我们把Hermes每次review生成的高质量建议特别是那种包含完整场景分析、触发条件、修复代码的问题直接同步到一个“代码评审知识库”文档里按微服务模块和语言分类。新同学入职的时候看这个文档比自己翻三个月PR学到的项目“暗坑”多得多——相当于把散落在无数次评审里的团队知识变成了一个可以检索的技术资料库。这个衍生价值是在接入Hermes之前没有预料到的。 Hermes自动化代码评审agent实践：接入GitHub PR流程与配置指南
组里PR越来越多之后不知道你们有没有一种感觉代码评审正在从“质量保障”慢慢变成“流程负担”。早上打开GitHub挂着十几个待review的PR每一条都要点开diff从头看到尾忙起来根本没时间细看只能粗略扫一眼就点Approve。可真正的问题往往不是评审人水平不行而是人的精力就那么多让一个后端开发连续看五六个PR之后后面几个基本就是走马观花。后来我把Hermes这类自动化代码评审agent接入到GitHub的PR流程里让机器先把低级问题、边界缺陷、安全隐患过滤掉再让人类评审专注于架构和业务逻辑整套流程才顺起来。这篇文章就以“Hermes”这个自动化代码评审agent项目为例讲讲它到底怎么工作、怎么接入GitHub的PR流程、配置里有哪些关键参数以及我在实际部署和使用中踩过的坑。如果你也想给团队的PR流程配一个“机器人评审员”这篇文章可以直接照着抄作业。1. 代码评审自动化Hermes解决的真实痛点1.1 人肉评审越来越不靠谱的过程代码评审最大的问题不是“没人看”而是“人看得不够准”。一个中型团队每天产生十几个PR很常见每个PR涉及几十个文件的改动跨语言、跨模块、还牵扯业务上下文。指望每个评审人都对所有代码了如指掌本来就不现实。我在好几个项目里观察下来人肉评审的质量曲线基本上是“前两个PR认真看中间的凭经验扫后面的直接LGTM”。这个锅不该让开发者背PR数量超过精力上限之后质量下降是必然结果。还有个更隐蔽的问题评审标准不一致。同一个项目的代码规范每个人理解都不一样。有人care命名有人care异常处理有人只关心自己的模块有没有被改坏。于是同一个PR有人Approve、有人Request Changes最后review feedback全靠PR作者运气。规则一直在那里但执行完全靠人人和人的神经敏感度差太多了。1.2 机器评审和人工评审的边界在哪里Hermes这类工具能做什么我先说清楚边界免得大家抱着不切实际的期待。它擅长处理的是可以被规则和上下文推断覆盖的问题明显的空指针风险、数组越界、资源未释放、错误处理缺失、危险函数调用、硬编码密钥、单测覆盖明显不足、代码风格偏离团队规范、重复代码等。这类问题本质上有迹可循大模型加上静态分析工具可以判断得比较稳。它做不到的是替人做产品决策和架构权衡比如“这个模块到底该不该拆成微服务”、“新方案和现有业务模型的兼容性该怎么取舍”这些需要业务上下文和长期项目经验机器读了diff也给不了靠谱答案。所以我把Hermes定位成“前置过滤器”而不是“终结评审者”——它先把60%的常规问题拦下来人类评审专家只需要集中精力看剩下的核心争议点。这比指望机器完全代替人类评审靠谱得多。1.3 Hermes项目的角色定位Hermes本质上是一个跑在服务端的自动化代码审查agent。它把自己挂在GitHub仓库上监听Pull Request相关事件每次有PR创建或更新的时候把这次的代码diff拉下来交给规则引擎和大模型一起分析然后把审查意见以评论、review summary、check run的形式回写到PR页面上。这样做的好处是所有动作都发生在PR界面里开发者不用切到别的平台就能看到机器人的意见。和传统的静态检查工具比如ESLint、SonarQube最大的区别是Hermes背后接了大模型能用自然语言理解代码的“意图”。传统的lint只能查格式和已知模式而Hermes能针对一段代码的逻辑缺陷说出“这里如果用户传入空数组会导致后续遍历越界”这个粒度完全不一样。2. Hermes的核心工作流程拆解2.1 一个PR从创建到审查完成的完整链路要理解Hermes的配置先得弄明白它处理一个PR时到底做了什么。我在部署前把这条链路完整梳理了一遍按顺序大概是这样的PR事件触发。有人创建PR或者push新的commit到已有PRGitHub把webhook事件推给Hermes服务或者Hermes通过轮询/定时任务的方式从GitHub API拉取状态变化的PR。获取并解析diff。Hermes调用GitHub REST API获取这个PR的.diff或.patch文件按文件解析出新增行、删除行和上下文行。这里有个很多AI评审工具忽略的点分析的范围应聚焦在“变更行”而不是整个文件否则大模型读的文件内容太多容易产生无关评论而且消耗的token量巨大。语言识别与规则匹配。按文件扩展名判断语言类型匹配对应的规则集。比如Python仓库重点检查异常处理、资源释放TypeScript重点检查类型安全、可选链使用Go重点检查错误返回和并发安全。静态分析前置处理。Hermes会先跑一轮基于AST的静态检查把能确定的问题直接提取出来这些问题不需要大模型判断速度快、准确率高。大模型深度分析。把代码diff片段、相关文件上下文、规则集、团队规范描述一起组装成prompt发给配置好的LLM服务OpenAI兼容接口都可以目前社区里比较多见的是接通用国产大模型或自建服务。大模型返回的分析结果是结构化的一般包含问题级别、文件位置、问题描述、修改建议代码。信息聚合与去重。把静态检查结果和大模型的结果合并同类型问题做归类整理同一文件重复报的问题只保留信息最全的一次。审查结果汇报。把最终结果以三种形式回写直接在PR的diff里对特定行发inline评论、在PR页面上提供一个汇总review summary、把conslusion写到commit的check run里作为CI状态的一部分。这七步里最容易被忽略的是第3步和第6步。没有规则匹配会拿到一堆不符合上下文的废话评论没有去重哪怕是同一个变量名在3个位置出现拼写问题机器人也会逐条刷屏开发者体验非常差。一个“好用”的Hermes部署例子里去重和分级这两层过滤是绝对少不了的。2.2 为什么选择“事件驱动”而不是“定时全量扫描”Hermes的接入形态有两种思路一种是在GitHub上安装一个App让它订阅pull_request事件实时响应另一种是起一个定时任务每隔几分钟扫一次未评审的PR。实际团队使用中我强烈建议用事件驱动。原因是评审及时性问题。代码评审的价值高度依赖“时间窗口”——PR刚提交的时候作者对代码的上下文记忆最清晰这时候给出review意见改起来的成本最低。如果等到定时扫描跑到才给反馈作者可能已经切去开发别的功能了回来再改这个PR光恢复上下文就要花不少时间。事件驱动的模式能做到“PR一更新机器人秒回评论”体验和真人评审基本同步。好在现在GitHub Actions天然支持事件触发的方式Hermes服务端只需要提供可调用的接口由workflow在pull_request事件时触发HTTP请求即可。这样你不用自己搭建常驻服务去接收webhook直接用GitHub的托管Runner跑流程运维成本低了很多。3. Hermes部署的完整实操从零到接入第一个PR3.1 部署前需要准备的东西Hermes的典型部署方式是“一个轻量级服务 LLM API GitHub凭证”。我先列一下全套清单然后逐项说每个组件的用途和选型建议运行时环境目前社区版本主要支持Node.js 18和Python 3.10。如果只是本地测试装好对应运行时就行如果放到服务器上长期跑建议用Docker方式部署它会把运行时依赖、配置文件、prompt模板都打进镜像里升级方便。一个大模型APIHermes不捆绑模型通过OpenAI兼容接口连接。你可以用GPT系列、Claude、DeepSeek或者其他任何提供OpenAI兼容API的服务。这个配置只影响审查质量不影响工具流程。GitHub Token或者GitHub App凭证用于读取PR内容和回写评审。如果是个人仓库测试直接用Fine-grained personal access token勾选Pull requests: Read and write和Contents: Read两个权限即可。如果是团队仓库强烈建议注册一个专用的GitHub App这样权限粒度更清晰也方便按仓库授权。Redis或数据库可选Hermes本身如果要做跨PR的重复问题检测比如同一个文件在最近的PR里刚刚提过同样的问题这次就不重复报了需要一个存储来记历史。小团队刚上手阶段可以先用SQLite跑得挺稳。3.2 CLI本地运行最快看到效果的方式我不建议团队一上来就把Hermes接到全仓库的CI上第一步应该是在本地跑起来先看看机器人对你代码的评审质量再决定要不要全量接入。Hermes提供了一套CLI命令最常用的是review。# 安装Hermes CLI假设项目支持npm全局安装 npm install -g hermes/cli # 登录配置GitHub Token和模型API Key hermes auth login --github-token ghp_xxx --llm-api-key sk-xxx # 指定目标仓库和PR编号执行一次本地评审 hermes review --repo owner/my-repo --pr 123执行完这个命令之后Hermes会在终端输出本次的分析摘要比如发现了几个错误级别问题、几个建议、分别在哪些文件的哪一行。确认输出质量符合预期之后再加--post参数把结果写到PR评论里。hermes review --repo owner/my-repo --pr 123 --post这里有个细节要注意本地执行时Hermes是用你当前登录的账号去发评论的所以评论作者会显示成你的账号而不是机器人账号。要解决这个问题得注册一个专门的GitHub账号或者GitHub App当作“机器人身份”。我建议从第一天就准备一个独立的账号不然后面审查记录里到处混着个人账号的消息很不好清理。3.3 用Docker部署常驻服务本地跑通了CLI之后就要把它升级成“团队公共设施”。服务器上用Docker部署的方式大致是这样把Hermes的代码仓库clone到服务器构建镜像然后把API key、GitHub凭证、模型endpoint作为环境变量传进去。git clone https://github.com/hermes-review/hermes.git cd hermes docker build -t hermes-review . # 创建配置文件目录准备挂载配置 mkdir -p /etc/hermes cp config.example.yml /etc/hermes/config.yml # 启动Hermes服务 docker run -d \ --name hermes \ -p 8080:8080 \ -e GITHUB_TOKENghp_xxx \ -e LLM_API_KEYsk-xxx \ -e LLM_BASE_URLhttps://api.your-llm-service.com/v1 \ -e LLM_MODELdeepseek-chat \ -v /etc/hermes/config.yml:/app/config.yml \ hermes-review启动之后Hermes服务默认会在8080端口监听GitHub的webhook事件。接下来去GitHub仓库的Settings - Webhooks页面新增一个webhookPayload URL填http://你的服务器地址:8080/webhook/githubContent type选application/json事件只勾选Pull requests即可。我可以直接说自己第一次配置webhook的时候漏掉了最重要的一步Secret。在GitHub创建webhook时填一个SecretHermes服务端会校验请求头的签名防止别人伪造webhook请求。很多公网上的Hermes服务被拿到仓库权限就是因为webhook没有配Secret攻击者可以直接给服务端塞伪造的PR事件。3.4 最小可用配置解析Hermes跑起来需要两套配置一套是服务端的连接配置已经通过环境变量传了另一套是每个仓库的代码评审规则文件名叫.hermes.yml放在仓库根目录。这个文件控制机器人在这个仓库里审什么、不审什么。我拆一个比较典型的最小配置# .hermes.yml 仓库根目录 version: 2 # 审查开关当PR满足任一ignore条件时跳过 ignore: paths: - package-lock.json - yarn.lock - *.min.js - dist/** - build/** - CHANGELOG.md title_matches: - ^docs\\(.*\\): - ^chore\\(release\\): # 触发审查的事件 on: pull_request: opened: true synchronize: true reopened: true # 按文件类型配置语言 language_map: .ts: typescript .tsx: typescript .js: javascript .py: python .go: go .java: java # 评审等级控制 severity: error: [blocking] # error级别的问题会阻止合入 warning: [critical, suggestion] # 大模型上下文窗口限制 analysis: max_diff_files: 20 # 单个PR最多分析文件数超过则截断 max_lines_per_file: 500 # 单文件最多分析行数超过部分跳过 max_comment_per_review: 15 # 单次review最多发表的评论数这个配置文件里的每一项都能展开讲不少我挑几个踩过坑的重点。ignore.paths这个配置非常实用。像package-lock.json、yarn.lock这种生成文件在依赖升级的PR里动不动就是上千行diff你不忽略掉Hermes每回都要拿几千行流水账给大模型分析钱花了评论还全是噪音。真实场景里这个ignore列表应该是慢慢长出来的——每被某个PR气到一次就加一条规则。severity决定了机器人评审的“严格程度”新接入的团队建议先全部用warning级别跑一两周统计一下机器人的报错准确率再逐步放宽对具体文件的分析。3.5 GitHub Actions作为事件触发器如果不想自己搭服务器接收webhook还有一个更轻的做法写一个GitHub Actions的workflow文件在pull_request事件触发时直接跑Hermes CLI。这种方式对中小团队特别友好因为跳过了一整层服务端部署。# .github/workflows/hermes-review.yml name: Hermes PR Review on: pull_request: types: [opened, synchronize, reopened] jobs: review: runs-on: ubuntu-latest permissions: contents: read pull-requests: write issues: write steps: - name: Checkout uses: actions/checkoutv4 - name: Set up Node.js uses: actions/setup-nodev4 with: node-version: 20 - name: Install Hermes run: npm install -g hermes/cli - name: Run Hermes Review env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} LLM_API_KEY: ${{ secrets.LLM_API_KEY }} LLM_BASE_URL: ${{ secrets.LLM_BASE_URL }} LLM_MODEL: ${{ secrets.LLM_MODEL }} run: | hermes review \ --repo ${{ github.repository }} \ --pr ${{ github.event.pull_request.number }} \ --post这套配置还需要到仓库的Secrets里添加LLM_API_KEY、LLM_BASE_URL和LLM_MODEL三个变量。GITHUB_TOKEN不需要额外新建workflow里直接用内置的就行但要注意权限在workflow文件里的permissions字段要显式声明pull-requests: write否则GitHub默认只给只读权限Hermes发评论会被拒绝。这个权限坑是我在配置Actions方案时遇到最多的报错来源报错信息长得像Resource not accessible by integration实际上就是权限没给够。4. 玩法升级规则定制、Prompt调优和review质量治理4.1 让Hermes懂团队规范规则文件不只是开关.hermes.yml里那套配置只是基础框架真正决定审查质量的是自定义规则。Hermes允许在配置里写custom_rules每一条规则其实是一段给大模型的指令。比如你的团队要求“所有Python函数必须带类型注解”你可以写一条这样的规则custom_rules: - id: PY_ANNOTATION_REQUIRED name: Python Typing Rules pattern: def .* message: 此函数的参数和返回值必须添加类型注解。Python文件里的每个def 函数如果参数或返回值没有类型注解请报告为warning级别。 上下文如果是需要在函数内部动态推导类型并且无法简单标注的场景 可以忽略本条规则并说明原因。 severity: warning applies_to: - **/*.py这种自定义规则的工作方式不是“正则匹配报错”而是把规则描述作为系统提示的一部分给到大模型让模型在阅读diff时判断是否命中。所以写规则的时候要注意不能只写“必须做什么”还要写清楚豁免场景。比如上面的类型注解规则如果遇到装饰器包了一层导致注解无法解析的情况模型如果没被告知豁免就会死板地报一大堆“假阳性”意见。我还强烈建议在配置里加入一个“自动带过”的规则白名单。像README修改、简单配置值调整这种改动Hermes默认还是要跑一轮LLM分析但这类PR真没什么好审的。配置一条skip_if: only_contains: - **/*.md - README* - .gitignore这样PR里的改动如果只涉及文档类文件仓库的workflow可以直接跳过Hermes省时省token。4.2 大模型review的提示词质量差异的根源Hermes虽然在部署上已经把大量逻辑做好了但有一个可变因素完全掌握在使用者手里——传给大模型的提示词。Hermes支持在.hermes.yml里配置system_prompt覆盖默认的审查指令。我一开始用默认提示词跑出来的结果偏“教科书式”——给出的建议倒是没错但很多不贴合实际项目场景怎么说呢太学术了。后来我把system_prompt改成了下面这个样子质量提了一截system_prompt: | 你是一个资深的前后端全栈代码评审专家正在审查GitHub上的Pull Request。 你的审查重点是 1. 只关注这个PR引入的实际变更不要对未修改区域的既有代码提意见除非这个PR逻辑会直接影响那部分代码的运行行为。 2. 优先报告会导致线上事故或功能异常的问题其次才是代码风格、可维护性、性能优化建议。 3. 对每个问题必须说明“为什么这是问题”、在什么输入或场景下会触发并给出最小修复建议。 4. 如果不确定或缺少上下文宁可不说也不要猜测性地丢一句“建议改成XX”。 5. 使用的语言跟随PR的commit message语言如果commit是英文评论用英文如果commit是中文评论用中文。这个提示词解决了两个核心痛点第一是上下文范围控制默认情况下大模型很容易对没改动过的老代码“指指点点”加了这个限制之后有效减少无关评论第二是确定性要求模型对没有把握的问题闭嘴不要瞎猜机器人review最烦的就是说了十个问题五个是误报开发者以后就不看它的评论了。准确性永远大于数量。4.3 三种审查输出的解读与配合Hermes把review结果写到PR上的时候是分三层的这三层的信息密度从高到低排列Inline comments挂在diff的具体代码行旁边的评论对应的是精确到代码行的问题。这类评论最适合开发者直接回复、讨论和修订。Review summary在PR详情页的“Files changed”标签页上方给出的整体评审意见包括对PR的综合评价好坏、是否有风险点、分类汇总的问题列表、以及优先处理的建议。这个建议很值得认真读它是模型对本次改动“大方向”的判断。Check run在PR底部的checks区域显示一个绿色的success或红色的failure。这个结果不会被普通开发者主动查看但它可以接入branch protection规则——当Hermes的检查为failure时PR就不能被merge。从团队运营的角度我建议把第三方human review和Hermes做任务切分Hermes负责在代码层面拦截低级bug和规范问题人类的approval负责业务正确性。在分支保护规则里把Hermes的check设置为“必须通过”同时保留至少1个human approver。这个双闸门模式团队接受度最高——没人会抱怨机器人太苛刻因为它挑出来的问题通常是真的问题同时人的权责也清晰毕竟最终拍板的是人。5. 真实部署中会遇到的问题和排查方法5.1 GitHub API连接与权限报错Hermes跑起来之后第一类大概率遇到的是权限问题。常见报错和排查路径我列个表报错信息出现原因解决办法Resource not accessible by integrationActions内置GITHUB_TOKEN权限不足在workflow的permissions字段里声明pull-requests: write403 Resource not accessible by integration个人访问令牌缺少repo或pull_requests权限检查Fine-grained token勾选Pull requests: Read and write404 Not FoundToken没有权限访问目标仓库确认token所属账号是否是该仓库的collaborator422 Unprocessable Entity评论的body内容格式非法触发GitHub限制检查评论中是否有违规markdown或超大行字符我遇到比较隐蔽的一个问题是用GitHub App的方式接入时虽然已经在App配置里给了权限但在安装App到仓库时没有勾选对应仓库或者仓库的settings页显示App已安装但实际上权限版本是旧的。这种问题排查起来最耗时间因为日志里权限都是正常的只是GitHub根本没把webhook推过来。检查的顺序应该是先看仓库Settings - GitHub Apps里App是否已安装再看App的Webhooks页面有没有最近一次的delivery记录。5.2 大模型API调用失败与超时Hermes这类AI评审工具依赖外部大模型API这一环出问题的方式五花八门timeout/Connection timed out服务器到模型API服务的网络不通。常见于自建机房部署、模型服务在国内而服务器在海外等场景。排查方法就是curl一下你配置的LLM_BASE_URL看看是否直接返回数据。401 Invalid API keyAPI密钥配置错误。检查环境变量有没有被正确加载在配置里用了特殊字符的话注意shell转义。429 Rate limit exceeded调用频率超限。这类最常出现在刚接入CI/CD、多个PR同时触发review的场景。缓解方案是把Hermes服务的内存缓存打开同一个PR短时间内的重复推送不要重复调用模型或者把workflow里加一个concurrency限制同一PR只允许一个review任务在跑。concurrency: group: hermes-review-${{ github.event.pull_request.number }} cancel-in-progress: false加了这个concurrency配置之后开发者连续往PR里push代码时GitHub不会同时启动多个Hermes任务节省了不少API配额也避免了一个PR瞬间收到好几轮评论的尴尬。5.3 审查质量相关的调优如果跑了一段时间你觉得机器人审得不好问题不一定要归因于Hermes本身很可能是配置的问题。排查思路按这个优先级来看是不是模型选型的问题。同样一段代码不同模型的代码理解能力差距非常大。如果用的是小型或偏对话的模型它擅长闲聊不一定擅长代码diff分析。换一个偏代码方向的模型试试往往效果提升最明显。看system_prompt是否约束住了模型。有没有明确要求模型只审变更行有没有告知项目语言风格没有这些约束模型“自由发挥”的空间就很广自然容易跑偏。看每次触发时传给模型的内容到底有多大。Hermes默认会把变更的代码包进prompt但部分语言如果函数体特别大模型在看到上下文的同时需要处理的代码行很多会超出它的注意力窗口。遇到超大函数时建议在analysis配置里把max_lines_per_file调低让模型聚焦在“变更的代码块”而不是“整个文件”。看review结果是否经过过滤。Hermes内置了一个基于规则的“评论分类器”它会根据大模型返回的消息格式、置信度评分、问题类型过滤掉低质量评论。这个分类器如果是开关状态试着打开如果已经打开可以调低confidence_threshold参数来减少误报。5.4 接入初期常见的“评论风暴”小组刚开始接Hermes的那一周最容易出现的场面就是一个PR进来机器人一次性发了15条评论开发者的PR通知都被刷屏了。这里要区分两种情况如果评论确实是“真问题”只是数量多那说明项目的存量技术债比较重要做的不是限流而是让开发者分批处理。我在团队里定了一条“机器人评论分级处理”的规则error级别的评论必须先解决才能mergewarning中critical的评论当周必须处理suggestion类的评论可以在PR描述里回复“已读暂不处理”并说明原因机器人在后续review中不会重复提。如果评论里混着大量的“假阳性”比如模型的建议不符合项目实际使用的设计模式那就要去补一条自定义规则告诉它“本项目约定所有仓库层方法都返回Result对象而非抛出异常如果代码中已经正确处理了Result不要建议改为异常捕获。”这个调优过程是持续的跑一个月之后机器人的评论数量和噪音量会明显下降。6. 实测效果用数据看看Hermes到底值不值接入Hermes两个月后我做了一次简单的数据分析把机器人review的数据导出来统计了一下。用的是GitHub API拉取的PR review时间线和评论数据大概看一下几个指标的变化趋势机器人平均每次review提出的问题数从初期的12.4个/PR降到5.7个/PR一方面是规则补全后误报减少另一方面开发者确实把规范性问题和潜在隐患提前解决了机器人能捞到的问题就少了。PR从“第一次提交”到“合并进主干”的中位时间从原来的18小时缩短到9.5小时。我分析主要原因不是代码改得快了而是“无效评审循环”减少了——以前人工review经常花两三天才给反馈现在机器人秒回大部分问题在提交当天就被堵住了不会到第二天才被review发现问题再打回修改。引入Hermes之前我们的bug中大概有一成是“历史代码回归导致”的即改了一处旧逻辑没注意到会影响别的调用点。接入之后这类bug明显减少了原因是机器人review会结合变更代码的调用方上下文对“疑似遗漏的调用方影响”给提示这在人肉review时经常被忽略。当然我也要泼一盆冷水Hermes不会神奇地把你们项目的bug清零。它更多的价值是把“一眼能发现的问题”自动化、常态化地处理掉让本来被这些琐碎评审工作占据的人力释放出来去认真思考真正的架构问题。建议把预期锚定在这上面而不要想着“人工review的成本全省了”然后砍掉代码评审制度。7. 一些给实操者的建议和避坑经验7.1 别急着全量接入先灰度跑两周我见过太多团队接了一个自动化评审工具第一天就打开全局分支保护结果机器人的误报把所有人的工作节奏都搅乱了第二天就被管理员下线。稳妥的方案是先在非核心仓库灰度跑或者用paths配置限定只review后端代码、先不review前端代码跑两周看看问题和规则库该怎么调。等误报率降到团队能接受的范围再扩展到核心仓库。7.2 规则库要有人维护不能只靠默认配置自动化评审工具和静态检查工具一样规则库是需要持续维护的资产。每个团队的项目特点、技术栈、编码约定的差异靠默认配置根本cover不住。我在团队里让CI负责人每个月花半天时间过一遍机器人近一个月的“假阳性”案例把集中的问题反映到规则库里。这样三个月后这个工具对你们项目的适配度会越来高而不是永远停留在“网上下的默认配置”。7.3 用review文档沉淀团队知识最后分享一个自己比较得意的小实践。我们把Hermes每次review生成的高质量建议特别是那种包含完整场景分析、触发条件、修复代码的问题直接同步到一个“代码评审知识库”文档里按微服务模块和语言分类。新同学入职的时候看这个文档比自己翻三个月PR学到的项目“暗坑”多得多——相当于把散落在无数次评审里的团队知识变成了一个可以检索的技术资料库。这个衍生价值是在接入Hermes之前没有预料到的。