东予薏米上一周我同时收到四个不算大但也撇不开的需求：一组老接口要改成新版协议，前端表格要加筛选和导出，缺失的单元测试要补，最后还要写个数据迁移脚本。我的第一反应是在本机开四个终端窗口，每个窗口各跑一个 Claude Code 会话。结果刚过一小时，笔记本风扇就没停过，四个会话全部变卡；更惨的是下班合盖回家，第二天再开终端，四个会话全部失效，之前的上下文也找不到。
后来的解决方式是把 Claude Code 搬到云上的虚拟机上，用终端复用器 tmux 同时支撑多个会话并行运行。所有任务挂在云端，本地电脑合盖、断网、重启都无所谓，想检查进度就用 SSH 登上去看一眼。这是"Claude Code 中英文系列教程"里关于云端并行运行的部分，适合已经把 Claude Code 跑熟、希望它能像后台员工一样长期稳定处理多任务的开发者。我会把每一步都写到能直接执行的程度，也会解释每一步背后的取舍。
1. 为什么我坚持把 Claude Code 放到云上虚拟机里跑
1.1 本地终端回答不了我的三个问题
先说我自己总结的三个真实瓶颈。
第一，会话存活时间被本机状态绑架。笔记本合盖休眠、系统自动更新后重启、家里突然断电，都会直接干掉终端里正在跑的 Claude Code 进程。对短促的问答还好，遇到那种需要连续处理几十个文件的批量任务，断一次基本就是重新来。你可能觉得"再跑一次就行"，但上下文丢了之后，Claude 对之前调整过的命名、逻辑约束记得乱七八糟，后续效果明显打折。尤其是并行多个会话时，每个会话都有自己的上下文，断掉一个就已经够头疼，全断就更让人崩溃。
第二，资源占用比想象中高。Claude Code 是一个常驻的 Node 进程，单个会话平时占的内存不算离谱，但当你开四个窗口时，四个 Node 进程加上各种 TUI 渲染和文本缓存，内存立刻多出几百 MB 到 1GB。如果再同时开着 IDE、浏览器、数据库客户端，笔记本的风扇直接拉满。内存吃紧后，系统开始频繁换页，Claude Code 的响应速度也会变慢。换句话说，本地并行会话的上限不是由 Claude 的能力决定的，而是由本机内存决定的。多任务并行这件事，本质上就是在吃机器容量。
第三，本地网络不稳定时远程调试很痛苦。我之前在咖啡厅连着 Wi-Fi 跑一个长任务的 Claude Code 会话，中间某个请求挂在"thinking"状态，Wi-Fi 正好抖动，终端直接报连接断开，任务没有完成。本地网络状况不可控，而云主机通常在机房环境里，网络稳定性和长时间连接的耐受度都更可靠。
1.2 云 VM + 并行会话真正解锁的场景
换到云主机之后，我看到的是另一个世界。用一个表格直观对比一下：
| 场景 | 本地终端跑多会话 | 云 VM 跑多会话 |
|---|---|---|
| 长时间批量任务 | 受制于笔记本睡眠、断网 | 7x24 挂着，随登随看 |
| 多窗口并行 | 内存吃紧、发热明显 | 按规格扩容，专机专用 |
| 中断恢复 | 进程随 SSH/本机状态消失 | tmux 后台常驻，attach 就回来 |
| 环境隔离 | 和日常办公环境互相干扰 | 独立环境，快照可回滚 |
| 多人协作 | 不好共享 | 别人也可以 SSH 查看实时进度 |
适合用云端并行会话跑的典型工作流有这么几类。一是历史代码库的批量重构，交给一个 Claude Code 会话慢慢改，另一个会话去补测试，再一个会话写迁移脚本，互不干扰。二是代码审查类的任务，把多个模块分别交给不同会话做静态检查和改进建议，顺手让另一个会话把结果整理成文档。三是深夜挂机任务，把耗时的数据清洗、文本批量生成、格式转换丢到云端，让它自己跑完，第二天直接看结果。
云 VM 对 Claude Code 的加成不只是"能跑"，而是能把会话当作可以被管理和调度的独立单元。这是并行工作流真正的地基。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 云主机选型与基础环境初始化
2.1 规格怎么定：从 2C4G 说起的配置理由
先说结论：如果只跑 2~3 个 Claude Code 会话，2 核 CPU、4GB 内存的云主机就够；想稳定跑 4~6 个会话，建议直接上 4 核 8GB；8 个以上并行时别省了，8 核 16GB 的机器会让操作体验更舒服。
为什么这么分？每个 Claude Code 会话本质上是独立的 Node 进程，常驻内存大约 200MB 左右，但一旦你给它一个大仓库，它需要递归读取目录结构、缓存文件内容、做代码索引，内存和 CPU 都会冲高。2C4G 跑四个会话，内存可能逼近 90%，系统稍微有点别的负担就容易卡；把数量控制在 2~3 个，剩余内存还能留给系统层使用。磁盘方面建议至少 40GB。Claude Code 本身不大，但代码库、node_modules、构建产物、日志会很快吃满空间。项目多的时候，最好把数据目录放在独立的云盘上，和系统盘分开，以后扩容也方便。
带宽其实不是主要瓶颈，Claude Code 是文本交互，流量不大。但如果你要在服务器上拉取依赖、同步大仓库，5Mbps 是起步，有条件就选按量计费或者更高带宽。我的经验是，与其纠结那几十块钱的带宽，不如把内存买大一点，因为并行会话的内存消耗是最先触顶的资源。
2.2 不踩系统包坑：用 nvm 装 Node 的完整步骤
登录云主机后，我习惯先升级系统，再装基础工具。
bash复制sudo apt update && sudo apt upgrade -y
sudo apt install -y curl git build-essential
然后安装 Node.js。这里我强烈建议用 nvm 而不是 apt install nodejs。原因是很多云镜像自带的 Node 版本不是最新的 LTS，而 Claude Code 对 Node 版本有要求，版本太旧会报兼容性错误；nvm 可以针对不同环境切换版本，后面要装多个 Node 版本也很方便。
bash复制curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
安装完会提示重新加载环境变量，执行：
bash复制source ~/.bashrc
然后安装最新的 LTS 版本：
bash复制nvm install --lts
node -v
npm -v
看到类似 v20 或更高的版本输出就说明环境没问题。这里有个容易忽略的点：如果你是通过终端复用器里的旧窗口执行命令，新装的 nvm 可能没生效，记得先退出重进或者重新执行 source ~/.bashrc。
2.3 Claude Code 安装和 API Key 配置
Node 就绪后，全局安装 Claude Code：
bash复制npm install -g @anthropic-ai/claude-code
claude --version
如果 nvm 安装成功，全局目录通常在用户自己的 node 目录下，一般不会遇到权限问题。万一你用的是系统自带的 Node 并且报了 EACCES 权限错误，说明当前用户对全局 node_modules 没有写权限。可以在用户目录下单独设置 npm 的全局安装路径，再把 PATH 加上，而不是直接 sudo npm install。
云主机大多没有图形浏览器，交互式登录不方便，所以更推荐用 API Key。把密钥写入环境变量：
bash复制echo 'export ANTHROPIC_API_KEY="你的密钥"' >> ~/.bashrc
source ~/.bashrc
然后运行一次 claude，能正常进入欢迎界面就说明配置成功。需要提醒的是，不要在公开截图或日志里露出完整 API Key，云主机的配置文件记得用 chmod 600 ~/.bashrc 收紧权限，避免同机其他用户读到。如果要用官方账号的 OAuth 登录方式，也可以在支持的终端里执行 claude /login，按提示走浏览器验证流程。
3. 用 tmux 管好并行的底子：会话、窗口和窗格
3.1 SSH 断开就丢任务：终端复用器解决的本质问题
如果你直接在 SSH 连接里运行 claude，一旦连接断开、超时或被本地网络掐断，终端进程就会收到 SIGHUP 信号被系统终止。重新登录后，那个 Claude Code 会话早就没了。这种模式没法谈"并行运行多个会话"。
tmux（终端复用器）把"终端界面"和"SSH 连接"解耦。tmux 在服务器上跑一个守护进程，维护多个虚拟终端窗口；你看到的终端只是这个守护进程的一个客户端。SSH 断开，客户端消失，但守护进程不退出，里面的 claude 进程照常运行。这就是为什么做云上并行，tmux 几乎是标配。从使用者的角度看，它就相当于给每个命令行环境装了一个"独立后台"，让终端不依赖本地的窗口连接。
3.2 tmux 常用操作速查：会话、窗口、窗格
先安装：
bash复制sudo apt install -y tmux
| 你想做的事 | 命令或快捷键 | 说明 |
|---|---|---|
| 新建一个 tmux 会话 | tmux new -s claude | 会话名取 claude，方便识别 |
| 从会话中分离 | Ctrl+b 然后按 d | 回到普通 shell，tmux 仍后台运行 |
| 重新接入已有会话 | tmux attach -t claude | 恢复之前的所有窗口内容 |
| 列出所有 tmux 会话 | tmux ls | 检查服务器上有哪些会话存活 |
| 新建窗口 | Ctrl+b 然后按 c | 每个窗口相当于一个终端标签页 |
| 切换到第 N 个窗口 | Ctrl+b 然后按 N | N 是 0~9 窗口序号 |
| 显示窗口列表 | Ctrl+b 然后按 w | 弹出列表后用方向键选择 |
| 左右分屏 | Ctrl+b 然后按 % | 同一窗口切成左右两栏 |
| 上下分屏 | Ctrl+b 然后按 " | 同一窗口切成上下两栏 |
| 关闭当前窗口 | Ctrl+d | 退出窗口内的程序后自动关闭 |
| 关闭全部 | tmux kill-server | 慎用，会杀掉所有会话 |
我通常会给每个项目建一个独立的 tmux 会话，而不是把所有任务塞在一个会话里。这样即使某个项目的所有窗口都失控，也能单独 kill 掉对应会话，不影响其他项目。如果你和我一样经常要翻超长日志，可以给 tmux 加一行配置开启鼠标滚动，长输出直接用滚轮看，不用死记快捷键：
bash复制echo 'set -g mouse on' >> ~/.tmux.conf
tmux source-file ~/.tmux.conf
第一次用 tmux 的人，不用急着背快捷键，先把分离、接入、新建窗口这几步练熟，其他都是水到渠成的事。
3.3 为什么选 tmux 而不是 screen
同样能分离会话，为什么要选 tmux？首先是窗口管理。tmux 的 Ctrl+b w 能弹出可交互的窗口列表，项目多了尤其好用；Ctrl+b 0~9 直接跳转窗口，比 screen 的切窗方式更符合现代终端使用习惯。其次是窗格。并行会话场景里，我经常需要同时观察两个 Claude Code 窗口的进展，tmux 的左右分屏、上下分屏非常干脆，screen 在这一块差了不少。第三是脚本能力。后面启动多个窗口时用的 send-keys，是 tmux 的原生能力，写批量脚本非常方便。基于这三点，多会话并行场景我基本都推 tmux。
4. 一台机器上同时跑多个 Claude Code 会话的实操
4.1 先分活再开会话：任务拆解的原则
并行最怕的不是机器扛不住，而是多个 Claude Code 会话改到同一个文件，最后提交时互相覆盖、冲突到无法收拾。我在分配任务时遵循几个原则。
第一，按目录或模块边界划分。比如让会话 A 只改动 src/api，会话 B 只改动 src/ui，会话 C 只写测试，会话 D 只处理脚本。这样各自的改动落点不同，代码评审和 merge 都轻松。第二，明确每个会话的"禁止事项"。运行前我会在提示词里说明"不要修改 .env"、"不要动数据库连接配置"、"不要执行删除命令"，给 AI 划清楚安全边界。第三，给每个会话留独立的上下文空间。如果 4 个会话都在同一个超大仓库里启动，每个会话都要读一遍项目目录，内存和启动时间都会叠加。对不需要读整个仓库的任务，可以在启动时限定工作目录，或者用忽略文件排除不必要的目录。
下面是我常用的一次四任务分配：
| 窗口号 | 工作目录 | 任务内容 | 边界 |
|---|---|---|---|
| 0 | ~/work/api | 重构接口路由 | 只改 api 目录 |
| 1 | ~/work/web | 前端表格加筛选 | 只改前端组件 |
| 2 | ~/work/test | 补充接口测试 | 用独立测试库 |
| 3 | ~/work/scripts | 数据迁移脚本 | 不动业务代码 |
4.2 手动创建和脚本批量启动两条路
手动方式适合偶尔用一次。SSH 登录后：
bash复制tmux new -s claude
进入 tmux 后，你会看到窗口 0，直接运行：
bash复制cd ~/work/api && claude
然后按 Ctrl+b 再按 c 新建窗口 1，进入后：
bash复制cd ~/work/web && claude
新建窗口 2、3 同理。所有窗口都跑起来后，按 Ctrl+b 再按 d 分离。此时 tmux 保留在云端后台，你可以放心断开 SSH。
如果这套流程要反复用，我更推荐脚本批量启动。下面这段脚本创建名为 claude 的 tmux 会话，并自动在四个窗口里分别启动 Claude Code：
bash复制tmux new-session -s claude -d
tmux rename-window -t claude:0 api
tmux send-keys -t claude:0 'cd ~/work/api && claude' Enter
tmux new-window -t claude -n web
tmux send-keys -t claude:1 'cd ~/work/web && claude' Enter
tmux new-window -t claude -n test
tmux send-keys -t claude:2 'cd ~/work/test && claude' Enter
tmux new-window -t claude -n scripts
tmux send-keys -t claude:3 'cd ~/work/scripts && claude' Enter
tmux attach -t claude
tmux new-session -s claude -d 中的 -d 表示创建后不立即进入；send-keys 的作用是向指定窗口发送一段键盘输入，最后的 Enter 相当于按了一下回车。脚本执行完，你已经 attach 进 tmux，能看到四个窗口里四个 Claude Code 正在各自初始化。
4.3 窗口切换、双屏监视与单路重启
启动之后的日常操作主要有三类。
切换窗口。Ctrl+b 然后按 w 会弹出窗口列表，用方向键和回车选择；Ctrl+b 0、Ctrl+b 1、Ctrl+b 2、Ctrl+b 3 可以直接跳到对应窗口。窗口名我一般用任务名，一眼就能看出哪个窗口在做什么。
同时看两个窗口。在某个窗口里按 Ctrl+b 再按 % 做左右分屏，另一个窗口会显示在旁边。比如窗口 0 正在等一个长任务执行，我按 Ctrl+b 0 切过去，再分屏摆一个窗口 1，就可以一边观察进度一边继续给窗口 1 提问题。这里的核心价值是"并行监视"，不用反复切换。
单路重启。如果某个会话卡死或者想换任务，切到对应窗口，先按 Esc 或 Ctrl+C 中断现有请求，退出 Claude Code 后重新运行 claude，或者直接 Ctrl+d 关掉窗口再新建一个。只影响当前窗口，其他会话完全不受干扰。这是并行方案最舒服的一点：隔离性足够好，局部故障不会拖垮全局。
5. 并行运行时的资源监控与调用节奏管理
5.1 实际内存消耗和一台机器能撑多少个会话
很多第一次上云并行跑的人，第一反应是"我开了 6 个窗口怎么还是卡？"这通常不是 Claude Code 的问题，而是内存评估没做对。
我实测的体感是：一个空的 Claude Code 会话，常驻内存大约 150~300MB；当给它加载了一个中型代码仓库、开场白、工具定义等上下文后，内存会进一步上升；如果同时跑的任务里有大量文件操作，CPU 也会间歇性冲高。所以不能只看单个进程的静态值，还要看实际仓库大小和任务复杂度。
估算参考如下：
| 云主机配置 | 建议并行会话数 | 备注 |
|---|---|---|
| 2C4G | 2~3 | 适合轻量任务 |
| 4C8G | 4~6 | 常见推荐配置 |
| 8C16G | 8~10 | 适合重度并行，注意 API 限流 |
在服务器上装个 htop 会让监控直观很多：
bash复制sudo apt install -y htop
htop
按 M 可以按内存占用排序进程。如果物理内存被占满、swap 使用率一路走高，说明该收一收了，关掉一些不用的窗口，而不是盲目开新会话。更精细一点的做法是结合项目目录来识别进程：top 界面按 c 显示完整命令行，能看到哪个 node 进程对应哪个项目目录，这样要杀也知道该杀哪个窗口的会话。
如果云主机本身带 GPU，可以用 nvidia-smi 看显存，但 Claude Code 大多数情况走 API，本地 GPU 不是必要条件，选云主机时别为这块多掏钱。
5.2 并行请求的限流判断与节奏控制
并行会话多了，另一个容易踩的坑是 API 限流。同一个账号或者同一个 API Key 同时在多个会话里发起请求，总数一多就会遇到限流错误，界面上可能直接显示请求失败或返回类似 429 的状态。
这不是程序 bug，不需要反复回车重试。我自己的调度策略是：不要四个窗口同时发起"长篇大任务"，把大任务和小任务混着来，让请求时刻错开；遇到限流错误先停一下，等 10~30 秒再让它重试；如果确实需要很高的并发，考虑分批，上午跑第一批 4 个会话，下午跑第二批 4 个，而不是一次性开 8 个。合理调度的核心是"错峰"。并行不是同时开火，而是让每个会话都有充足、稳定的响应时间，整体产出反而更高。
6. 断线、卡死、会话丢失的排查与恢复
6.1 SSH 断开后的恢复流程
先说最让人放心的一种情况：SSH 闪断后怎么找回任务。
假设你本地网络断了，重新 SSH 上云主机，此时之前打开的终端已经消失，但 tmux 会话还在。执行：
bash复制tmux ls
输出大概是 claude: 4 windows (created ...)，然后：
bash复制tmux attach -t claude
你会看到四个窗口原封不动，连当时命令行的输出都还在。之所以能这样，是因为 tmux 是独立的守护进程，SSH 只是它的客户端外壳；客户端断开，壳子没了，里面的进程不会死。
有几个细节需要注意。如果 tmux ls 显示有会话但 attach 时报错，大多数情况是存在失效会话残留，用 tmux kill-session -t 名字 清掉再开。如果 SSH 客户端经常超时，可以在本机 ~/.ssh/config 里给云主机单独设置长保活参数：
code复制Host my-cloud
HostName 你的云主机IP
User 你的用户名
ServerAliveInterval 30
ServerAliveCountMax 3
这样客户端每 30 秒发一次心跳，网络断开后可以更快感知，不会长时间卡在假死连接上。
6.2 卡死怎么定位：区分等待、假死和真死
多会话并行最烦的是某个窗口没反应。我的排查步骤分三步。
第一步，先等一等。Claude Code 在等待 API 返回时屏幕常常停在"thinking"，如果等 1~2 分钟还没变化，很可能只是上游响应慢。这种情况按 Esc 可以尝试终止当前工具调用，但注意有时候需要多按几次才生效。
第二步，判断是不是终端假死。比如键盘输入没有任何回显，Ctrl+C 也没用。这时可以先按 Ctrl+b 再按 d 分离整个 tmux，然后重新 tmux attach -t claude 回来。窗口界面通常会刷新一次，假死的情况往往能恢复。
第三步，如果重新 attach 还是卡住，说明是那一个窗口里的 Claude Code 进程真挂了或挂起了。在另一个 SSH 连接的普通终端里执行：
bash复制ps aux | grep claude
找到对应窗口启动的进程 PID，然后：
bash复制kill -9 <pid>
这样只会杀掉那一个窗口的 claude，其他窗口继续正常运行。杀完回到那个窗口，重新启动 claude 即可。
注意：强制 kill 之前，尽量先确认 Claude Code 的会话记录已经保存。多数情况下它支持在启动时选择历史会话，或者用
claude --continue接续最近的对话，能救回来一部分进度，省得完全重来。
6.3 会话记录备份与磁盘清理习惯
Claude Code 的全局配置和会话记录一般保存在 ~/.claude 目录下，具体路径可能随版本微调。如果这些会话记录对你有价值，定期备份是个好习惯：
bash复制tar czf claude-backup-$(date +%F).tar.gz ~/.claude
把压缩包传到本地或对象存储，任务出错时还能翻回去看之前的历史对话。
磁盘清理方面，最容易膨胀的是各项目的 node_modules、构建产物和 .claude 下的日志文件。隔段时间跑一次：
bash复制du -sh ~/work/*/node_modules 2>/dev/null | sort -rh | head
找出体积最大的目录，按需清理。项目多的时候，建议每个项目用独立目录，别把几十个依赖全堆在一个目录下，方便后面单独备份和清理。云主机的 /tmp 目录也容易被下载的安装包填满，顺手清一清，避免莫名其妙的磁盘告警。
7. 并行会话的实际运营习惯与容易忽略的细节
这套方案用下来，我总结了几条比较容易忽略的经验，送给准备直接在云上并行跑 Claude Code 的朋友。
第一，不要在同一个窗口无限堆问题。Claude Code 的上下文窗口是有上限的，如果你的某个会话连续处理了几十个互不相关的需求，一会儿改接口，一会儿查配置，一会儿让它写文档，上下文里会塞满大量无关内容，真正针对当前任务的注意力空间反而变小。最直观的体感就是，同一个会话用久了之后，明明是很简单的改动，它却回答得越来越偏离预期。我的解决方法是每个会话只负责一个明确任务，做完就 /clear，或者干脆关掉窗口重开一个干净环境。
第二，任务拆解时给 AI 明确的安全边界。并行会话多起来之后，最怕的不是单个会话失败，而是 A 窗口的 Claude 改了 B 窗口正在改的文件，或者自作主张执行了删除、覆盖、数据库迁移这类危险操作。我现在的做法是在每个会话的开场提示词里直接划边界："本任务只允许修改这些目录，禁止执行删除类命令，不要动数据库配置，所有命令在执行前先说明。"一开始觉得啰嗦，多跑几次就会发现特别省心，尤其是在多会话同时操作一个项目的时候，边界划得越清楚，后期冲突越少。
第三，真正需要关注的不是"同时开了几个窗口"，而是"几个窗口在同一时刻都在真正工作"。API 限流、上下文检索、文件操作都会消耗时间和容量，盲目堆窗口数容易出现一种尴尬情况：看起来开了 6 个会话，实际同时能发出请求的只有 3 个，剩下几个全在等限流窗口过去。我实测下来，稳定跑 4 个并行会话是投入产出比比较高的状态；如果想跑 8 个，需要先把任务分成两批或者错峰调度，不然总吞吐未必翻倍，反而增加很多上下文切换成本。
第四，用完记得清理 tmux 会话。云主机跑久了，tmux 里的会话堆一个不用的就会一直占着内存，我见过有人一台 2G 的机器上攒了二十多个 tmux 会话，白白吃掉几百 MB。长时间不用的就 tmux kill-session -t 名字 清掉，全部都不要了就用 tmux kill-server，然后在需要的时候重新按脚本创建就行。保持环境干净，对排查问题和保留记忆都有帮助。
最后说个大实话：Claude Code 并行会话的真正价值，不是让你打开了很多终端显得任务排得很满，而是可以同时在多个维度推进一个项目——有的会话在写代码，有的在补测试，有的在梳理文档，各干各的，最后合到一起。这套"云 VM + tmux + 多会话"的组合我跑了好几个项目都很稳，如果你也被本机内存和断电断网折腾过，不妨照着上面的步骤试试。