Roo Code 停运后迁移：保留 API，替换代码客户端
Roo Code 已归档。为现有用户梳理 API 配置、原生工具和权限的迁移方法，通过小任务验证替代客户端，而非继续推荐旧扩展。
发布 2026-09-29 · 更新 2026-09-29 · KeepRouter Editorial · 5 分钟阅读
迁移现有 Roo Code 配置时，先把“模型 API”与“代码客户端”分开。可以评估保留原来的兼容 API，同时更换扩展；提示词、文件选择、工具执行、权限和会话状态则需要重新验证。
Roo Code 官方仓库已归档，并包含 2026 年 5 月 15 日停运说明。本文服务于现有用户迁移，不建议新项目继续把旧扩展作为生产起点。仓库提到 Cline 和社区 fork ZooCode，但这种列名不能替代适用性验证。
记录真正使用的配置
保存旧客户端版本和不含秘密的配置。导出文件如果包含 Key，先移除，别提交到代码仓库。
| 原配置 | 迁移时确认 |
|---|---|
| 基础地址与型号 | 新客户端是否支持该协议和准确型号 |
| 原生工具 | 是否消费工具事件并返回对应结果 |
| 上下文与输出 | 限制数值和单位是否一致 |
| 自定义模式 | 哪些是通用规则，哪些依赖旧工具 |
| 文件与命令权限 | 哪些操作需要审批 |
| MCP | 凭证存在哪里、由谁执行 |
| 旧会话 | 是否引用已执行动作或过期文件 |
相同 API Key 不会自动迁移全部行为。两个客户端可能选择不同文件、构建不同提示词，并提供不同工具。
原生工具协议不能只看文字效果
归档版接入文档说明 Roo Code 只支持原生工具调用，没有 XML 回退。因此原来的工作流需要真实工具事件，普通文本里打印命令不算等价替代。
先让新旧配置读取同一个无敏感信息的文件，并报告指定一行。检查实际工具调用和结果，而不是只相信“已读取”的文字。之后才在临时分支测试一次小改动，查看文件 diff 并运行测试。
用相同项目做迁移样本
固定仓库版本，分别开启新任务，避免某个客户端继承已经解决的上下文。可以使用下面的测试：
1. 阅读 README，找出项目的测试命令。
2. 打开名为 empty_input 的解析器测试。
3. 解释预期结果，暂不修改。
4. 添加一个仅包含空白输入的测试。
5. 获得批准后只运行该测试文件。
需要凭证、升级依赖或调用外部服务时停止。这是测试设计，不是实测排名。读取成功但补丁无法应用，与工具 schema 被拒绝是不同错误，应该分开记录。
有选择地移动项目规则
自定义模式可能含有旧工具名称和审批假设。把可复用项目规则整理为普通文本，再按新客户端的配置方式处理工具专属部分。
旧会话可保留为参考，不直接视为当前可执行状态。它可能指向已经发生的动作或已修改文件。让新客户端先查看现有工作区，再继续工作。
第一次比较客户端时保持模型不变。客户端验证完成后，再单独评估其他模型或 API，这样才能定位回归来自哪一层。
费用和权限都需要重新核对
客户端估算可能采用不同 tokenizer 和价格表。统计整个任务的实际调用、修正、失败费用与人工复核时间。即使可见提示词一致，客户端发送的仓库上下文也可能不同。
可参考 Cline 接入或 Aider 接入验证不同工作方式。如果保留 KeepRouter，先在目录确认型号与协议。旧配置可留作参考，新客户端的维护状态与安全适用性仍需独立判断。
常见问题
这是推荐新安装 Roo Code 吗？
不是。官方项目已归档，本文帮助现有用户在选择替代客户端时区分 API 配置与客户端行为。
迁移后能保留相同模型 API 吗？
可能可以，前提是新客户端支持对应协议，型号支持需要的工具，并通过读取、编辑和测试的完整流程。
客户端和模型要一起换吗？
建议分开。先固定模型验证客户端，便于定位回归；之后再比较模型质量和任务费用。
参考的一手资料
本文最近复核 2026-09-29
- [1] Roo Code archived repository and shutdown notice
- [2] Archived Roo Code compatible-provider protocol