Kilo Code：代码审查前动态决定启用0/1/6个AI Agent

今年 Product Hunt 上大多数"AI 编程智能体"帖子都是同一个套路换了不同的 logo：编辑器侧边栏、系统提示词、每月订阅加一个大约第三周就会用完的用量上限。Kilo Code 也在持续发布#1 Product of the Day 和#1 Product of the Week，表面上听起来完全一样——开源编程智能体、VS Code 和 JetBrains，现在还加了 AI 代码审查功能。但发布文案没说的东西比说出来的更有意思：Kilo 不是一个代码库。它是两个独立开源编程智能体，由共享的计费层缝合在一起，而且最近还加上了一条审查流水线，在读取你的 diff 之前就能决定自己的规模。

我花了几个小时研究实际的 Kilo-Org/kilocode 代码仓库——不是营销站点（那玩意禁止自动化抓取），而是代码、变更日志和文档源码——来找出哪些是真实的东西。以下是我的发现。

Kilo Code 实际上是什么

Kilo Code 是一个开源 AI 编程智能体，以 VS Code 扩展、JetBrains 插件、CLI/TUI、云端"Agent Manager" Web 界面，以及（通过一个叫 KiloClaw 的子产品）可从 Telegram、Discord 或 Slack 触发的聊天式智能体形式交付。当前仓库约有 27,000 GitHub star 和 3,100 个 fork，它自己的 README 称其为"最受欢迎的开源编程智能体"——这个说法至少在 star 数量与同类开源智能体相比的方向性上是得到支持的。

在产品内部，并不是一个整体的"AI 助手"人格。Kilo 搭载了五个命名智能体，每个都有明确的任务范围：

Code — 默认的实现智能体：在多个文件间编写、编辑和重构代码

Plan — 实现开始前的架构和设计

Ask — 只读的代码库问答

Debug — 诊断和修复问题

Review — 读取 diff 并报告问题，不修改代码

你也可以定义自定义模式（上面的截图显示了一个内置的"UX Designer"模式），并且在任务中途可以在 500 多种模型之间切换——文档列出了当前选项包括 GPT-5.5、Claude Opus 4.7、Claude Sonnet 4.6 和 Gemini 3.1 Pro Preview，以及 MiniMax M2.1 等低成本和免费选项，MiniMax M2.1 还出现在 Kilo 自己关于 Review 模式的文档截图中作为活跃模型。

还有两个小功能完善了整个产品面。扩展内置置了一个 MCP 市场，用于发现和连接 Model Context Protocol 服务器，这样扩展智能体可触及的范围（数据库、工单跟踪器、内部 API）就不需要从头手写配置文件。还有一个内联自动补全运行在专用模型上——Mistral 的 Codestral 2508——而不是把幽灵文本建议路由到你为聊天选的大模型，这样能保持低延迟，而且值得注意的是，如果你自备 Codestral 密钥就是免费的，因为 Mistral 为此提供了无成本 tier。文档对此作为后台进程的情况异常坦率：Codestral 请求会在自动补全启用时持续发送，即使你没有打开聊天面板，而且有一个明确设置的开关来禁用它，如果你不想要这种始终开启的行为。

以上这些在 2026 年都不稀奇。模型无关、多模式的编程智能体现在已经是这个品类的默认形态了。但它下面的东西就不再通用。

发布页面略过的部分：这是两个分支，不是一个产品

Kilo Code 的 VS Code 和 JetBrains 扩展是 Roo Code 的分支，而 Roo Code 本身又是 Cline 的分支。仓库自己的 README 仍然直接向 Roo Code 用户打招呼——"来自 Roo Code？切换到 Kilo 并查看我们的迁移指南"——而且变更日志定期记录类似"从上游 Roo-Code 精选 cherry-pick"这样的条目，从 RooCodeInc/Roo-Code 按编号和作者拉取特定的 pull request。Kilo 不是悄无声息地从 Roo Code 派生而来；它在持续跟踪它，持续从上游拉取修复。

CLI 和 TUI 则是完全不同的世系。根据 README，"Kilo CLI 是 OpenCode 的分支，增强了可工作在 Kilo 智能体工程平台内。"变更日志证实这不是一次性分支——"从 opencode v1.17.13 到 v1.18.0 上游的变更"这样的条目反复出现（我在可见的变更日志历史中数到了至少十几个独立的上游 OpenCode 版本升级引用），每一次都从 @opencode-ai 包系列中拉取对应的上游 bugfix 和特性。

