Roo Code 深度评测：仓库已归档，存量用户该怎么迁移

一句话结论

这篇评测和站内其他评测不一样 —— 它不是回答「Roo Code 好不好用」，而是回答一个更紧迫的问题：它已经归档了，你现在手上的这份配置还能撑多久、该往哪转。

先把事实摆出来：GitHub 仓库 RooCodeInc/Roo-Code 当前 archived: true（已归档，只读），最后一次代码推送是 2026-05-15T18:08:47Z，最后一个正式版本 v3.54.0（2026-05-15 发布）。官网域名 roocode.com 已经 301 重定向到 roomote.dev —— 那是同一个团队今年 7 月新开的云端 Agent 产品。

它当年确实是 Cline 分支里最有想象力的那支：多模式（Code / Architect / Ask / Debug）、Boomerang Tasks 子任务编排、自定义 Modes、BYOK。设计思路放到今天也不落伍。但一个已经归档近半年的上游仓库，不该再被当作新项目的默认选择 —— 这是本文最想传达的结论。

本文以 GitHub API 仓库元信息、官方 Releases 页与域名解析结果为一手依据核对整理，非厂商付费内容；未做长期一手实测，仓库状态与版本以官方实时页面为准。

Roo Code 到底是什么

它是从 Cline 早期版本 fork 出来的 VS Code AI 智能体，Apache-2.0 许可，走「power user 路线」：同一套 BYOK（自带模型 Key）底座上，抽象出多个工作模式，让不同任务用不同模型、不同审批策略。

它最有辨识度的设计是 Boomerang Tasks：主任务可以把子任务派发给不同模式执行（Architect 设计 → Code 实现 → Debug 验证），每个子任务可用不同模型 —— 贵模型负责规划、便宜模型负责实现。这个思路在重构与多文件改动里确实能省 token 成本，后来被不少工具借鉴。

所以它的问题从来不是设计，而是持续性。

归档事实核对（截至 2026-10-07）

把发布节奏拉出来看，趋势更清楚：

官方工具卡里写的「每周多次发布」在 2026 年 3 月之后已经不再成立 —— 到 4 月变成两三次，5 月只发了最后一个版本。归档不是突然发生的，是节奏逐步停下来的结果。

团队去哪了：Roomote

归档不等于团队解散。同一个组织（RooCodeInc）在 2026-07-07 建了新仓库 Roomote（官网 roomote.dev），至今活跃（2026-10-07 仍有推送）。

但要注意：Roomote 不是「Roo Code 的下一版」，产品形态完全不同 ——

也就是说，「Roo Code 归档 → 换成 Roomote 就用上了」这条路在体验层面不成立。Roomote 是「把任务丢给云端 Agent，等它开 PR」，而 Roo Code 用户依赖的「在编辑器里逐步审批、自己控制每一步」恰恰是前者不提供的。

与 Cline 的对比：差距已经拉大到 2.9 倍

Roo Code 与 Cline 同源，是最自然的替代候选。两者当前状态对比：

Cline 的 Star 数已经是 Roo Code 的约 2.9 倍，且在归档同期持续发版。Roo Code 当年「比 Cline 更激进的新特性」这个卖点，如今已经反过来 —— 特性更新的那一方是 Cline。

存量用户该怎么做

分三种情况：

1. 只是本地自己用、配置不复杂 → 可以暂不动，但要锁版本 扩展是本地 BYOK 执行，不依赖官方云服务，装了就能用。但必须清楚：没有安全修复。长期使用建议固定扩展版本（关闭自动更新），并在 .rooignore 里把敏感目录排除干净，Auto-Approve 保持关闭。

2. 团队在用、有共享配置或依赖团队治理 → 尽快迁 Cline 同源迁移的成本最低（模式概念、BYOK、审批流程都对应得上）。要重做的东西提前列清单：自定义 Modes 的提示词、Auto-Approve 规则、.rooignore、以及依赖 Boomerang 子任务编排的工作流。

3. 想保留「子任务编排 + 多模式省 token」这套用法 → 需要重新评估，别指望 Roomote 接上 这套能力是 Roo Code 的独有设计，替代品不一定有等价物。如果它是你流程的核心，要么接受 Cline 上重建等价工作流，要么考虑换到别的编排形态（例如用支持子 Agent 的终端 Agent 自己搭）。

局限与注意点

• 「扩展还能装」不等于「还能安全用」。归档意味着零上游修复，任何新发现的漏洞都不会有人打补丁。
• 不要买/续任何与 roocode.com 相关的云服务，域名已重定向，原站点形态不再维护 —— 涉及订阅或额度的事项先确认指向的是哪个产品。
• 迁移评估要按「配置资产」而不是「插件」来算。Roo Code 用户往往积累了大量自定义 Modes 与审批规则，这部分才是迁移的真实成本。
• 本文不对 Roo Code 做功能优劣评价。它在活跃期是一款设计有想法的工具，归档是商业与团队决策，不构成对产品本身的否定。

AI 之家 观点

Roo Code 的归档，是 2026 年开源 AI 编程工具赛道一个值得记住的样本：它证明了「fork 一个成熟工具、把新特性做得更激进」能快速拿到 2 万 Star，但也证明了这条路没有护城河 —— 一旦上游（Cline）加速、一旦团队转向别的商业模式（云端 Agent），fork 出来的那支就失去了持续投入的理由。

对开发者的直接教训有两条：

1. 选开源 AI 编程工具，要看「谁在为它的长期维护付钱」。纯社区热情支撑的项目，路线会随团队状态漂移。
2. 把配置资产当成可迁移的东西来管理。如果你的工作流深绑某个工具的自定义模式，那本身就是一次迁移的负债 —— 设计时就要考虑「换工具时哪些能带走」。

对 aiho.net 的读者，我们的建议很干脆：新项目直接选 Cline（活跃、同源、Star 与版本都在跑）；已经在用 Roo Code 的，按上面第 1 / 2 条做选择，别拖到出现安全问题时被动迁移。

相关阅读

• Roo Code 工具卡 · Cline 工具卡
• Cline vs Roo Code 对比 · Cline 深度评测
• Claude Code 深度评测 · Claude Code vs Cline 对比
• 开源通用 Agent 上手指南

来源

• GitHub API — RooCodeInc/Roo-Code 仓库元信息（archived: true；最后推送 2026-05-15T18:08:47Z；24,282 Star / 3,419 Fork / 1,033 open issue / Apache-2.0）（2026-10-07 访问）
• Roo Code Releases（v3.54.0 = 2026-05-15T17:52:24Z，为最后一个正式版本）（2026-10-07 访问）
• GitHub API — RooCodeInc/Roomote（创建于 2026-07-07，2026-10-07 仍有推送，官网 roomote.dev）（2026-10-07 访问）
• GitHub API — cline/cline 仓库元信息与最新版本 v4.1.23（2026-10-07T07:28:08Z）（2026-10-07 访问）
• roocode.com 域名解析实测：301 重定向至 https://roomote.dev/（200）（2026-10-07 访问）