从 Claude Code 迁移到开源 harness：概念对照表与七步流程

这条路线最彻底，也最容易做错。做错的方式通常是同一个——先挑工具，再想怎么把东西搬过去。正确顺序恰好相反。

更新于 2026 年 10 月 22 日 · 约 8 分钟阅读 · 专题第 7 篇

一、先建映射表

下面这张表按"你会带走什么"排序。注意最后一列：有些东西不是换个名字，而是真的没有了。

二、七步迁移流程

1. 盘点。把 ~/.claude 与各项目里的 .claude 目录过一遍，列出你实际在用的东西：哪些命令、哪些 hook、哪些规则文件。多数人会发现真正常用的只有少数几项。
2. 分类。按上表的三档归类：能直接带走的、要改写的、没有对应物的。第三档决定这次迁移的真实成本。
3. 选型。用第二档和第三档当筛选条件，而不是用评测分数。你需要的不是"最强的 harness"，而是"最少让我丢东西的 harness"。
4. 迁移规则文件。把 CLAUDE.md 改成目标格式。这一步能立刻见效，因为它是上下文质量的主要来源。
5. 重建 hooks。用 git hooks（如 pre-commit 跑格式化）或包装脚本补上。不要指望一次做到位，先把最痛的一条建起来。
6. 跑同一个真实任务。拿一个你上周做过的任务，在新旧两边各做一遍，比较：步数、人工干预次数、是否需要返工。这比任何主观感受都可靠。
7. 留下回退路径。旧环境别急着删，配置、凭据、规则文件先备份。迁移期至少保留两周的双环境。

三、一定会丢的能力

把这一节单独写出来，是因为它最容易被低估，也最容易在两周后变成"早知道就不迁了"。

• subagents 的上下文隔离。多开几个终端看着像，实际差别很大：主上下文是否被污染、子任务之间能否共享状态，都做不回来。
• hooks 的强制力。自己写的包装脚本很容易被绕过或漏掉，而内置 hook 是"不可能忘记执行"的。
• 长任务的稳定性。一次跑二十分钟不跑偏，是 harness 层面的工程积累，不是换个模型能补上的。
• 统一的手感。每个 harness 的工具调用风格不同，你的肌肉记忆会有一段时间的错位期。

如果你读完这四条觉得"其实我不用这些"，那说明你的痛点在别处——大概率是模型质量和成本，那么只换模型就够，不需要迁移。

四、按场景选型

不做排名，只给筛选逻辑。三类常见场景的权重完全不同：

五、双跑过渡

最省心的迁移方式不是切换，而是分工。用两到四周让新旧并存：

• 第一周：新 harness 只做低风险任务——写文档、补测试、改小 bug。目的是熟悉工具而不是产出。
• 第二周：让它承担一个完整的小需求，从读到改到跑通。记录人工干预了几次。
• 第三周：把项目里最讨厌的那类任务交给它（比如重构、跨文件改名），这类任务最能暴露稳定性问题。
• 第四周：做决定。要么扩大比例，要么承认不合适、回退到只换模型的方案。

这个节奏的好处是：无论结果如何，你都没有在关键项目上冒过产能断崖的风险。而"承认不合适然后回退"本身也是一个合格的结果——迁移不是立场问题。