所以实际情况是：Kilo Code 的编辑器扩展是基于 Cline 经 Roo Code 的连续上游 cherry-pick，而 Kilo Code 的 CLI 是基于 OpenCode 的连续上游合并。两个不同的代码库、两个不同的上游社区、两种不同的发布节奏，由 Kilo 团队手动协调——只在共享账户系统、共享模型计费，以及叠加在顶层的一套共享的五个智能体定义上统一。

你可以在数字中看到这条接缝：仅 VS Code 扩展的变更日志在撰写本文时已记录了 397 个独立版本条目，其中大多数在一两天内发布。这是一支在两个方向同时承受上游持续压力下维护分支的团队节奏，不是一个从头写编程智能体的团队节奏。而且公平地说，这也是一种合理的策略——你继承了 Cline/Roo Code 的 IDE 集成成熟度和 OpenCode 的终端原生架构，而不是重建任何一个，而且你可以指向特定的上游 commit 来证明你没有悄无声息地漂移。

不过权衡是真实存在的：双世系分支意味着 VS Code 侧边栏和 CLI 之间的功能对等不能由架构保证，只能靠持续的维护工作。Agent Manager——Kilo 基于 worktree 的多会话编排器——目前仅限 VS Code，专门构建在扩展的嵌入式运行时中，这样就不需要单独的 CLI 安装或 CLI 认证。如果你生活在终端里，你现在还无法使用它。

真正的新闻：一个能自我调整规模的 AI 审查器

推动 Kilo 最近 Product Hunt 排名的功能是 Code Reviews——一个能在 GitHub 或 GitLab 上自动审查 pull 和 merge request 的 AI 智能体，外加一个 /review 斜杠命令，用于在本地审查你还没打开 PR 的变更。

这个宣传的通用版本（"AI 审查你的 PR"）并不有意思；CodeRabbit 和 Greptile 已经将其作为独立产品做了一段时间了，而且每个通用编程智能体都可以被提示去审查一个 diff。Kilo 实现的具体之处在于它如何自我扩展。

根据 Kilo 自己的文档，Review 智能体会估算 diff 的大小——变更文件数和变更行数——然后从三个层级中选择一种审查策略：

子智能体是只读的，不能自己发表评论——它们向主审查器返回发现结果（路径、行号、严重程度、理由），由主审查器负责去重、验证每个发现结果确实落在有效的 diff 行上，并撰写最终审查。这比听起来更重要：朴素的多智能体审查设置在几个智能体查看重叠代码时往往会产生冗余或矛盾的评论，而 Kilo 的文档明确指出主审查器拥有最终输出，原因正在于此。

真正不寻常的部分是这个策略可以通过在仓库根目录提交一个 REVIEW.md 文件来按仓库覆盖——不是仪表盘设置，而是一个位于版本控制中、与它所管理的代码同处的文件。Kilo 从 pull request 的基础分支（而非特性分支）读取 REVIEW.md，特别目的是让 PR 无法重写用来评判自身的规则。如果文件缺失、被禁用、无法读取或超过 10,000 字符（会被截断，审查摘要中会有说明），Kilo 会回退到其内置的分层策略。团队可以用它来声明诸如"仅文档变更或仅锁文件变更使用 0 个子智能体"或"触及 API、UI 和测试覆盖率的变更使用 3 个子智能体分别覆盖"——基本上就是把审查运行手册写成代码，签入同一个仓库，在它自己的 PR 中也可审查。

审查行为还可以沿另外两个轴进行配置：风格（Strict / Balanced / Lenient）和关注领域（安全性、性能、bug 检测、风格、测试覆盖率、文档），每次审查的可配置时间上限在 5 到 30 分钟之间。审查结果以原生 GitHub/GitLab 评论形式呈现，"就像来自团队审查者一样"，而机器人-authored 的 PR——Dependabot、Renovate——默认被排除，以免审查额度和通知噪音浪费在依赖版本更新上。

Agent Manager：/"它是如何工作的"的另一半故事

Review 智能体是当前推动 Product Hunt 热度的核心功能，但它并非唯一具有架构意义的部分。Agent Manager——Kilo 针对"当你希望同时运行多个智能体会话时会发生什么"这一问题的答案——是一个完整面板编辑器标签页，直接内置于 VS Code 扩展的嵌入式运行时中。文档中特别指出，它无需安装独立的 CLI 或进行 CLI 身份验证。

