预算有限，效率拉满：为什么 Kilo Code 成了我的首选 Coding Agent

TL;DR

打开 Kilo Code 的官网，首先入眼的就是这句话“适用于 VS Code 的最佳 AI 编程助手”，也确实我目前在 VS Code 上用过的几款插件中，Kilo Code 的表现是最好的。

写这篇文章的时候，我想到的是老板的那句话“有什么模型就用什么”。

在有限的条件下，寻找最优的解。

不乏有比 Kilo Code 更加优秀的工具，但往往需要更强的模型支持，或者更高的费用。投入和产出是成正比的，单次请求成本越高，慢慢地 Coding Agent 也有“氪金”的趋势。

照此以往，可能在不远的将来，优秀的工具和高级的模型会成为奢侈品，成为少数大企业的专属。

Kilo Code 作为站在巨人肩膀上（Cline + Roo Code）的存在，凭借着自身的优化和改进，成为了我目前的首选。

Kilo Code 可以支持 30+ 模型提供商，同时本身也提供了收费的 Kilo API。通过 Kilo API 可以使用几十种模型，包括 OpenAI、Claude、Gemini、MoonShot、Qwen、DeepSeek、xAI 各家的通用模型和 Coding 模型。并且计费与各家费用一样，Kilo Code 本身不加价不收手续费。

背景

AI Coding Agent 对我的日常来说是提效的利器，主要体现在两个方面：

• 快速的 copy & paste：改变了过去搜索、筛查、复制、粘贴、测试、再搜索循环往复的繁琐流程，也节省了在浏览器和 IDE 间切换的时间。
• 处理非结构化的数据：在数据格式五花八门、规则难以穷举（不规范）的情况下，直接读取原始内容进行处理，省去了大量的预处理时间。

第一种场景少而精，但是预训练的模型已经对无效信息做了很好的过滤，准确率也偏高。第二种场景多且杂，尤其是面对一些非结构化的数据、不规则的代码时，Coding Agent 的优势就体现出来了。

什么叫“非结构化”

• 纯文本：邮件、工单、聊天记录、PDF 报告、网页。
• 半结构化：JSON 里嵌套 HTML，XML 中包含 Java 或者其他脚本代码片段。
• 结构多变、不规范：今天多一个字段，明天换分隔符，后天又来一个嵌套数组；项目间的风格不统一、缺少注释、框架版本碎片化。

对于这类数据，传统的做法是： 穷举规则、编写代码、测试、调试、再测试，直到覆盖所有的边界情况。这个过程往往是反复迭代的，耗时耗力，像是在写规则引擎。使用 AI 的做法则是：用一段自然语言描述想要的结果，让模型直接处理原始数据。

处理后两种情况则也是我当下的常态。

契机

之前在 介绍 OpenRewrite 的文章 中提过当前的工作主要是系统改造相关，涉及框架与平台的迁移。也是当时探索 OpenRewrite 的契机。

OpenRewrite 处理结构化的代码，如特定语言或者特定的框架，能做的事情特别多，而且效果很好。正是传统的做法，找到有限的边界就能实现转换。比如我曾经实现过 用 OpenRewrite 一键将 Spring REST 服务转换成 MCP 服务。因为 Spring REST 服务的代码结构是比较规范的，OpenRewrite 可以很容易的解析和转换。

但是遇到不规范的代码或者不支持语言和框架，尤其是复杂操作的场景，OpenRewrite 就无能为力了。比如：

• 对整个项目的代码进行分析，涉及多种语言和各种不规范的代码。
• 在不同语言间进行转换。

往往针对一个项目的改造，可能拆分 20+ 的子任务，每个子任务又涉及多个步骤，有些步骤涉及编写代码、决策分支、复杂的逻辑判断和验证。

后来我便将目光转向了 AI Coding Agent。

选择

GitHub Copilot

最初 Coding Agent 的选择上，其实没有真正意义上的“选择”——更像是被环境推着走。因为工作环境的限制：只有 GitHub Copilot 以及 2 个不是很高级的模型，但好处是 token “量大管饱”，没什么限制。

