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：

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

由于我对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]
    end

graph 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]
    end

graph 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 为核心扩展机制

sequenceDiagram
    participant User
    participant GitHub
    participant Agent

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

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

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

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

有意思的是他们的通信和执行pipeline也不一样：

• OpenHands 通过标签触发
• Open SWE 通过 @mention 触发
• AWS 支持多入口（GitHub Actions/Slack/REST API）
• SWE-agent 主要是 CLI 驱动，默认输出 patch 而非直接开 PR

（没写完，挖个坑）

front design#

https://github.com/pbakaus/impeccable

https://github.com/pbakaus/radiant

感觉一般，先不理了