Kilo Code 评测：多模型、云端任务与代码审查，值得换吗？

Kilo Code 是什么？

Kilo Code，也叫 Kilo，是一款能够读取项目上下文、调用工具来协助编写、修改和审查代码的智能体。它是围绕语言模型运行的软件，本身并不是模型。它的开源客户端覆盖 Visual Studio Code、JetBrains 集成开发环境（IDE）和终端；托管服务则提供 Cloud Agents、拉取请求审查以及模型接入网关。这个区别很重要：能查看智能体的源码，不代表你拥有处理托管请求的基础设施或模型。官方宣传的模型目录代表可选的模型范围，并不能证明每个模型都能同样出色地处理你的代码仓库。

本文已于 2026 年 10 月 31 日对照 Kilo 当时在线的产品页面、文档和定价完成核验。 对替代产品的描述，也在同一天核对了各自厂商的页面。本文基于公开资料评估，包含工作流建议和费用计算示例，并未登录产品进行性能实测。判断重点是工作流程能否衔接、模型选择是否可控、账单是否清晰，以及代码审查能覆盖到哪里。

谁适合选 Kilo，谁可以继续用现有工具？

对于希望保留现有编辑器、自由选择模型，并把本地工作衔接到托管执行环境的开发者或小团队，Kilo 的吸引力最强。如果你已经有可靠的智能体，又说不出哪项任务交给 Kilo 会更方便，那么换用它的理由就不充分。

这里比较的是换工具能带来什么。功能清单长，不等于产出的补丁质量更高；本文也不声称 Kilo 在你的代码上一定优于这两款替代产品。

Kilo Code 与 Cline 怎么选？

Cline 是开源智能体，提供编辑器和终端界面，支持选择模型提供商、使用本地模型，并通过 Plan/Act 工作流将讨论改动与执行改动分开。其当前网站还介绍了技能、集成和多智能体协作。这些能力并不是 Kilo 独有的选择理由。Cline 当前功能。

**适合选 Kilo 的情况：**你明确希望将 Cloud Agents、模型路由、托管审查和共享账单整合到同一套工作环境中。例如，一家维护多个代码仓库的小型开发服务公司，可以在编辑器中交互式修复问题，把范围明确的清理工作交给云端任务，再按照仓库内的审查指引检查结果，最后由人合并。

**适合选 Cline 的情况：**现有提供商配置、审批方式和项目规则已经适合你的工作。仅仅为了多一个模型选择器，就替换运转良好的本地流程，收益有限。如果你希望围绕 Cline 的智能体运行时搭建自己的方案，而不是采用 Kilo 的托管服务，也值得继续考虑 Cline。

要进一步比较这两种替代方案的工作方式，可以阅读 Cline 与 Claude Code 对比。JetBrains 用户还需要注意：Cline 当前的定价页将 JetBrains 扩展列在 Enterprise 方案中，不能默认其个人方案与 Kilo 覆盖相同的编辑器。

Kilo Code 与 Claude Code 怎么选？

Claude Code 是 Anthropic 的编程智能体，可在终端、IDE、桌面端和浏览器中使用。它的终端和编辑器集成也支持文档列明的第三方提供商接入方式。因此，两者的区别并不在于 Claude Code 只能在终端运行，或只能通过个人订阅结算。Claude Code 概览。

**适合选 Claude Code 的情况：**你想围绕 Claude 工作，而且现有订阅额度足以轻松覆盖需求。为了使用一个已经在用的模型，再引入一个网关，必要性不大。这里需要考虑的限制是订阅额度共享：与 Claude 交互和使用 Claude Code，会消耗同一个额度池。

**适合选 Kilo 的情况：**切换模型家族、使用自己的提供商密钥，或结合 Kilo 的本地与托管工作流，本来就是你每周的常规需求。Kilo 也可以与 Claude Code 并用：先把需要不同接入路径或运行环境的任务交给 Kilo，比较最终补丁与总投入，再决定是否转移更多工作。在 Kilo 中使用 Claude 模型，并不会让这个客户端变成 Claude Code。

