提 PR 之后，最耗人的环节经常是第一眼看进去。
Reviewer 要先弄清楚这个 PR 改了哪些文件、有没有漏测、有没有安全风险、需求有没有做偏。等这些扫完，才轮到真正的设计讨论。团队忙一点，这一轮很容易卡半天。
小G今天想推荐的 PR-Agent，干的就是这件事：先读 diff、写描述、提建议、回答问题，把第一轮机械 Review 交给它。
它替不了人工 Review，但很适合做第一轮筛查。
先分清 PR-Agent 和 Qodo
这篇只写开源仓库 The-PR-Agent/pr-agent。
PR-Agent 是开源的 AI Code Review Agent，也是 Qodo 的 community-maintained legacy project（由社区维护的旧项目）；Qodo 另有自己的免费版和商业代码审查产品，别把两者混着用。
PR-Agent 目前在 GitHub 上有约 12k+ Star。
注意 Docker 镜像换了命名空间：从 0.34.2开始发布到 pragent/pr-agent；旧的 codiumai/pr-agent只保留到 v0.31，不再推新镜像。
它具体能帮你做什么
PR-Agent 适合放在人正式 Review 之前。
比如一个 PR 改了十几个文件，Reviewer 第一眼最想知道的是：
- 这个 PR 在改什么？
- 哪些文件要优先看？
- 有没有明显风险点？
- 代码建议能不能贴到 diff 旁边？
- 我能不能在 PR 里直接问某段改动？
PR-Agent 的命令基本围着这些动作走：/describe生成 PR 标题、类型、摘要和文件级 walkthrough；/review给 Review 反馈、潜在问题、安全关注点和 Review effort；/improve给代码建议；/ask用来追问 PR；/update_changelog、/add_docs、/generate_labels更偏辅助。
小G更愿意把它当成第一轮筛查工具：少做一轮机械阅读，把人的时间留给业务语义、架构取舍和最终判断。
如果团队本来就有 Code Review Checklist，也可以把这些规则沉到 PR-Agent 的配置里，比如功能是否符合需求、边界条件有没有处理、异常和权限有没有兜住、有没有明显重复代码。这样它输出的就不是泛泛的"代码质量建议"，而是贴近团队 Review 习惯的第一轮检查。
工作原理
PR-Agent 的工作原理是：接收 PR 评论或 CLI 命令后，先读取 PR 状态和 diff，压缩并优先处理关键改动，再根据 /describe、/review、/improve、/ask等指令调用对应工具，把结果写回 PR 描述、评论、标签或行内建议。
接入起来其实很轻
GitHub Action 的接入成本低。最短路径就是一个 workflow 文件，加上 OPENAI_KEY和 GITHUB_TOKEN。放进 .github/workflows/pr-agent.yml后，新 PR 打开时就能跑。
name: PR Agent on: pull_request: types: [opened, synchronize] jobs: pr_agent_job: runs-on: ubuntu-latest steps: - name: PR Agent action step uses: the-pr-agent/pr-agent@v0.38.0 env: OPENAI_KEY: ${{ secrets.OPENAI_KEY }} GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
另一处是输出贴着 PR 流程走。
/describe先让 PR 好读，/review做第一轮反馈，/improve给建议，/ask回答追问。你可以让它自动跑，也可以在 PR 评论区手动打 slash command。
它也会补上下文：PR compression 处理大小不同的 PR，dynamic context 在 diff 附近扩上下文，还能读取 GitHub/GitLab Issues 或 Jira 里的 ticket 信息。
裸 diff 很容易丢掉"为什么这么改"。
这里其实就是一个很典型的 AI Workflow：先根据 diff 生成描述，再评估风险和 review effort，最后给出可改进点。它不是单次生成完就结束，而是把 PR 摘要、审查、追问和改进建议串到同一个 Review 流程里。
传统 Workflow 与 AI Workflow 对比
AIGuide：AI 应用开发、AI 编程实战与面试指南 的 AI 工作流中的 Workflow、Graph 与 Loop文章有详细介绍 AI Workflow 里"生成、评估、修正"这类循环机制。
部署和模型选择也比较灵活。
部署方式覆盖 CLI、GitHub Actions、Docker、自托管和 webhook；GitHub、GitLab、Bitbucket、Azure DevOps、Gitea 这些平台都能接，模型侧也能配置 OpenAI、Claude、DeepSeek、Gemini、Bedrock、Ollama 等。
本地 CLI 可以直接这样跑：
pip install pr-agent export OPENAI_KEY=your_key_here pr-agent --pr_url https://github.com/owner/repo/pull/123 review
从源码仓库运行时，也可以用 python -m pr_agent.cli形式：
python -m pr_agent.cli --pr_url=<pr_url> review python -m pr_agent.cli --pr_url=<pr_url> describe python -m pr_agent.cli --pr_url=<pr_url> improve
每个平台细节不一样，别直接搬到生产。GitLab 可以用 pragent/pr-agent:latest放进 .gitlab-ci.yml；Azure DevOps 可以用 pipeline container 跑 describe、review、improve；Gitea 走 webhook server。
几个要提前知道的限制
PR-Agent 开源，不代表代码一定不离开你的环境。
如果你配置 OpenAI、Claude 或其他云模型，PR 内容会交给对应模型供应商处理。自托管只意味着 PR-Agent 跑在你机器上，PR 内容仍然会发到你配置的 LLM 供应商。
如果想全走本地模型，可以接 Ollama，但更适合先从 /ask这类轻任务试起，别直接当生产级代码分析的默认项。
平台侧也有差异。Bitbucket Pipeline 不支持在 PR 上发表评论；Azure Pipelines 缺少从 PR 评论触发 workflow 的能力。跨平台能跑，不等于每个平台体验完全一样。
怎么开始
如果你只是在 GitHub 仓库里试，小G建议先开 /describe和 /review，看摘要、风险提示和误报情况。输出稳定后，再决定要不要自动跑 /improve。
配置上也不用一步到位。github_action_config.auto_review、github_action_config.auto_describe、github_action_config.auto_improve都能单独控制；团队自己的 review 要求，可以放到 .pr_agent.toml或环境变量里。
先看误报率，再决定要不要让它自动跑 /improve。
如果后面要把它接成质量门禁，最好留一小批历史 PR 做固定样本，记录哪些建议被采纳、哪些是误报、哪些问题人工 Reviewer 后来才发现。AI Review 也需要评测闭环，不然很容易变成"这次感觉还行"的体感判断。AIGuide：AI 应用开发、AI 编程实战与面试指南 的 AI 应用评测体系文章有详细介绍 Golden Set、Trace 回放和线上灰度这类评测方法。
写在最后
如果你的团队已经有稳定 PR 流程，只是第一轮阅读和重复检查太耗时间，PR-Agent 可以先从 GitHub Action 或 CLI 接进去试。它适合做第一层自动化：先生成描述，先扫明显问题，先把可疑点贴出来，再让人判断哪些建议要采纳。