Agent Manager 中的每个会话都在独立的 git worktree 中运行，工作树检出到项目下的 .kilo/worktrees/ 目录中，处于独立的分支上，配备专用的集成终端以及一个与父分支进行对比的 diff/review 面板。这种 worktree 隔离机制是让你能够在同一仓库上运行多个智能体而不会相互争夺工作目录的关键——这对于任何曾尝试在同一个 checkout 中运行两个智能体会话并眼睁睁看着它们踩踏彼此未提交的编辑的人来说，都是一个真实且反复出现的问题。会话还可以从现有分支、外部 worktree 或直接的 GitHub PR URL 导入，侧边栏会话也可以在需要更多空间时通过"Continue in Worktree"晋升为 Agent Manager 中的完整会话。

在展示 PR 状态方面有一个真正经过深思熟虑的细节：每个 worktree 都有一个颜色编码的徽章，显示其关联的 PR 编号，Kilo 按顺序尝试三种策略通过 gh CLI 查找该 PR——首先是分支的跟踪引用（这对于使用 gh pr checkout 检出的 fork PR 也有效），其次是同仓库分支名匹配，最后作为兜底方案按 HEAD 提交 SHA 搜索。这正是你在发现简单方法在真实世界的分支命名约定下会出问题之后才会写出的 fallback 链，而不是在第一天就凭猜测设计出来的。

相较于前代的改变

如果将 Kilo 放在 review-bot 类别（CodeRabbit、Greptile 及类似的独立工具）中比较，Kilo 的做法是架构层面的：reviewer 与你的编码智能体是同一个产品、同一个账户、同一个积分池，而且按照子智能体层级划分，进行 review 的底层运行时与进行编码的运行时也是同一个。你不需要购买第二个工具来闭合第一个工具的循环。

如果将其与 Cursor、Windsurf 和 GitHub Copilot 等闭源 IDE 智能体相比，差异在于许可和定价结构而非原始能力。Kilo 采用 MIT 许可证发布（LICENSE 中注明了 OpenCode 的 2025 年版权，与上述 fork 世系一致），其文档明确说明了计费模式："我们的定价与模型提供商的 API 费率完全一致。我们不收取任何佣金或加价。你给我们的 $1 会变成 $1 的 Kilo 积分。"这是一种与月度订阅制截然不同的经济模式——你支付的是 Anthropic、OpenAI 或 Google 实际对 token 收取的费用，而不是必须在轻度用户和重度用户之间摊平的捆绑费率。Kilo 还销售预付费的"Kilo Pass"作为加载积分的折扣方式，并支持自带提供商 API 密钥（BYOK），以完全跳过 Kilo 积分来使用其不加价的模型。

如果将其与自身的前代 Roo Code 和 Cline 相比，诚实的评价是：Kilo 并不是一次彻底的重新设计，而更像是在现有基础上叠加了一层商业化外壳，并添加了第二个独立维护的入口面（源自 OpenCode 的 CLI），加上 Review 智能体和 Agent Manager 这些在上游不存在的新功能。

为什么这对你特别重要

成本暴露是直接的，而非抽象的。使用按提供商透传的定价方式，Anthropic 或 OpenAI 的价格变动会准确反映在你的 Kilo 账单上——就像你直接调用 API 一样——没有加价缓冲，但也没有加价缓冲来保护你免受月中提供商涨价的影响。如果你习惯了固定费率的 IDE 订阅，这是一种思维模式的转变：你现在像管理原始 API 密钥一样在管理 token 支出，只是这一切发生在 IDE 内部。

锁定风险低于常规水平，而且是一种可验证的方式。MIT 许可证加上与两个开源项目的活跃上游关系，意味着如果 Kilo 这家公司明天消失，VS Code 扩展的世系（Roo Code、Cline）和 CLI 的世系（OpenCode）都将独立继续存在和发布。这是一个比"它是开源的"通常意味着的更强的保证，因为你可以说出具体哪个上游仓库会继续推进。

Review 策略即代码是一个真正的安全/可维护性收益，而非锦上添花。将 review 严格程度、重点领域和子智能体委托规则存储在从基础分支读取的 REVIEW.md 中——且不能被正在 review 的 PR 更改——这类细节表明构建这个功能的团队真正考虑过对抗性场景（贡献者试图在同一需要宽松审查的 PR 中削弱审查力度）。这是一个小的设计选择，但正是它将"review bot 作为玩具"与"你会信任它来 gating merge 的 review bot"区分开来。

