你可能也遇到过这种场景终端里开了四五个标签页每个标签页一个claude会话分别处理不同项目。标签一多就开始乱A 项目改到一半切到 B 项目查个东西再切回 A发现 Agent 上下文里混进了 B 的内容。我给 Claude Code 配了个“总管”之后这个问题算是彻底解决了——用 tmux 做终端复用把多个 AI Agent 会话统一挂在一个管理平面上想看哪个看哪个想恢复哪个恢复哪个再也不用靠记忆硬找窗口了。这篇文章不是教你claude命令怎么用而是讲清楚一个更实操的问题当你同时跑多个 Agent 任务时终端层到底该怎么组织我会把为什么需要“总管”、为什么选 tmux、具体怎么配、以及使用中的坑全部过一遍。适合已经在终端里用 Claude Code 或类似命令行 Agent、又经常被多任务并行搞到头大的人。1. 为什么说多个 Claude Code 会话需要“总管”而不仅是“多开”很多人的第一反应是多开几个终端标签页不就行了问题恰恰出在这里。标签页只是把窗口叠在一起它不会帮你隔离上下文也不会帮你管理任务生命周期。真正让多个 Agent 会话变得可控的是一层位于终端之上、能够独立管理会话状态的“管理层”。1.1 单会话的真实局限上下文污染与任务切换成本Claude Code 这类终端 Agent 的核心机制是它在一个会话里维护完整的上下文窗口你之前给它看过哪些文件、它自己读过哪些代码、执行过哪些命令都会沉淀成它的“工作记忆”。这个机制在小任务上没什么问题一旦你让它在同一个会话里反复切换需求问题就来了。我举一个非常典型的翻车例子。有一次我在同一个会话里让它先重构项目 A 的工具函数过了一会儿又让它去修项目 B 的测试用例。它执行到一半直接把 A 项目的 import 路径写进了 B 项目的文件里。为什么因为上下文窗口里有大量 A 项目的代码片段Agent 在推理时把这些信息当成了“当前项目环境”的一部分它分不清你所说的“这个项目”到底是哪一个。那时候我就意识到一个会话最好只对应一个明确任务。多任务并行就应该多开会话但也正因为多开窗口管理就变成了新的问题。标签页一多你很难记住哪个标签页对应哪个项目更难快速判断某个任务现在到底跑到哪一步了。1.2 多会话后的真实管控需求状态、持久化与审计当你真的开了三四个 Agent 会话之后管控需求会从“能多开”升级到“能管住”。我把实际遇到的问题整理了一下基本上就四个会话状态可见性某个任务是在等待输入、正在跑测试还是已经卡住了如果不点进对应标签页根本看不到。会话恢复能力电脑合盖休眠、SSH 掉线、终端模拟器崩溃任何一个意外都可能导致窗口里跑了一小时的 Agent 任务前功尽弃。任务并行与编排两个 Agent 相互独立但需要对比结果时有没有办法让它们“同屏显示”而不是来回切换标签页操作记录留存Agent 跑完就完事了但过程中改了哪些文件、执行了哪些命令事后想复盘有没有办法低成本留下日志这些问题都不是“再开一个标签页”能解决的。它们本质上要求一个独立于终端模拟器的会话管理层它负责把会话挂在哪里、何时销毁、如何恢复。这也是我把这个工具比作“总管”的原因——它管理的不是窗口而是会话的状态和生命周期。2. “总管”选型为什么我选了 tmux 而不是 Tabby、Zellij 或 Screen确定要加一层“总管”之后接下来就是选型。我在终端工具这条路上试过不少方案包括 Tabby、Zellij、GNU Screen、tmux最终长期用的是 tmux。不是说另外几个不好而是它们的适用场景和 tmux 不一样搞清楚这个差异你才能选对。2.1 备选方案横向对比从界面到脚本化能力先放一个对比表格后面详细说工具核心定位会话持久化分屏能力脚本化/自动化资源占用适用场景Tabby终端模拟器依赖 SSH 配置标签页为主弱中日常多标签操作Zellij终端复用支持支持中中习惯现代交互的新手GNU Screen终端复用支持弱中低老旧环境应急tmux终端复用强强强低重度终端用户/多任务管理Tabby 是很多人的首选终端模拟器界面好看、标签和分屏做得也不错。但它有一个本质问题它是一个前台应用。你肉眼看到的标签页、分屏布局都绑定在 GUI 进程上。一旦 Tabby 崩溃或者系统重启里面的会话就没了。它本身也带有 SSH session 保持和恢复机制但那要配合远程服务器配置对于“本地终端里跑 Agent”这个场景来说管理粒度还是太粗了。Zellij 这两年很火理念也很新潮它把布局、插件、鼠标交互都做到了开箱即用如果你是完全的新手Zellij 的上手体验确实比 tmux 平滑得多。但我个人的顾虑是Zellij 的脚本化能力还在快速演进中如果我想用一段 shell 脚本自动化地创建一套多会话工作区tmux 的命令接口明显更成熟、更稳定网上能搜到的资料也多一个量级。GNU Screen 是上古神器功能层面其实已经过时分屏操作别扭、默认配置老气、很多快捷键和现代终端模拟器有冲突。除非你所在的服务器环境连 tmux 都装不上否则我不建议从 Screen 开始。2.2 tmux 的核心优势client-server 架构与三层级对象模型选 tmux 最重要的一条理由可能很多人没意识到就是它的 client-server 架构。简单说tmux 启动后真正干活的会话进程跑在一个独立的后台服务里你打开的终端窗口只不过是一个“显示器”随时可以离开随时可以重新接上。这个概念特别适合 Agent 场景。Claude Code 会话一旦在 tmux 里启动就挂在 tmux server 下面你关掉终端模拟器、断掉 SSH、甚至电脑睡一觉再醒来会话进程都还在后台继续跑。重新打开终端后一条tmux attach就能把之前的界面恢复回来。这就是持久化的本质——任务跑在后台而不是跑在窗口里。tmux 的第二个核心设计是 session / window / pane 三层模型。我还是拿实际场景来解释session 相当于一个独立工作区每个项目一个 sessionsession 里可以有多个 window相当于标签页每个 window 又可以切分成多个 pane相当于分屏。这三层对应到 Agent 管理里非常自然session 一个项目或一个任务window 这个任务下的不同工作模式比如“和 Agent 对话”一个窗口、“看测试结果”一个窗口、“看资源占用”一个窗口pane 同一个工作模式内在屏幕上同时显示多个视角。很多人在 tmux 里只用了 window 这一层平铺开一堆标签页这当然也能用但错过了 session 这一层最强的隔离能力。真正多 Agent 并管的时候session 层才是你的“任务列表”window 层是每个任务里的细节页。3. 实战给 Claude Code 配 tmux 的完整操作流程铺垫了这么多下面进入正题。这一节我会把从安装、配置到实际组织多个 Claude Code 会话的完整流程写一遍所有命令都是我在真实环境里验证过的复制就能用。3.1 安装与初始化配置Linux 环境下Ubuntu/Debiansudo apt update sudo apt install -y tmuxmacOS 环境下brew install tmux如果你在 Windows 上建议用 WSL 里的 Linux 发行版来跑或者用 Git Bash 配合 Windows 版 tmux操作逻辑完全一致。装完之后先验证一下版本tmux -V能看到版本号就说明环境没问题。然后是最基础的一份配置文件。我放在~/.tmux.conf# 开启鼠标支持方便用滚轮翻历史和点击切换 pane set -g mouse on # 把前缀键从 CtrlB 改成 CtrlA避免和 VSCode 内置快捷键冲突 set -g prefix C-a unbind C-b bind C-a send-prefix # 窗口索引从 1 开始而不是默认的 0更符合直觉 set -g base-index 1 setw -g pane-base-index 1 # 增大回滚缓冲区Agent 输出大段日志时不容易丢 set -g history-limit 50000 # 修改配置后按 C-a r 即可热加载不用重启 tmux bind r source-file ~/.tmux.conf \; display config reloaded几个配置点说明一下。鼠标支持和历史缓冲是必须开的Claude Code 经常输出一长串修改文件列表缓冲太小你翻个几屏就到底了。前缀键改成 Ctrl-A 是我个人习惯如果你不用 VSCode 或者没有冲突保持默认 Ctrl-B 也行。关键是配置要跟着自己的使用习惯走不要照抄。3.2 按“项目即会话”原则组织多个 Agent我的组织原则非常简单粗暴一个项目一个 session一个 Agent 任务一个 window。比如我现在同时有两个项目在跑项目 A 做代码重构项目 B 在修一个线上 bug。按传统方式我会开两个终端标签页各自跑一个claude。但用 tmux 之后我会这样建# 后台创建 session命名为 refactor首窗口命名为 agent tmux new-session -d -s refactor -n agent # 在 refactor 的 agent 窗口里启动 Claude Code并切到项目 A 目录 tmux send-keys -t refactor:agent cd ~/work/project-a claude Enter # 再创建一个 bugfix session同样启动另一个 Agent tmux new-session -d -s bugfix -n agent tmux send-keys -t bugfix:agent cd ~/work/project-b claude Enter # 查看当前所有 session tmux ls执行完tmux ls你会看到类似这样的输出refactor: 1 windows (created ...) 212x45 bugfix: 1 windows (created ...) 212x45这就是你的“任务列表”。两个 Agent 各自跑在自己的 session 里上下文完全隔离。想看哪个就tmux attach -t refactor或tmux attach -t bugfix。这里有个细节值得注意我用了-d参数让 session 刚创建时不立刻进入前台然后用send-keys往里面发命令。这样做的意义在于你可以先在一段脚本里把所有 session 全部创建好、把 Agent 都启动起来最后再统一 attach——这比手动一个个开窗口再敲命令高效得多。3.3 一键恢复整套 Agent 工作区的脚本化思路一旦你形成了“项目即 session”的组织方式下一步很自然就是写一个脚本把整套工作区一键拉起来。这样每天早上到了工位或者服务器 SSH 断开重连之后跑一条命令就能恢复昨天的工作现场。下面是一个能直接用的脚本雏型保存为start-workspace.sh#!/usr/bin/env bash set -euo pipefail SESSION_NAMEdev # 已存在同名 session 则直接附着避免重复创建 if tmux has-session -t $SESSION_NAME 2/dev/null; then echo session $SESSION_NAME already exists, attaching... tmux attach -t $SESSION_NAME exit 0 fi # 创建主 session第一个窗口跑项目 A 的 Claude Code tmux new-session -d -s $SESSION_NAME -n agent-a tmux send-keys -t $SESSION_NAME:agent-a cd ~/work/project-a claude Enter # 在同一窗口右侧分屏实时看测试日志 tmux split-window -h -t $SESSION_NAME:agent-a tmux send-keys -t $SESSION_NAME:agent-a.2 cd ~/work/project-a tail -f test.log Enter # 新建第二个窗口跑项目 B 的 Agent tmux new-window -t $SESSION_NAME -n agent-b tmux send-keys -t $SESSION_NAME:agent-b cd ~/work/project-b claude Enter # 第三个窗口留作终端备用手动操作 git 或看文件用 tmux new-window -t $SESSION_NAME -n shell # 默认回到第一个窗口 tmux select-window -t $SESSION_NAME:agent-a # 进入前台 tmux attach -t $SESSION_NAME这个脚本解决了一个很关键的问题可重复性。你不需要记得昨天开了哪些窗口、每个窗口里跑了什么命令脚本本身就是这个工作区的“定义文件”。再次强调一下has-session判断的作用如果 session 已经存在脚本直接 attach不会二次创建导致状态错乱。3.4 日常操作几张快捷键速查表配置和脚本都准备好了日常使用还得靠快捷键。快捷键不用一口气全背先记住最常用的几个剩下的碰到场景再查表快捷键作用C-a c在当前 session 里新开一个 windowC-a ,重命名当前 window推荐和项目名对应C-a %垂直分屏把当前 pane 分成左右两个C-a 水平分屏分成上下两个C-a 方向键在相邻 pane 之间切换C-a z最大化/还原当前 pane分屏看眼花了就放大看一个C-a d离开 sessiondetach但任务继续后台跑C-a [, 然后方向键/翻页键进入拷贝模式可以往上翻历史输出C-a x关闭当前 pane会弹出确认慎用C-a $重命名当前 session这套快捷键把最常用的操作都覆盖到了。我认为C-a z是很多人低估的功能当你分屏同时看 Agent 输出和测试日志时某一瞬间你可能只想看 Agent 的完整输出按一下z放大看完了再按一下还原比来回切换窗口高效得多。也因此我建议给每个 Agent 会话至少分一块屏出来放测试或运行日志这样“放大/还原”才用得上。4. 进阶玩法把 tmux 升级成 Agent 调度台当你已经能熟练用 session 隔离多个 Agent 之后还可以再往前走一步把“总管”从单纯的会话管理器变成一个小型调度台。这一节讲的是我自己日常工作流里最有用的几个进阶玩法。4.1 建立在分屏之上的“看板式”并行监控先插一个概念问题。很多人把“AI Agent”和“LLM大语言模型”混着用其实这两个层次不一样。LLM 是一个模型负责“理解语言、生成语言”比如常说的 DeepSeek 属于这一类AI Agent 则是跑在模型之上的智能体系统它能拆解目标、调用工具、执行命令、循环反馈。Claude Code 就是一个典型的终端 AI Agent底层会调用大模型能力但在上层它具备“自己动手改代码、跑测试、看结果”的自主性。搞清这个区分你才能真正理解为什么 Agent 任务需要长期维持会话——它不是一个“问一句答一句”的对话而是一个有状态的执行过程。正因为有状态监控就很重要。我在跑任务时最喜欢的一个布局是三块 pane左侧 60%Claude Code 主会话Agent 在干活右上 25%测试日志tail -f输出Agent 每次改完都会触发测试右下 15%btop或htop看 CPU 内存占用防止 Agent 跑疯。布局效果用脚本化方式建一次后面每次都能复用# 已有 session 内先垂直分屏 tmux split-window -h -p 40 # 右侧再水平分屏下面的 pane 放资源监控 tmux split-window -v -p 40 tmux send-keys -t $SESSION_NAME:agent.3 btop Enter tmux select-pane -t $SESSION_NAME:agent.1不要小看这个布局。它本质上是把“Agent 在做什么”和“系统发生了什么”拉到同一个视野里。你不需要点进每个窗口去轮询状态余光一扫就知道 Agent 还在跑还是在空转。4.2 多模型多 Agent 并行同屏对比工作流选定一个 Agent 工具不意味着你只能绑定一个模型或一个产品。实际上终端 Agent 生态里已经有不少可选工具比如 Claude Code 之外还有 OpenAI 系 Codex 等。它们各有各的优劣势有的理解代码能力强有的执行长任务稳定有的上下文窗口大。我在做一些关键决策前会开两个独立 session分别让 Claude Code 和 Codex 处理同一个需求然后分屏对比它们的方案。具体做法是# 在两个独立的 session 里分别启动 Agent tmux new-session -d -s compare-a -n agent tmux send-keys -t compare-a:agent claude Enter tmux new-session -d -s compare-b -n agent tmux send-keys -t compare-b:agent codex Enter然后通过 tmux 的join-pane命令把两个 session 的窗口拼到一个屏幕里# 把 compare-b 的 agent 窗口拉到当前 session 的右侧分屏 tmux join-pane -s compare-b:agent -t compare-a:agent -h拼接完之后你在同一个窗口里可以直观地看到两个 Agent 各自怎么理解需求、怎么拆步骤、怎么改代码。这个对比方式很有价值因为你同时给它们相同的指令等于做了一个人工 A/B 测试而不是凭印象判断哪个更好用。注意一点join-pane之后目标 session 和源 session 的布局会发生改变。用完之后可以通过break-pane把 pane 恢复成独立 window也可以直接tmux kill-session -t compare-b把原来的 session 关掉。我个人习惯是保留独立 session因为脚本和窗口布局更稳定只有临时对比时才用join-pane。4.3 用 alias 封装整套管理命令“调度台”的最后一块拼图是把常用操作封装成短命令。我在~/.zshrc里加了下面几个 aliasalias agt-listtmux ls alias agt-attachtmux attach -t alias agt-killtmux kill-session -t alias agt-workspacebash ~/scripts/start-workspace.sh添加之后source ~/.zshrc生效每天的实际操作就变成了agt-list看有哪几个 Agent 会话在跑agt-workspace一键拉起项目工作区agt-attach refactor进入某个具体会话退出后按C-a ddetach任务继续跑。可能有人觉得这三个 alias 太简单了。但对“总管”来说降低摩擦本身就是最大价值。如果一条命令能启动整个复杂工作区你就会愿意每天用如果还要敲一堆路径和参数大概率两天就放弃了。4.4 日志与审计Agent 跑了什么怎么复盘Agent 跑完任务之后怎么复盘它到底干了什么Claude Code 本身有会话导出功能可以导出对话记录但如果你需要的是终端层面的“过程快照”——包括 Agent 执行的命令、输出的关键信息、测试日志——那 tmux 有两个非常实用的能力。第一个是pipe-pane它可以把某个 pane 的所有输出实时写入文件# 把 refactor session 的 agent 窗口所有输出写入日志文件 tmux pipe-pane -t refactor:agent -o ~/logs/refactor-$(date %Y%m%d-%H%M%S).log第二个是capture-pane它可以把当前 pane 显示的画面保存下来适合事后回滚查找某个瞬间的状态# 把当前窗口最近 2000 行输出保存到文件 tmux capture-pane -pS -2000 ~/logs/snapshot.txt我的经验是pip-pane适合整个任务周期全程开启capture-pane适合在 Agent 报错或者行为异常时抓现场。两条命令配合使用基本上每个 Agent 的关键操作节点都能复盘到位。5. 实测中踩过的坑和对应解法光讲漂亮配置不说坑是典型的教程式偷懒。我在实际用 tmux 管理多个 Agent 的这一个多月里确实踩了不少坑。下面按“症状 — 原因 — 解法”的方式列几个都是我测过有效的方案。5.1 鼠标滚动和复制粘贴在 tmux 里失灵症状打开 tmux 后鼠标滚轮不再翻历史输出而是把整个终端内容当作文本选中想复制 Agent 输出的一段关键日志粘贴出来却是乱的。原因tmux 默认不开启鼠标模拟滚轮事件被解释成文本选择开启鼠标支持之后普通的拖拽选择又会和 pane 切换手势冲突。解法先在~/.tmux.conf里打开鼠标支持和拷贝模式前面配置里已经写过了。然后复制粘贴时按住Shift再拖拽选择文本就能临时绕过 tmux 的选择逻辑直接用终端模拟器的原生剪切板。如果你用的是 macOS 的 iTerm2按住Option键也能达到类似效果VSCode 集成终端里则是按住Alt。 如果还是嫌麻烦就用C-a [进入拷贝模式先按空格开始选择再按 Enter 复制。这个组合键多练几遍就成了肌肉记忆。5.2 快捷键冲突CtrlB 被 VSCode 和系统抢走症状在 VSCode 的集成终端里使用 tmux按C-b发现侧边栏被打开了或者系统弹出了别的响应tmux 完全没有反应。原因C-b这个组合键在很多软件里都有定义VSCode 就把Cmd/CtrlB绑定了切换侧边栏。解法最简单的是把 tmux 前缀键改成C-a就是我在配置里写的那套。改完配置后执行tmux source-file ~/.tmux.conf热加载。如果你在 VSCode 里必须用C-b也可以到 keybindings.json 里把toggleSidebarVisibility改成其他组合键。这个属于“环境和工具链的兼容性调整”没有标准答案但原则是优先保留 tmux 的前缀键稳定因为 tmux 是整个管理层的核心其他软件可以迁就它。5.3 并行任务触发 API 配额和限流症状同时跑三四个 Claude Code 会话过了一段时间某个会话开始频繁报限流类错误任务执行速度明显变慢甚至停在某个步骤不走了。原因每个会话都在独立消耗同一个账号的 API 配额和速率限制。多 Agent 并行表面上是在“加快”任务完成实际上是在加速消耗资源。对按量计费或者有配额上限的账号来说这种模式很容易撞墙。解法我给每个并发 Agent 设置一个显式的“完成标志”。比如让 Agent 在处理完任务后创建一个done文件然后我定期用agt-list和tail -f去确认哪些任务已经完成完成后立刻 kill 掉对应 session释放资源而不是让它一直挂在后台“待命”。这看起来只是个小习惯但在配额紧张时能救命。 如果你的任务量大更合理的做法是把大任务拆成小批次分批喂给 Agent控制并发度而不是一味地堆并行。5.4 新 pane 不继承当前 shell 的环境变量症状我在某个 session 里已经export了一个环境变量比如 API key然后在这个 session 里新建了一个 pane发现新 pane 里根本读不到这个变量。原因tmux 的 pane 本质上是独立的 shell 进程新建 pane 时会重新走一遍 shell 的启动流程你手动在某个 pane 里export的变量只对那一个特定 shell 进程生效不会自动广播到其他 pane。Agent 的登录态和 API key 配置也需要特别注意如果你把凭据写在启动 session 之前的环境变量里tmux server 会继承初始值但如果你中途改了环境变量新的 pane 会读新值旧的 pane 里还是旧值。解法规范的做法是所有环境变量统一写进~/.bashrc或~/.zshrc让每个新开的 pane 都能加载到对 Claude Code 的登录态可以确认凭据文件存在且路径稳定同一台机器上启动的所有 Agent 会话都会共享。改完~/.bashrc之后如果 tmux server 已经跑了一段时间建议先完全退出 tmuxtmux kill-server重新启动确保 server 进程本身加载的是新环境而不是沿用过时的初始环境。这个操作很容易被忽略但它往往是“为什么我的 Agent 在新 pane 里忽然没有权限了”的根因。5.5 误关窗口导致会话消失症状想关闭某个 Agent 的 pane按快捷键手滑按到了 kill-session整个 session 里的所有窗口和运行中的任务全没了而且 tmux 的 confirm 提示一晃而过直接执行了。原因tmux 的kill-pane和kill-session默认在确认前不会等你某些坏习惯比如在 pane 里连按快捷键很容易误触。解法我给kill-session加了一个确认保护绑定在~/.tmux.conf里自定义# 按 C-a x 关闭 pane 前要求输入 y/n bind x confirm-before kill-pane # 按 C-a X 才有权关闭整个 session同样要求确认 bind X confirm-before kill-session加上这个保护之后手滑的概率大大降低。还有一个更稳妥的习惯kill session 之前先用capture-pane或者tmux ls看一眼会话状态确定这个 Agent 的任务真的结束了再动手。在自动化脚本里我会在创建 session 之后跑一个“心跳”命令定期检查 Agent 是否还在往前推进如果输出在很长时间内没有任何变化就在日志里打一条告警而不是让它无限等下去。6. 最后说说我把这套工作流跑起来之后的感受配置 tmux 这件事门槛说高不高说低也不低。如果你第一次看前面的命令觉得有点多我的建议是先别急着抄全套配置从最简单的一个 session 一个 Agent 开始用把C-a ddetach和C-a [翻历史这两个操作练熟其他能力都可以在真实使用中逐步加进来。实际用了两三周之后再回来写脚本、搞分屏布局你会发现一切都顺理成章。我现在每天的工作流基本稳定为早上一条agt-workspace把项目 A 和项目 B 的 Agent 会话全部拉起来然后该干嘛干嘛中途用agt-list扫一眼任务状态需要介入就agt-attach进去处理下午任务完成agt-kill把对应 session 清掉。这个流程最有价值的地方在于它让我和 Agent 之间的协作从“临时起意”变成了“有节奏、可管理、能复盘”的工程化流程。如果你也在用 Claude Code 或者类似终端 Agent我强烈建议你花一个下午把 tmux 这套“总管”配起来。别指望一次就配到完美先跑起来再慢慢调成适合自己的形态。 用tmux给Claude Code配个会话总管：多Agent并行管理实战
你可能也遇到过这种场景终端里开了四五个标签页每个标签页一个claude会话分别处理不同项目。标签一多就开始乱A 项目改到一半切到 B 项目查个东西再切回 A发现 Agent 上下文里混进了 B 的内容。我给 Claude Code 配了个“总管”之后这个问题算是彻底解决了——用 tmux 做终端复用把多个 AI Agent 会话统一挂在一个管理平面上想看哪个看哪个想恢复哪个恢复哪个再也不用靠记忆硬找窗口了。这篇文章不是教你claude命令怎么用而是讲清楚一个更实操的问题当你同时跑多个 Agent 任务时终端层到底该怎么组织我会把为什么需要“总管”、为什么选 tmux、具体怎么配、以及使用中的坑全部过一遍。适合已经在终端里用 Claude Code 或类似命令行 Agent、又经常被多任务并行搞到头大的人。1. 为什么说多个 Claude Code 会话需要“总管”而不仅是“多开”很多人的第一反应是多开几个终端标签页不就行了问题恰恰出在这里。标签页只是把窗口叠在一起它不会帮你隔离上下文也不会帮你管理任务生命周期。真正让多个 Agent 会话变得可控的是一层位于终端之上、能够独立管理会话状态的“管理层”。1.1 单会话的真实局限上下文污染与任务切换成本Claude Code 这类终端 Agent 的核心机制是它在一个会话里维护完整的上下文窗口你之前给它看过哪些文件、它自己读过哪些代码、执行过哪些命令都会沉淀成它的“工作记忆”。这个机制在小任务上没什么问题一旦你让它在同一个会话里反复切换需求问题就来了。我举一个非常典型的翻车例子。有一次我在同一个会话里让它先重构项目 A 的工具函数过了一会儿又让它去修项目 B 的测试用例。它执行到一半直接把 A 项目的 import 路径写进了 B 项目的文件里。为什么因为上下文窗口里有大量 A 项目的代码片段Agent 在推理时把这些信息当成了“当前项目环境”的一部分它分不清你所说的“这个项目”到底是哪一个。那时候我就意识到一个会话最好只对应一个明确任务。多任务并行就应该多开会话但也正因为多开窗口管理就变成了新的问题。标签页一多你很难记住哪个标签页对应哪个项目更难快速判断某个任务现在到底跑到哪一步了。1.2 多会话后的真实管控需求状态、持久化与审计当你真的开了三四个 Agent 会话之后管控需求会从“能多开”升级到“能管住”。我把实际遇到的问题整理了一下基本上就四个会话状态可见性某个任务是在等待输入、正在跑测试还是已经卡住了如果不点进对应标签页根本看不到。会话恢复能力电脑合盖休眠、SSH 掉线、终端模拟器崩溃任何一个意外都可能导致窗口里跑了一小时的 Agent 任务前功尽弃。任务并行与编排两个 Agent 相互独立但需要对比结果时有没有办法让它们“同屏显示”而不是来回切换标签页操作记录留存Agent 跑完就完事了但过程中改了哪些文件、执行了哪些命令事后想复盘有没有办法低成本留下日志这些问题都不是“再开一个标签页”能解决的。它们本质上要求一个独立于终端模拟器的会话管理层它负责把会话挂在哪里、何时销毁、如何恢复。这也是我把这个工具比作“总管”的原因——它管理的不是窗口而是会话的状态和生命周期。2. “总管”选型为什么我选了 tmux 而不是 Tabby、Zellij 或 Screen确定要加一层“总管”之后接下来就是选型。我在终端工具这条路上试过不少方案包括 Tabby、Zellij、GNU Screen、tmux最终长期用的是 tmux。不是说另外几个不好而是它们的适用场景和 tmux 不一样搞清楚这个差异你才能选对。2.1 备选方案横向对比从界面到脚本化能力先放一个对比表格后面详细说工具核心定位会话持久化分屏能力脚本化/自动化资源占用适用场景Tabby终端模拟器依赖 SSH 配置标签页为主弱中日常多标签操作Zellij终端复用支持支持中中习惯现代交互的新手GNU Screen终端复用支持弱中低老旧环境应急tmux终端复用强强强低重度终端用户/多任务管理Tabby 是很多人的首选终端模拟器界面好看、标签和分屏做得也不错。但它有一个本质问题它是一个前台应用。你肉眼看到的标签页、分屏布局都绑定在 GUI 进程上。一旦 Tabby 崩溃或者系统重启里面的会话就没了。它本身也带有 SSH session 保持和恢复机制但那要配合远程服务器配置对于“本地终端里跑 Agent”这个场景来说管理粒度还是太粗了。Zellij 这两年很火理念也很新潮它把布局、插件、鼠标交互都做到了开箱即用如果你是完全的新手Zellij 的上手体验确实比 tmux 平滑得多。但我个人的顾虑是Zellij 的脚本化能力还在快速演进中如果我想用一段 shell 脚本自动化地创建一套多会话工作区tmux 的命令接口明显更成熟、更稳定网上能搜到的资料也多一个量级。GNU Screen 是上古神器功能层面其实已经过时分屏操作别扭、默认配置老气、很多快捷键和现代终端模拟器有冲突。除非你所在的服务器环境连 tmux 都装不上否则我不建议从 Screen 开始。2.2 tmux 的核心优势client-server 架构与三层级对象模型选 tmux 最重要的一条理由可能很多人没意识到就是它的 client-server 架构。简单说tmux 启动后真正干活的会话进程跑在一个独立的后台服务里你打开的终端窗口只不过是一个“显示器”随时可以离开随时可以重新接上。这个概念特别适合 Agent 场景。Claude Code 会话一旦在 tmux 里启动就挂在 tmux server 下面你关掉终端模拟器、断掉 SSH、甚至电脑睡一觉再醒来会话进程都还在后台继续跑。重新打开终端后一条tmux attach就能把之前的界面恢复回来。这就是持久化的本质——任务跑在后台而不是跑在窗口里。tmux 的第二个核心设计是 session / window / pane 三层模型。我还是拿实际场景来解释session 相当于一个独立工作区每个项目一个 sessionsession 里可以有多个 window相当于标签页每个 window 又可以切分成多个 pane相当于分屏。这三层对应到 Agent 管理里非常自然session 一个项目或一个任务window 这个任务下的不同工作模式比如“和 Agent 对话”一个窗口、“看测试结果”一个窗口、“看资源占用”一个窗口pane 同一个工作模式内在屏幕上同时显示多个视角。很多人在 tmux 里只用了 window 这一层平铺开一堆标签页这当然也能用但错过了 session 这一层最强的隔离能力。真正多 Agent 并管的时候session 层才是你的“任务列表”window 层是每个任务里的细节页。3. 实战给 Claude Code 配 tmux 的完整操作流程铺垫了这么多下面进入正题。这一节我会把从安装、配置到实际组织多个 Claude Code 会话的完整流程写一遍所有命令都是我在真实环境里验证过的复制就能用。3.1 安装与初始化配置Linux 环境下Ubuntu/Debiansudo apt update sudo apt install -y tmuxmacOS 环境下brew install tmux如果你在 Windows 上建议用 WSL 里的 Linux 发行版来跑或者用 Git Bash 配合 Windows 版 tmux操作逻辑完全一致。装完之后先验证一下版本tmux -V能看到版本号就说明环境没问题。然后是最基础的一份配置文件。我放在~/.tmux.conf# 开启鼠标支持方便用滚轮翻历史和点击切换 pane set -g mouse on # 把前缀键从 CtrlB 改成 CtrlA避免和 VSCode 内置快捷键冲突 set -g prefix C-a unbind C-b bind C-a send-prefix # 窗口索引从 1 开始而不是默认的 0更符合直觉 set -g base-index 1 setw -g pane-base-index 1 # 增大回滚缓冲区Agent 输出大段日志时不容易丢 set -g history-limit 50000 # 修改配置后按 C-a r 即可热加载不用重启 tmux bind r source-file ~/.tmux.conf \; display config reloaded几个配置点说明一下。鼠标支持和历史缓冲是必须开的Claude Code 经常输出一长串修改文件列表缓冲太小你翻个几屏就到底了。前缀键改成 Ctrl-A 是我个人习惯如果你不用 VSCode 或者没有冲突保持默认 Ctrl-B 也行。关键是配置要跟着自己的使用习惯走不要照抄。3.2 按“项目即会话”原则组织多个 Agent我的组织原则非常简单粗暴一个项目一个 session一个 Agent 任务一个 window。比如我现在同时有两个项目在跑项目 A 做代码重构项目 B 在修一个线上 bug。按传统方式我会开两个终端标签页各自跑一个claude。但用 tmux 之后我会这样建# 后台创建 session命名为 refactor首窗口命名为 agent tmux new-session -d -s refactor -n agent # 在 refactor 的 agent 窗口里启动 Claude Code并切到项目 A 目录 tmux send-keys -t refactor:agent cd ~/work/project-a claude Enter # 再创建一个 bugfix session同样启动另一个 Agent tmux new-session -d -s bugfix -n agent tmux send-keys -t bugfix:agent cd ~/work/project-b claude Enter # 查看当前所有 session tmux ls执行完tmux ls你会看到类似这样的输出refactor: 1 windows (created ...) 212x45 bugfix: 1 windows (created ...) 212x45这就是你的“任务列表”。两个 Agent 各自跑在自己的 session 里上下文完全隔离。想看哪个就tmux attach -t refactor或tmux attach -t bugfix。这里有个细节值得注意我用了-d参数让 session 刚创建时不立刻进入前台然后用send-keys往里面发命令。这样做的意义在于你可以先在一段脚本里把所有 session 全部创建好、把 Agent 都启动起来最后再统一 attach——这比手动一个个开窗口再敲命令高效得多。3.3 一键恢复整套 Agent 工作区的脚本化思路一旦你形成了“项目即 session”的组织方式下一步很自然就是写一个脚本把整套工作区一键拉起来。这样每天早上到了工位或者服务器 SSH 断开重连之后跑一条命令就能恢复昨天的工作现场。下面是一个能直接用的脚本雏型保存为start-workspace.sh#!/usr/bin/env bash set -euo pipefail SESSION_NAMEdev # 已存在同名 session 则直接附着避免重复创建 if tmux has-session -t $SESSION_NAME 2/dev/null; then echo session $SESSION_NAME already exists, attaching... tmux attach -t $SESSION_NAME exit 0 fi # 创建主 session第一个窗口跑项目 A 的 Claude Code tmux new-session -d -s $SESSION_NAME -n agent-a tmux send-keys -t $SESSION_NAME:agent-a cd ~/work/project-a claude Enter # 在同一窗口右侧分屏实时看测试日志 tmux split-window -h -t $SESSION_NAME:agent-a tmux send-keys -t $SESSION_NAME:agent-a.2 cd ~/work/project-a tail -f test.log Enter # 新建第二个窗口跑项目 B 的 Agent tmux new-window -t $SESSION_NAME -n agent-b tmux send-keys -t $SESSION_NAME:agent-b cd ~/work/project-b claude Enter # 第三个窗口留作终端备用手动操作 git 或看文件用 tmux new-window -t $SESSION_NAME -n shell # 默认回到第一个窗口 tmux select-window -t $SESSION_NAME:agent-a # 进入前台 tmux attach -t $SESSION_NAME这个脚本解决了一个很关键的问题可重复性。你不需要记得昨天开了哪些窗口、每个窗口里跑了什么命令脚本本身就是这个工作区的“定义文件”。再次强调一下has-session判断的作用如果 session 已经存在脚本直接 attach不会二次创建导致状态错乱。3.4 日常操作几张快捷键速查表配置和脚本都准备好了日常使用还得靠快捷键。快捷键不用一口气全背先记住最常用的几个剩下的碰到场景再查表快捷键作用C-a c在当前 session 里新开一个 windowC-a ,重命名当前 window推荐和项目名对应C-a %垂直分屏把当前 pane 分成左右两个C-a 水平分屏分成上下两个C-a 方向键在相邻 pane 之间切换C-a z最大化/还原当前 pane分屏看眼花了就放大看一个C-a d离开 sessiondetach但任务继续后台跑C-a [, 然后方向键/翻页键进入拷贝模式可以往上翻历史输出C-a x关闭当前 pane会弹出确认慎用C-a $重命名当前 session这套快捷键把最常用的操作都覆盖到了。我认为C-a z是很多人低估的功能当你分屏同时看 Agent 输出和测试日志时某一瞬间你可能只想看 Agent 的完整输出按一下z放大看完了再按一下还原比来回切换窗口高效得多。也因此我建议给每个 Agent 会话至少分一块屏出来放测试或运行日志这样“放大/还原”才用得上。4. 进阶玩法把 tmux 升级成 Agent 调度台当你已经能熟练用 session 隔离多个 Agent 之后还可以再往前走一步把“总管”从单纯的会话管理器变成一个小型调度台。这一节讲的是我自己日常工作流里最有用的几个进阶玩法。4.1 建立在分屏之上的“看板式”并行监控先插一个概念问题。很多人把“AI Agent”和“LLM大语言模型”混着用其实这两个层次不一样。LLM 是一个模型负责“理解语言、生成语言”比如常说的 DeepSeek 属于这一类AI Agent 则是跑在模型之上的智能体系统它能拆解目标、调用工具、执行命令、循环反馈。Claude Code 就是一个典型的终端 AI Agent底层会调用大模型能力但在上层它具备“自己动手改代码、跑测试、看结果”的自主性。搞清这个区分你才能真正理解为什么 Agent 任务需要长期维持会话——它不是一个“问一句答一句”的对话而是一个有状态的执行过程。正因为有状态监控就很重要。我在跑任务时最喜欢的一个布局是三块 pane左侧 60%Claude Code 主会话Agent 在干活右上 25%测试日志tail -f输出Agent 每次改完都会触发测试右下 15%btop或htop看 CPU 内存占用防止 Agent 跑疯。布局效果用脚本化方式建一次后面每次都能复用# 已有 session 内先垂直分屏 tmux split-window -h -p 40 # 右侧再水平分屏下面的 pane 放资源监控 tmux split-window -v -p 40 tmux send-keys -t $SESSION_NAME:agent.3 btop Enter tmux select-pane -t $SESSION_NAME:agent.1不要小看这个布局。它本质上是把“Agent 在做什么”和“系统发生了什么”拉到同一个视野里。你不需要点进每个窗口去轮询状态余光一扫就知道 Agent 还在跑还是在空转。4.2 多模型多 Agent 并行同屏对比工作流选定一个 Agent 工具不意味着你只能绑定一个模型或一个产品。实际上终端 Agent 生态里已经有不少可选工具比如 Claude Code 之外还有 OpenAI 系 Codex 等。它们各有各的优劣势有的理解代码能力强有的执行长任务稳定有的上下文窗口大。我在做一些关键决策前会开两个独立 session分别让 Claude Code 和 Codex 处理同一个需求然后分屏对比它们的方案。具体做法是# 在两个独立的 session 里分别启动 Agent tmux new-session -d -s compare-a -n agent tmux send-keys -t compare-a:agent claude Enter tmux new-session -d -s compare-b -n agent tmux send-keys -t compare-b:agent codex Enter然后通过 tmux 的join-pane命令把两个 session 的窗口拼到一个屏幕里# 把 compare-b 的 agent 窗口拉到当前 session 的右侧分屏 tmux join-pane -s compare-b:agent -t compare-a:agent -h拼接完之后你在同一个窗口里可以直观地看到两个 Agent 各自怎么理解需求、怎么拆步骤、怎么改代码。这个对比方式很有价值因为你同时给它们相同的指令等于做了一个人工 A/B 测试而不是凭印象判断哪个更好用。注意一点join-pane之后目标 session 和源 session 的布局会发生改变。用完之后可以通过break-pane把 pane 恢复成独立 window也可以直接tmux kill-session -t compare-b把原来的 session 关掉。我个人习惯是保留独立 session因为脚本和窗口布局更稳定只有临时对比时才用join-pane。4.3 用 alias 封装整套管理命令“调度台”的最后一块拼图是把常用操作封装成短命令。我在~/.zshrc里加了下面几个 aliasalias agt-listtmux ls alias agt-attachtmux attach -t alias agt-killtmux kill-session -t alias agt-workspacebash ~/scripts/start-workspace.sh添加之后source ~/.zshrc生效每天的实际操作就变成了agt-list看有哪几个 Agent 会话在跑agt-workspace一键拉起项目工作区agt-attach refactor进入某个具体会话退出后按C-a ddetach任务继续跑。可能有人觉得这三个 alias 太简单了。但对“总管”来说降低摩擦本身就是最大价值。如果一条命令能启动整个复杂工作区你就会愿意每天用如果还要敲一堆路径和参数大概率两天就放弃了。4.4 日志与审计Agent 跑了什么怎么复盘Agent 跑完任务之后怎么复盘它到底干了什么Claude Code 本身有会话导出功能可以导出对话记录但如果你需要的是终端层面的“过程快照”——包括 Agent 执行的命令、输出的关键信息、测试日志——那 tmux 有两个非常实用的能力。第一个是pipe-pane它可以把某个 pane 的所有输出实时写入文件# 把 refactor session 的 agent 窗口所有输出写入日志文件 tmux pipe-pane -t refactor:agent -o ~/logs/refactor-$(date %Y%m%d-%H%M%S).log第二个是capture-pane它可以把当前 pane 显示的画面保存下来适合事后回滚查找某个瞬间的状态# 把当前窗口最近 2000 行输出保存到文件 tmux capture-pane -pS -2000 ~/logs/snapshot.txt我的经验是pip-pane适合整个任务周期全程开启capture-pane适合在 Agent 报错或者行为异常时抓现场。两条命令配合使用基本上每个 Agent 的关键操作节点都能复盘到位。5. 实测中踩过的坑和对应解法光讲漂亮配置不说坑是典型的教程式偷懒。我在实际用 tmux 管理多个 Agent 的这一个多月里确实踩了不少坑。下面按“症状 — 原因 — 解法”的方式列几个都是我测过有效的方案。5.1 鼠标滚动和复制粘贴在 tmux 里失灵症状打开 tmux 后鼠标滚轮不再翻历史输出而是把整个终端内容当作文本选中想复制 Agent 输出的一段关键日志粘贴出来却是乱的。原因tmux 默认不开启鼠标模拟滚轮事件被解释成文本选择开启鼠标支持之后普通的拖拽选择又会和 pane 切换手势冲突。解法先在~/.tmux.conf里打开鼠标支持和拷贝模式前面配置里已经写过了。然后复制粘贴时按住Shift再拖拽选择文本就能临时绕过 tmux 的选择逻辑直接用终端模拟器的原生剪切板。如果你用的是 macOS 的 iTerm2按住Option键也能达到类似效果VSCode 集成终端里则是按住Alt。 如果还是嫌麻烦就用C-a [进入拷贝模式先按空格开始选择再按 Enter 复制。这个组合键多练几遍就成了肌肉记忆。5.2 快捷键冲突CtrlB 被 VSCode 和系统抢走症状在 VSCode 的集成终端里使用 tmux按C-b发现侧边栏被打开了或者系统弹出了别的响应tmux 完全没有反应。原因C-b这个组合键在很多软件里都有定义VSCode 就把Cmd/CtrlB绑定了切换侧边栏。解法最简单的是把 tmux 前缀键改成C-a就是我在配置里写的那套。改完配置后执行tmux source-file ~/.tmux.conf热加载。如果你在 VSCode 里必须用C-b也可以到 keybindings.json 里把toggleSidebarVisibility改成其他组合键。这个属于“环境和工具链的兼容性调整”没有标准答案但原则是优先保留 tmux 的前缀键稳定因为 tmux 是整个管理层的核心其他软件可以迁就它。5.3 并行任务触发 API 配额和限流症状同时跑三四个 Claude Code 会话过了一段时间某个会话开始频繁报限流类错误任务执行速度明显变慢甚至停在某个步骤不走了。原因每个会话都在独立消耗同一个账号的 API 配额和速率限制。多 Agent 并行表面上是在“加快”任务完成实际上是在加速消耗资源。对按量计费或者有配额上限的账号来说这种模式很容易撞墙。解法我给每个并发 Agent 设置一个显式的“完成标志”。比如让 Agent 在处理完任务后创建一个done文件然后我定期用agt-list和tail -f去确认哪些任务已经完成完成后立刻 kill 掉对应 session释放资源而不是让它一直挂在后台“待命”。这看起来只是个小习惯但在配额紧张时能救命。 如果你的任务量大更合理的做法是把大任务拆成小批次分批喂给 Agent控制并发度而不是一味地堆并行。5.4 新 pane 不继承当前 shell 的环境变量症状我在某个 session 里已经export了一个环境变量比如 API key然后在这个 session 里新建了一个 pane发现新 pane 里根本读不到这个变量。原因tmux 的 pane 本质上是独立的 shell 进程新建 pane 时会重新走一遍 shell 的启动流程你手动在某个 pane 里export的变量只对那一个特定 shell 进程生效不会自动广播到其他 pane。Agent 的登录态和 API key 配置也需要特别注意如果你把凭据写在启动 session 之前的环境变量里tmux server 会继承初始值但如果你中途改了环境变量新的 pane 会读新值旧的 pane 里还是旧值。解法规范的做法是所有环境变量统一写进~/.bashrc或~/.zshrc让每个新开的 pane 都能加载到对 Claude Code 的登录态可以确认凭据文件存在且路径稳定同一台机器上启动的所有 Agent 会话都会共享。改完~/.bashrc之后如果 tmux server 已经跑了一段时间建议先完全退出 tmuxtmux kill-server重新启动确保 server 进程本身加载的是新环境而不是沿用过时的初始环境。这个操作很容易被忽略但它往往是“为什么我的 Agent 在新 pane 里忽然没有权限了”的根因。5.5 误关窗口导致会话消失症状想关闭某个 Agent 的 pane按快捷键手滑按到了 kill-session整个 session 里的所有窗口和运行中的任务全没了而且 tmux 的 confirm 提示一晃而过直接执行了。原因tmux 的kill-pane和kill-session默认在确认前不会等你某些坏习惯比如在 pane 里连按快捷键很容易误触。解法我给kill-session加了一个确认保护绑定在~/.tmux.conf里自定义# 按 C-a x 关闭 pane 前要求输入 y/n bind x confirm-before kill-pane # 按 C-a X 才有权关闭整个 session同样要求确认 bind X confirm-before kill-session加上这个保护之后手滑的概率大大降低。还有一个更稳妥的习惯kill session 之前先用capture-pane或者tmux ls看一眼会话状态确定这个 Agent 的任务真的结束了再动手。在自动化脚本里我会在创建 session 之后跑一个“心跳”命令定期检查 Agent 是否还在往前推进如果输出在很长时间内没有任何变化就在日志里打一条告警而不是让它无限等下去。6. 最后说说我把这套工作流跑起来之后的感受配置 tmux 这件事门槛说高不高说低也不低。如果你第一次看前面的命令觉得有点多我的建议是先别急着抄全套配置从最简单的一个 session 一个 Agent 开始用把C-a ddetach和C-a [翻历史这两个操作练熟其他能力都可以在真实使用中逐步加进来。实际用了两三周之后再回来写脚本、搞分屏布局你会发现一切都顺理成章。我现在每天的工作流基本稳定为早上一条agt-workspace把项目 A 和项目 B 的 Agent 会话全部拉起来然后该干嘛干嘛中途用agt-list扫一眼任务状态需要介入就agt-attach进去处理下午任务完成agt-kill把对应 session 清掉。这个流程最有价值的地方在于它让我和 Agent 之间的协作从“临时起意”变成了“有节奏、可管理、能复盘”的工程化流程。如果你也在用 Claude Code 或者类似终端 Agent我强烈建议你花一个下午把 tmux 这套“总管”配起来。别指望一次就配到完美先跑起来再慢慢调成适合自己的形态。