GitHub Copilot 除了支持 VS Code 之外，还支持 JetBrains 系列的 IDE，在代码补全方面的表现不错。但是在处理复杂任务时，其表现并不理想，需要拆分得非常细致，才能得到想要的结果。

Copilot 像一辆自动挡汽车：在市区里（单行补全、简单重构）轻踩油门就能跑；一旦要上盘山公路（多步骤多子任务），它就只会一条直道冲到黑：将所有步骤压缩成一次性输出，结果往往不尽如人意。

Cline

如果 Copilot 最多只能算是个副驾驶，不能完全交给它去开车。那么 Cline 可能算个“代驾”了，可以实现端到端的自动化，尤其是 Plan（规划）和 Act（执行）两种模式的结合。

• Plan：进行对话式交流，专注于问题分析和解决方案设计，而不立即生成代码。在这个模式下，它会帮你梳理目标和需求、分解复杂问题、制定实施策略，并分析潜在挑战和解决方案。这个模式特别适合项目初期的头脑风暴和结构化思考，让你在编写任何代码前先厘清思路。
• Act：在这个模式下，它会根据你的指令生成代码。你可以直接给出需求，它会自动分析并生成代码。这个模式适合于具体的编码任务，尤其是当你已经有了清晰的思路和设计时。

我甚至通过 Cline 用 Vibe Coding 开发了一个量化交易程序，不过不要太过当真。

Cline 内置了 大量的工具 并且自主能力强，可以改动多文件、跑测试、执行命令等，可以执行复杂的任务链。还有我非常喜欢的“回滚”功能：当结果不符合预期时，可以让它回到上一个 检查点（checkpoint） 继续尝试，直到满意为止。

但是这些不是没有代价的，Cline 的 System Prompt 特别长（不知道新版本有没有优化），执行简单的任务时，都会把上千行的 System Prompt 传给模型，上下文一膨胀就是名副其实的“吞金兽”了。

还有执行大量长任务时，上下文容易丢失，响应还会越来越慢，从秒级调到 10 分钟级；容易陷入死循环，卡死。

甚至让我一度切回 Copilot。

Kilo Code

抱歉，终于说到正题了。

正当我准备放弃 Cline 的时候，从群聊中得知了 Roo Code：Roo Code 尤其是在模型能力不强的情况下，表现不错。而且 Roo Code 作为 Cline 的 fork，保留了 Cline 的大部分功能，还做了大量的优化，更新速度更快。尤其是 多模式，相比 Cline 的 Plan 和 Act 跟多，甚至可以 自定义模式（这个好像 Copilot 后来也支持了）。

正当我去 OpenRouter 查看 排行 的时候，Roo Code 的排名并不靠前，反而是 Kilo Code 排名第一。而且搜索后得知，Kilo Code 是 Roo Code 的 fork。

Kilo Code = Roo Code 的“多模式 + 高可定制” + Cline 的“稳定 + 强集成” + 自己的“零门槛、可扩展、更聪明”，把前两者的优点打包，又补上了它们最明显的短板。

Kilo Code 最让我惊艳的就是它的 任务清单（todo list），它会自动为复杂的任务生成任务清单，并且可以根据任务的完成情况动态调整任务清单，展示在聊天界面中。这样就不会错过任何步骤，并对任务进度一目了然。

除了自动出发生成任务清单之外，还可以通过输入 update_todo_list 使用工具手动触发。

图片来自 Kilo Code 官网

除了任务清单之外，还可以通过 Kilo Code 的 Orchestrator 模式 进行“套娃“：将多个子任务串联起来，形成一个更加复杂的任务链。每个子任务都是在独立的会话中执行（父任务暂停），有独立的上下文（不会继承父任务的上下文，但可以显式地指定向上或向下传递），可以使用不同的模型、不同的模式，甚至不同的工具。

我打算把 Kilo Code 推到极限：用 30+ 连续子任务的实战项目给它做“压力测试”，一边验证它在超长上下文里的稳定性，一边把 Orchestrator 模式和任务清单玩出最佳实践。