Kilo Code GitHub 代码评审通过 GitHub App 配置 AI Review Agent 与自动化 PR 审查【免费下载链接】kilocodeKilo is the all-in-one agentic engineering platform. Build, ship, and iterate faster with the most popular open source coding agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kilocode本文基于 Kilo Code 官方文档 GitHub Code Reviews 展开完整覆盖前置条件、KiloConnect GitHub App 安装、Review Agent 配置项、PR 事件触发规则与故障排查。读完本篇你可以独立完成「GitHub 连接 → 评审配置 → PR 自动评审」的全链路搭建并理解评审背后的队列化执行机制与基于REVIEW.md的仓库级评审策略定制。一、功能定位与前置条件Kilo Code 的 Code Reviews 功能通过一个GitHub App与 GitHub 集成自动用 AI 评审拉取请求当 PR 被打开、更新或被标记为 ready for review 时Review Agent 会分析变更并直接把反馈发到 PR 上。它与本地/review命令、以及仓库中提供的 Kilo GitHub Action在 issue/PR 评论里输入/kilo、/kc触发按需任务是相互独立的能力本篇聚焦「事件驱动的自动评审」这一条主线。启用前需要满足三个前提一个 Kilo Code 账号Kilo 个人控制台 / 组织控制台均可一个能访问目标仓库的 GitHub 账号且具备为目标仓库安装 GitHub App 的权限Kilo Code credits——AI 模型在评审过程中推理会消耗 credits在有限 beta 期内评审的算力与运行时间本身免费详见 Code Reviews 概览。二、Step 1安装并授权 KiloConnect GitHub AppGitHub 侧的接入通过 Kilo 的 Integrations 页完成标准流程是进入个人 Dashboard 或组织 Dashboard 的 Integrations 页在 GitHub 面板上点击Configure跳转到 GitHub 授权KiloConnectApp选择要连接的 GitHub 账号或组织选择仓库访问范围——All repositories若计划跨项目使用 Cloud Agents / Deploy 时推荐或Only selected repositories点击Install Authorize完成后回到 Kilo 页面会显示Connected状态。该 GitHub App 申请以下仓库权限每一项目对应评审链路中的一个具体动作PermissionAccessPurposePull requestsRead Write发布评审意见review commentsRepository contentsRead读取并分析代码IssuesRead Write发布总结评论、添加 reaction如评审中的 标记MetadataRead列举仓库列表如果后续发现仓库列表中缺少仓库或组织限制第三方 App需要回到 GitHub App 设置中确认 KiloConnect 安装在正确的组织上、且仓库范围包含目标仓库这一点与 Integrations 文档的 GitHub 排查章节 一致。三、Step 2配置 Review AgentApp 连接完成后进入Code Reviews配置页个人维度在控制台的 code-reviews 页组织维度在 组织 → Code Reviews完成以下配置打开Enable AI Code Review开关配置偏好项AI Model— 从可用模型中选择默认Claude Sonnet 4.5Review Style— Strict、Balanced 或 Lenient 三档Repository Selection— 所有仓库或只选指定仓库Focus Areas— Security、performance、bugs、style、testing、documentationUse REVIEW.md— 启用后评审 Agent 会从base 分支读取仓库内的REVIEW.md加载仓库专属评审指引包括子代理sub-agent用法点击Save Configuration。其中两个配置项值得展开Review Style 的含义三种评审风格决定了反馈的严格程度定义见 Code Reviews 概览风格行为适用场景Strict标记所有潜在问题强调正确性、质量与安全关键代码路径、生产服务Balanced最常用选项优先清晰与实用只暴露重要问题、不制造噪音日常 PR 评审Lenient只标记关键问题反馈轻量且鼓励式探索性 PR、原型、早期 WIPFocus Areas 的含义Focus Areas 用来收窄 Agent 的关注面可选维度及其典型检查点包括Security— SQL 注入、XSS、不安全 API、密钥与凭据泄露Performance— N1 查询、低效循环、高复杂度函数Bugs— 逻辑错误、边界条件失败、错误假设Style— 格式、命名规范、可读性改进Testing— 缺失或不足够的测试、未覆盖的逻辑路径Documentation— 缺失注释、不清晰的 API。用 REVIEW.md 把评审策略交给仓库当评审策略应该跟着代码仓库走、而不是只存在控制台配置里时可以使用REVIEW.md在仓库根目录创建该文件提交到 PR/MR 所使用的 base 分支然后在 Code Reviews 设置中开启Use REVIEW.md。几个关键机制来自 overview 文档只从 base 分支读取而非 feature 分支——防止一个未评审的变更改写「用来评审它自己」的策略文件被禁用、缺失、为空或不可读时回退到内置指引超过 10,000 字符会被截断并在评审总结的 footer 中注明。本仓库根部就有一份可直接参考的 REVIEW.md它展示了「不重复 CI 已覆盖的检查lint、typecheck、测试失败、聚焦 CI 抓不到的 bug 与设计问题、以及针对 fork 合并卫生的专项规则」这类仓库级策略的写法。REVIEW.md还能覆盖默认的子代理调度策略。默认情况下Code Reviews 只有在子代理能实质性提升覆盖率时才使用评审 Agent 读完 diff 后估算变更文件数与变更行数取两个信号触发的最大档位。Diff 规模默认行为原因Tiny≤2 个文件且 100 变更行0 个子代理直接评审极小变更下协调开销高于覆盖收益Small3-5 个文件或 100-300 变更行至多 1 个子代理针对一个独立的风险区域一次聚焦的二次检查有帮助且不会制造重复/低信号结论Medium 及以上≥6 个文件或 300 变更行完整 6 个子代理按独立区域分片大 diff 受益于跨文件、跨领域、跨风险类别的并行覆盖子代理是只读的、不直接发评论只返回带 path、line、severity、rationale 的结论主评审仍负责验证、去重、确认行内评论落在合法 diff 行上并发布最终评论与总结。REVIEW.md可以改变评审策略与子代理用法但不能覆盖 Kilo 的硬安全约束只读模式、非交互执行、平台 API 指令、diff 行规则、去重规则与输出格式要求。四、Step 3触发规则——哪些 PR 事件会跑评审配置完成后Review Agent 的自动触发规则如下PR EventTriggers ReviewPR opened✅ YesNew commits pushed to PR✅ YesPR reopened✅ YesDraft PR marked ready✅ YesDraft PR opened❌ SkippedPR closed❌ No另外由机器人如依赖升级、自动化账号等 bot打开的 PR 默认不会被自动评审以避免把 credits 和通知消耗在非人工变更上。五、评审运行时会发生什么一次评审被触发后PR 上出现一个 reaction——表示 Kilo 正在评审所选模型分析 diff 与变更文件只评审变更过的文件不评审整个仓库Agent 发布一条summary comment总体结论针对具体行的inline comments问题与建议严重级别标签critical、warning、info。当你推送新提交时上一次评审会被自动取消避免过时反馈针对最新提交启动新评审若已存在旧的 summary comment会被原地更新update in place而不是堆叠新评论。底层执行模型数据库队列 每 owner 并发槽位从本仓库的贡献者架构文档 Automation Services Architecture 可以确认 Code Review 服务在 Kilo Cloud 中的静态源结构触发Pull-request webhook 或 review dispatch排队评审以 pending 行的形式等待在数据库队列中并发控制Next.js dispatch 层按 owner个人或组织维护独立的并发槽位个人与组织路径彼此隔离编排槽位可用时启动CodeReviewOrchestratorDurable Objectcode-review-infra保持 Cloud Agent 连接存活恢复Worker 更新数据库并触发下一个 pending 评审的派发。这也解释了上面的运行时行为同一 PR 的评审是单槽位串行的所以新提交到来时旧评审被取消、新评审在队列中接续而「评审容量在 beta 期可能对超大 PR 限流」则对应队列与超时告警机制。该描述基于贡献文档中的静态源说明反映的是已支持的代码路径不代表生产环境的实时开启状态。六、仓库选择范围All repositories—— GitHub App 可访问的每个仓库的 PR 都会触发评审Selected repositories—— 只有你在配置中勾选的仓库才触发。仓库列表从 GitHub 同步而来可在 Code Reviews 配置页手动刷新。若选定的仓库不在允许列表里PR 事件会被直接忽略——这是「评审不触发」排查清单中常见的一项。七、Troubleshooting 全清单官方文档给出四类故障的排查路径此处完整保留1. 评审不触发Reviews are not triggering确认 KiloConnect GitHub App 已安装且对该仓库有访问权限检查 Code Reviews 配置中 Review Agent 是否已enabled若使用「Selected repositories」模式确认该仓库在允许列表中确认 PR 不是 draft。2. 评审失败Reviews are failing在 Code Reviews 页面查看具体某次评审的错误详情确认 Kilo Code credits 充足超大 PR 可能超时——考虑把变更拆成更小的 PR评审受固定时间上限约束beta 期超大 PR 还可能被限流。3. GitHub App 缺少权限进入 GitHub Settings → Applications → KiloConnect → Configure对照上表的权限清单逐项核对若权限发生过变更可能需要重新授权re-authorize。4. 出现重复评论Duplicate comments系统会对「同一 PR 同一 commit SHA」的评审自动去重。若仍看到重复评论可能来自旧版本——推送一个新提交触发一次全新评审即可。八、边界与已知限制结合 Code Reviews 概览文档 的 Limitations 章节使用该功能时需要知道评审有固定时间上限超大 PR 建议拆分Agent 只评审变更文件不评审整个仓库高度动态或强领域相关的代码建议在REVIEW.md中补充上下文只在选定仓库上自动运行beta 期评审容量可能对极大 PR 限流bot 打开的 PR 默认跳过。九、与 Kilo GitHub Action 的区分仓库的 github/README.md 与 action.yml 提供的是另一条 GitHub 集成路线把 Kilo 作为 GitHub Action 装进仓库如kilo github install可引导安装 KiloConnect App、创建 workflow 并配置 secrets在 issue 或 PR 评论中写/kilo、/kc让 Kilo 在 Actions runner 中执行解释、修复、按行评审等按需任务。它与本文的自动 Code Reviews 不冲突——前者是「评论触发的按需代理」后者是「PR 事件触发的自动评审」两者都依赖 KiloConnect App 完成认证。十、延伸阅读Code Reviews 概览评审风格、Focus Areas、REVIEW.md子代理策略与本地/review用法GitLab Code ReviewsGitLab 侧对应流程OAuth/PAT 接入、webhook 自动管理、bot 身份IntegrationsGitHub/GitLab/DoltHub 接入全流程与连接管理本地评审提示词/review命令的完整 scope 选择规则与输出格式可对照理解云端评审 Agent 的评审轨道security、performance、business logic、deploy safety、duplication、dead code与严重级别CRITICAL / WARNING / SUGGESTION设计。【免费下载链接】kilocodeKilo is the all-in-one agentic engineering platform. Build, ship, and iterate faster with the most popular open source coding agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kilocode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考