Kilo Code 与 Cursor 怎么选？

Cursor 是集成式编程环境，包含智能体、终端和云端工作流。如果你看重的是编辑器本身，又不想单独管理智能体配置，继续用 Cursor 就好。如果保留自己偏好的编辑器、控制智能体的模型接入路径更重要，可以选 Kilo。Kilo 的安装页也将 Cursor 列为可安装扩展的宿主，因此加装 Kilo 不一定意味着马上放弃 Cursor。Cursor、Kilo 安装选项。

Kilo Code 与 OpenCode 怎么选？

OpenCode 是开源编程智能体，提供终端、编辑器和桌面端界面，并支持选择提供商。Kilo 当前的 CLI 和重构后的 VS Code 扩展都以 OpenCode 为基础。如果 OpenCode 自身的工作流已经合用，就选 OpenCode；如果你需要的是 Kilo 围绕智能体提供的服务，就选 Kilo。底层基础相同，并不代表行为、发布节奏或托管功能相同。OpenCode、Kilo CLI 的技术基础。

Kilo Code 与 Roo Code：迁移前要注意什么？

在重新筛选工具时，不应再把 Roo Code 当作同等维护状态的产品。它的官方仓库已归档，README 也明确表示扩展已停止服务。现有用户评估 Kilo 时，应把这次切换视为指令和工作流程的迁移，而不能假设旧设置可以原样沿用。Roo Code 仓库。

如果以上工作方式都不适合，可以参考范围更广的 Claude Code 替代方案。

在编辑器和终端之间切换，沿用同一个智能体

Kilo 首先有用的地方，是让智能体贴近代码，同时把任务拆成便于审查的改动。它当前的编辑器能力包括并行会话、工作树和差异审查，已经不只是一个提供代码片段建议的聊天面板。

VS Code：把问题调查与补丁编写分开

Kilo 的 VS Code 扩展与 CLI 共用可移植核心，支持并行智能体、工作树，以及针对差异的逐行反馈。工作树是同一仓库在独立分支上的另一份检出目录，让任务可以修改文件，而不必立即影响主工作副本。扩展还可以将你的审查意见传回智能体对话。Kilo for VS Code。

以一个小型电商应用的退款故障为例：让一个任务调查退款状态在哪里发生变化，另一个任务编写范围有限的补丁，并添加能复现故障的测试。给负责改代码的任务单独分配工作树。在任何一个智能体扩大修改范围之前，先让调查任务解释相关行为。

验收标准应描述预期结果：重复收到 webhook，也就是外部传入的事件通知时，不能再次退款；现有成功路径必须仍然可用；无关支付代码不能改动。这样的起点，比笼统要求智能体“优化支付系统”更有用。

拿到补丁后，阅读改动文件，检查测试断言，并针对需要调整的代码行给出具体反馈。只有减少等待、又不增加协调冲突改动的时间，并行才有价值。两个智能体同时修改同一份检出目录，仍可能互相干扰。

JetBrains：原生支持，但要留意工作树的使用细节

Kilo 提供原生 JetBrains 插件，支持 IntelliJ IDEA、PyCharm 和 WebStorm 等 IDE，无需 Node.js。通过 Settings → Plugins → Marketplace 安装，然后在 Settings → Tools → Kilo Code 中配置。智能体的共享设置使用 kilo.jsonc，IDE 专属设置则保留在插件中。JetBrains 文档。

对后端开发者来说，实际要验证的是：智能体能否适应自己赖以工作的项目结构和构建配置。可以让它从控制器一路追踪到服务层和持久化层，提出小范围改动，再用平时的 IDE 检查和测试流程评估结果。

