CodeRabbit 用 AI 做 PR 审查，体验不错，但它是闭源 SaaS——代码和密钥都得过它的服务器。Colin McDonnell 写的 Pullfrog 换了一条路：整个机器人跑在你自己的 GitHub Actions 里，模型随便选，密钥自己管。对在意数据边界和成本控制的团队来说，这个思路值得认真看看。
它解决什么问题
日常仓库维护里有几件高频但低价值的活：
- PR 审查：大仓库每天几十个 PR，人工逐条看注释和风格，耗时且容易漏。
- Issue 分拣：新 issue 该标什么标签、分给谁、是不是重复，纯靠人判断效率低。
- CI 修复：流水线红了，很多时候是 lint 报错或依赖缺失，修法套路化但每次都要人去读日志。
Pullfrog 把这三件事交给 LLM 处理，但关键区别是——执行环境是你自己的 GitHub Actions runner，不是第三方服务器。这意味着代码不离开你的 GitHub 组织，密钥存在你的 repo secrets 里。
模型无关 + 自带密钥
Pullfrog 不绑定任何一家 LLM 厂商。它的架构是 model-agnostic：你传什么 provider 的 key，它就调什么模型。实际操作上：
- 用 OpenAI——传
OPENAI_API_KEY - 用 Anthropic——传
ANTHONY_API_KEY（或对应的环境变量） - 用自部署的 Ollama / vLLM——传自定义 endpoint
Bring-your-own-key 模型意味着没有中间商抽成，也没有统一计费。你的 API 费用直接发生在你和模型厂商之间，Pullfrog 不经手。
在仓库里跑起来：一个可复制的最小配置
下面是一个把 Pullfrog 接进仓库的完整 GitHub Actions workflow。你只需要改两处：YOUR_REPO_OWNER/YOUR_REPO_NAME 换成你的仓库，以及在 repo Settings → Secrets 里加上你选的 LLM API key。
# .github/workflows/pullfrog.yml
name: Pullfrog AI Review
on:
pull_request:
types: [opened, synchronize]
issues:
types: [opened]
permissions:
contents: read
pull-requests: write
issues: write
jobs:
review:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Run Pullfrog
uses: pullfrog/pullfrog@main
env:
# 选一个你用的 provider，把 key 存在 repo secrets 里
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
# 如果用 Anthropic，换成：
# ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
# 如果用自部署模型，加：
# LLM_ENDPOINT: ${{ secrets.LLM_ENDPOINT }}
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
部署前要做的事：
- 在仓库 Settings → Secrets and variables → Actions 里添加
OPENAI_API_KEY（或你选的 provider 对应的 key）。 GITHUB_TOKEN是 Actions 自动提供的，不需要手动加，但确保permissions块给了pull-requests: write和issues: write，否则机器人发不出评论。- 如果你用的是 GitHub Enterprise 或私有仓库，确认你的 runner 能访问外部 LLM API endpoint——有些企业网络会拦截。
三件事的具体运作方式
PR 审查
PR 打开或更新时，Pullfrog 拿到 diff，让 LLM 逐段分析，然后以 review comment 的形式直接贴在 PR 对应行上。和 CodeRabbit 类似，但审查逻辑和模型选择完全在你手里。你可以通过配置文件调整审查重点——比如只关注安全漏洞和性能问题，忽略风格细节。
Issue 分拣
新 issue 创建时触发。Pullfrog 读 issue 标题和正文，让 LLM 判断该打什么标签、是否和已有 issue 重复、建议指派给谁。结果以 issue comment 的形式回写。对标签体系稳定的仓库，这能省掉大量手动归类时间。
CI 修复
这是最有意思的部分。CI 失败后，Pullfrog 读日志，让 LLM 分析根因并生成修复建议。它不会自动提交修复（这是安全边界），而是把建议贴在 PR comment 里，比如"这个 lint 错误可以这样改"，附带具体代码片段。开发者确认后手动合并。
和 CodeRabbit 的取舍
| 维度 | CodeRabbit | Pullfrog |
|---|---|---|
| 部署位置 | 第三方 SaaS | 你自己的 GitHub Actions |
| 数据流向 | 代码 diff 经过 CodeRabbit 服务器 | 代码只在你和 LLM API 之间流动 |
| 模型选择 | 固定（CodeRabbit 选的模型） | 任意，你选 provider 和模型 |
| 费用 | 按仓库订阅计费 | 只付 LLM API 费用，无中间层 |
| 定制能力 | 有限（配置项固定） | 开源，可改审查逻辑和 prompt |
| 维护成本 | 零 | 需要自己维护 workflow 和 key |
简单说：想省心、不在乎代码过第三方服务器——CodeRabbit 开箱即用。想控制数据边界、调模型、改审查策略——Pullfrog 更合适，但你要承担一点运维。
上手前的检查清单
- API 成本估算：先在一个低频仓库试跑一周，观察 LLM 调用量。PR 审查每次大概消耗几千 token，issue 分拣几百，CI 修复看日志长度。用 GPT-4o-mini 或 Claude Haiku 做日常审查，成本很低；复杂审查再切强模型。
- 权限最小化：workflow 的
permissions只给write在pull-requests和issues上，不给contents: write，防止机器人意外修改代码。 - Prompt 定制：Pullfrog 开源，审查 prompt 可以改。如果你的仓库有特定规范（比如"禁止使用
eval"、"所有 API 必须有 rate limit"），把这些规则写进 prompt，比通用审查更有价值。 - 冷启动策略：先只开 issue 分拣，观察一周效果；满意后再开 PR 审查；CI 修复最后接。逐步放量比一次性全开风险小。
Pullfrog 目前还在早期阶段，文档和生态不如 CodeRabbit 成熟，但"在 Actions 里跑、模型自选、密钥自管"这个架构方向是对的。如果你的团队已经在用 GitHub Actions 做自动化，加一个 Pullfrog workflow 是改动最小的一步。