打开 Kilo Code 的官网，首先映入眼帘的就是这样一句话："适用于 VS Code 的最佳 AI 编程助手"。在 VS Code 上用过的几款插件里，Kilo Code 的表现确实是最让人省心的那个。

在有限的条件下，寻找最优的解——这是它给我的感觉。当然，市面上不乏比 Kilo Code 更强大的工具，但往往需要更强的模型支持，或者更高的费用。投入和产出总成正比，单次请求成本一高，Coding Agent 也开始有了"氪金"的味道。而 Kilo Code 站在 Cline 和 Roo Code 的肩膀上，靠着自身的优化和改进，成了当下的首选。

它支持 30 多家模型提供商，自家也提供了收费的 Kilo API，能用几十种模型——OpenAI、Claude、Gemini、MoonShot、Qwen、DeepSeek、xAI 的通用模型和 Coding 模型都在列。计费标准和各家一样，Kilo Code 本身不加价也不收手续费。

背景

AI Coding Agent 对日常工作的提升主要体现在两个方面：

• 快速的 copy & paste：改变了以往搜索、筛查、复制、粘贴、测试、再搜索的循环往复，省去了在浏览器和 IDE 之间来回切换的时间。
• 处理非结构化数据：数据格式五花八门、规则难以穷举的时候，直接读取原始内容交给模型处理，省掉大量预处理时间。

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

什么叫"非结构化"

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

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

契机

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

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

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

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

往往一个项目的改造，可能拆分成 20 多个子任务，每个子任务又涉及多个步骤，有些步骤涉及编写代码、决策分支、复杂的逻辑判断和验证。后来便将目光转向了 AI Coding Agent。

选择

GitHub Copilot

最初在选择 Coding Agent 时，其实没有真正意义上的"选择"——更像是被环境推着走。工作环境限制下，只有 GitHub Copilot 可用，以及两个不是很高级的模型，好处是 token "量大管饱"，没什么限制。

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

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

Cline

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

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

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

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

但这些不是没有代价的。Cline 的 System Prompt 特别长（不知道新版本有没有优化），执行简单的任务时，都会把上千行的 System Prompt 传给模型，上下文一膨胀就成了名副其实的"吞金兽"。还有执行大量长任务时，上下文容易丢失，响应越来越慢，从秒级掉到 10 分钟级；容易陷入死循环，卡死。甚至一度让人想切回 Copilot。

Kilo Code

抱歉，终于说到正题了。

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

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

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

图片来自 Kilo Code 官网

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

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

参考资料

[1] Kilo Code 的官网: https://kilocode.ai/
[2] 介绍 OpenRewrite 的文章: https://atbug.com/openrewrite-basics-and-principles-overview/
[3] OpenRewrite: https://github.com/openrewrite/rewrite
[4] 用 OpenRewrite 一键将 Spring REST 服务转换成 MCP 服务: https://atbug.com/one-command-to-convert-legacy-spring-rest-services-to-mcp-services/
[5] GitHub Copilot: https://github.com/features/copilot
[6] Cline: https://cline.bot/
[7] 用 Vibe Coding 开发了一个量化交易程序: https://atbug.com/vibe-coding-quant-trading/
[8] 大量的工具: https://github.com/cline/cline/tree/main/src/core/prompts/system-prompt/tools
[9] 检查点（checkpoint）: https://docs.cline.bot/features/checkpoints
[10] Roo Code: https://roocode.com/
[11] 多模式: https://docs.roocode.com/#multiple-modes
[12] 自定义模式: https://docs.roocode.com/features/custom-modes
[13] 排行: https://openrouter.ai/rankings#apps
[14] Kilo Code: https://kilocode.ai/
[15] 任务清单（todo list）: https://kilocode.ai/docs/basic-usage/task-todo-list
[16] Orchestrator 模式: https://kilocode.ai/docs/basic-usage/orchestrator-mode