20260903 OpenCode 和 KiloCode 的主要区别是什么？为什么我会选择 KiloCode？

OpenCode 与 KiloCode 工作流对比封面

最近 OpenCode 和 KiloCode 经常被放在一起讨论：一个让我在终端里专注完成任务，一个把多个 Agent、隔离工作区和代码审查组织进 IDE。很多朋友真正想问的其实不是“谁更强”，而是“我现在的工作方式，应该把哪一个放在手边”。这篇文章记录我最近一次切换工具的原因，也把我认为最影响选择的差异讲清楚。蓝色高亮表示工具事实，绿色高亮表示我的判断，红色高亮表示容易踩的坑，黄色高亮表示可以直接尝试的做法。文中的产品信息按 2026 年 9 月 3 日查阅到的官方文档整理，后续可能随版本变化。

先说我的结论：如果你主要在终端里工作，喜欢自己控制会话、目录和模型，OpenCode 依然是一把很顺手的工具；如果你经常同时推进多个任务，希望在 VS Code 或 JetBrains 里集中看状态、diff 和工作区，KiloCode 更贴合我的习惯。更准确地说，Kilo CLI 是 OpenCode 的 fork；Kilo 的 IDE 插件和 Agent Manager 则是 Kilo 另行组织的产品层。所以它们不是两个完全无关的竞品，也不是同一个产品换了两个皮肤。

我为什么又换了一次？上一篇文章里，我写过自己怎样把 OpenCode 接进日常开发，那些经验现在仍然有效：终端里可以跑命令，配合 LSP（语言服务协议）理解代码，也可以通过 MCP（模型上下文协议）接入外部工具，项目规则则写进 AGENTS.md。后来我的任务从“一个人在终端里重构 Go 服务”，变成了同时推进重构、补测试、写文档、审 PR 和修 bug，还要在 VS Code 与 JetBrains 之间来回切换。OpenCode 的多 session 能力并不弱，只是我需要自己安排目录、创建 git worktree（并行分支工作区），再盯住每个会话的进度。KiloCode 的 Agent Manager 把这部分协调工作做成了看板：每个 Agent 可以在独立 worktree 里运行，我只需要负责拆任务和合并结果。

我实际感受到的差异，主要有四点：

  1. 工具住在哪里不同。 OpenCode 的核心体验是终端 TUI（终端用户界面），并通过 Models.dev 接入多个模型提供商，也支持本地模型。 KiloCode 则把 VS Code、JetBrains、CLI 以及云端能力放在同一套产品里。如果终端就是你的主工作台，OpenCode 的路径更短；如果 IDE 是你的主工作台，KiloCode 的侧边栏和 diff 面板更自然。
  2. 并行能力的产品化程度不同。 OpenCode 可以开多个 session，但在我的用法里，目录隔离、worktree 创建和任务协调仍然需要自己处理。Kilo Agent Manager 为并行会话提供独立 worktree、状态面板、差异审查和独立终端。 对我这种常常同时跑三到五个任务的人来说，这不是多了一个按钮，而是少了一层心智负担。
  3. 模型入口的取舍不同。 OpenCode 更像开放的模型接入层；Kilo Gateway 则提供统一入口，官方目前宣传可选 500+ 模型，并支持自动路由。 我更愿意把“规划”和“执行”交给不同模型，但不太愿意完全交出选择权。自动路由不是银弹：复杂重构如果被分给能力不足的模型，返工成本可能高过自己挑模型。
  4. 覆盖范围不同。 Kilo 的优势在于把 IDE、CLI、云端和移动端会话串起来，具体可用范围要以当前版本为准；OpenCode 则更聚焦在终端工作流。我会把这个差异理解成“单机专注”与“跨界面接力”的选择，而不是功能数量的比赛。

我最后选择 KiloCode，理由也只有三条：

  1. Agent Manager 让我可以把重构、测试和审查拆成几个相对独立的任务，让它们在不同 worktree 里并行推进；我从“手动协调多个 Agent”变成了“看板式管理多个结果”。不过 worktree 不是免费的：独立 checkout 里的依赖、构建产物、本地数据库和缓存都可能重复占用磁盘，任务结束后要及时关闭不用的工作区。
  2. VS Code、JetBrains 和 CLI 之间的会话衔接，更接近我现在的工作节奏。Kilo 文档也明确支持跨界面同步会话，但云端、浏览器和移动端的具体能力仍会随产品迭代变化。 这让我在换设备或离开 IDE 时，不必从头解释上下文。
  3. 我可以使用 BYOK（自带 API 密钥）并保留 Kilo 的产品能力。在 BYOK 场景下，Kilo 官方说明不会在自身侧增加模型调用加价，但供应商仍会按自己的计费规则收费。 我因此更倾向于自己选模型，而不是默认打开自动路由。我目前的最小可用集是：VS Code 安装 KiloCode，接入自己的 Key，Agent Manager 使用 worktree 模式，模型手动选择。

最后，我想把这次切换留下的启示收束成八句话：

  1. 先找瓶颈：是终端效率、并行协作、跨 IDE，还是跨设备接力？
  2. 工具形态比功能清单更重要，真正决定体验的是它是否贴合你的日常路径。
  3. Kilo CLI 与 OpenCode 有明确的 fork 关系，但 Kilo 的 IDE 产品层带来了另一套使用方式。
  4. Agent Manager 是 Kilo 最打动我的地方，尤其适合需要隔离 worktree 的并行任务。
  5. “500+ 模型”和“零加价”要放回语境里理解：前者是会变化的目录规模，后者主要对应 BYOK 或 Gateway 的具体计费规则。
  6. 不要按 star 数量选工具，社区热度不能替代自己的工作流测试。
  7. 两者都支持开放的模型接入思路，先各自试用一周，通常比争论更快得到答案。
  8. 把“为什么换”问清楚：工具变化只有在工作场景真的变化时，才值得付出迁移成本。

所以，我不是因为 OpenCode 不好才选择 KiloCode，而是因为现在更需要一个能替我管理并行任务的工作台。如果你的瓶颈仍然是“安静地在终端里把一件事做好”，那 OpenCode 可能就是更合适的答案。

参考资料：