Kilo Gas Town 核心概念全解析Town、Bead、Convoy、Rig 与多智能体编排架构【免费下载链接】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 推出的自主智能体编排平台用一组小而可组合的原语primitive把「一组 AI 智能体在代码库上协作」这件事结构化Town持久化工作区、Bead最小工作单元、Convoy多任务依赖工作流、Rig仓库连接、Polecat/Refinery/Mayor编码、评审、协调三类智能体。本文基于 Gas Town 概念文档 展开并结合仓库内 快速开始、设置、代码评审、Mayor 指南 等文档帮助你完整掌握这套编排模型的每个构件、它们之间的调用关系以及如何配置和观察它们工作。Towns团队的持久化工作区Town城镇是智能体在你的代码上运作的持久化工作区。它是一个「团队的 workspace」会随时间积累机构化知识——城镇里的智能体可以从「已构建、已评审、已合并」的历史中持续学习。一个 town 维护四类状态Configuration配置——模型选择、合并策略、评审设置、自定义指令。详细配置项见 设置文档包括默认模型、per-role 模型覆盖、review mode、merge strategy 等。Agent state智能体状态——存在哪些智能体、各自在做什么、具备什么能力。可通过 Mayor 的gt_list_agents工具查询每个 rig 中所有智能体的角色与状态见 Mayor 指南。Work history工作历史——每一个被创建、被处理、被评审、被关闭的 bead 的完整记录。town 的 beads 页面提供按状态open / in_progress / in_review / closed / failed、类型、rig 的过滤视图见 Sling Work 文档。Rig connections仓库连接——哪些仓库已连接、各自如何配置。从所有权角度一个 town 可以是个人的归你所有也可以是组织的团队共享。创建第一个 town 的流程见 快速开始首次访问 Gas Town 时直接进入新建引导命名后即可添加 rig 连接仓库。Beads最小工作单元与生命周期Bead珠子是工作的基本单元。每一个任务、评审和协调动作都表示为一个带生命周期的 bead状态含义open等待智能体领取in_progress某个智能体正在处理in_review工作已完成等待 refinery 评审closed成功完成并已合并failed无法完成智能体耗尽重试次数在 Sling Work 文档 中可以看到这套生命周期在 UI 上的完整映射rig 页面的 kanban 看板把 bead 按 open / in progress / in review / closed 分列实时展示reconciler 分发智能体后 bead 自动在各列间流动。Bead 类型类型用途issue编码任务——bug 修复、功能开发、重构merge_request交给 refinery 的评审任务convoy多步骤工作流的容器escalation智能体无法解决的问题——需要人工介入message智能体之间的通信bead 还支持优先级字段low、medium默认、high、critical。当多个 bead 等待智能体时高优先级的先被分发见 Sling Work 文档。当某个 bead 反复失败时会生成一条escalation类型记录等待人类确认——这对应 Mayor 工具中的gt_escalation_acknowledge确认已审阅的升级项。Convoys把复杂工作表达为有向图Convoy车队是一种多 bead 工作流任务之间可以互相依赖。它不要求你「一次抛出一堆孤立任务」而是让你把复杂工作表达为一个有向图directed graph。创建 convoy 时需要定义三样东西Tasks任务——需要做什么每个任务都会变成一个 beadDependencies依赖——哪些任务必须先完成后续任务才能开始Feature branch功能分支——convoy 工作落地的共享分支。Reconciler协调器保证只有依赖满足时 bead 才会被分发这意味着后置智能体天然地在已验证的前置工作之上构建。每个任务从convoy feature branch出发该分支累积所有已合并的前置工作refinery 针对 convoy 分支评审每个子 PR所有 bead 关闭后会进行一次landing review落地评审把合并后的完整 diff 作为一个整体检查再合并到 main见 Sling Work 文档。Staged Convoys暂存车队Convoy 可以暂存staged——被创建但不会立即启动。这让你在智能体开始执行前先审查计划确认任务拆分合理、依赖顺序正确之后再「解除暂存」正式开工un-stage。暂存行为可在 town 设置中作为默认值配置staged convoys default为true时新 convoy 默认以暂存状态创建见 设置文档。Convoy 还支持两种合并模式设置文档review-then-land默认——每个 bead 先合并到功能分支再通过 landing review 合并到 main质量保证最强但耗时更长review-and-merge——每个 bead 评审后直接合并到 main不经过功能分支适合简单任务或需要即时反馈的场景。Rigs仓库连接与配置单元Rig钻机把一个仓库连接到你的 town。每个 rig 拥有自己的一组智能体polecats 与 refinery分支配置默认分支、合并目标覆盖设置模型、评审模式、合并策略。一个 town 可以有多个 rig——当项目横跨多个仓库时非常有用。任何 town 级设置都可以在 rig 级覆盖比如为复杂仓库用更强的模型、为生产代码库设置更严格的评审门、允许一个多模块仓库跑更多 polecat、或为纯文档仓库关闭评审见 设置文档。rig 的创建流程见 快速开始点击Add Rig→ 选择 GitHub 仓库或粘贴 URL→ 选择默认分支通常是main→Connect。Gas Town 通过 Kilo GitHub App 访问仓库未安装时会引导你安装。Agents城镇里的三类工作者智能体是 town 里的工人每类都有专门角色。Polecats编码智能体Polecat鼬负责真正的软件工程工作阅读并理解你的代码库在隔离的 git worktree 中编写代码改动运行测试和命令验证自己的工作完成后推送分支。多个 polecat 可以并行处理不同的 bead默认每个 rig 2 个可配置到 5 个以上。每个 polecat 拥有独立的 git worktree——它们之间永远不会互相冲突也不会与你本地开发冲突。并行度通过max_polecats_per_rig配置1-2 保守适合小仓库或预算有限、3-4 中等并行适合中型项目、5 激进适合大量独立工作的大仓库见 设置文档。The Refinery评审智能体Refinery精炼厂是质量门。当 polecat 完成一个 bead 时refinery 评审 diff检查问题、风格违规、缺失的测试要么批准并合并要么发回反馈如果发回反馈polecat 修改后重新提交。这形成了微型对抗循环micro-adversarial loop——一个智能体写、另一个批判在代码落地前强制迭代改进。refinery 的评审聚焦四个维度见 代码评审文档正确性代码是否完成任务要求、风格是否符合项目约定、完整性是否包含测试、边界情况是否处理、安全性是否存在安全问题、数据泄露或破坏性变更。可配置项包括review_modealways/never/pr_only默认always、merge_strategydirect/pr默认direct、auto_merge默认true、review_gates严格度 1-5默认 3、max_review_cycles默认 3。评审门级别 1 只做基本健全性检查能编译、不破坏测试级别 3 为标准检查风格、测试、正确性级别 5 为严格检查架构评审、性能、安全。一个典型 bead 经历 1-2 轮修订连续 3 轮评审失败后bead 会升级为failed并生成 escalation而不是无限循环见 代码评审文档。The Mayor协调智能体Mayor市长是你与 town 交互的界面从高层描述规划 convoy汇报状态与进度分诊 issue 与 escalation管理智能体配置回答关于代码库与工作历史的问题。Mayor持久运行——即使没有编码智能体在工作它也始终可用见 Mayor 指南。它拥有 21 个专用工具覆盖工作创建gt_sling、gt_sling_batch、convoy 管理gt_convoy_status、gt_convoy_start、gt_convoy_close、gt_convoy_update等、bead 管理gt_bead_update、gt_bead_reassign、gt_bead_delete等、智能体管理gt_agent_reset、gt_nudge、gt_list_agents、gt_mail_send以及 town/UI 工具gt_list_rigs、gt_escalation_acknowledge等。这些工具在你提出请求时自动被调用无需手动触发。The Reconciler驱动城镇前进的引擎Reconciler协调器是驱动 town 前进的引擎。它在每个 alarm tick 运行有活跃工作时每5 秒一次空闲时默认60 秒一次见 设置文档执行四步Drain events排空事件——智能体完成、状态变更、失败Evaluate rules评估规则——哪些 bead 需要智能体、哪些 convoy 可以推进Emit actions发出动作——分发智能体、创建评审、更新 convoy 进度Enforce invariants强制不变量——不重复分发、不产生孤儿 hook、有界重试。你不需要直接与 reconciler 交互——它是让 town 持续运转的自主引擎。当出现「beads 一直停在 open、没有智能体领取」的情况时可从 故障排查文档 入手可能原因包括所有 polecat 已达最大分发尝试次数、reconciler 暂停排空、或没有可用 polecat需要提高max_polecats_per_rig。The Micro-Adversarial Loop对抗评审循环Gas Town 最强大的概念是微型对抗循环。与其信任单个智能体的输出每一份工作都会经历对抗循环Write编写——polecat 读取任务、写代码、跑测试、推送Review评审——refinery 找出问题如缺失测试用例、命名不一致Revise修订——polecat 补充测试、修正命名、再次推送Approve merge批准并合并——refinery 批准代码落到目标分支。这一模式与让单个智能体自我评审有本质区别见 代码评审文档自我评审存在确认偏差——写代码的「心智」和评估它的「心智」是同一个而对抗评审创造真正的张力——refinery 的优先级与 polecat 不同每一轮修订都会因为反馈具体、可执行而可度量地改进输出。与 Convoy 结合分层对抗评审这个模式与convoy组合后会放大成多层质量保障见 Sling Work 文档Bead 1探索代码库 → 被评审 → 合并到 convoy 分支Bead 2设计 schema基于 bead 1 的上下文→ 被评审 → 合并Bead 3实现功能基于 bead 12→ 被评审 → 合并Landing review完整的 convoy 分支作为一个内聚整体被评审后才合并到 main。每层评审都独立进行per-bead review由 refinery 检查单次贡献质量landing review检查合并后的整体特性一致性human review可选由你的团队把关业务逻辑与架构见 代码评审文档。叠加起来代码在进入 main 前会经历3-4 轮评审bug 在最小的作用域内修复成本最低处就被捕获。再结合 Kilo 的 Code Review 产品代码在到达你的 main 分支之前会由不同视角的多个智能体评审多次。How It All Fits Together各组件如何协同组件职责你You描述工作、评审 PR、设定方向Mayor规划、协调、沟通Reconciler调度、分发、执行规则Polecats写代码、跑测试、推分支Refinery评审、批判、合并Container带 git、工具、运行时的隔离环境Rig仓库连接与配置端到端的运转流程详见 快速开始是创建 town → 连接仓库rig→ 配置 GitHub PAT让提交与 PR 以你的身份呈现而非 Kilo bot→ 抛任务sling work→ reconciler 把任务分配给可用 polecat → bead 在 kanban 上从 open 流动到 in_progress → 完成后进入 in_review 由 refinery 检查 → 按合并策略直接合并或创建 PR → bead 落入 closed 列。整个周期通常需要2-10 分钟取决于任务复杂度和所用模型。完整的 town 体验——Mayor 对话、convoy 进度与智能体协调——集中在 town 总览页gt-town-overview.png展示了运行中的完整架构。若某个环节出现问题容器无法启动、git 认证失败、评审循环卡死、convoy 停滞、Mayor 无响应、失败率偏高均可对照 故障排查文档 中的症状-原因-修复对照表逐一处理或直接让 Mayor 诊断它能检查智能体状态消息、评审反馈与容器日志多数问题可自行修复重置智能体、关闭卡住的 convoy、重新分发工作。【免费下载链接】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 核心概念全解析Town、Bead、Convoy、Rig 与多智能体编排架构【免费下载链接】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 推出的自主智能体编排平台用一组小而可组合的原语primitive把「一组 AI 智能体在代码库上协作」这件事结构化Town持久化工作区、Bead最小工作单元、Convoy多任务依赖工作流、Rig仓库连接、Polecat/Refinery/Mayor编码、评审、协调三类智能体。本文基于 Gas Town 概念文档 展开并结合仓库内 快速开始、设置、代码评审、Mayor 指南 等文档帮助你完整掌握这套编排模型的每个构件、它们之间的调用关系以及如何配置和观察它们工作。Towns团队的持久化工作区Town城镇是智能体在你的代码上运作的持久化工作区。它是一个「团队的 workspace」会随时间积累机构化知识——城镇里的智能体可以从「已构建、已评审、已合并」的历史中持续学习。一个 town 维护四类状态Configuration配置——模型选择、合并策略、评审设置、自定义指令。详细配置项见 设置文档包括默认模型、per-role 模型覆盖、review mode、merge strategy 等。Agent state智能体状态——存在哪些智能体、各自在做什么、具备什么能力。可通过 Mayor 的gt_list_agents工具查询每个 rig 中所有智能体的角色与状态见 Mayor 指南。Work history工作历史——每一个被创建、被处理、被评审、被关闭的 bead 的完整记录。town 的 beads 页面提供按状态open / in_progress / in_review / closed / failed、类型、rig 的过滤视图见 Sling Work 文档。Rig connections仓库连接——哪些仓库已连接、各自如何配置。从所有权角度一个 town 可以是个人的归你所有也可以是组织的团队共享。创建第一个 town 的流程见 快速开始首次访问 Gas Town 时直接进入新建引导命名后即可添加 rig 连接仓库。Beads最小工作单元与生命周期Bead珠子是工作的基本单元。每一个任务、评审和协调动作都表示为一个带生命周期的 bead状态含义open等待智能体领取in_progress某个智能体正在处理in_review工作已完成等待 refinery 评审closed成功完成并已合并failed无法完成智能体耗尽重试次数在 Sling Work 文档 中可以看到这套生命周期在 UI 上的完整映射rig 页面的 kanban 看板把 bead 按 open / in progress / in review / closed 分列实时展示reconciler 分发智能体后 bead 自动在各列间流动。Bead 类型类型用途issue编码任务——bug 修复、功能开发、重构merge_request交给 refinery 的评审任务convoy多步骤工作流的容器escalation智能体无法解决的问题——需要人工介入message智能体之间的通信bead 还支持优先级字段low、medium默认、high、critical。当多个 bead 等待智能体时高优先级的先被分发见 Sling Work 文档。当某个 bead 反复失败时会生成一条escalation类型记录等待人类确认——这对应 Mayor 工具中的gt_escalation_acknowledge确认已审阅的升级项。Convoys把复杂工作表达为有向图Convoy车队是一种多 bead 工作流任务之间可以互相依赖。它不要求你「一次抛出一堆孤立任务」而是让你把复杂工作表达为一个有向图directed graph。创建 convoy 时需要定义三样东西Tasks任务——需要做什么每个任务都会变成一个 beadDependencies依赖——哪些任务必须先完成后续任务才能开始Feature branch功能分支——convoy 工作落地的共享分支。Reconciler协调器保证只有依赖满足时 bead 才会被分发这意味着后置智能体天然地在已验证的前置工作之上构建。每个任务从convoy feature branch出发该分支累积所有已合并的前置工作refinery 针对 convoy 分支评审每个子 PR所有 bead 关闭后会进行一次landing review落地评审把合并后的完整 diff 作为一个整体检查再合并到 main见 Sling Work 文档。Staged Convoys暂存车队Convoy 可以暂存staged——被创建但不会立即启动。这让你在智能体开始执行前先审查计划确认任务拆分合理、依赖顺序正确之后再「解除暂存」正式开工un-stage。暂存行为可在 town 设置中作为默认值配置staged convoys default为true时新 convoy 默认以暂存状态创建见 设置文档。Convoy 还支持两种合并模式设置文档review-then-land默认——每个 bead 先合并到功能分支再通过 landing review 合并到 main质量保证最强但耗时更长review-and-merge——每个 bead 评审后直接合并到 main不经过功能分支适合简单任务或需要即时反馈的场景。Rigs仓库连接与配置单元Rig钻机把一个仓库连接到你的 town。每个 rig 拥有自己的一组智能体polecats 与 refinery分支配置默认分支、合并目标覆盖设置模型、评审模式、合并策略。一个 town 可以有多个 rig——当项目横跨多个仓库时非常有用。任何 town 级设置都可以在 rig 级覆盖比如为复杂仓库用更强的模型、为生产代码库设置更严格的评审门、允许一个多模块仓库跑更多 polecat、或为纯文档仓库关闭评审见 设置文档。rig 的创建流程见 快速开始点击Add Rig→ 选择 GitHub 仓库或粘贴 URL→ 选择默认分支通常是main→Connect。Gas Town 通过 Kilo GitHub App 访问仓库未安装时会引导你安装。Agents城镇里的三类工作者智能体是 town 里的工人每类都有专门角色。Polecats编码智能体Polecat鼬负责真正的软件工程工作阅读并理解你的代码库在隔离的 git worktree 中编写代码改动运行测试和命令验证自己的工作完成后推送分支。多个 polecat 可以并行处理不同的 bead默认每个 rig 2 个可配置到 5 个以上。每个 polecat 拥有独立的 git worktree——它们之间永远不会互相冲突也不会与你本地开发冲突。并行度通过max_polecats_per_rig配置1-2 保守适合小仓库或预算有限、3-4 中等并行适合中型项目、5 激进适合大量独立工作的大仓库见 设置文档。The Refinery评审智能体Refinery精炼厂是质量门。当 polecat 完成一个 bead 时refinery 评审 diff检查问题、风格违规、缺失的测试要么批准并合并要么发回反馈如果发回反馈polecat 修改后重新提交。这形成了微型对抗循环micro-adversarial loop——一个智能体写、另一个批判在代码落地前强制迭代改进。refinery 的评审聚焦四个维度见 代码评审文档正确性代码是否完成任务要求、风格是否符合项目约定、完整性是否包含测试、边界情况是否处理、安全性是否存在安全问题、数据泄露或破坏性变更。可配置项包括review_modealways/never/pr_only默认always、merge_strategydirect/pr默认direct、auto_merge默认true、review_gates严格度 1-5默认 3、max_review_cycles默认 3。评审门级别 1 只做基本健全性检查能编译、不破坏测试级别 3 为标准检查风格、测试、正确性级别 5 为严格检查架构评审、性能、安全。一个典型 bead 经历 1-2 轮修订连续 3 轮评审失败后bead 会升级为failed并生成 escalation而不是无限循环见 代码评审文档。The Mayor协调智能体Mayor市长是你与 town 交互的界面从高层描述规划 convoy汇报状态与进度分诊 issue 与 escalation管理智能体配置回答关于代码库与工作历史的问题。Mayor持久运行——即使没有编码智能体在工作它也始终可用见 Mayor 指南。它拥有 21 个专用工具覆盖工作创建gt_sling、gt_sling_batch、convoy 管理gt_convoy_status、gt_convoy_start、gt_convoy_close、gt_convoy_update等、bead 管理gt_bead_update、gt_bead_reassign、gt_bead_delete等、智能体管理gt_agent_reset、gt_nudge、gt_list_agents、gt_mail_send以及 town/UI 工具gt_list_rigs、gt_escalation_acknowledge等。这些工具在你提出请求时自动被调用无需手动触发。The Reconciler驱动城镇前进的引擎Reconciler协调器是驱动 town 前进的引擎。它在每个 alarm tick 运行有活跃工作时每5 秒一次空闲时默认60 秒一次见 设置文档执行四步Drain events排空事件——智能体完成、状态变更、失败Evaluate rules评估规则——哪些 bead 需要智能体、哪些 convoy 可以推进Emit actions发出动作——分发智能体、创建评审、更新 convoy 进度Enforce invariants强制不变量——不重复分发、不产生孤儿 hook、有界重试。你不需要直接与 reconciler 交互——它是让 town 持续运转的自主引擎。当出现「beads 一直停在 open、没有智能体领取」的情况时可从 故障排查文档 入手可能原因包括所有 polecat 已达最大分发尝试次数、reconciler 暂停排空、或没有可用 polecat需要提高max_polecats_per_rig。The Micro-Adversarial Loop对抗评审循环Gas Town 最强大的概念是微型对抗循环。与其信任单个智能体的输出每一份工作都会经历对抗循环Write编写——polecat 读取任务、写代码、跑测试、推送Review评审——refinery 找出问题如缺失测试用例、命名不一致Revise修订——polecat 补充测试、修正命名、再次推送Approve merge批准并合并——refinery 批准代码落到目标分支。这一模式与让单个智能体自我评审有本质区别见 代码评审文档自我评审存在确认偏差——写代码的「心智」和评估它的「心智」是同一个而对抗评审创造真正的张力——refinery 的优先级与 polecat 不同每一轮修订都会因为反馈具体、可执行而可度量地改进输出。与 Convoy 结合分层对抗评审这个模式与convoy组合后会放大成多层质量保障见 Sling Work 文档Bead 1探索代码库 → 被评审 → 合并到 convoy 分支Bead 2设计 schema基于 bead 1 的上下文→ 被评审 → 合并Bead 3实现功能基于 bead 12→ 被评审 → 合并Landing review完整的 convoy 分支作为一个内聚整体被评审后才合并到 main。每层评审都独立进行per-bead review由 refinery 检查单次贡献质量landing review检查合并后的整体特性一致性human review可选由你的团队把关业务逻辑与架构见 代码评审文档。叠加起来代码在进入 main 前会经历3-4 轮评审bug 在最小的作用域内修复成本最低处就被捕获。再结合 Kilo 的 Code Review 产品代码在到达你的 main 分支之前会由不同视角的多个智能体评审多次。How It All Fits Together各组件如何协同组件职责你You描述工作、评审 PR、设定方向Mayor规划、协调、沟通Reconciler调度、分发、执行规则Polecats写代码、跑测试、推分支Refinery评审、批判、合并Container带 git、工具、运行时的隔离环境Rig仓库连接与配置端到端的运转流程详见 快速开始是创建 town → 连接仓库rig→ 配置 GitHub PAT让提交与 PR 以你的身份呈现而非 Kilo bot→ 抛任务sling work→ reconciler 把任务分配给可用 polecat → bead 在 kanban 上从 open 流动到 in_progress → 完成后进入 in_review 由 refinery 检查 → 按合并策略直接合并或创建 PR → bead 落入 closed 列。整个周期通常需要2-10 分钟取决于任务复杂度和所用模型。完整的 town 体验——Mayor 对话、convoy 进度与智能体协调——集中在 town 总览页gt-town-overview.png展示了运行中的完整架构。若某个环节出现问题容器无法启动、git 认证失败、评审循环卡死、convoy 停滞、Mayor 无响应、失败率偏高均可对照 故障排查文档 中的症状-原因-修复对照表逐一处理或直接让 Mayor 诊断它能检查智能体状态消息、评审反馈与容器日志多数问题可自行修复重置智能体、关闭卡住的 convoy、重新分发工作。【免费下载链接】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），仅供参考