这项集成有明确边界。默认情况下，智能体工作树不会被纳入其所属项目的索引，可能导致其中的文件缺少正常的代码解析或检查。需要完整索引时，应将工作树作为独立项目打开。另外，工作树初始化脚本启动后，智能体可能不会等它执行完毕。让智能体使用依赖和生成文件前，先确认这些准备工作已经完成。这些是工作流程的约束，不能据此认定模型没看懂代码。

CLI：在终端工作的实用入口

Kilo 的命令行界面允许你从项目目录使用智能体，并选择 Kilo 账号或自己的提供商密钥。文档给出的 npm 安装方式如下：Kilo CLI。

npm install -g @kilocode/cli
kilo

第二条命令应在准备处理的仓库中运行。初次尝试时，先让智能体解释测试为什么失败、准备如何修复，再批准编辑。一个简短、便于检查的修复，比笼统要求它把整个仓库现代化，更能帮助你判断工具是否合适。

Kilo 还在文档中介绍了 /sandbox，用于在操作系统层面限制工具执行范围。官方列出的控制项包括仅允许写入工作区、Git 元数据只读，以及可选的网络限制。权限决定一个动作能否执行；沙箱规则决定这个动作能接触哪些资源。应根据任务同时配置两者，不能用自动批准代替执行边界。

Kilo Code 模型选择：模型之外，还要选接入路径

要用好 Kilo 的模型灵活性，先要分清模型本身与承接请求的服务。网关提供托管接入；自带密钥（BYOK）让提供商账号承担推理，也就是由模型处理你的请求；本地模型支持则让你通过 Ollama 或 LM Studio 等软件，在自己的电脑上运行模型。提供商密钥是 API 访问凭证，并不是把另一个应用的订阅通用地转移过来的凭据。Kilo 推理选项、Gateway。

这里有两个决定：让哪个模型尝试任务，以及通过哪个账号、哪套基础设施处理请求。把这两件事分清，后续成本比较才有意义。

Kilo Auto Model 提供 Efficient、Frontier 和 Free 三种路由。Efficient 会对任务分类，再按难度选择模型策略；Frontier 使用面向高要求任务的付费模型；Free 则路由到可用的免费模型。你也可以自行指定模型。Auto Model。

日常搭建测试框架时，可以先尝试注重成本的路由，并明确预期行为。遇到牵涉多个服务的故障，则应提供相关追踪记录，让智能体先提出不同的可能原因，再授权它修改代码。判断重点是：回答有没有找到正确的代码，有没有提出能证伪其假设的方法。更贵的模型，只有在减少产出合格结果所需的总工作量时才值得。

自动路由方便，但它不是固定不变的实验条件。Kilo 文档说明，底层模型可能在服务端调整，展开模型选择器可以看到所选模型和费用。如果要在同一任务上比较工具，应记录实际模型与路由，不能只记一个 Auto。Auto Model 文档。

Kilo Code 技能：把重复任务写成明确流程

Kilo 支持技能：用包含 SKILL.md 文件的目录，封装可重复执行任务的指令。当前项目技能放在 .kilo/skills/ 下；智能体会发现其元数据，并在需要时加载相关指令。这能为智能体提供有文档可循的操作流程，但不保证每条指令都能正确执行。技能文档。

以前面的退款场景为例，项目技能可以说明支付测试数据放在哪里、哪条测试命令覆盖重试，以及如何区分重复 webhook 与合法的第二笔退款。描述要足够具体，让智能体能判断何时适用。把流程纳入版本控制，下一位开发者也能检查。

这样做的收益是减少反复交代背景。但指令仍依赖可用的运行环境和人工审查。测试流程写得再好，如果云端检出的项目根本没安装依赖，也无法弥补这一缺口。

Cloud Agents：把可复现的任务交给云端

当任务可以脱离你的笔记本，在托管环境中运行时，Kilo Cloud Agents 就有用武之地。Kilo 文档介绍了仓库连接、远程 Linux 环境、分支和工作树创建，以及可复用的环境配置。这些配置保存初始化命令、环境变量和密钥。Cloud Agents。

