OpenClaw Agent Hub

OpenClaw GitHub Issue 管理

使用 OpenClaw 进行 GitHub issue 分类、审核和跟进的实用工作流。
2026/03/12

OpenClaw GitHub Issue 管理

这个工作流展示 OpenClaw 如何融入 GitHub issue 工作流，减少手动分类工作并保持 issue 队列有序。

这个工作流做什么

自动监控 GitHub 仓库的新 issue，进行摘要，识别缺失的上下文，并将摘要发送到维护者可以处理的 channel。

你需要什么

在搭建这个工作流之前：

工作流结构

第一步：检测新 issue

按计划（例如每天早上）查询仓库中上次检查之后创建的 issue。

第二步：摘要每个 issue

对于每个新 issue，助手：

  • 读取标题和正文
  • 提取核心问题或请求
  • 识别缺失的信息（复现步骤、版本、环境）
  • 分配粗略优先级（紧急 / 普通 / 低）

第三步：投递摘要

将格式化的摘要发送到配置的 channel：

  • issue 标题和链接
  • 一句话摘要
  • 缺失上下文标记
  • 建议优先级

第四步：起草回复（可选）

对于缺少上下文的 issue，助手可以起草一条澄清评论，维护者审核后发布。

第一天不要开启自动发布。保持人工在环。

第五步：跟踪未解决项目

维护一个未处理 issue 的运行列表，并在下一次摘要中重新提醒仍然开放的项目。

定制选项

按标签过滤

只分类有特定标签的 issue，或者忽略标记为 "wontfix" 或 "duplicate" 的 issue。

多仓库

监控多个仓库并生成合并摘要。保持列表短（2-3 个仓库）以避免噪音。

负责人感知

在摘要中包含当前负责人信息，让维护者知道谁在处理。

升级规则

标记超过阈值（例如 7 天）仍未收到回复的 issue。

为什么这是一个强工作流

GitHub issue 工作重复性强、以文本为主、常常因为缺少上下文而延迟。这让它非常匹配助手类自动化。

助手不取代维护者。它缩短了从"issue 被打开"到"issue 被理解并分类"的时间。

接下来该看什么