最近在排查一个日志分析任务时，我的终端又一次变成了一盘需要人肉维护的状态散沙：窗口 1 里有个 AI 会话在帮我整理错误码，窗口 2 里有一个 agent 正在补测试用例，窗口 3 还把之前跑完的一份方案推进到一半。来回切了几次以后，我停在一个窗口前问自己：现在到底有几个会话已经停下来，正在等我发下一句指令？
这个问题听起来很小，但真正遭遇过的人会知道，它足以毁掉整个“多开 AI 并行工作”的体验。你原本是想让几个不同方向的活同时推进，结果大量精力被消耗在“谁在等我”的调度判断上。tmux 在这里表现得相当克制：窗口都活着，会话都没有丢，进程也都在，可你看不到它们各自处在什么阶段。
这段经历让我对 tmux 的定位有了更具体的认知：tmux 擅长的是让终端会话持久、可恢复、可切换，它不是任务调度器。当你把一个 AI 会话装进一个窗口时，它只保证“这个终端不会因为关掉 SSH 而断开”，并不会回答“这个 AI 当前是在等待输入，还是在持续处理，还是已经跑完退出了”。
多开 AI 以后，tmux 并不是真的不够用，它缺少的是任务级状态可见性。
1. “tmux 不够用”的本质：窗口活了，任务状态是盲的
这一节想先把问题定义清楚。我们常说的“tmux 不够用”，并不是说 tmux 本身有什么功能缺陷，而是它作为“容器”和人的使用预期之间出现了错位。
1.1 tmux 的天花板不在终端，而在任务语义
tmux 在设计上考虑的是终端会话的可靠性。它会帮你把任务留在后台，断开连接后不会主动杀掉进程，重新进入会话后还能看到原来的界面，这对运行长任务、远程开发、调试服务来说很关键。
它不会主动建立某个“任务当前是什么状态”的概念。tmux 只知道当前 pane 里有没有新输出、进程有没有退出，它不理解窗口里运行的是不是 AI，不理解“这次输出结束后的停顿”是等待用户指令还是模型内部思考，更不理解“最后一行出现一闪一闪的输入光标”意味着这轮对话已经回到了你手里。
所以当你把多个 AI 会话放进不同的 tmux 窗口后，出现的信息结构其实非常有限：
- 窗口有输出，说明某个终端里有内容在动；
- 窗口没有输出，说明终端已经安静了一段时间；
- 进程还在，说明对应的命令还没退出；
- 进程退出，说明窗口可能已经回到 shell。
这些信息不足以回答“我现在该去处理哪个窗口”。它等于把一个任务调度问题，退化成了一堆终端事件，让人每次切窗口时都要靠“扫最后几行输出”来重建上下文。
1.2 多会话的真正成本，是切换后的恢复时间
只开一个 AI 会话时，tmux 通常不会带来困扰。你切进去，看看输出，发个指令，很顺。但开会话数量达到三五个时，问题就会从“工具有没有这个能力”变成“人类使用者能不能记住所有状态”。
每个窗口都代表一条独立任务线。每切一次窗口，你就要读取最后几行内容，确认上一轮结论是什么、当前是否卡住、上下文是否还记得前面的要求。这个过程看起来只要几秒钟，遇到复杂的需要追溯的会话，恢复成本会被放大。
当你有多个窗口同时在等你时，你不仅要做任务，还要做“任务状态扫描”。这种多会话工作流，真正瓶颈往往不是 tmux，不是 AI 的输出质量，而是人对多个并发任务的跟踪能力。最直接的解法不是强迫自己变得更专注，而是让每个会话显式暴露自己的状态。
1.3 monitor-activity 和 bell，为什么都只能算辅助
tmux 自带几种提醒机制。很多人的第一反应会是用monitor-activity，让窗口有活动时在状态栏高亮。但在 AI 会话场景里，它很可能成为反向干扰。
原因在于 AI 的输出往往是流式的。一个会持续打印日志的 agent，会让窗口在很长一段时间里一直处于“活动”状态。你看到状态栏某个窗口亮起，并不代表它正在等你，很可能只是它正在吐字。而当你真正需要被提醒时——比如它已经输出完并在等待你的下一轮指令，此时反而没有任何活动事件，monitor-activity不会触发。
终端响铃bell也不是一个可靠信号。响应式 AI CLI 在等待用户输入时，并不会像传统编辑器那样主动响铃。想要用 bell 做提醒，前提是程序自己实现了这个动作，大部分终端 agent 并没有。
倒是有个很少被注意到的配置值得单独说：monitor-silence。它不是在窗口有输出时提醒，而是在窗口超过指定秒数没有输出时给出提醒。这个语义和“某个 AI 可能已经等了一会儿”更接近，实践里更像一个兜底信号，适合用来发现“这个窗口已经安静得可疑了”。
2. 先别急着写监控脚本，要分清“等你”的四种形态
在开始写脚本之前，更值得做的一件事，是把“正在等你”拆细。不同形态的“等你”，对应的终端特征、提醒方式和处理动作完全不一样。如果不分清楚，很容易写出一个“看起来很智能、实际上不断误报”的监控。
2.1 四种常见状态，不能用一个规则覆盖
从实际使用经验看，多个 AI 会话分散在 tmux 里时，会出现这几种状态：
| 状态 | 表面现象 | 最容易误判的点 |
|---|---|---|
| 等待你输入下一轮指令 | 输出已经停止，光标停在 AI 的输入框，或提示符已经出现 | 这种状态没有任何输出事件，activity 不会触发 |
| 正在生成/思考中 | 输出可能暂时停止，但进程活着，过一会儿又继续输出 | LLM 经常有静默思考的现象，安静不代表等你 |
| 命令或工具卡死 | 长时间无输出，进程一直挂着，既不退出也不继续 | 和“思考中”难以区分，需要超时阈值兜底 |
| 会话已退出或已崩溃 | pane 内容停在末尾，进程不存在，可能回到了 shell | 如果最后没有明显的退出信息，容易以为是还在运行 |
这些状态如果混在一起处理，监控逻辑就会失真。比如你把“窗口安静超过 30 秒”当成“它在等你”，那遇到一个正在做复杂推理的模型，每隔十几秒才输出一小段，或者干脆静默一分钟再开始说话，就会不断误报。
一个可靠的方案应该对不同状态采用不同信号。比如“等待输入”应该靠 AI 输出中是否出现约定标记来判断，“卡死”应该靠较长时间没有输出变化来判断，“会话退出”则可以通过进程状态判断。先分好类，后面写代码才不容易糊涂。
2.2 肉眼扫描和可解析信号，差距在哪里
你手动切窗口时，其实是靠阅读最后几行文本，再结合自己对上下文的记忆，才能判断当前是不是“该你说话”。这种判断方式有两个问题：
第一，不是所有输出都能一望而知。有些 CLI 工具即使结束了任务，也不会输出一个明确的“等待指令”提示，只是光标在闪；有时还会输出一大段统计分析，最后才问你要不要继续，需要人阅读完才能知道已经轮到自己。
第二，靠阅读意味着必须把注意力完全投入进去。当你开多个 AI 时，扫描动作本身也在消耗你的注意力。
更好的做法，是给 AI 会话增加一个“可解析信号”。让它每次完成一个回合、进入等待用户输入状态时，明确输出一行统一标记，比如===AI_WAIT===。这个标记不是给人看的，更多是给监控脚本看的。有了它，监控就可以从“通过阅读人话来判断”，变成“通过识别固定 token 来判断”。
有人可能会觉得，给 prompt 加这种标记很麻烦，而且模型不一定每次都遵守。这是真实情况。它确实不是完美协议，但比完全依赖人去读要可靠得多。这就是后面整套轮询方案的基础。
3. 一个能跑起来的最小方案：结束标记 + 轮询 + 通知
先不追求完美的工程化，你需要的是一个今晚就能试起来的路径。最小方案分三层：一是给 AI 会话约定输出标记，二是用 tmux 自身做静默提醒，三是用 capture-pane 拉取内容判断标记，再发桌面通知。
3.1 给提示词加一个“回合结束标记”
如果你在用命令行里的 AI 客户端，并且有自定义系统提示词或任务说明的能力，可以在提示词尾部加一条约定：
任务规则： - 当本轮任务已经结束并等待用户输入下一步指令时，请在新的一行输出一行标记：===AI_WAIT=== - 不要在正文中间使用这个标记，只有本轮真正结束时才输出它。这个做法的原理很简单：你不再主观判断“它是不是在等我”，而是让 AI 在下一次与你交互前，主动给你一个结构化的状态字。脚本只要检测===AI_WAIT===是否出现，就能知道这个窗口已经进入“等待输入”阶段。
它有几个明显的边界要接受：
- 模型不一定会每次都遵循，尤其是被复杂指令分散注意力时；
- 如果同一个会话里同时处理多条指令，可能会出现提前标记或漏标记；
- 模型输出这个标记后，如果网络中断或程序崩溃，需要兜底判断。
所以结束标记是“主要信号”，但不是唯一信号。超时和静默提醒仍然是必要的兜底。
3.2 先开启 monitor-silence，让“安静很久”的窗口浮出来
tmux 里有一组与“长时间无输出”相关的配置，虽然不如 activity 常用，但更适合 AI 会话场景。
# 对指定窗口开启静默提醒 tmux setw -t work:0 monitor-silence 30 # 开启后，视觉提醒会显示在状态栏 tmux set -g visual-silence onmonitor-silence 30表示：如果这个窗口在 30 秒内没有任何输出，状态栏会给一个提醒。它的价值在于提醒你“有个窗口已经安静了”，这对发现“它可能已经等你一会儿了”很有帮助。
代价是它不知道 AI 是在想你还是在等你。当模型进入长思考阶段，也会出现持续没有输出的情况，所以不建议把monitor-silence的阈值设得太低，否则你会在每个窗口之间频繁被告知“它不说话了”。它适合当辅助提醒，不适合当唯一答案。
先跑通这个配置，你至少能凭直觉从状态栏上看出哪个窗口安静异常。
3.3 从手工切窗，升级为一条捕获命令
tmux 提供了一个很关键的能力，capture-pane。它可以把某个 pane 当前屏幕的内容抓出来，以纯文本形式交给其他命令处理。
# 捕获 work 会话里 0 号窗口 0 号 pane 的最后 200 行 tmux capture-pane -p -t work:0.0 -S -200 | tail -n 30先手动跑一下，看看你能不能看到刚才约定的===AI_WAIT===标记。如果能，说明监控链路是通的。
接下来可以把这个命令和 grep 组合起来，做一轮最简单的检测：
tmux capture-pane -p -t work:0.0 -S -200 | grep -q "===AI_WAIT===" && echo "这个窗口在等你"这一步是整套方案中最核心的动作。之后不管是写循环、发通知，还是做状态面板，都是在这个捕获结果上做文章。
3.4 持续轮询并发送桌面通知，一个简化脚本示例
下面的 Python 脚本并不复杂，它做三件事：每隔几秒捕获指定 pane 的文本，检查是否出现结束标记，如果出现且之前没有通知过，就发一条桌面通知。
#!/usr/bin/env python3 import subprocess import time import sys HOSTS = sys.argv[1:] # 示例：work:0.0 work:1.0 work:2.0 states = {} def capture(host): out = subprocess.check_output( ["tmux", "capture-pane", "-p", "-S", "-200", "-t", host], text=True, ) return out def notify(host, message): print(f"[notify] {host}: {message}") subprocess.run(["notify-send", host, message]) while True: for host in HOSTS: body = capture(host) if "===AI_WAIT===" in body: if states.get(host) != "waiting": states[host] = "waiting" notify(host, "AI 会话在等你输入") else: states[host] = "running" time.sleep(5)命令示例：
python3 ~/bin/tmux_ai_watch.py work:0.0 work:1.0 work:2.0需要说明的是，notify-send是 Linux 桌面环境的常见命令，macOS 上需要换成osascript或terminal-notifier这类工具。如果你的环境没有桌面通知，也可以先把打印信息写到一个汇总文件，或者直接用 tmux 的display-message在状态栏里提示。逻辑是一样的。
# 捕获几个窗口是否出现等待标记 for host in work:0.0 work:1.0 work:2.0; do if tmux capture-pane -p -t "$host" -S -200 | grep -q "===AI_WAIT==="; then echo "$host 正在等你" fi done跑通之后，你会明显感到一个变化：你不再需要把每个窗口都看一遍，只要等通知过来，再切到对应窗口去看它接下来要你做什么。
4. 提升可靠性：历史回溯、状态去重和卡死兜底
最小方案能解决“大部分时候哪个窗口在等我”，但它离稳定好用还有几个坑要处理。如果跳过这节，很容易在实际使用中觉得方案还是靠不住。
4.1 capture-pane 默认只抓当前屏幕，回溯行数别省
tmux capture-pane默认捕获的是 pane 当前可见的那一屏内容。如果某段输出太长，让标记滚到了可视区域之外，你直接 grep 就会漏掉。
因此前面的命令里用了-S -200，表示回溯最近的 200 行。这个参数可以按实际情况加大，比如你要处理很长的输出，可以改成-S -1000。
实操建议是先用一个小命令验证一下，你捕获范围是否覆盖了标记可能出现的位置：
tmux capture-pane -p -t work:0.0 | tail -n 3 tmux capture-pane -p -t work:0.0 -S -200 | grep "===AI_WAIT==="如果第一条命令里已经能看到标记，说明还在屏幕内；否则就要检查回溯行数是否够大，以及 pane 目标坐标是否正确。
4.2 避免同一个状态反复通知
如果脚本每 5 秒检查一次，发现标记存在就通知一次，那个 AI 会话等待你 3 分钟，你就会被提醒几十次。所以需要给每个 pane 加一个状态去重逻辑。
可以理解为：状态从“running”翻转到“waiting”时通知一次，进入 waiting 后不再重复触发，直到下一次捕获不到标记，才把状态重置回 running。上面脚本里的states字典就是这个作用，实际使用时也可以改成状态文件，方便多个脚本共享。
这也改变了监控的语义。你收到通知的瞬间，代表的是一个状态翻转事件：这个会话刚刚进入等待输入。而如果它已经等了十分钟，你之前已经收到过通知，那就不需要再被轰炸。
4.3 加入卡死判断，但要留足“思考余量”
等待标记解决的是正常回合的结束，但有一种尴尬情况是：AI 既没有输出结束标记，也没有继续输出，只是长时间停在那里。它可能卡在 API 请求上，可能等某个子命令超时，也可能只是模型进入了一段很长的静默推理。
不同工具、不同模型，静默行为的差异很大。有些本地模型的思考阶段确实可能十几秒甚至更久没有任何输出，但这不叫“等你”，也不一定是“卡死”。所以卡死判断必须用宽阈值。
一个通用思路是维护每个 host 的“最后有输出时间”，如果超过 N 分钟没有输出，并且也没有出现等待标记，才判定为“可能卡死，需要人工检查”。
N 的取值要结合场景，不要盲目追求敏感。我一般会把“提醒可能卡死”的阈值放在 3 到 5 分钟以上，太长会漏报警，太短会把长思考误报为卡死。你可以先跑一周观察自己的工具典型静默时间，再据此调整阈值。
判断卡死的核心还是“有输出时间戳”。每次 capture 到的文本和上一次一样，说明界面没有变；如果连续多次都一样，同时进程还活着，那就要怀疑是不是真的卡住了。但要注意，如果窗口里恰好有动画光标或进度条，即使内容没变化，也可能产生活动事件，这种情况靠文本比对会更可靠。
5. 再往前走一步：与其不断盯窗口，不如把工作流改成任务闸门
到这里，我们已经能知道“哪个 AI 在等你”。但如果你的工作流本身设计得不好，解决这个问题的价值也会被抵消。比如同时开六个会话，即使通知到了，你依然会面临一堆待办判断：这个会话的结果要不要采纳，那个会话是不是改坏了代码，另一个会话的结果和当前任务有没有冲突。
这已经不是 tmux 能解决的问题，而是任务调度思路的问题。
5.1 先判断这些任务适不适合并行
多个 AI 会话并行，并不总是好事。最典型的反面场景是：三个 agent 同时改同一个仓库。
如果它们在同一个代码副本里写代码，很容易产生覆盖、冲突、上下文互相踩踏的问题。你收到的可能不是“哪个在等我”，而是“哪个把我的代码改成了一团乱麻”。真正适合在 tmux 里同时跑的，通常是彼此边界清晰的任务：
- 不同模块的文档分析；
- 互相独立的日志排查；
- 不同目录下的测试代码生成；
- 可以用独立分支或不同目录隔离的实验。
如果任务之间需要共享同一个工作目录，那更适合让它们串行处理，或者干脆用任务队列，而不是让多个 agent 同时扑上去。多开 AI 的计划，一定要在启动前先确认任务彼此独立。
5.2 给每个任务一个独立目录，让 AI 变成“结果生成器”
一个能明显降低多会话管理成本的做法是：为每个 AI 任务分配一个独立工作目录，并把任务的最终输出写到固定的结果文件。
work/ ├── job-01-log-analysis/ │ ├── prompt.md │ └── output.md ├── job-02-test-writing/ │ ├── prompt.md │ └── output.md └── job-03-doc-proofreading/每个窗口只负责进入对应目录，跑对应任务。结束标记出现后，你只需要切到那个窗口查看结果文件，决定是否接受、修改或重跑。如果结果符合预期，这个任务就可以关闭；如果不符合，把新的反馈追加到prompt.md再让 AI 继续。
这种组织方式的好处是，状态不只存在于 AI 会话的上下文里，也以文件的形式留到了磁盘上。即使 tmux 窗口全部误删，或者你隔了一天才回来检查，只要任务目录还在，你就能知道当时让它做了什么、目前输出到什么程度。这比靠一串会话记录更踏实。
5.3 真正要管理的不是窗口，而是“谁有权占用你的注意力”
当你把多个 AI 会话变成并行任务后，“哪个窗口在等你”这个问题会逐渐演变成“哪个结果值得我现在投入注意力”。
这背后有一个不太容易被意识到的规律：你同时能接收和处理的任务数不是无限的。如果你的工作流是让 5 个 AI 会话同时产出，并且都等着你逐个人工确认，那你就成了新的瓶颈。结果不是效率变高，而是你被 AI 的通知牵着走。
所以与其无限增加窗口，不如先稳住节奏。更多实践里的体面做法是：同一时间只保留一两个需要你交互的 AI 会话，另一批可以批量化、不需要频繁判断的任务，用脚本加队列去跑。
tmux 在这里的价值不是替你调度任务，而是提供一个不会丢失会话的稳定底座。真正的调度逻辑，仍然需要你用目录结构、输出标记和轮询脚本来搭建。
6. 排查链路、常见误判与适用边界
这套监控方案并不复杂，但它涉及 tmux、终端输出、桌面通知、提示词约定四个环节，任何一环出问题都会导致“明明在等你，却没提醒”或“根本没在等你，却不断提醒”。遇到问题不能靠猜，按链路一层层验证更高效。
6.1 按这个顺序排查：捕获、坐标、标记、通知
我自己的排查顺序通常是这样的：
- 先确认
tmux capture-pane -p -t <host>能正常输出内容； - 再确认
<host>写对了，用tmux list-panes查完整坐标； - 然后确认标记是否在捕获范围内，必要时加大
-S的行数； - 接着检查标记字符是否完全一致，注意大小写、空格、是否被终端转义影响；
- 最后再测试通知命令本身能不能弹出来，权限是否允许桌面通知。
如果脚本里用了grep -q，还要注意它在没有匹配时会返回非 0 退出码。如果 shell 开启了set -e，整个脚本很容易在半路退出，看起来就像“没有发现问题”，实际是脚本已经停了。
6.2 常见误判，对号入座
我在使用中踩过比较典型的几个坑，列出来供你检查：
monitor-activity在流式输出时会高频触发，不适合当作“等待我”的信号；monitor-silence能发现安静，但会把长思考和卡死混在一起，需要配合超时阈值；- 结束标记离窗口末尾很远时，只抓当前屏幕的 grep 会漏报；
- 模型有时不按提示词输出标记，需要靠静默提醒兜底；
- 多个 pane 都在等通知时，如果状态去重没做好，会变成连环通知轰炸；
- 捕获文本里如果混入大量转义序列，会干扰 grep，可以先肉眼观察一段输出再判断。
解决转义干扰的办法不是直接写复杂过滤器，而是先看输出是什么样。如果tmux capture-pane -p得到的文本已经可读，就不需要额外处理；如果看到了一大堆\x1b[开头的颜色码，说明你的终端工具在输出 ANSI 控制序列，可能需要先清洗，或者在客户端层面关闭彩色输出。
6.3 这个方法适合谁，不适合谁
如果工作流主要是终端里的 CLI agent，比如
