github robot

https://github.com/pbakaus/agent-reviews

这个项目让我想到一个有意思的场景：一个让人血压升高的下午

你提了一个 PR，信心满满。几秒钟后，Copilot 来了，CodeRabbit 来了，Cursor Bugbot 也来了。它们在你的代码行上密密麻麻留下几十条评论：这里可能空指针，那里命名不规范，这个函数复杂度超标。你认认真真改了一轮，git push。

然后，新的评论又冒出来了。

你再改，再 push，它们又冒出来一批。

你开始机械地在每条评论下面敲 "Fixed in abc1234"，敲到第 47 遍的时候，你意识到一个下午已经没了。

这就是 agent-reviews 官网直接挂在标题上的痛点，叫 bot review doom loop（评审机器人死循环）：

你修一轮、推一次、冒一批新评论，循环往复，永无止境。官网那句话很扎心：没人应该把整个下午花在敲第 47 遍Fixed in abc1234上。

agent-reviews 就是来杀掉这个循环的。本质上就是一个 CLI 工具加三套 Agent Skill（给 AI 编码 agent 用的自动化剧本），专门管理 GitHub PR 上各种评审机器人留下的评论。

我们常见用的是 gh ，但它不是为"管理评审评论"设计的。它能拉到原始数据，但是它并没有任何额外的设计，它是as little as necessary，所以为了好用，对不起，这要我们自己写 jq去。

# 列出当前分支对应 PR 上所有 review 评论(默认 list 模式)
agent-reviews

只看没人回复过的、机器人发的评论


agent-reviews –unanswered –bots-only


看某条评论的完整详情(展开正文、代码 diff、所有回复)


agent-reviews –detail 123456


回复某条评论,并顺手把这条 review 线程标记为已解决


agent-reviews –reply 123456 “Fixed in abc1234.” –resolve


输出 JSON,方便管道处理


agent-reviews –unanswered –json | jq ‘.[].id’

注意它的过滤维度：–unresolved（只看未解决）、–unanswered（只看没人回过）、–bots-only / –humans-only（只看机器人或人类），而且这些维度可以任意组合。这正是 gh 给不了你的东西。

它的三套 Agent Skill对应三种不同的工作流：

  • /resolve-reviews：处理全部评论（人类 + 机器人）

  • /resolve-agent-reviews：只处理机器人评论

  • /resolve-human-reviews：只处理人类评论

你装好 skill，在 agent 里敲一句 /resolve-agent-reviews，然后就可以去喝杯咖啡了。agent 会自动跑完这样一套闭环：

拉取所有未答复评论，逐条判断是真问题还是误报，修真问题并跑 lint/type-check，误报就附理由驳回，把所有修复打成一次 commit 推送，逐条回复结果并标记线程已解决，起一个 watcher 循环监听新评论，直到 10 分钟没有新评论才退出，输出一份汇总报告。

你回来的时候，PR 已经干净了。这就是它的产品定位：对人类是"按一个斜杠命令然后走开"，对 agent 是"拿到一个可靠、紧凑、带状态的接口，不用自己跟 GitHub API 和各家机器人的样板文本搏斗"。

那它到极限了吗？我觉得不然，再看看别的

github自动流

我们以以下功能为workflow：

编号

能力

含义

为什么重要

R1

自动读取 GitHub issue

能把一个 issue 直接作为任务输入(标签触发、评论触发、或传入 issue 链接),自动拉取标题、正文、上下文

这是"自治"的起点。没有它就只能人工喂 prompt

R2

构建 code sandbox 复现问题

能在隔离的容器 / 虚拟机环境里真正运行代码(跑测试、执行复现脚本),把问题重现出来

区分"评审 bot"与"真 agent"的分水岭。只有能跑代码,才能验证 bug 是否真实、修复是否有效

R3

自动改代码解决

能定位问题并自动修改源码,生成修复

核心产出能力

R4

自动开 / 写 PR

修复完成后自动创建分支并开 Pull Request 提交改动

决定它是"给你一个 patch"还是"直接交付可合并的 PR"

R5

在 PR 上评论

能在 PR 上留评论 / 评审意见 / 响应 review 反馈

决定能否参与协作回路、根据反馈迭代

R6

在 issue 上评论

能在 issue 上回帖(进度、计划、结果、追问)

决定能否对外汇报状态、闭合 issue 沟通

借助cc调研了一下，还蛮多项目可以做到的，但是需要注意的是，cc只会关注它web search搜到的项目，我建议有需要还是要自己多搜一搜：

项目

R1 读ISSUE

R2 沙箱复现

R3 改码

R4 开PR

R5 评论PR

R6 评论ISSUE

命中

OpenHands(+resolver)

✅

✅

✅

✅

✅

✅

6 / 6

LangChain Open SWE

✅

✅

✅

✅

✅

✅

6 / 6

AWS remote-swe-agents

✅

✅

✅

✅

🟡

✅

5.5 / 6

pullfrog/pullfrog

✅

🟡

✅

✅

✅

✅

5.5 / 6

SWE-agent(Princeton)

✅

✅

✅

🟡

❌

❌

3.5 / 6

AutoCodeRover