适合首次交给云端的，是范围小、验收检查可执行的重构。例如，替换指定模块中已弃用的辅助函数，同时保持测试通过。如果任务依赖未记录的本地服务，以及只存在于 shell 历史记录中的凭证，就不适合直接移交。

迁移到云端有一个具体障碍：Cloud Agents 不会自动发现并执行 .kilo/setup-script。如果仓库需要靠这个脚本完成准备，就要在云端环境配置的 Setup Commands 中显式调用。项目技能可以随仓库一起迁移；主目录中的用户全局技能不会自动带过去。Cloud Agent 文档。

此外，独立对话与独立执行环境是两回事。云端对话共享容器，同一工作树中的对话能看到彼此的编辑。分开工作树有助于隔离改动，但不意味着各自拥有独立机器。如果任务会安装不同依赖、在同一端口启动服务，或假定自己独占生成文件，这个区别就很重要。

Code Reviews：先明确仓库规则，再让 AI 提意见

Kilo Code Reviewer 可以使用你选定的模型和审查重点，为已配置的 GitHub 拉取请求及 GitLab 合并请求添加反馈，也支持提交前的本地审查。真正有用的问题是：这些评论能否指出代码中可采取行动处理的风险，而不是能否列出一长串建议。Kilo Code Reviewer。

小团队可以把它作为人工审查前的额外检查。让它聚焦仓库中真正重要的行为：客户门户的授权、计费系统对重复事件的安全处理，或共享服务的迁移兼容性。格式争论则交给已经负责格式约束的工具。

最有用的配置是 REVIEW.md，即由仓库维护的审查规则。将它提交到基准分支，并在 Code Reviews 设置中启用 Use REVIEW.md。Kilo 从基准分支读取规则，而不是从待合并改动中读取。否则，拉取请求就可能修改用于评估自身的指令。Code Reviews 文档。

对于退款服务，规则可以要求审查重复事件处理、租户授权，以及针对外部调用失败的断言。让审查智能体为每个疑点给出相关路径、解释和证据。这些只是建议采用的审查标准，并不意味着本文测试过智能体、确认它发现了这些缺陷。

在本地工作时，/review 检查未提交的改动；/review branch 则将当前分支与其基准分支对比。一个实用顺序是先本地审查，再针对问题修复，最后提交拉取请求，进入团队正常流程。留意反复运行是否带来了新证据，还是只在换一种说法重复同一个问题。

这项功能的边界不可忽视：托管审查默认忽略机器人创建的拉取请求，包括依赖更新机器人。它还聚焦于改动文件，并受执行和并发限制。如果你最需要解决的是自动依赖更新的审查，就不能假设启用 Code Reviews 后，这批请求也会被覆盖。在把它设为流程必经环节之前，先验证预期用法。

Kilo Code 价格：个人开发者和小团队要算哪些费用？

Kilo 将平台使用、模型推理和托管计算分开计费。除非需要共享管理，否则先从个人平台开始。 当前方案与相关费用可以放在一起看：

• **Free & Open Source：**平台不收费，用量另计。
• Teams： $15/用户/月，提供共享账单、密钥、智能体和用量可见性。**Enterprise：**采用定制报价，提供提供商/模型限制、单点登录和审计日志等治理能力。
• **推理：**Gateway 用量按提供商费率计费，另列 5% 的额度购买手续费。BYOK 的推理费用由你的提供商结算。可选的 Kilo Pass 每月 $19 起，用于订阅额度；它既不代表无限用量，也不包含 Teams 席位。
• **计算：**Code Review $0.33/小时；Docker/Small Cloud Agent $0.60/小时；Standard $1.20/小时。按秒计量，推理费用另计。Kilo 定价。

