Kilo Gas Town 代码评审指南Refinery 代理驱动的自动化审查与合并流水线【免费下载链接】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/kilocodeGas Town 是 Kilo 平台内置的自主代理编排工作区编码代理polecat负责写代码评审代理refinery专职审查、验证并把关所有进入代码库的改动。本文以 Gas Town 的code-review文档为主体系统讲解其微对抗评审循环micro-adversarial loop、两种合并策略、车队级convoy多层级评审机制以及评审配置参数与反馈处理流程。读完本文你将掌握如何配置 review mode、review gates、merge strategy 等核心参数理解每颗 bead工作单元从提交、评审、修订到合并的完整生命周期以及如何将 Gas Town 的自动评审与 Kilo Code Review 组合成自动化评审 人工辅助评审的双层流水线。评审流水线每段代码在合并前必经的关卡在 Gas Town 中每一段由代理产出的代码在合并前都会经过自动化评审。专职的refinery 代理负责批判、验证并把关最终落入代码库的内容——它扮演的是质量守门员角色。当某个 polecat编码代理完成一颗 bead 并推送其分支后工作便进入评审流水线正确性Correctness—— 代码是否完成了任务所要求的内容风格Style—— 是否遵循项目约定完整性Completeness—— 是否包含测试边界情况是否被处理安全性Safety—— 是否存在安全漏洞、数据泄露或破坏性变更评审完成后refinery 要么批准并合并要么把具体的修改反馈发回给 polecat。这一过程可以在 rig 页面实时观察当一颗 bead 处于评审中in review状态时界面上会显示 refinery 正在评估 polecat 的工作。从 bead 生命周期看评审中只是其中的一个状态节点。完整的状态机详见 concepts.md包括open等待代理接取、in_progress代理正在处理、in_review工作完成等待 refinery 评审、closed成功完成并合并、failed代理耗尽重试次数后失败。其中merge_request类型的 bead 本身就是交由 refinery 评审这一动作的载体。微对抗循环为什么两个代理比一个代理自审更好Gas Town 评审系统的核心洞察是对抗式迭代adversarial iteration不是让一个代理直接产出最终答案而是让两个目标不同的代理通过张力推动产出不断改进。这一模式与单个代理自我评审有本质区别自我评审存在确认偏差confirmation bias—— 写代码与评代码的是同一个大脑对抗式评审制造真正的张力—— refinery 与 polecat 的优先级不同前者追求质量把关后者追求完成任务每一轮修订都能被度量地改进产出—— 因为反馈是具体且可执行的。循环的实际运转一颗典型的 bead 会经历 12 轮修订循环循环阶段发生什么编写WritePolecat 读取任务、编写代码、运行测试、推送分支评审 1Review 1Refinery 发现 2 个问题缺少测试用例、命名不一致修订 1Revise 1Polecat 补充测试、修正命名、再次推送评审 2Review 2Refinery 批准 —— 代码达到质量线合并Merge代码落入目标分支防无限循环机制当修订循环失败 3 次后bead 不会永远循环下去而是升级escalate为需要人工介入的状态——这既避免了死循环也确保高难度代码不会在缺乏足够质量把关的情况下蒙混过关。从 concepts.md 可以进一步看到这一对抗循环与车队convoy结合后会形成逐层累积的效果探索代码库 → 评审合并到车队分支设计 schema基于前一步上下文→ 评审合并实现功能基于前两步→ 评审合并最后在合并到 main 之前整个车队分支作为整体接受一次landing review。每个阶段都被批判、被打磨。合并策略Direct Merge 与 Pull Request ModeGas Town 支持两种合并策略可在每个 town 或每个 rig 级别分别配置。直接合并Direct Mergerefinery 直接将改动合并到目标分支车队功能分支或 main不创建 GitHub PR。这种方式更快但单个合并的可见性较低。适合场景可信的代理产出、内部项目、快速迭代。拉取请求模式Pull Request Moderefinery 为每次合并创建 GitHub PRPR 中包含变更差异diffrefinery 的评审意见CI 的状态检查结果你可以配置 PR 在 refinery 批准后自动合并或要求人工审批后才合并。适合场景生产代码库、团队环境、需要审计轨迹。关于合并策略的配置位置在 town 的 Settings 中设置合并策略direct/pr并且任何 town 级设置都可以在 rig 级别覆盖——例如为生产代码库设置更严格的评审关卡或为纯文档仓库关闭评审详见 settings.md 的 Per-Rig Overrides 一节。车队级评审在单颗 bead 评审之上的额外一层车队convoy在逐 bead 评审之外增加了一层评审机制。车队是多 bead 工作流任务之间可以存在依赖关系共享一个功能分支reconciler 确保只有依赖满足时 bead 才会被派发。评审同样分多层进行评审层检查什么谁评审逐 bead 评审单个贡献的质量Refinery 代理落地评审Landing合并后特性的整体一致性Refinery 代理人工评审可选业务逻辑、架构你的团队车队合并模式也有两种选择详见 settings.mdreview-then-land默认每颗 bead 先合并到功能分支再通过一次落地评审合并到 main——质量保证最强但耗时更长review-and-merge每颗 bead 评审后直接合并到 main不使用功能分支——适合简单任务或希望即时反馈的场景。与 Kilo Code Review 组合自动化与人工判断兼得Gas Town 的 refinery 独立工作但将它和 Kilo Code Review 组合起来可以构建更强的流水线代理编写→ 代理级 refinery 评审快速、自动化代码以 PR 落地→ Kilo Code Review 提供人类可读的评审更深入、更有上下文人工批准→ 代码发布。这样既获得了自动化对抗评审的速度又保留了 AI 辅助人工评审的判断力——两种方式的优势兼得。合并队列一览所有进行中与已完成的评审合并队列页面merge queue集中展示你的 town 中所有进行中与已完成的评审是观察评审流水线全貌的入口。每一颗 bead 的评审反馈交换过程都记录在其事件历史event history中便于回溯。评审配置Town Settings → Reviewrefinery 的行为可以在Town Settings → Review中自定义。核心配置项如下设置项可选值默认值review_modealways/never/pr_onlyalwaysmerge_strategydirect/prdirectauto_mergetrue/falsetruereview_gates严格度等级1–53max_review_cycles允许的修订尝试次数3评审模式Review Modealways—— 每颗 bead 都经过 refinery 评审推荐never—— 跳过评审polecat 完成即直接合并快但有风险pr_only—— 只评审会创建 PR 的工作。评审关卡Review Gates关卡等级越高refinery 越严格Level 1—— 基础健全性检查能编译、不破坏测试Level 3—— 标准检查风格、测试、正确性—— 默认等级Level 5—— 严格检查架构评审、性能、安全。从 settings.md 可以看到等级越高 refinery 拒绝的频率越高但产出质量也越高。评审等级与max_review_cycles默认 3共同决定了修订—拒绝的边界超过修订上限的 bead 会转为failed状态并触发升级。除评审外town 级配置还包括模型配置默认模型、按角色覆盖 mayor/refinery/polecat 的模型、用于会话标题生成与explore子代理的小模型、Git 与认证GitHub App 安装为必需用于获取克隆与推送的安装令牌GitHub PAT 为强烈推荐用于让提交、分支与 PR 以你的身份出现在 git 历史中、代理并发限制每 rig 最大 polecat 数默认 2可调至 5、告警间隔reconciler 检查工作的频率活动时默认 5 秒空闲时默认 60 秒、环境变量与自定义指令注入每个代理系统提示词的约定与约束。处理评审反馈与升级当 refinery 拒绝一次提交时它会提供具体、可操作的反馈。polecat 收到反馈后进行修订反馈交换的完整过程可以在 bead 的事件历史中查看。升级路径如果一颗 bead 连续 3 次评审失败达到max_review_cycles上限它会转为failed状态并为人工介入创建一个escalation升级事项。escalation 同时也是 bead 类型之一详见 concepts.md代表代理无法解决、需要人类输入的 issue。这一机制的价值在于既防止了无限循环浪费算力又确保了困难代码不会在缺乏适当质量把关的情况下被放行。小结Gas Town 的代码评审体系可以概括为三层把关微对抗循环polecat 编写 → refinery 批判 → 修订再提交以两代理的张力替代单代理自审的确认偏差合并把关direct与pr两种策略配合auto_merge、review_gates、max_review_cycles等可调参数多层评审逐 bead 评审 车队落地评审 可选人工评审并与 Kilo Code Review 组合形成自动化与人工判断兼备的完整流水线。其核心设计理念始终如一不要让写代码的大脑独自决定代码是否合格——通过角色分离的对抗式迭代让每段代码在进入主干分支前都接受独立、严格且可度量的质量审查。相关完整文档可继续查阅 code-review.md本文所依据的主体文档、concepts.mdtown / bead / convoy / rig / 各代理角色与 reconciler 的概念体系以及 settings.md全部配置项的完整说明。【免费下载链接】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），仅供参考 Kilo Gas Town 代码评审指南：Refinery 代理驱动的自动化审查与合并流水线
Kilo Gas Town 代码评审指南Refinery 代理驱动的自动化审查与合并流水线【免费下载链接】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/kilocodeGas Town 是 Kilo 平台内置的自主代理编排工作区编码代理polecat负责写代码评审代理refinery专职审查、验证并把关所有进入代码库的改动。本文以 Gas Town 的code-review文档为主体系统讲解其微对抗评审循环micro-adversarial loop、两种合并策略、车队级convoy多层级评审机制以及评审配置参数与反馈处理流程。读完本文你将掌握如何配置 review mode、review gates、merge strategy 等核心参数理解每颗 bead工作单元从提交、评审、修订到合并的完整生命周期以及如何将 Gas Town 的自动评审与 Kilo Code Review 组合成自动化评审 人工辅助评审的双层流水线。评审流水线每段代码在合并前必经的关卡在 Gas Town 中每一段由代理产出的代码在合并前都会经过自动化评审。专职的refinery 代理负责批判、验证并把关最终落入代码库的内容——它扮演的是质量守门员角色。当某个 polecat编码代理完成一颗 bead 并推送其分支后工作便进入评审流水线正确性Correctness—— 代码是否完成了任务所要求的内容风格Style—— 是否遵循项目约定完整性Completeness—— 是否包含测试边界情况是否被处理安全性Safety—— 是否存在安全漏洞、数据泄露或破坏性变更评审完成后refinery 要么批准并合并要么把具体的修改反馈发回给 polecat。这一过程可以在 rig 页面实时观察当一颗 bead 处于评审中in review状态时界面上会显示 refinery 正在评估 polecat 的工作。从 bead 生命周期看评审中只是其中的一个状态节点。完整的状态机详见 concepts.md包括open等待代理接取、in_progress代理正在处理、in_review工作完成等待 refinery 评审、closed成功完成并合并、failed代理耗尽重试次数后失败。其中merge_request类型的 bead 本身就是交由 refinery 评审这一动作的载体。微对抗循环为什么两个代理比一个代理自审更好Gas Town 评审系统的核心洞察是对抗式迭代adversarial iteration不是让一个代理直接产出最终答案而是让两个目标不同的代理通过张力推动产出不断改进。这一模式与单个代理自我评审有本质区别自我评审存在确认偏差confirmation bias—— 写代码与评代码的是同一个大脑对抗式评审制造真正的张力—— refinery 与 polecat 的优先级不同前者追求质量把关后者追求完成任务每一轮修订都能被度量地改进产出—— 因为反馈是具体且可执行的。循环的实际运转一颗典型的 bead 会经历 12 轮修订循环循环阶段发生什么编写WritePolecat 读取任务、编写代码、运行测试、推送分支评审 1Review 1Refinery 发现 2 个问题缺少测试用例、命名不一致修订 1Revise 1Polecat 补充测试、修正命名、再次推送评审 2Review 2Refinery 批准 —— 代码达到质量线合并Merge代码落入目标分支防无限循环机制当修订循环失败 3 次后bead 不会永远循环下去而是升级escalate为需要人工介入的状态——这既避免了死循环也确保高难度代码不会在缺乏足够质量把关的情况下蒙混过关。从 concepts.md 可以进一步看到这一对抗循环与车队convoy结合后会形成逐层累积的效果探索代码库 → 评审合并到车队分支设计 schema基于前一步上下文→ 评审合并实现功能基于前两步→ 评审合并最后在合并到 main 之前整个车队分支作为整体接受一次landing review。每个阶段都被批判、被打磨。合并策略Direct Merge 与 Pull Request ModeGas Town 支持两种合并策略可在每个 town 或每个 rig 级别分别配置。直接合并Direct Mergerefinery 直接将改动合并到目标分支车队功能分支或 main不创建 GitHub PR。这种方式更快但单个合并的可见性较低。适合场景可信的代理产出、内部项目、快速迭代。拉取请求模式Pull Request Moderefinery 为每次合并创建 GitHub PRPR 中包含变更差异diffrefinery 的评审意见CI 的状态检查结果你可以配置 PR 在 refinery 批准后自动合并或要求人工审批后才合并。适合场景生产代码库、团队环境、需要审计轨迹。关于合并策略的配置位置在 town 的 Settings 中设置合并策略direct/pr并且任何 town 级设置都可以在 rig 级别覆盖——例如为生产代码库设置更严格的评审关卡或为纯文档仓库关闭评审详见 settings.md 的 Per-Rig Overrides 一节。车队级评审在单颗 bead 评审之上的额外一层车队convoy在逐 bead 评审之外增加了一层评审机制。车队是多 bead 工作流任务之间可以存在依赖关系共享一个功能分支reconciler 确保只有依赖满足时 bead 才会被派发。评审同样分多层进行评审层检查什么谁评审逐 bead 评审单个贡献的质量Refinery 代理落地评审Landing合并后特性的整体一致性Refinery 代理人工评审可选业务逻辑、架构你的团队车队合并模式也有两种选择详见 settings.mdreview-then-land默认每颗 bead 先合并到功能分支再通过一次落地评审合并到 main——质量保证最强但耗时更长review-and-merge每颗 bead 评审后直接合并到 main不使用功能分支——适合简单任务或希望即时反馈的场景。与 Kilo Code Review 组合自动化与人工判断兼得Gas Town 的 refinery 独立工作但将它和 Kilo Code Review 组合起来可以构建更强的流水线代理编写→ 代理级 refinery 评审快速、自动化代码以 PR 落地→ Kilo Code Review 提供人类可读的评审更深入、更有上下文人工批准→ 代码发布。这样既获得了自动化对抗评审的速度又保留了 AI 辅助人工评审的判断力——两种方式的优势兼得。合并队列一览所有进行中与已完成的评审合并队列页面merge queue集中展示你的 town 中所有进行中与已完成的评审是观察评审流水线全貌的入口。每一颗 bead 的评审反馈交换过程都记录在其事件历史event history中便于回溯。评审配置Town Settings → Reviewrefinery 的行为可以在Town Settings → Review中自定义。核心配置项如下设置项可选值默认值review_modealways/never/pr_onlyalwaysmerge_strategydirect/prdirectauto_mergetrue/falsetruereview_gates严格度等级1–53max_review_cycles允许的修订尝试次数3评审模式Review Modealways—— 每颗 bead 都经过 refinery 评审推荐never—— 跳过评审polecat 完成即直接合并快但有风险pr_only—— 只评审会创建 PR 的工作。评审关卡Review Gates关卡等级越高refinery 越严格Level 1—— 基础健全性检查能编译、不破坏测试Level 3—— 标准检查风格、测试、正确性—— 默认等级Level 5—— 严格检查架构评审、性能、安全。从 settings.md 可以看到等级越高 refinery 拒绝的频率越高但产出质量也越高。评审等级与max_review_cycles默认 3共同决定了修订—拒绝的边界超过修订上限的 bead 会转为failed状态并触发升级。除评审外town 级配置还包括模型配置默认模型、按角色覆盖 mayor/refinery/polecat 的模型、用于会话标题生成与explore子代理的小模型、Git 与认证GitHub App 安装为必需用于获取克隆与推送的安装令牌GitHub PAT 为强烈推荐用于让提交、分支与 PR 以你的身份出现在 git 历史中、代理并发限制每 rig 最大 polecat 数默认 2可调至 5、告警间隔reconciler 检查工作的频率活动时默认 5 秒空闲时默认 60 秒、环境变量与自定义指令注入每个代理系统提示词的约定与约束。处理评审反馈与升级当 refinery 拒绝一次提交时它会提供具体、可操作的反馈。polecat 收到反馈后进行修订反馈交换的完整过程可以在 bead 的事件历史中查看。升级路径如果一颗 bead 连续 3 次评审失败达到max_review_cycles上限它会转为failed状态并为人工介入创建一个escalation升级事项。escalation 同时也是 bead 类型之一详见 concepts.md代表代理无法解决、需要人类输入的 issue。这一机制的价值在于既防止了无限循环浪费算力又确保了困难代码不会在缺乏适当质量把关的情况下被放行。小结Gas Town 的代码评审体系可以概括为三层把关微对抗循环polecat 编写 → refinery 批判 → 修订再提交以两代理的张力替代单代理自审的确认偏差合并把关direct与pr两种策略配合auto_merge、review_gates、max_review_cycles等可调参数多层评审逐 bead 评审 车队落地评审 可选人工评审并与 Kilo Code Review 组合形成自动化与人工判断兼备的完整流水线。其核心设计理念始终如一不要让写代码的大脑独自决定代码是否合格——通过角色分离的对抗式迭代让每段代码在进入主干分支前都接受独立、严格且可度量的质量审查。相关完整文档可继续查阅 code-review.md本文所依据的主体文档、concepts.mdtown / bead / convoy / rig / 各代理角色与 reconciler 的概念体系以及 settings.md全部配置项的完整说明。【免费下载链接】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），仅供参考