一个 ssh 终端挂着 tmux左边窗格跑一个用于改代码的 AI Agent右边窗格开一个命令行问答模型往下还有一个正在批量生成测试用例的脚本。几个任务同时跑的时候真正耗神的已经不是命令本身而是来回切换窗口去确认哪个 AI 已经停住、正在等你输入。tmux 把会话保持得很好却不会告诉你屏幕上的 CLI 现在是正在推理、已经输出完毕、还是早就卡住。要回答“哪个正在等你”需要在 tmux 之外补一层状态感知机制。这篇文章就从 tmux 的实际边界出发逐步搭建一套能识别多个 AI 任务状态、在状态栏和系统通知里标出“谁在等你”的工作区监控方案。适合已经会使用 tmux 基本命令、想进一步管理多个 AI Agent 或命令行 AI 客户端、又不想打开一堆浏览器标签页的开发者阅读。代码示例主要基于 Linux 环境macOS 稍作调整也能运行关键脚本会标明适配点。1. 先在 tmux 工作流里回答“哪个 AI 在等我”1.1 tmux 在 AI 开发工作流里的看家本领tmux 是终端多路复用器通俗讲它让一个终端窗口里同时存在多个“虚拟终端”。这些虚拟终端不是普通界面里的标签页而是运行在 tmux server 中的会话可以随时 detach、再 attach。用命令行方式与 AI 模型交互时tmux 的三个能力非常合适。第一是会话保持。ssh 连接断开或者本地笔记本电脑合盖tmux 里的进程不会跟着终端退出。模型生成完代码、Agent 执行完一轮任务后结果还在会话里等着你回来查看。第二是并行多路。一个窗口里可以拆成左右两个窗格左边跑代码生成 AI右边跑日志工具也可以开多个窗口分别对应不同项目或不同 Agent。第三是滚动回看。终端输出一旦刷屏就丢掉但在 tmux 窗口中可以用 Ctrl-b [ 进入复制模式回看前面的输出。AI Agent 的输出经常一次几百行这个能力在排查时相当有用。这套能力决定了 tmux 是终端 AI 工作流里的底座不是可选项。1.2 为什么多个 AI 并发时 tmux 的默认信息不够问题出在 tmux 默认只关心“面板还在不在”并不关心“面板里的程序在做什么”。具体来说tmux 状态栏默认显示窗口编号、名称、时间等信息。某个窗口有新输出时窗口名区域会出现 activity 提示某个窗口内部发出终端响铃时可以配置 bell 提醒。但一个 AI 客户端完成生成、停留在交互提示符前等待输入时并不会触发 activity也不会响铃。例如你在ai-codegen窗口问代码生成模型“帮我把这个接口改成异步”模型花了 40 秒生成完整代码现在停在prompt后面等你回复。此时这个窗口没有任何新输出也没有 bell 事件。tmux 的原生机制会把它当成一个“静止窗口”不会主动提醒你切回去。如果只开两个窗口这个问题不严重。当你开了四五个 AI 窗口分别是代码生成、数据库优化、测试数据生成、运维排障助手就会频繁出现“怀疑某个窗口在等我切过去发现还在思考刚切走它又等我回复”的低效循环。还有一种更隐蔽的情况某个 Agent 因为缺少 API Key、遇到网络错误或者连续重试失败程序已经卡住不再输出。tmux 同样不会告诉你这个窗口已经无效需要人工切过去看。结论是tmux 适合管理会话生命周期但任务级状态识别需要额外设计。1.3 等待状态可以拆成哪几类信号要做监控先把“哪个 AI 在等我”拆成可判断的信号不能靠感觉。最基本的信号是“屏幕内容不再变化”。AI 输出结束后画面往往会停在某个交互提示符或一段完整代码上内容哈希在一段时间内保持不变。第二个信号是“最后一行内容匹配交互提示特征”。很多命令行 AI 客户端在等待输入时最后一行会显示prompt、Continue?、?或输入你的问题这些文本可以作为辅助判断。第三个信号是“进程当前命令”。某个窗格正在运行的进程如果是 bash、python、node通常说明 AI CLI 还在运行如果变成了交互 shell可能已经退出了。第四个信号是 tmux 可以监听的 activity 和 bell。AI 输出过程中会产生内容变化这个变化本身可以触发新的事件。把这些信号组合起来才能相对可靠地判断“正在运行”“正在等你”“可能卡住”。单纯看屏幕是否静止是不够的因为模型思考阶段屏幕也可能静止较长时间。2. 搭建一个方便监控的多 AI tmux 工作区2.1 规划布局一个窗格一个 AI 任务监控的前提是任务边界清晰。推荐一条