因此，三人 Teams 工作区的起步费用是 $45/月，用量另计（3 × $15）。按列出的审查计算费率，假设一次审查耗时十分钟，其计算费用为 $0.055（10 ÷ 60 × $0.33），再加上推理和适用的手续费。这只是算术示例，不是实测运行时间，也不是单次审查总价。最终账单仍有很大一部分取决于模型推理和重试。

云端还要求启动时余额至少为 $5。这是余额门槛，不是额外收费；使用 BYOK 也不能免除计算费用。云端计费详情。如果考虑 Pass，只把确定会用掉的赠送额度计入价值，因为这些额度每月到期。Kilo Pass 条款。

从 Free 升到 Teams，关键是是否需要共享管理；从 Teams 升到 Enterprise，关键是治理要求。按所需控制能力选方案，再单独安排用量预算。

哪些限制可能改变你的选择？

Kilo 的灵活性也带来了需要小团队自行负责的配置选择。下面这些限制最可能改变推荐结论。

**未核实数据流向前，不宜用 Auto Free 处理机密工作。**Kilo 自己的 Auto Model 文档说明，免费路由可能使用会记录提示词和输出、并利用这些数据改进服务的提供商。文档明确建议不要提交个人或机密数据。客户端开源，并不会改变所选提供商的数据处理方式。私有代码应使用经过批准的接入路径。Auto Free 数据处理说明。

**本地配置不会自动变成云端配置。**云端不会自动执行 .kilo/setup-script，也没有主目录中的技能，同一条指令因此可能在远程产生不同结果。应将必要的项目指令纳入版本控制，并明确配置云端初始化步骤。否则，你比较的不只是智能体，也是在比较运行环境。

**托管审查无法为整个仓库提供保证。**只审查改动文件、排除机器人请求，以及执行限制，都会留下覆盖空白。依赖机器人提出的更新，以及隐藏在差异之外的行为，可能仍需单独检查。审查智能体没有提意见，并不能证明发布安全。

**公开的审查定价说明存在不一致。**功能页宣传使用免费模型可以免费审查；审查文档则表示，在限期测试阶段，计算资源免费。但专门的定价页和云端页面列出了计算费用。本文按专门的定价页估算预算。在向团队承诺托管审查零成本之前，应确认是否适用测试期或特定账号的豁免。这些说明之间有冲突，也不意味着可以把标价说成未经测试账号上的实际扣费。

**团队方案并不包含全部治理能力。**如果你需要集中限制哪些模型或提供商可以接收代码，定价页将这项控制列在 Enterprise 中。共享账单并不等于拥有相同的管理规则。这个条件可能在讨论模型质量之前，就已经决定采购选择。

Kilo Code 评测结论：为了用得上的工作流再迁移

如果你需要源码可查的智能体、模型选择权，以及相互衔接的本地、云端和审查服务，Kilo 值得进入候选名单。最有说服力的购买理由，是这些能力组合起来能怎样安排工作。仅仅因为模型目录更大就迁移，理由并不充分。

**选 Kilo：**你能明确指出某项经常做的任务，会受益于它的环境切换、模型路由或仓库审查配置，并且愿意管理相关用量账单。**选 Cline：**现有开源智能体配置已经能顺畅处理本地工作。**选 Claude Code：**你想要围绕 Claude 的体验，而且额度适合自己的需求。只要 Kilo 的额外价值仍集中在特定场景，让它与其中任一工具并用也很合理。

下周，选一个小型、可回退的仓库任务。记录模型路由、环境准备工作、计费用量、人工修正，以及最终补丁是否通过你自己的验收检查。只有结果能回答一个有意义的选购问题时，才继续尝试。当 Kilo 减少了交付一项合格改动所需的投入，再把更多工作迁过去；生成的代码更多，本身并不足以成为理由。

常见问题

扩展智能体配置前，可以用 AI 业务工作流审计清单 梳理任务、审查负责人和验收检查。