尧图网页设计 
在终端里同时开几个 AI Agent是一件听起来很“工程师”实际上却很折磨人的事情。比如我正在同时让一个 Agent 做接口重构另一个 Agent 修测试用例还有一个 Agent 在写临时分析脚本。为了不让它们互相抢占上下文我习惯把每个任务放进独立 tmux 会话里。可一段时间后我发现tmux 的确能同时开很多窗口但它不会告诉你哪个窗口里的 AI 正在安静地等你输入 y/N哪个窗口里的 AI 其实早就跑完退出了哪个窗口里的 AI 还在疯狂调用工具思考中。这篇文章我把自己最近在用的这套 tmux 多 AI 会话管理方法整理了出来。内容不是单纯罗列 tmux 快捷键而是解决一个非常具体的问题多个 AI 并行时如何快速识别、自动感知“谁在等我”。1. 场景还原终端里的 AI Agent 为什么需要 tmux1.1 AI 会话不是“一问一答”那么简单如果你把大模型只当作网页聊天窗口来用那么确实没必要开多个终端。但当 AI 进入编程、执行命令、修改文件这类 Agent 场景时一个任务可能会持续几分钟甚至更久。常见流程是Agent 接收你的任务描述。它开始分析代码、搜索文件、读取上下文。它计划修改方案然后可能停下来问你是否同意。你确认后它执行命令、修改文件、再次验证。最后输出阶段性结论或者再次等待你的下一步指令。整个过程并不是一次请求返回完整的答案而是“思考、执行、提问、再执行”的循环。如果只有一个终端你在等待 A Agent 的时候就无法同时跟进 B Agent效率会低很多。1.2 tmux 解决的是“会话保活”和“多任务并行”tmux 是一个终端复用器。它允许你在同一个 SSH 连接或同一个本地终端窗口里创建多个会话、窗口和窗格。对于 AI Agent 工作流来说tmux 有几个很明显的价值会话不会因为终端关闭而中断。可以同时在多个窗口里跑不同的 Agent。可以随时 detach再重新 attach 回来看进度。即使网络波动或 SSH 断开Agent 任务仍然在服务器上继续运行。我常用的启动方式如下# 新建一个名为 ai-user-service 的会话 tmux new-session -d -s ai-user-service -n agent-1 # 在第一个窗口里启动你正在用的 AI CLI # 你可以把 your-ai-cli 替换成 codex、claude、opencode 或自己的 Agent 脚本 tmux send-keys -t ai-user-service:agent-1 your-ai-cli Enter # 新建一个窗口用于看日志 tmux new-window -t ai-user-service -n logs tmux send-keys -t ai-user-service:logs tail -f /tmp/ai-user-service.log Enter # 回到 agent 窗口并 attach tmux select-window -t ai-user-service:agent-1 tmux attach-session -t ai-user-service这里我先用-d创建后台会话再把命令发送到指定窗口最后才 attach。这样整个流程可以脚本化也适合在服务器上创建一个长期存活的 AI 任务会话。1.3 多个 AI 并行时的原始状态真正让我感觉到“焦虑”的不是 tmux 的窗口数量不够而是当我有 3 个甚至 5 个 AI 会话一起工作时我根本不知道每个会话处于什么状态。我举个例子ai-user-service: 正在跑你的 AI CLI界面好像停住了 ai-report-agent: 正在跑你的 AI CLI界面最后一行是 [y/N] ai-test-agent: 正在跑你的 AI CLI界面一直刷日志从用户视角看3 个窗口可能都在闪烁但它们的“逻辑状态”完全不同。第一个可能正在等你确认某个操作第二个可能在思考第三个可能已经跑完了只是 shell 还挂在那个 pane 上。这里的核心矛盾是tmux 天然只知道“终端有没有输出、当前前台进程是谁”它并不知道这个 pane 对应的 AI 任务是不是在等待用户输入。2. tmux 不够用的真正原因缺少“状态语义层”2.1 tmux 是终端复用器不是任务看板我们经常把 tmux 当成一个“多任务管理工具”但它的真实定位是“终端复用”。它管理的是窗口、窗格和会话而不是任务的抽象状态。你要在 tmux 里看到“哪个会话正在等你”只能通过以下方式间接判断查看 pane 当前前台进程比如是不是还在跑 Agent 程序。捕获 pane 的屏幕内容观察底部是否出现了确认提示。检查最近是否有新输出判断任务是否卡住了。人工切换到每个窗口用眼睛去读屏幕上的内容。前面 3 条其实都能自动化但原生 tmux 并不会把结果直接告诉你。2.2 状态盲区的典型表现我把实际使用中容易踩坑的情况总结了一下我以为是实际上Agent 还在思考Agent 已经完成任务停在 shell 提示符Agent 在等待我确认Agent 只是输出比较慢还在跑Agent 卡死了它正在等你输入 y/N只是界面没有明显提示Agent 已经结束它其实还在后台生成一个大文件某个窗口没有输出应该没问题它已经因为权限问题停在确认页一直空转这种状态盲区带来的最大问题不是“浪费时间切窗口”而是 AI 任务明明已经停下来等你你却以为它还在运行。等你过几分钟再切回去可能 Agent 已经超时或者整个会话被某种交互机制锁住了。2.3 光标闪动不等于“在等你”很多人判断 pane 是否在等待时会下意识看光标。这个方式在普通命令里很有效但在 AI Agent 的 TUI 界面里并不可靠。现在的许多 AI CLI 会做成全屏交互式界面当你看到光标在闪烁时它可能正在等待你输入但它也可能只是渲染了一个输入框而真正的 Agent 进程仍然在处理前面的请求。反过来有些 Agent 在没有输出时会显示一个不停旋转的 spinner但你很难确定那个 spinner 是在“思考”还是在“等待网络响应”。因此靠人眼去盯屏幕总有遗漏。更可靠的思路是先建立一套能识别的会话规范再用脚本去捕获并判断每个 pane 的真实状态。3. 先建立一套可识别的 AI 会话规范在写任何监控脚本之前我强烈建议先统一自己的 tmux 会话命名。否则脚本不知道该扫描哪些 pane最后只能全盘扫描造成误报。3.1 统一使用 ai- 前缀我把所有跑 AI Agent 的 tmux 会话统一命名为ai-项目名或ai-任务名tmux new-session -d -s ai-user-service tmux new-session -d -s ai-order-report tmux new-session -d -s ai-refactor-test这样做的好处是一眼就能区分哪个会话是普通终端哪个会话跑的是 AI 任务。监控脚本可以只扫描ai-开头的会话减少误报。即使后来开了几十个会话排序和查找都比较方便。如果你同时跑多个同类任务可以在会话名后面再加窗口名tmux rename-window -t ai-user-service:0 agent-1 tmux rename-window -t ai-user-service:1 agent-2 tmux rename-window -t ai-user-service:2 logs3.2 做一个标准启动脚本为了避免每次手动敲一堆命令我习惯把会话创建流程写成一个脚本。示例脚本~/bin/ai-session.sh#!/usr/bin/env bash # 文件路径~/bin/ai-session.sh set -euo pipefail name${1:-ai-default} # 如果会话已经存在直接 attach if tmux has-session -t $name 2/dev/null; then tmux attach-session -t $name exit 0 fi # 新建会话和第一个 agent 窗口 tmux new-session -d -s $name -n agent-1 # 把 your-ai-cli 换成你实际使用的 AI 终端命令 tmux send-keys -t $name:agent-1 your-ai-cli Enter # 可选的日志窗口 tmux new-window -t $name -n logs tmux send-keys -t $name:logs tail -f /tmp/${name}.log 2/dev/null || true Enter # 切回 agent 窗口并 attach tmux select-window -t $name:agent-1 tmux attach-session -t $name保存后加上执行权限chmod x ~/bin/ai-session.sh以后只需要这样启动一个新 AI 任务~/bin/ai-session.sh ai-user-service ~/bin/ai-session.sh ai-order-report统一的命名规则和启动脚本是后面自动监控的前提。4. 手动巡检快速知道哪个 AI 正在等你在完全自动化之前先掌握几个手动检查命令会很有帮助。即使脚本偶尔误判你也能自己快速确认。4.1 查看所有 AI 会话的前台命令tmux 提供了list-panes命令可以输出每个 pane 的基础信息。配合-F格式化参数可以输出“会话名:窗口号.窗格号”和“当前前台命令”。tmux list-panes -a -F #{session_name}:#{ tmux 多 AI 会话管理：如何快速识别“谁在等你”
在终端里同时开几个 AI Agent是一件听起来很“工程师”实际上却很折磨人的事情。比如我正在同时让一个 Agent 做接口重构另一个 Agent 修测试用例还有一个 Agent 在写临时分析脚本。为了不让它们互相抢占上下文我习惯把每个任务放进独立 tmux 会话里。可一段时间后我发现tmux 的确能同时开很多窗口但它不会告诉你哪个窗口里的 AI 正在安静地等你输入 y/N哪个窗口里的 AI 其实早就跑完退出了哪个窗口里的 AI 还在疯狂调用工具思考中。这篇文章我把自己最近在用的这套 tmux 多 AI 会话管理方法整理了出来。内容不是单纯罗列 tmux 快捷键而是解决一个非常具体的问题多个 AI 并行时如何快速识别、自动感知“谁在等我”。1. 场景还原终端里的 AI Agent 为什么需要 tmux1.1 AI 会话不是“一问一答”那么简单如果你把大模型只当作网页聊天窗口来用那么确实没必要开多个终端。但当 AI 进入编程、执行命令、修改文件这类 Agent 场景时一个任务可能会持续几分钟甚至更久。常见流程是Agent 接收你的任务描述。它开始分析代码、搜索文件、读取上下文。它计划修改方案然后可能停下来问你是否同意。你确认后它执行命令、修改文件、再次验证。最后输出阶段性结论或者再次等待你的下一步指令。整个过程并不是一次请求返回完整的答案而是“思考、执行、提问、再执行”的循环。如果只有一个终端你在等待 A Agent 的时候就无法同时跟进 B Agent效率会低很多。1.2 tmux 解决的是“会话保活”和“多任务并行”tmux 是一个终端复用器。它允许你在同一个 SSH 连接或同一个本地终端窗口里创建多个会话、窗口和窗格。对于 AI Agent 工作流来说tmux 有几个很明显的价值会话不会因为终端关闭而中断。可以同时在多个窗口里跑不同的 Agent。可以随时 detach再重新 attach 回来看进度。即使网络波动或 SSH 断开Agent 任务仍然在服务器上继续运行。我常用的启动方式如下# 新建一个名为 ai-user-service 的会话 tmux new-session -d -s ai-user-service -n agent-1 # 在第一个窗口里启动你正在用的 AI CLI # 你可以把 your-ai-cli 替换成 codex、claude、opencode 或自己的 Agent 脚本 tmux send-keys -t ai-user-service:agent-1 your-ai-cli Enter # 新建一个窗口用于看日志 tmux new-window -t ai-user-service -n logs tmux send-keys -t ai-user-service:logs tail -f /tmp/ai-user-service.log Enter # 回到 agent 窗口并 attach tmux select-window -t ai-user-service:agent-1 tmux attach-session -t ai-user-service这里我先用-d创建后台会话再把命令发送到指定窗口最后才 attach。这样整个流程可以脚本化也适合在服务器上创建一个长期存活的 AI 任务会话。1.3 多个 AI 并行时的原始状态真正让我感觉到“焦虑”的不是 tmux 的窗口数量不够而是当我有 3 个甚至 5 个 AI 会话一起工作时我根本不知道每个会话处于什么状态。我举个例子ai-user-service: 正在跑你的 AI CLI界面好像停住了 ai-report-agent: 正在跑你的 AI CLI界面最后一行是 [y/N] ai-test-agent: 正在跑你的 AI CLI界面一直刷日志从用户视角看3 个窗口可能都在闪烁但它们的“逻辑状态”完全不同。第一个可能正在等你确认某个操作第二个可能在思考第三个可能已经跑完了只是 shell 还挂在那个 pane 上。这里的核心矛盾是tmux 天然只知道“终端有没有输出、当前前台进程是谁”它并不知道这个 pane 对应的 AI 任务是不是在等待用户输入。2. tmux 不够用的真正原因缺少“状态语义层”2.1 tmux 是终端复用器不是任务看板我们经常把 tmux 当成一个“多任务管理工具”但它的真实定位是“终端复用”。它管理的是窗口、窗格和会话而不是任务的抽象状态。你要在 tmux 里看到“哪个会话正在等你”只能通过以下方式间接判断查看 pane 当前前台进程比如是不是还在跑 Agent 程序。捕获 pane 的屏幕内容观察底部是否出现了确认提示。检查最近是否有新输出判断任务是否卡住了。人工切换到每个窗口用眼睛去读屏幕上的内容。前面 3 条其实都能自动化但原生 tmux 并不会把结果直接告诉你。2.2 状态盲区的典型表现我把实际使用中容易踩坑的情况总结了一下我以为是实际上Agent 还在思考Agent 已经完成任务停在 shell 提示符Agent 在等待我确认Agent 只是输出比较慢还在跑Agent 卡死了它正在等你输入 y/N只是界面没有明显提示Agent 已经结束它其实还在后台生成一个大文件某个窗口没有输出应该没问题它已经因为权限问题停在确认页一直空转这种状态盲区带来的最大问题不是“浪费时间切窗口”而是 AI 任务明明已经停下来等你你却以为它还在运行。等你过几分钟再切回去可能 Agent 已经超时或者整个会话被某种交互机制锁住了。2.3 光标闪动不等于“在等你”很多人判断 pane 是否在等待时会下意识看光标。这个方式在普通命令里很有效但在 AI Agent 的 TUI 界面里并不可靠。现在的许多 AI CLI 会做成全屏交互式界面当你看到光标在闪烁时它可能正在等待你输入但它也可能只是渲染了一个输入框而真正的 Agent 进程仍然在处理前面的请求。反过来有些 Agent 在没有输出时会显示一个不停旋转的 spinner但你很难确定那个 spinner 是在“思考”还是在“等待网络响应”。因此靠人眼去盯屏幕总有遗漏。更可靠的思路是先建立一套能识别的会话规范再用脚本去捕获并判断每个 pane 的真实状态。3. 先建立一套可识别的 AI 会话规范在写任何监控脚本之前我强烈建议先统一自己的 tmux 会话命名。否则脚本不知道该扫描哪些 pane最后只能全盘扫描造成误报。3.1 统一使用 ai- 前缀我把所有跑 AI Agent 的 tmux 会话统一命名为ai-项目名或ai-任务名tmux new-session -d -s ai-user-service tmux new-session -d -s ai-order-report tmux new-session -d -s ai-refactor-test这样做的好处是一眼就能区分哪个会话是普通终端哪个会话跑的是 AI 任务。监控脚本可以只扫描ai-开头的会话减少误报。即使后来开了几十个会话排序和查找都比较方便。如果你同时跑多个同类任务可以在会话名后面再加窗口名tmux rename-window -t ai-user-service:0 agent-1 tmux rename-window -t ai-user-service:1 agent-2 tmux rename-window -t ai-user-service:2 logs3.2 做一个标准启动脚本为了避免每次手动敲一堆命令我习惯把会话创建流程写成一个脚本。示例脚本~/bin/ai-session.sh#!/usr/bin/env bash # 文件路径~/bin/ai-session.sh set -euo pipefail name${1:-ai-default} # 如果会话已经存在直接 attach if tmux has-session -t $name 2/dev/null; then tmux attach-session -t $name exit 0 fi # 新建会话和第一个 agent 窗口 tmux new-session -d -s $name -n agent-1 # 把 your-ai-cli 换成你实际使用的 AI 终端命令 tmux send-keys -t $name:agent-1 your-ai-cli Enter # 可选的日志窗口 tmux new-window -t $name -n logs tmux send-keys -t $name:logs tail -f /tmp/${name}.log 2/dev/null || true Enter # 切回 agent 窗口并 attach tmux select-window -t $name:agent-1 tmux attach-session -t $name保存后加上执行权限chmod x ~/bin/ai-session.sh以后只需要这样启动一个新 AI 任务~/bin/ai-session.sh ai-user-service ~/bin/ai-session.sh ai-order-report统一的命名规则和启动脚本是后面自动监控的前提。4. 手动巡检快速知道哪个 AI 正在等你在完全自动化之前先掌握几个手动检查命令会很有帮助。即使脚本偶尔误判你也能自己快速确认。4.1 查看所有 AI 会话的前台命令tmux 提供了list-panes命令可以输出每个 pane 的基础信息。配合-F格式化参数可以输出“会话名:窗口号.窗格号”和“当前前台命令”。tmux list-panes -a -F #{session_name}:#{