Hermify
返回博客

hermes-agent-github-actions

作者：Hermify Team||阅读约 3 分钟
hermes-agent-github-actions

title: "Hermes Agent + GitHub Actions：自动化管理你的代码仓库" description: "三个实用方案，让 Hermes Agent 帮你守护 GitHub 仓库：CI 失败诊断、每晚 PR 汇总，以及过期 Issue 清理。" date: 2026-05-18 author: "Hermify Team" tags: ["Hermes", "GitHub", "AI Agents", "Automation"] coverImage: "cover.jpg" coverAlt: "深色代码编辑器界面中，Hermes 徽标与 GitHub Octocat 之间连接着一条发光的绿色线条，配文"GitHub 自动化""

你的仓库需要的是助手，不是又一个控制台

如果你维护着两三个以上的 GitHub 仓库，你大概已经发现了一个共同规律：大部分时间花在的不是写代码上。而是排查 CI 故障、扫一眼昨天开的 PR、关掉没人会碰的过期 Issue、再给自己发一份周一早上的周末进展摘要。

这些正是 AI 真正擅长的那类工作——不是创意性的编程，而是日常的"管家事务"。而 Hermes Agent 凭借其内置的 cron 调度器、webhook 监听器以及原生的 GitHub CLI 访问能力，天生就是为此而设计的。

本文提供三个你今天就能直接复用的实战方案，每一个都针对你可能每周都在面对的真实问题。

  • 一个 CI 失败诊断智能体，在 PR 变红后几分钟内自动发布诊断评论
  • 一个每晚推送到 Telegram 或 Discord 的 PR 汇总
  • 一个每周自动梳理过期 Issue、并为 60 天无人问津的 Issue 起草关闭评论的定时任务

读完这篇文章，你应该能在一次坐下来的时间内完成上述任意一个方案的部署。如果你还没开始，在 Hermify 注册 可以直接获得一个已配置好所有 GitHub 管道的托管 Hermes 实例。

为什么选择 Hermes 来做仓库自动化

GitHub Actions Marketplace 上有很多现成的机器人，各司其职：一个做代码审查、一个处理过期 Issue、一个生成发布说明。但把它们拼凑在一起的问题在于：没有一个有记忆。每次运行都从零开始，各自需要独立配置，各自对接不同的外部服务。

Hermes 在三个关键点上有所不同：

  • 一个智能体，多项技能。 单个 Hermes 实例可以同时审查 PR、分类 Issue、运行定时任务，还能通过 Telegram 回答临时问题。只需配置一次、训练一次，进步也是一体的。
  • 持久化记忆。 上周 Hermes 在 PR #312 上标记了一个不稳定的测试，今天 PR #340 出现同样的问题时，它还记得。这种上下文记忆是绝大多数 Marketplace 插件做不到的。
  • 自然语言 cron。 不需要写 0 9 * * 1-5，你只需说"每个工作日早上 9 点发我一份 PR 汇总"，Hermes 会自动生成技能和调度配置。

Hermes Agent 在终端中审查 GitHub 拉取请求

想深入了解底层机制，可以阅读我们关于 Hermes 记忆与技能 的文章。

方案一：CI 失败诊断智能体

痛点。 一个测试在 PR 上失败了。你看到红叉，点进 Actions，翻日志，找到是哪一步出了问题，判断是随机抖动还是真实回归，然后写一条评论。每次这个流程要花 5 到 15 分钟。一周下来，跨多个仓库，累计就是好几个小时。

Hermes 的做法。 当 check_run 事件以 conclusion: failure 完成时触发 webhook。Hermes 通过 GitHub CLI 拉取失败任务的日志，定位出错步骤和最可能的根因，然后在对应 PR 上发布一段评论，包含一段诊断说明和下一步建议（重跑、本地修复，或标记为已知抖动）。

配置步骤。

  1. 在 Hermes 配置中，为你关注的仓库订阅 check_run.completed webhook 事件。
  2. 添加一个名为 github-ci-triage 的技能，提示词大致如下："用 gh run view --log-failed 获取失败任务的日志。定位失败步骤和第一条堆栈跟踪或报错行。如果该错误与记忆中已知的抖动模式匹配，将评论标注为"可能是抖动"；否则用一段话总结根因，并给出最小修复建议。"
  3. 将 webhook 处理器指向该技能，并使用 gh pr comment 将结果作为 PR 评论发布。

第一次运行后，快速浏览一下评论，给它点赞（Hermes 会将其存储为一次确认正确的诊断）或者纠正它。经过几轮之后，诊断会越来越准确——因为 Hermes 在逐渐了解你的代码库、你的 CI 特性，以及哪些测试文件是老问题户。

方案二：每晚 PR 汇总

痛点。 你在个人项目、工作仓库和维护的开源项目中，随时有 3 到 15 个开放的 PR。到周五下午，你根本不知道哪些有进展、哪些在等你、哪些在等别人。

