在终端用tmux管理多个AI Agent：环境隔离与MCP接入实战

1. 为什么要在终端里同时管理多个 AI Agent1.1 从单兵作战到多 Agent 协作的真实痛点最开始用 Claude Code 的时候我的工作流很简单开一个终端窗口敲claude然后一路对话到底。写代码、改 bug、查文档全在一个会话里完成。但用了一段时间之后问题就暴露出来了。比如我正在用 Claude Code 重构一个模块突然需要查一个 API 的用法这时候如果直接在同一个会话里问上下文就被污染了——它可能会把之前重构的代码逻辑和 API 查询混在一起理解。再比如我同时想让一个 Agent 帮我写测试用例另一个 Agent 帮我审查代码风格如果都在同一个会话里它们会互相干扰输出质量明显下降。更现实的问题是不同的任务需要不同的模型和不同的工具链。Claude Code 适合做代码理解和重构Codex 在某些代码补全场景下响应更快而有些任务可能需要接入 MCP 协议去调用外部工具。如果每次切换都要退出当前会话、重新配置、再启动这个效率损耗是很大的。所以核心需求就一个能不能在一个终端里像管理多个终端会话一样管理多个 AI Agent每个 Agent 有自己的上下文、自己的模型配置、自己的工具权限互不干扰随时切换。1.2 终端复用工具选型为什么是 tmux要实现这个目标第一步是找到一个合适的终端复用工具。市面上常见的选择有 tmux、screen、zellij 等。我最终选了 tmux原因很实际成熟稳定tmux 已经发展了十几年几乎所有的 Linux 发行版和 macOS 都能直接安装WSL 2 里跑 Ubuntu 也没问题。会话保持即使 SSH 断开了tmux 会话还在后台跑着Agent 的任务不会中断。这一点对于跑长时间任务特别重要。窗格分割灵活可以水平分、垂直分还能自由调整大小一个屏幕里同时看多个 Agent 的输出。脚本化能力强tmux 支持通过命令行发送按键、创建窗口、切换窗格这意味着我可以写脚本来自动化整个 Agent 的启动和管理流程。提示如果你之前没用过 tmux建议先花 20 分钟熟悉基本操作——创建会话tmux new -s name、分离Ctrlb d、重新连接tmux attach -t name、分割窗格Ctrlb %和Ctrlb 。这些是后续所有操作的基础。1.3 整体架构设计思路我的方案核心是三层结构第一层是 tmux 会话层负责终端复用和窗格管理。每个 AI Agent 跑在独立的 tmux 窗格里互不干扰。第二层是 Agent 管理层我写了一个 shell 脚本作为“总管”负责启动、停止、切换、查看各个 Agent 的状态。这个脚本封装了 Claude Code、Codex 等工具的启动参数和环境变量配置。第三层是配置隔离层每个 Agent 有自己独立的配置目录和环境变量确保上下文不串。比如 Claude Code 的配置放在~/.claude-agent-1/Codex 的配置放在~/.codex-agent-2/通过环境变量HOME或者工具自身的配置路径参数来隔离。这个设计的优势在于不需要修改任何 AI Agent 工具本身的代码完全通过终端层面的管理和环境隔离来实现多 Agent 并行。换句话说不管以后出来什么新的 AI Agent 工具只要它能在终端里跑就能纳入这套管理体系。2. 核心细节解析与实操要点2.1 tmux 窗格布局与 Agent 分配策略在实际操作中窗格布局直接影响到使用效率。我试过几种方案最终确定了一套比较顺手的布局------------------------------------ | | | | Agent 1 | Agent 2 | | (Claude Code) | (Codex) | | | | ------------------------------------ | | | | Agent 3 | 总管面板 | | (MCP 工具链) | (状态监控) | | | | ------------------------------------四个窗格每个负责不同的角色。Agent 1 跑 Claude Code 做主力的代码理解和重构Agent 2 跑 Codex 做快速代码补全和查询Agent 3 用来跑需要 MCP 协议连接外部工具的任务第四个窗格作为总管面板显示各个 Agent 的运行状态和日志。创建这个布局的命令如下# 创建名为 agents 的 tmux 会话 tmux new-session -d -s agents -n workspace # 垂直分割成左右两列 tmux split-window -h -t agents:workspace # 左右两列各自水平分割成上下两行 tmux split-window -v -t agents:workspace.0 tmux split-window -v -t agents:workspace.2 # 设置每个窗格的标题 tmux select-pane -t agents:workspace.0 -T Claude Code tmux select-pane -t agents:workspace.1 -T Codex tmux select-pane -t agents:workspace.2 -T MCP Tools tmux select-pane -t agents:workspace.3 -T Manager # 附加到会话 tmux attach -t agents注意tmux 的窗格编号规则是随着分割动态变化的上面的.0.1.2.3是分割完成后的最终编号。如果你在脚本里执行建议每步分割后都用tmux list-panes -t agents:workspace确认一下当前编号。2.2 环境隔离让每个 Agent 拥有独立上下文这是整个方案里最关键的一环。如果环境不隔离多个 Agent 之间会共享配置文件、缓存、历史记录导致上下文混乱。以 Claude Code 为例它默认会在用户主目录下创建配置文件和缓存。如果两个 Claude Code 实例共享同一个主目录它们的会话历史可能会互相覆盖。我的做法是为每个 Agent 创建独立的配置目录然后通过环境变量指定# 为 Agent 1 创建独立配置目录 mkdir -p ~/.ai-agents/agent1/claude mkdir -p ~/.ai-agents/agent1/cache # 启动 Agent 1 时指定配置路径 export CLAUDE_CONFIG_DIR~/.ai-agents/agent1/claude export XDG_CACHE_HOME~/.ai-agents/agent1/cache claude对于 Codex 也是类似的思路。Codex 的配置通常放在~/.codex/目录下可以通过设置HOME环境变量来重定向# 为 Agent 2 创建独立的 HOME 目录 mkdir -p ~/.ai-agents/agent2/home # 启动时重定向 HOME HOME~/.ai-agents/agent2/home codex这样做的好处是每个 Agent 的登录状态、会话历史、工具配置都是完全独立的。你可以用不同的账号登录不同的 Agent也可以用同一个账号但保持不同的会话上下文。2.3 MCP 协议接入的注意事项MCPModel Context Protocol是让 AI Agent 连接外部工具的重要协议。在实际使用中我发现有几个坑需要注意第一MCP Server 的启动顺序。如果 Agent 启动时 MCP Server 还没准备好Agent 会报连接失败。我的做法是在总管脚本里先启动所有 MCP Server等待它们就绪后再启动 Agent。第二端口冲突。多个 MCP Server 如果都用默认端口会冲突。需要在配置里为每个 Server 指定不同的端口。第三权限隔离。不同 Agent 可能需要访问不同的 MCP 工具。比如 Agent 1 需要访问代码仓库的 MCPAgent 2 需要访问文档查询的 MCP。在配置 MCP 连接时要确保每个 Agent 只连接到它需要的 Server。# 示例为不同 Agent 配置不同的 MCP Server # Agent 1 的 MCP 配置 cat ~/.ai-agents/agent1/claude/mcp.json EOF { servers: { code-repo: { command: npx, args: [-y, modelcontextprotocol/server-github], env: { GITHUB_TOKEN: your-token-here } } } } EOF # Agent 2 的 MCP 配置 cat ~/.ai-agents/agent2/home/.codex/mcp.json EOF { servers: { doc-search: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, /path/to/docs] } } } EOF提示MCP 的配置文件格式可能因工具版本不同而有差异建议先查阅对应工具的官方文档确认最新格式。上面的配置是基于常见实践的示例实际使用时需要根据你的工具版本调整。3. 实操过程与核心环节实现3.1 总管脚本的完整实现下面是我实际在用的总管脚本放在~/bin/agent-manager.sh通过chmod x赋予执行权限后就可以直接调用。#!/bin/bash # agent-manager.sh - 多 AI Agent 终端管理器 AGENTS_DIR$HOME/.ai-agents TMUX_SESSIONagents # 初始化目录结构 init_dirs() { for i in 1 2 3; do mkdir -p $AGENTS_DIR/agent$i/claude mkdir -p $AGENTS_DIR/agent$i/cache mkdir -p $AGENTS_DIR/agent$i/home done echo 目录结构初始化完成 } # 启动单个 Agent start_agent() { local agent_num$1 local agent_type$2 local pane_target$3 case $agent_type in claude) tmux send-keys -t $pane_target \ export CLAUDE_CONFIG_DIR$AGENTS_DIR/agent$agent_num/claude \ export XDG_CACHE_HOME$AGENTS_DIR/agent$agent_num/cache \ claude C-m ;; codex) tmux send-keys -t $pane_target \ HOME$AGENTS_DIR/agent$agent_num/home codex C-m ;; *) echo 未知的 Agent 类型: $agent_type return 1 ;; esac echo Agent $agent_num ($agent_type) 已在 $pane_target 启动 } # 创建完整工作区 create_workspace() { # 如果会话已存在先杀掉 tmux kill-session -t $TMUX_SESSION 2/dev/null # 创建新会话 tmux new-session -d -s $TMUX_SESSION -n workspace # 分割窗格 tmux split-window -h -t $TMUX_SESSION:workspace tmux split-window -v -t $TMUX_SESSION:workspace.0 tmux split-window -v -t $TMUX_SESSION:workspace.2 # 设置标题 tmux select-pane -t $TMUX_SESSION:workspace.0 -T Claude Code tmux select-pane -t $TMUX_SESSION:workspace.1 -T Codex tmux select-pane -t $TMUX_SESSION:workspace.2 -T MCP Tools tmux select-pane -t $TMUX_SESSION:workspace.3 -T Manager echo 工作区创建完成 } # 查看所有 Agent 状态 status() { echo AI Agent 状态 tmux list-panes -t $TMUX_SESSION:workspace -F \ 窗格 #{pane_index}: #{pane_title} - #{pane_current_command} (PID: #{pane_pid}) } # 主命令分发 case $1 in init) init_dirs ;; start) create_workspace start_agent 1 claude $TMUX_SESSION:workspace.0 start_agent 2 codex $TMUX_SESSION:workspace.1 start_agent 3 claude $TMUX_SESSION:workspace.2 tmux attach -t $TMUX_SESSION ;; status) status ;; attach) tmux attach -t $TMUX_SESSION ;; stop) tmux kill-session -t $TMUX_SESSION echo 所有 Agent 已停止 ;; *) echo 用法: $0 {init|start|status|attach|stop} exit 1 ;; esac这个脚本的核心逻辑很清晰init初始化目录start创建 tmux 工作区并启动所有 Agentstatus查看状态attach重新连接stop停止所有 Agent。3.2 参数计算与资源分配同时跑多个 AI Agent 对系统资源是有要求的。我实测下来每个 Claude Code 实例大约占用 200-400MB 内存Codex 稍轻一些大约 150-300MB。如果同时跑三个 Agent加上 tmux 本身和系统开销建议至少预留 2GB 可用内存。CPU 方面AI Agent 在等待 API 响应时基本不占 CPU但在处理代码分析和文件操作时会有短时峰值。我的机器是 8 核同时跑三个 Agent 没有明显卡顿。如果是 4 核机器建议最多跑两个 Agent。磁盘空间主要消耗在会话历史和缓存上。每个 Agent 的配置目录初始大约 50MB随着使用会增长到几百 MB。建议为~/.ai-agents/预留至少 5GB 空间。# 查看当前 Agent 资源占用 ps aux | grep -E (claude|codex) | awk {print $2, $4, $11} | column -t # 查看磁盘占用 du -sh ~/.ai-agents/*3.3 日常操作流程与快捷键工作区建好之后日常使用主要靠 tmux 的快捷键来切换窗格操作快捷键说明切换到下一个窗格Ctrlb o循环切换切换到指定窗格Ctrlb q然后按数字显示窗格编号后选择切换到上一个窗格Ctrlb ;快速回到上一个放大当前窗格Ctrlb z全屏/还原切换调整窗格大小Ctrlb Ctrl方向键微调尺寸分离会话Ctrlb d后台保持运行我个人的习惯是主力工作在 Agent 1Claude Code需要快速查东西时按Ctrlb o切到 Agent 2Codex需要调用外部工具时切到 Agent 3。总管面板平时不用管需要看状态时按Ctrlb q再按 3 跳过去。提示如果你觉得Ctrlb前缀键不顺手可以在~/.tmux.conf里改成Ctrlaset -g prefix C-a然后bind C-a send-prefix。这个改动对从 screen 转过来的人特别友好。4. 常见问题与排查技巧实录4.1 Agent 启动失败或卡住的排查思路这是最常见的问题。我遇到过几次 Claude Code 启动后一直卡在加载界面或者 Codex 提示“没有终端和文件编辑工具”。排查下来原因主要有这么几类第一类环境变量冲突。如果你在.bashrc或.zshrc里设置了全局的CLAUDE_CONFIG_DIR它会覆盖脚本里的设置。解决办法是在脚本里用env -i清空环境变量后再设置或者在启动前先unset相关变量。第二类配置文件损坏。Agent 的配置文件如果写了一半被中断下次启动就会报错。这时候把对应的配置目录重命名备份让 Agent 重新生成一份默认配置就行。第三类MCP Server 未就绪。如果 Agent 配置了 MCP 连接但 Server 没启动Agent 可能会一直等待超时。检查方法是先手动启动 MCP Server确认能正常响应后再启动 Agent。# 排查环境变量冲突 env | grep -E (CLAUDE|CODEX|MCP) # 备份并重置配置 mv ~/.ai-agents/agent1/claude ~/.ai-agents/agent1/claude.bak mkdir -p ~/.ai-agents/agent1/claude # 检查 MCP Server 是否响应 curl -s http://localhost:3000/health || echo MCP Server 未响应4.2 上下文串扰的识别与解决上下文串扰的表现是你在 Agent 1 里问的问题Agent 2 好像“知道”了或者 Agent 1 的输出风格突然变得像 Agent 2。这通常是因为两个 Agent 共享了某些缓存文件或历史记录。排查方法是检查两个 Agent 的配置目录是否有重叠# 检查配置目录是否独立 ls -la ~/.ai-agents/agent1/claude/ ls -la ~/.ai-agents/agent2/home/.codex/ # 检查是否有符号链接指向同一位置 find ~/.ai-agents -type l -exec ls -la {} \;如果发现有共享的文件最彻底的解决办法是确保每个 Agent 的HOME、XDG_CONFIG_HOME、XDG_CACHE_HOME、XDG_DATA_HOME都指向各自独立的目录。4.3 常见问题速查表问题现象可能原因解决方法Agent 启动后无响应环境变量冲突或配置损坏检查 env重置配置目录MCP 连接失败Server 未启动或端口冲突先启动 Server检查端口占用上下文串扰配置目录共享确保 HOME/XDG 变量独立tmux 窗格标题不显示tmux 版本过低升级到 tmux 2.6Agent 输出乱码终端编码问题设置LANGen_US.UTF-8切换窗格后 Agent 暂停tmux 焦点问题按Ctrlb z放大再还原内存占用过高Agent 实例过多减少同时运行的 Agent 数量会话历史丢失配置目录被清理检查是否有定时清理任务4.4 几个我踩过的坑和独家技巧坑一tmux 窗格编号会变。每次分割窗格编号都会重新分配。如果你在脚本里硬编码了窗格编号分割顺序一变就全乱了。我的做法是每次分割后立即用tmux select-pane -T设置标题后续通过标题来定位窗格而不是编号。坑二Agent 的登录状态会过期。Claude Code 和 Codex 都需要登录token 过期后 Agent 会卡在登录界面。我的做法是在总管脚本里加一个健康检查定期用tmux capture-pane抓取窗格内容如果发现登录提示就发通知。坑三MCP Server 的日志会淹没终端。有些 MCP Server 默认输出大量日志把 Agent 的界面冲得看不见。解决办法是在 MCP 配置里把日志重定向到文件args: [-y, server-name, --log-file, /tmp/mcp.log]。技巧一用 tmux 的synchronize-panes批量操作。有时候需要同时给所有 Agent 发送相同的命令比如都执行clear可以开启同步模式Ctrlb :然后输入setw synchronize-panes on。用完记得关掉不然会误操作。技巧二给每个 Agent 设置不同的终端颜色。在 tmux 配置里为不同窗格设置不同的背景色一眼就能区分哪个是哪个# 在 ~/.tmux.conf 中添加 set -g pane-border-style fgcolour235 set -g pane-active-border-style fgcolour51 # 为特定窗格设置背景色需要在脚本里动态设置 tmux select-pane -t agents:workspace.0 -P bgcolour17 tmux select-pane -t agents:workspace.1 -P bgcolour22技巧三用tmux pipe-pane记录每个 Agent 的完整输出。这个功能可以把窗格的所有输出追加到文件里方便事后回溯# 开始记录 Agent 1 的输出 tmux pipe-pane -t agents:workspace.0 -o cat ~/.ai-agents/agent1/output.log # 停止记录 tmux pipe-pane -t agents:workspace.0这个技巧在排查“Agent 到底输出了什么”这类问题时特别有用因为终端滚动缓冲区有限有些输出滚上去就找不到了但 pipe-pane 记录的文件是完整的。4.5 扩展思路从手动管理到自动化编排上面这套方案是手动管理为主的适合个人开发者日常使用。如果你想把多 Agent 协作做得更自动化可以考虑几个扩展方向方向一基于任务队列的自动分发。写一个调度脚本监听任务队列根据任务类型自动分配给对应的 Agent。比如代码审查任务分配给 Claude Code文档查询任务分配给 Codex。方向二Agent 之间的消息传递。通过 tmux 的send-keys和capture-pane可以实现 Agent 之间的简单消息传递。比如 Agent 1 完成代码生成后自动把结果发给 Agent 2 做审查。方向三与 CI/CD 流水线集成。把 Agent 管理脚本接入 CI/CD在代码提交后自动启动 Agent 做代码审查和安全扫描结果输出到指定文件。这些扩展方向的实现复杂度递增建议先把基础的多 Agent 管理跑通再根据实际需求逐步扩展。我自己目前用到方向一的程度已经能覆盖大部分日常场景了。提示无论怎么扩展核心原则不变——每个 Agent 的上下文必须隔离每个 Agent 的职责必须清晰。只要守住这两条多 Agent 协作的效率提升是实实在在的。