当你同时开着 5 个 tmux 窗口3 个在跑 AI 生成任务1 个挂着 Agent 在检查代码另外 1 个还在等你确认某个工具调用。表面上tmux 把一切安排得井井有条实际上你根本不知道哪一个窗口背后的程序正在等你输入哪一个早已跑完只是安静地把结果留在屏幕上等着你切过去看。这篇文章要讨论的不是“要不要用 tmux”而是 tmux 在“多个 AI 任务并行”这个场景下的真正短板它是一个优秀的终端复用器但它不是一个任务状态管理器。AI 任务不像编译任务那样跑完就完了。大模型 API 的响应是异步的AI Agent 可能在工具调用中间停下来征求确认甚至一个看起来还在工作的窗口其实已经卡死等待输入很久了。读完本文你会得到一套不依赖任何商业平台、直接用 tmux Shell 脚本搭建的轻量 AI 任务状态管理方案。核心就一句话把“这个 AI 正在等我”从屏幕里的隐式信号变成机器可读的显式状态。1. 多个 AI 任务并行时最先丢失的是上下文先还原一个场景。你负责一个小型团队的基础设施最近开始把 AI Agent 接入日常研发流程。今天早上你一口气发起了 5 个任务让 AI 阅读一份技术方案并输出摘要让 AI 为一个接口生成测试用例让 AI 分析某个模块的日志文件让 Agent 自动化修复一批 lint 告警让一个代码审查 Agent 检查最近提交。你给每个任务开了一个 tmux 窗口然后开始等。问题是你不可能同时盯着 5 个窗口。等你处理完其他工作再切回来你看到的不是一个清晰的“任务调度面板”而是 5 份滚动未定的终端输出。窗口 2 的文件可能已经生成完毕你在等窗口 3 可能输出了一个权限确认提示Agent 在等你窗口 4 可能早就因为 API 报错退出而你没有看到错误码窗口 5 也许刚刚开始但屏幕上的最后一行看不出它到底在进行中还是已经卡住。这种混乱的根源不是 tmux 不够稳定而是 tmux 提供的信息粒度太低了。tmux 能告诉你的是某个窗口还活着、某个进程还没退出、终端里有输出。它无法告诉你的是这个进程是在等待外部接口还是在等待用户输入还是在等待某个不可预知的资源。换句话说当你跑的是普通 Shell 命令时一条命令退出后你自然能看到结果当你跑的是多轮、异步、可能有人工确认点的 AI Agent 任务时“进程退出”只是一种最粗粒度的状态中间还有大量“等待中”的阶段。这些阶段不会影响终端进程的存活却直接影响你的工作效率。所以真正要管理的不是终端会话而是异步等待关系。2. tmux 能解决什么不能解决什么很多人一提到 tmux 就说“多开几个终端窗口”这个理解没错但它低估了 tmux也高估了 tmux。tmux 的三层结构是 Session会话、Window窗口、Pane窗格tmux 对象作用范围类比Session一组窗口的集合适合隔离不同项目一个项目的工作区Window单个可切换的终端屏幕一个独立任务的工作台Pane窗口内分割出的区域同一任务下的多个视图它真正的价值是让你在一个 SSH 连接里同时维护多个终端环境断开服务器后任务不会随着连接断开而终止。这一条对远程执行 AI 任务尤其重要你不会希望因为本地网络抖动就把跑了一半的 Agent 任务打回原形。但在“多个 AI 任务并行”的场景里tmux 有几个明显短板第一窗口名只是装饰。虽然 tmux 允许你重命名窗口但如果没有人维护窗口名永远只代表“我最初用它做什么”而不代表“它现在进行到什么状态”。第二状态变化只发生在屏幕内部。任务从“运行中”变成“等待用户”在 tmux 看来只是一串输出停止滚动。它不会自动把这个变化提升为你可以扫一眼就识别的事件。第三它没有“任务结束事件”的概念。一个任务失败了终端会显示错误但 tmux 不会用视觉或声音方式提醒你除非你主动配置。窗口可能安静地放在那里而任务早就结束了。第四多个窗口之间的状态是孤立的。你没有一个“汇总视图”告诉你当前 5 个 AI 任务里哪个在跑、哪个在等、哪个失败了。你必须逐个切换窗口去看。一句话总结tmux 解决了“窗口要不要关”的问题没有解决“这个任务该不该等”的问题。在 AI 并发任务变成常态的今天后者恰恰是最耗人的部分。3. AI 并发场景里的“等待”到底有哪几种要让状态可见首先得搞清楚我们到底在等什么。AI 任务中的“等待”远比普通命令复杂。3.1 等大模型 API 返回你向某个大模型接口发送了一条请求模型服务需要排队、推理、流式返回。对于复杂的生成任务这个过程可能持续几十秒甚至几分钟。在这个阶段程序没有卡死只是单纯在等待外部服务响应。如果你只看窗口很难区分它是“正在认真思考”还是“网络已经断开”。3.2 等 Agent 执行工具现在的 AI Agent 不只是生成文本它会读文件、执行代码、调用搜索、写测试、跑命令。这些工具调用的耗时可长可短。Agent 可能正在读一个巨大的代码仓库也可能在一个无限循环里反复执行同一条命令。从终端表面看滚动输出会给你一些线索但当任务很多时你不可能全部实时跟踪。3.3 等用户确认这是最容易被忽略也最影响效率的一种“等”。很多 Agent 框架出于安全考虑会把高风险操作设为需要人工确认删除文件、覆盖代码、发布到某个环境、执行数据库迁移等。Agent 在等待确认时进程并没有退出日志可能也没有新增内容它只是停在一个 Y/N 提示符前面。如果没有状态管理这个窗口可以安静地等你一上午。3.4 等任务完成后的审阅命令已经执行完退出码为 0AI 也已经把结果输出到终端。但因为你没有切到那个窗口结果不会主动找你。在并行任务很多时“已经完成”和“还在运行”在窗口列表里看起来几乎一样。理解了这四种等待你就明白为什么简单的“前台命令执行完自动退出”模型不够用了。AI 任务本质上是一个异步事件流而不是一次普通函数调用。4. 最小改造方案把状态变成窗口的一等公民工欲善其事必先利其器。在引入任何重量级平台之前我们可以先用一套轻量约定把上述状态变成可见、可查、可写的信息。这套方案有三个原则4.1 一个任务一个窗口名字里带上状态不要在同一个 tmux 窗口里混杂多个 AI 任务。每个任务独立窗口并且立即把窗口名重命名为类似这样的格式[run] api-review [done] gen-testcase [fail] analyse-log [wait] lint-fix窗口名不再是对任务的静态描述而是任务的实时状态栏。4.2 状态写入文件让机器也能读取终端窗口名适合人看但不利于脚本统计。所以每个任务还要在状态目录里维护一个.state文件STATERUNNING TASKapi-review STARTED2025-06-01 10:00:00这样无论是你自己写监控脚本还是以后接入任务框架都能读取这些文件来判断当前所有 AI 任务的分布情况。4.3 日志统一落盘完成/失败触发提醒每个任务除了往终端输出也要把完整输出写入独立日志文件。这样即使你错过了窗口里的滚动信息事后也可以翻日志。任务结束时通过 tmux 或者系统通知提醒你。这套方案不改变你原有的 AI 调用方式只是在任务外层加了一个“状态包装层”。它的成本很低却能解决最痛的问题。5. 环境准备与前置条件下面的实现基于常见的 Linux/macOS tmux 3.x Bash 环境。不同版本的 tmux 在细节上可能略有差异但整套思路是通用的。先确认本机 tmux 版本tmux -V如果还没有安装macOS 可以用 Homebrewbrew install tmuxDebian/Ubuntu 系列sudo apt update sudo apt install tmux还要确认你的 Shell 支持 Bash 风格的进程替换和${PIPESTATUS[]}默认 Bash 4 都支持Zsh 也兼容。为了保存任务日志和状态建议使用独立目录不要散落在各个项目目录里。下面是我的推荐结构~/.ai-tasks/ ├── logs/ # 每个任务一个 log 文件 └── states/ # 每个任务一个 state 文件注意如果你的 AI 任务会涉及敏感数据建议给这个目录单独设置权限chmod 700 ~/.ai-tasks不要把 API Key、Token 等敏感信息写在窗口名或日志文件名中。6. 核心实现一套可复制的 tmux AI 任务状态工作流下面进入代码实现。我会把脚本放到~/.bashrc或~/.zshrc里这样每次打开终端都能直接使用。6.1 初始化目录和状态变量在 Shell 配置文件中加入# 文件~/.bashrc 或 ~/.zshrc # AI 任务状态管理目录默认放在 ~/.ai-tasks export AI_TASK_DIR${AI_TASK_DIR:-$HOME/.ai-tasks} export AI_TASK_LOG_DIR${AI_TASK_LOG_DIR:-$AI_TASK_DIR/logs} export AI_TASK_STATE_DIR${AI_TASK_STATE_DIR:-$AI_TASK_DIR/states} mkdir -p $AI_TASK_DIR $AI_TASK_LOG_DIR $AI_TASK_STATE_DIR这里使用“如果变量为空就用默认值”的写法是方便你以后在某个项目里临时修改路径export AI_TASK_DIR/tmp/ai-debug source ~/.bashrc6.2 核心函数run_ai_task这个函数负责三件事在任务开始前把 tmux 窗口改名为[run] 任务名把任务输出同时送到终端和日志文件根据退出码更新窗口名、状态文件和通知。run_ai_task() { local task_name$1 shift if [[ -z $task_name || $# -eq 0 ]]; then echo Usage: run_ai_task task_name command... 2 return 2 fi local log_file$AI_TASK_LOG_DIR/${task_name}.log local state_file$AI_TASK_STATE_DIR/${task_name}.state local started started$(date %Y-%m-%d %H:%M:%S) local exit_code0 # 写初始状态 { echo STATERUNNING echo TASK$task_name echo STARTED$started } $state_file # 如果当前就在 tmux 里把窗口名改成运行时状态 if [[ -n $TMUX ]]; then tmux rename-window [run] ${task_name} fi echo START $task_name at $started $log_file # 使用 tee 让输出同时到终端和日志文件 $ 21 | tee -a $log_file exit_code${PIPESTATUS[0]} local ended ended$(date %Y-%m-%d %H:%M:%S) if [[ $exit_code -eq 0 ]]; then { echo STATEDONE echo TASK$task_name echo STARTED$started echo ENDED$ended echo EXIT0 } $state_file if [[ -n $TMUX ]]; then tmux rename-window [done] ${task_name} tmux display-message AI task done: ${task_name} fi else { echo STATEFAILED echo TASK$task_name echo STARTED$started echo ENDED$ended echo EXIT$exit_code } $state_file if [[ -n $TMUX ]]; then tmux rename-window [fail] ${task_name} tmux display-message AI task FAILED: ${task_name} (exit $exit_code) fi fi echo END $task_name exit_code$exit_code at $ended $log_file return $exit_code }这段代码里有两个关键细节值得展开说明。第一个是tee -a的用法。如果没有tee你只能在“看到实时输出”和“保留完整日志”之间二选一。加了tee之后任务输出会同时出现在终端窗口和日志文件中非常实用。第二个是exit_code${PIPESTATUS[0]}。在管道命令$ 21 | tee -a $log_file中最终退出码是tee的退出码而不是原命令的退出码。tee几乎总是能成功如果你取$?就会把“任务失败”误判成“任务成功”。${PIPESTATUS[0]}取的才是管道中第一个命令也就是你真正想执行的那个 AI 命令的退出码。6.3 手动标记等待状态外部 AI 工具不像你可以通过退出码判断状态。当它停在 Y/N 等待人工确认时进程没有退出run_ai_task里的退出码逻辑不会触发。对这种场景我们需要手动标记。mark_status() { local label${1:-wait} local task_name${2:-$(basename $PWD)} # 任务名里最好不要包含空格和斜杠 task_name$(echo $task_name | sed s/[^A-Za-z0-9_.-]/_/g) local state_file$AI_TASK_STATE_DIR/${task_name}.state local upper_label upper_label$(echo $label | tr [:lower:] [:upper:]) { echo STATE$upper_label echo TASK$task_name echo MARKED$(date %Y-%m-%d %H:%M:%S) } $state_file if [[ -n $TMUX ]]; then tmux rename-window [${label}] ${task_name} fi } # 常用别名 mark_wait() { mark_status wait $; } mark_done() { mark_status done $; } mark_fail() { mark_status fail $; }用法很简单。假设某个 AI Agent 正在等你审批mark_wait api-review窗口名会变成[wait] api-review当你处理完准备继续推进这个任务mark_done api-review窗口名就变成[done] api-review这里有一个工程判断使用外部商业 AI 工具时你往往无法在工具内部注入状态回调。与其写千奇百怪的解析规则去猜工具输出不如在 Agent 停下等你的时候手动按一次标记。高频操作成本极低但信息价值极高。6.4 Dashboard一条命令看全部任务窗口名适合人扫一眼但它散落在 tmux 的窗口列表里还不够集中。我们再加一个简单的 Dashboard 脚本统一读取所有状态文件。创建文件~/.local/bin/ai-dashboard#!/usr/bin/env bash # 文件~/.local/bin/ai-dashboard AI_TASK_STATE_DIR${AI_TASK_STATE_DIR:-$HOME/.ai-tasks/states} AI_TASK_LOG_DIR${AI_TASK_LOG_DIR:-$HOME/.ai-tasks/logs} echo AI Task Dashboard echo State dir: $AI_TASK_STATE_DIR echo Log dir: $AI_TASK_LOG_DIR echo found0 for state_file in $AI_TASK_STATE_DIR/*.state; do [[ -e $state_file ]] || continue found1 task_name$(basename $state_file .state) state$(awk -F /^STATE/{print $2} $state_file) started$(awk -F /^STARTED/{print $2} $state_file) ended$(awk -F /^ENDED/{print $2} $state_file) printf [%-8s] %-20s started%s ended%s\n \ $state $task_name $started $ended done if [[ $found -eq 0 ]]; then echo No AI task states found. fi保存后加上执行权限chmod x ~/.local/bin/ai