多入口架构存在一个真实的缺口。Agent Manager 的 worktree 编排——并行的隔离会话、每个在独立分支上、通过 gh CLI 拉取 PR 状态徽章——目前仅限于 VS Code。如果你的团队标准化使用 CLI 或 JetBrains，你就无法使用它，而且考虑到上述双代码库结构，文档中没有承诺关闭这一缺口的明确时间线。

在仔细阅读实际代码和文档而非宣传材料后，有两件事一直困扰着我。

首先："零加价"定价是一个真实且可验证的声明，但它不等于"便宜"。透传定价意味着 Kilo 没有激励结构来推动你使用更高效的模型或更小的 diff——计量表与你所选的前沿模型的运行速度完全同步，一个允许 Review 智能体以 Strict 模式和 30 分钟上限对繁忙的 monorepo 的每次推送都触发的团队，可以累积出真实的支出，而没有人会在任何单一决策上刻意超支。"不加价"的表述是诚实的，但它将成本纪律的全部负担转移给了用户，就像原始云 API 账单一样。对于许多团队来说这是一个公平的权衡，但不是 Product Hunt 标语暗示的那种免费午餐。

其次：双世系 fork 结构既是 Kilo 最佳论据，也是其最大的开放性问题。继承 Roo Code/Cline 的 IDE 成熟度和 OpenCode 的终端架构，而不是从零开始构建，是比几乎任何从零开始构建的团队都能更快实现"在 VS Code 中运行良好且在终端中运行良好"的合法聪明方式。但这也意味着 Kilo 的路线图在某种程度上受制于它无法控制的两个上游项目，而 Agent Manager——可以说是最近最具差异化的功能——仅限于 VS Code 这件事，实际上不是一个产品决策，而是那种分裂的后果：VS Code 扩展有自己的嵌入式运行时可以构建，而 CLI 需要自己单独实现相同的工作树编排逻辑。公开文档中没有任何内容承诺在何时关闭这一差距。如果你在评估这个产品用于 CLI 优先或 JetBrains 优先的团队，这是采用前要追问的细节，而不是积分定价的宣传。

适用场景

Gating PR 而无需雇用第二个 reviewer。Balanced 模式加上 15–20 分钟上限是一个合理的默认值，适用于希望在每次 PR 都有统一的首轮审查后才让人工介入的团队，尤其是对于规模太小而无法在每次变更都有专职 reviewer 的团队。

Pre-push 本地审查。/review uncommitted 或 /review branch 在 PR 根本不存在之前就捕获问题，这对于希望 review 反馈来塑造 diff 而不是在事实之后才 gating 的团队很重要。

在无关任务上并行运行多个智能体会话。Agent Manager 的 worktree 隔离（存储在 .kilo/worktrees/ 下）让你可以在同一仓库中同时让 Kilo 处理三个不同的 ticket，而不会有一个会话的未提交更改与另一个发生碰撞——对于曾经因为两个智能体同时编辑同一文件而丢失工作的人来说，这确实有用。

CI-gated 自主运行。kilo run --auto 完全禁用交互式提示，专为 CI/CD 流水线构建——适用于脚本化的维护任务（依赖升级、codemod），这些任务不需要人工批准每次工具调用。

从 IDE 外部触达智能体。KiloClaw 的聊天平台集成（Telegram、Discord、Slack，加上无需 token 设置的第一方"Kilo Chat"）旨在从你的团队已经交谈的地方触发智能体工作，而不仅仅是从编辑器窗口。

** launch 页面不会告诉你的局限性**

"免费"审核是一个 beta 阶段的附带条件，而非定价模式。Kilo 的文档说，计算和审核时间在"有限 beta 期间"是免费的——但 Kilo Code 积分仍然会被用于模型推理审核过程。一旦 beta 标签去掉，预计这一点会发生变化。

Reviews only see the diff, not the repo. The Review agent explicitly reviews changed files, not the whole codebase — it won't catch a regression in a file the PR didn't touch, even if the PR's logic depends on it.

Reviews 只能看到 diff，无法看到整个 repo。Review 智能体明确只审核变更的文件，而非整个代码库——它不会捕获一个 PR 未触及的文件中的回归，即使该 PR 的逻辑依赖于它。