Hermes 的做法。 每个工作日晚上 9 点（马德里时间，或你自定义的时区），Hermes 运行 GitHub CLI 列出所有开放 PR，按状态分组（等待审查、等待 CI、草稿、可合并），并将格式化后的汇总发送到你的 Telegram 或 Discord。

汇总示例如下：

PR digest - 18 May 2026

WAITING ON YOU (3):
- albertoaquinodev/hermes-up #421 "fix: revalidate blog index" - review requested 4d ago
- albertoaquinodev/hermes-up #418 "feat: BYOK provider snapshot" - your review is the last blocker
- nousresearch/hermes-agent #2104 "docs: add cron examples" - small docs PR

WAITING ON OTHERS (2):
- albertoaquinodev/hermes-up #420 - blocked on reviewer for 2d
- nousresearch/hermes-agent #2099 - CI red, owner is fixing

MERGEABLE NOW (1):
- albertoaquinodev/hermes-up #422 - all green, ready to merge

配置步骤。

  1. 创建一个 cron 任务，提示词如下："每个工作日 21:00，用 gh pr list 列出 albertoaquinodev/* 和 nousresearch/* 中的开放 PR，按状态分组，发送到我的 Telegram。"
  2. Hermes 会将自然语言调度解析为 cron 表达式 0 21 * * 1-5 并注册该技能。
  3. 如果还未配置，连接一个 Telegram 或 Discord 推送目标。

整个配置大约需要 10 分钟。运行起来后，使用 Sonnet 模型每晚的成本大约在 $0.02 到 $0.05 之间，具体取决于开放 PR 的数量。

相比之下，用 Actions 和 Slack 插件拼凑出同样功能需要花一个周末，而且 GitHub 每次改 API 就会坏掉。

方案三：每周过期 Issue 分类

痛点。 Issue 会不断积累。有些在某个并行 PR 中已被修复，却没人手动关闭；有些是用户报告后就消失了，Issue 就这样永远开着；还有些是重复的。手动梳理 backlog 是没人愿意做的事。

Hermes 的做法。 每周一上午，Hermes 列出 60 天内无活动的所有 Issue，读取 Issue 正文和评论，在四种处理方式中做出判断，然后（根据你给予它的自主度）要么起草评论等你审批，要么直接发布。

四种处理方式：

  • 关闭为已修复。 相关 Bug 似乎已在近期的某次提交或发布中被解决。Hermes 发布一条礼貌的关闭评论，并附上关联提交。
  • 关闭为过期。 作者在 30 天以上前被要求提供更多信息，但始终未回复。
  • 提升优先级。 该 Issue 仍然相关，有其他用户点赞，值得更新标签。
  • 转为 Discussion。 该 Issue 是功能请求，更适合放在 Discussions 而非 Issues 中。

终端中显示 Hermes Agent 定时任务正在对 GitHub 仓库执行操作

配置步骤。

  1. 创建一个 cron 任务："每周一上午 10 点，梳理我仓库中的过期 Issue，起草评论但暂不发布。"
  2. Hermes 生成一个技能，运行 gh issue list --state open --search 'updated:<2026-03-18'（日期在运行时动态计算），读取每个 Issue 并决定处理方式。
  3. 起草内容会以单条 Telegram 消息的形式发送，或者（如果你偏好）以类似 PR 摘要的形式供你审阅。

经过几周的监督运行后，你可以选择切换为自动发布模式（Hermes 直接执行），或者永远保持草稿模式。无论哪种方式，你的 backlog 都会停止膨胀。

Hermes 的边界，以及你该接手的地方

说句实话：Hermes 在仓库维护中例行公事的 80% 部分表现出色，但剩下那 20% 需要真正判断力的事情，你仍然需要亲力亲为——比如判断一个 CI 抖动是否其实是真实 Bug、决定 API 中的破坏性变更、告诉用户某个功能请求超出了项目范围。

上述配置的全部意义，就是把 80% 的事情从你的盘子里清走，让你有时间专注于那 20%。关于同一思路的另一种实践，可以参考我们关于 用 Docker 自托管 AI 智能体 的文章，那篇文章介绍了长期运行 Hermes 的基础设施侧内容。

本周就上手试试

如果你已经在自托管 Hermes，上面三个方案大概花一个晚上就能配置完成。如果还没有，最快的路径是 在 Hermify 注册——托管的 Hermes 实例已内置 GitHub CLI、webhook 监听器和 cron 调度器。你只需要添加仓库 token，然后用自然语言写下 cron 句子就好。

这套"仓库守护者"方案，是那种让人想问"为什么之前没人做"的东西。然后你会想明白：大多数"面向开发者的 AI"工具都在针对写代码的那 20%，而不是管家事务的 80%。Hermes 瞄准的，正是那 80%。

参考资料

运行你自己的 Hermes Agent

自带 API 密钥，连接 Telegram，60 秒内即可上线一个自我改进的 AI 智能体。

立即开始