✅

✅

✅

❌

❌

❌

3 / 6

irgolic/AutoPR(已归档)

✅

❌

✅

✅

❌

❌

3 / 6

由于我对aws的云服务不太敏感，然后功能缺失不见得有好的架构，所以选一些成熟的来看看

很有意思的是，他们有三类很经典的架构：

graph TB subgraph OpenHands OH_API[FastAPI Server] –> OH_SANDBOX[Sandbox Service] OH_API –> OH_AGENT[Agent Server 独立进程] OH_AGENT –> OH_SDK[openhands SDK] OH_SDK –> OH_LLM[LiteLLM] endgraph TB subgraph Open_SWE[“Open SWE”] OS_WH[Webhook Handler] –> OS_LG[LangGraph] OS_LG –> OS_DA[Deep Agents] OS_DA –> OS_SB[Sandbox Backend] OS_DA –> OS_LLM[Multi-Provider LLM] endgraph TB subgraph SWE_Agent[“SWE-agent”] SA_CLI[CLI run.py] –> SA_AGENT[DefaultAgent] SA_AGENT –> SA_ENV[SWEEnv] SA_ENV –> SA_REX[SWE-ReX Runtime] SA_AGENT –> SA_LLM[LiteLLM] end

  • OpenHands 采用 App Server + Agent Server 分离部署，这种侧重存储和服务层的可替换

  • Open SWE 基于 LangGraph 图编排 + Deep Agents 库组合，这种是强调中间件和模型的灵活组合

  • SWE-agent 则是经典的 CLI + Agent-Environment-Tools 三层设计，这种是以 Bundle 和 Hook 为核心扩展机制

<text-diagram data-type=“mermaid” data-content=“sequenceDiagram participant User participant GitHub participant Agent

rect rgb(200, 220, 255)
    Note over User,Agent: OpenHands
    User-&gt;&gt;GitHub: 给 Issue 打 fix-me 标签
    GitHub-&gt;&gt;Agent: Webhook → Resolver
    Agent-&gt;&gt;GitHub: 创建 Draft PR / 留评论
end

rect rgb(220, 255, 200)
    Note over User,Agent: Open SWE
    User-&gt;&gt;GitHub: Issue/PR 中 @openswe
    GitHub-&gt;&gt;Agent: Webhook → webapp.py
    Agent-&gt;&gt;GitHub: 创建 PR / 回复评论
end

rect rgb(255, 220, 200)
    Note over User,Agent: AWS remote-swe-agents
    User-&gt;&gt;GitHub: Issue comment / GitHub Actions
    GitHub-&gt;&gt;Agent: REST API → Lambda → EC2
    Agent-&gt;&gt;GitHub: gh CLI 创建 PR / 评论
end

rect rgb(255, 255, 200)
    Note over User,Agent: SWE-agent
    User-&gt;&gt;Agent: CLI 传入 Issue URL
    Agent-&gt;&gt;Agent: 解析 → 沙箱执行
    Agent-&gt;&gt;Agent: 输出 patch 文件
end">sequenceDiagram
participant User
participant GitHub
participant Agent

rect rgb(200, 220, 255)
    Note over User,Agent: OpenHands
    User-&gt;&gt;GitHub: 给 Issue 打 fix-me 标签
    GitHub-&gt;&gt;Agent: Webhook → Resolver
    Agent-&gt;&gt;GitHub: 创建 Draft PR / 留评论
end

rect rgb(220, 255, 200)
    Note over User,Agent: Open SWE
    User-&gt;&gt;GitHub: Issue/PR 中 @openswe
    GitHub-&gt;&gt;Agent: Webhook → webapp.py
    Agent-&gt;&gt;GitHub: 创建 PR / 回复评论
end

rect rgb(255, 220, 200)
    Note over User,Agent: AWS remote-swe-agents
    User-&gt;&gt;GitHub: Issue comment / GitHub Actions
    GitHub-&gt;&gt;Agent: REST API → Lambda → EC2
    Agent-&gt;&gt;GitHub: gh CLI 创建 PR / 评论
end

rect rgb(255, 255, 200)
    Note over User,Agent: SWE-agent
    User-&gt;&gt;Agent: CLI 传入 Issue URL
    Agent-&gt;&gt;Agent: 解析 → 沙箱执行
    Agent-&gt;&gt;Agent: 输出 patch 文件
end</text-diagram><p style="">有意思的是他们的通信和执行pipeline也不一样：</p><ul><li><p style="">OpenHands 通过标签触发</p></li><li><p style="">Open SWE 通过 @mention 触发</p></li><li><p style="">AWS 支持多入口（GitHub Actions/Slack/REST API）</p></li><li><p style="">SWE-agent 主要是 CLI 驱动，默认输出 patch 而非直接开 PR</p></li></ul><p style=""></p><p style="">（没写完，挖个坑）</p><p style=""></p><p style=""></p><p style=""></p><p style=""></p><p style=""></p><p style=""></p><h1 style="" id="front-design">front design</h1><p style="">https://github.com/pbakaus/impeccable</p><p style="">https://github.com/pbakaus/radiant</p><p style="">感觉一般，先不理了</p>