Worktrees multiply disk usage. Kilo's own docs warn that node_modules, build output, and local databases get duplicated per parallel worktree, and closing a worktree removes its checkout but not external caches, containers, or databases your scripts created outside it — a detail that matters the first time you run five parallel sessions on a monorepo with a heavy install step.

Worktrees 会成倍增加磁盘占用。Kilo 自己的文档警告说，node_modules、构建输出和本地数据库会在每个并行 worktree 中被复制，而关闭一个 worktree 会移除其 checkout，但不会移除外部缓存、容器或脚本在 worktree 之外创建的数据库——当你第一次在安装步骤繁重的 monorepo 上运行五个并行会话时，这个细节就会变得重要。

PR badges need a working gh CLI. Agent Manager's PR status detection depends on the GitHub CLI being installed and authenticated locally; without it, badges silently don't appear rather than erroring loudly.

PR badges 需要可用的 gh CLI。Agent Manager 的 PR 状态检测依赖本地安装并完成认证的 GitHub CLI；没有它，badges 会静默地不显示，而不是大声报错。

Bot PRs are silently skipped. Dependabot and Renovate PRs don't get reviewed by default. That's a reasonable default for noise reduction, but it also means a dependency bump that introduces a real breaking change gets zero AI review coverage unless you change the setting.

Bot 发起的 PR 会被静默跳过。Dependabot 和 Renovate 的 PR 默认不会受到审核。这是一个降低噪音的合理默认设置，但也意味着一个引入真正破坏性变更的依赖升级除非你更改设置，否则将得不到任何 AI 审核覆盖。

Two upstream codebases means two sets of bugs to inherit. Tracking both Roo Code/Cline and OpenCode upstream means Kilo absorbs upstream regressions from either lineage on top of its own — the tradeoff of not reimplementing either from scratch.

两个上游代码库意味着要继承两组 bug。同时跟踪 Roo Code/Cline 和 OpenCode 上游意味着 Kilo 除了自身的回归问题外，还会吸收来自任一上游的回归——这是不从头重新实现两者的权衡。

Who should actually try this

谁应该真正试试这个

Try it now if you're a small team without a dedicated code reviewer and want a first-pass gate on every PR, or if you're already comfortable managing raw API spend and want that model applied to a coding agent instead of a flat subscription. The REVIEW.md mechanism alone is worth evaluating if you've been burned by review bots that can't be told "skip lockfile-only changes."

如果你的团队没有专职代码审核人员，想在每个 PR 上设置第一道关卡，请立即尝试；或者如果你已经习惯于管理原始 API 支出，想把这种模式应用到编码智能体而不是扁平订阅的话。仅仅是 REVIEW.md 机制就值得评估——如果你曾被那些无法被告知"跳过仅 lockfile 变更"的审核机器人坑过的话。

Wait if you need Agent Manager's parallel-worktree workflow specifically but your team lives in JetBrains or the terminal — that feature isn't there yet, and there's no public timeline for it given the split codebase.

如果你特别需要 Agent Manager 的并行 worktree 工作流，但你的团队生活在 JetBrains 或终端中——请等待——该功能还不存在，而且考虑到分叉的代码库，目前没有公开的时间表。

Skip it if your organization has hard constraints around vendor-hosted credit systems and BYOK doesn't fully route around them, or if you specifically want a single, from-scratch codebase rather than a maintained fork of two separate upstream projects — that's a legitimate preference, and Kilo isn't that.

如果有以下情况请跳过：你的组织对供应商托管的积分系统有硬性限制，而 BYOK 无法完全绕过它们；或者你特别想要一个单一的、从头构建的代码库，而不是一个维护中的两个独立上游项目的分叉——这是一个合法的偏好，而 Kilo 不是那样的产品。

Kilo-Org/kilocode on GitHub

Kilo Code Reviews documentation

Kilo Agent Manager documentation

Kilo Code VS Code extension changelog

Roo Code (RooCodeInc/Roo-Code) on GitHub

What's your actual experience with review policy that lives in the repo (REVIEW.md-style) versus review policy locked in a vendor dashboard — has putting it in version control changed how your team argues about review strictness, or just moved the argument into PR comments on the policy file itself?

你实际使用过存在于 repo 中的审核策略（REVIEW.md 风格）与锁定在供应商仪表板中的审核策略吗——将它放入版本控制是否改变了你团队关于审核严格程度的争论方式，还是只是把争论转移到了策略文件本身的 PR 评论中？

For further actions, you may consider blocking this person and/or reporting abuse