最近在排查一個(gè)日志分析任務(wù)時(shí)我的終端又一次變成了一盤(pán)需要人肉維護(hù)的狀態(tài)散沙窗口 1 里有個(gè) AI 會(huì)話(huà)在幫我整理錯(cuò)誤碼窗口 2 里有一個(gè) agent 正在補(bǔ)測(cè)試用例窗口 3 還把之前跑完的一份方案推進(jìn)到一半。來(lái)回切了幾次以后我停在一個(gè)窗口前問(wèn)自己現(xiàn)在到底有幾個(gè)會(huì)話(huà)已經(jīng)停下來(lái)正在等我發(fā)下一句指令這個(gè)問(wèn)題聽(tīng)起來(lái)很小但真正遭遇過(guò)的人會(huì)知道它足以毀掉整個(gè)“多開(kāi) AI 并行工作”的體驗(yàn)。你原本是想讓幾個(gè)不同方向的活同時(shí)推進(jìn)結(jié)果大量精力被消耗在“誰(shuí)在等我”的調(diào)度判斷上。tmux 在這里表現(xiàn)得相當(dāng)克制窗口都活著會(huì)話(huà)都沒(méi)有丟進(jìn)程也都在可你看不到它們各自處在什么階段。這段經(jīng)歷讓我對(duì) tmux 的定位有了更具體的認(rèn)知tmux 擅長(zhǎng)的是讓終端會(huì)話(huà)持久、可恢復(fù)、可切換它不是任務(wù)調(diào)度器。當(dāng)你把一個(gè) AI 會(huì)話(huà)裝進(jìn)一個(gè)窗口時(shí)它只保證“這個(gè)終端不會(huì)因?yàn)殛P(guān)掉 SSH 而斷開(kāi)”并不會(huì)回答“這個(gè) AI 當(dāng)前是在等待輸入還是在持續(xù)處理還是已經(jīng)跑完退出了”。多開(kāi) AI 以后tmux 并不是真的不夠用它缺少的是任務(wù)級(jí)狀態(tài)可見(jiàn)性。1. “tmux 不夠用”的本質(zhì)窗口活了任務(wù)狀態(tài)是盲的這一節(jié)想先把問(wèn)題定義清楚。我們常說(shuō)的“tmux 不夠用”并不是說(shuō) tmux 本身有什么功能缺陷而是它作為“容器”和人的使用預(yù)期之間出現(xiàn)了錯(cuò)位。1.1 tmux 的天花板不在終端而在任務(wù)語(yǔ)義tmux 在設(shè)計(jì)上考慮的是終端會(huì)話(huà)的可靠性。它會(huì)幫你把任務(wù)留在后臺(tái)斷開(kāi)連接后不會(huì)主動(dòng)殺掉進(jìn)程重新進(jìn)入會(huì)話(huà)后還能看到原來(lái)的界面這對(duì)運(yùn)行長(zhǎng)任務(wù)、遠(yuǎn)程開(kāi)發(fā)、調(diào)試服務(wù)來(lái)說(shuō)很關(guān)鍵。它不會(huì)主動(dòng)建立某個(gè)“任務(wù)當(dāng)前是什么狀態(tài)”的概念。tmux 只知道當(dāng)前 pane 里有沒(méi)有新輸出、進(jìn)程有沒(méi)有退出它不理解窗口里運(yùn)行的是不是 AI不理解“這次輸出結(jié)束后的停頓”是等待用戶(hù)指令還是模型內(nèi)部思考更不理解“最后一行出現(xiàn)一閃一閃的輸入光標(biāo)”意味著這輪對(duì)話(huà)已經(jīng)回到了你手里。所以當(dāng)你把多個(gè) AI 會(huì)話(huà)放進(jìn)不同的 tmux 窗口后出現(xiàn)的信息結(jié)構(gòu)其實(shí)非常有限窗口有輸出說(shuō)明某個(gè)終端里有內(nèi)容在動(dòng)窗口沒(méi)有輸出說(shuō)明終端已經(jīng)安靜了一段時(shí)間進(jìn)程還在說(shuō)明對(duì)應(yīng)的命令還沒(méi)退出進(jìn)程退出說(shuō)明窗口可能已經(jīng)回到 shell。這些信息不足以回答“我現(xiàn)在該去處理哪個(gè)窗口”。它等于把一個(gè)任務(wù)調(diào)度問(wèn)題退化成了一堆終端事件讓人每次切窗口時(shí)都要靠“掃最后幾行輸出”來(lái)重建上下文。1.2 多會(huì)話(huà)的真正成本是切換后的恢復(fù)時(shí)間只開(kāi)一個(gè) AI 會(huì)話(huà)時(shí)tmux 通常不會(huì)帶來(lái)困擾。你切進(jìn)去看看輸出發(fā)個(gè)指令很順。但開(kāi)會(huì)話(huà)數(shù)量達(dá)到三五個(gè)時(shí)問(wèn)題就會(huì)從“工具有沒(méi)有這個(gè)能力”變成“人類(lèi)使用者能不能記住所有狀態(tài)”。每個(gè)窗口都代表一條獨(dú)立任務(wù)線(xiàn)。每切一次窗口你就要讀取最后幾行內(nèi)容確認(rèn)上一輪結(jié)論是什么、當(dāng)前是否卡住、上下文是否還記得前面的要求。這個(gè)過(guò)程看起來(lái)只要幾秒鐘遇到復(fù)雜的需要追溯的會(huì)話(huà)恢復(fù)成本會(huì)被放大。當(dāng)你有多個(gè)窗口同時(shí)在等你時(shí)你不僅要做任務(wù)還要做“任務(wù)狀態(tài)掃描”。這種多會(huì)話(huà)工作流真正瓶頸往往不是 tmux不是 AI 的輸出質(zhì)量而是人對(duì)多個(gè)并發(fā)任務(wù)的跟蹤能力。最直接的解法不是強(qiáng)迫自己變得更專(zhuān)注而是讓每個(gè)會(huì)話(huà)顯式暴露自己的狀態(tài)。1.3 monitor-activity 和 bell為什么都只能算輔助tmux 自帶幾種提醒機(jī)制。很多人的第一反應(yīng)會(huì)是用monitor-activity讓窗口有活動(dòng)時(shí)在狀態(tài)欄高亮。但在 AI 會(huì)話(huà)場(chǎng)景里它很可能成為反向干擾。原因在于 AI 的輸出往往是流式的。一個(gè)會(huì)持續(xù)打印日志的 agent會(huì)讓窗口在很長(zhǎng)一段時(shí)間里一直處于“活動(dòng)”狀態(tài)。你看到狀態(tài)欄某個(gè)窗口亮起并不代表它正在等你很可能只是它正在吐字。而當(dāng)你真正需要被提醒時(shí)——比如它已經(jīng)輸出完并在等待你的下一輪指令此時(shí)反而沒(méi)有任何活動(dòng)事件monitor-activity不會(huì)觸發(fā)。終端響鈴bell也不是一個(gè)可靠信號(hào)。響應(yīng)式 AI CLI 在等待用戶(hù)輸入時(shí)并不會(huì)像傳統(tǒng)編輯器那樣主動(dòng)響鈴。想要用 bell 做提醒前提是程序自己實(shí)現(xiàn)了這個(gè)動(dòng)作大部分終端 agent 并沒(méi)有。倒是有個(gè)很少被注意到的配置值得單獨(dú)說(shuō)monitor-silence。它不是在窗口有輸出時(shí)提醒而是在窗口超過(guò)指定秒數(shù)沒(méi)有輸出時(shí)給出提醒。這個(gè)語(yǔ)義和“某個(gè) AI 可能已經(jīng)等了一會(huì)兒”更接近實(shí)踐里更像一個(gè)兜底信號(hào)適合用來(lái)發(fā)現(xiàn)“這個(gè)窗口已經(jīng)安靜得可疑了”。2. 先別急著寫(xiě)監(jiān)控腳本要分清“等你”的四種形態(tài)在開(kāi)始寫(xiě)腳本之前更值得做的一件事是把“正在等你”拆細(xì)。不同形態(tài)的“等你”對(duì)應(yīng)的終端特征、提醒方式和處理動(dòng)作完全不一樣。如果不分清楚很容易寫(xiě)出一個(gè)“看起來(lái)很智能、實(shí)際上不斷誤報(bào)”的監(jiān)控。2.1 四種常見(jiàn)狀態(tài)不能用一個(gè)規(guī)則覆蓋從實(shí)際使用經(jīng)驗(yàn)看多個(gè) AI 會(huì)話(huà)分散在 tmux 里時(shí)會(huì)出現(xiàn)這幾種狀態(tài)狀態(tài)表面現(xiàn)象最容易誤判的點(diǎn)等待你輸入下一輪指令輸出已經(jīng)停止光標(biāo)停在 AI 的輸入框或提示符已經(jīng)出現(xiàn)這種狀態(tài)沒(méi)有任何輸出事件activity 不會(huì)觸發(fā)正在生成/思考中輸出可能暫時(shí)停止但進(jìn)程活著過(guò)一會(huì)兒又繼續(xù)輸出LLM 經(jīng)常有靜默思考的現(xiàn)象安靜不代表等你命令或工具卡死長(zhǎng)時(shí)間無(wú)輸出進(jìn)程一直掛著既不退出也不繼續(xù)和“思考中”難以區(qū)分需要超時(shí)閾值兜底會(huì)話(huà)已退出或已崩潰pane 內(nèi)容停在末尾進(jìn)程不存在可能回到了 shell如果最后沒(méi)有明顯的退出信息容易以為是還在運(yùn)行這些狀態(tài)如果混在一起處理監(jiān)控邏輯就會(huì)失真。比如你把“窗口安靜超過(guò) 30 秒”當(dāng)成“它在等你”那遇到一個(gè)正在做復(fù)雜推理的模型每隔十幾秒才輸出一小段或者干脆靜默一分鐘再開(kāi)始說(shuō)話(huà)就會(huì)不斷誤報(bào)。一個(gè)可靠的方案應(yīng)該對(duì)不同狀態(tài)采用不同信號(hào)。比如“等待輸入”應(yīng)該靠 AI 輸出中是否出現(xiàn)約定標(biāo)記來(lái)判斷“卡死”應(yīng)該靠較長(zhǎng)時(shí)間沒(méi)有輸出變化來(lái)判斷“會(huì)話(huà)退出”則可以通過(guò)進(jìn)程狀態(tài)判斷。先分好類(lèi)后面寫(xiě)代碼才不容易糊涂。2.2 肉眼掃描和可解析信號(hào)差距在哪里你手動(dòng)切窗口時(shí)其實(shí)是靠閱讀最后幾行文本再結(jié)合自己對(duì)上下文的記憶才能判斷當(dāng)前是不是“該你說(shuō)話(huà)”。這種判斷方式有兩個(gè)問(wèn)題第一不是所有輸出都能一望而知。有些 CLI 工具即使結(jié)束了任務(wù)也不會(huì)輸出一個(gè)明確的“等待指令”提示只是光標(biāo)在閃有時(shí)還會(huì)輸出一大段統(tǒng)計(jì)分析最后才問(wèn)你要不要繼續(xù)需要人閱讀完才能知道已經(jīng)輪到自己。第二靠閱讀意味著必須把注意力完全投入進(jìn)去。當(dāng)你開(kāi)多個(gè) AI 時(shí)掃描動(dòng)作本身也在消耗你的注意力。更好的做法是給 AI 會(huì)話(huà)增加一個(gè)“可解析信號(hào)”。讓它每次完成一個(gè)回合、進(jìn)入等待用戶(hù)輸入狀態(tài)時(shí)明確輸出一行統(tǒng)一標(biāo)記比如AI_WAIT。這個(gè)標(biāo)記不是給人看的更多是給監(jiān)控腳本看的。有了它監(jiān)控就可以從“通過(guò)閱讀人話(huà)來(lái)判斷”變成“通過(guò)識(shí)別固定 token 來(lái)判斷”。有人可能會(huì)覺(jué)得給 prompt 加這種標(biāo)記很麻煩而且模型不一定每次都遵守。這是真實(shí)情況。它確實(shí)不是完美協(xié)議但比完全依賴(lài)人去讀要可靠得多。這就是后面整套輪詢(xún)方案的基礎(chǔ)。3. 一個(gè)能跑起來(lái)的最小方案結(jié)束標(biāo)記 輪詢(xún) 通知先不追求完美的工程化你需要的是一個(gè)今晚就能試起來(lái)的路徑。最小方案分三層一是給 AI 會(huì)話(huà)約定輸出標(biāo)記二是用 tmux 自身做靜默提醒三是用 capture-pane 拉取內(nèi)容判斷標(biāo)記再發(fā)桌面通知。3.1 給提示詞加一個(gè)“回合結(jié)束標(biāo)記”如果你在用命令行里的 AI 客戶(hù)端并且有自定義系統(tǒng)提示詞或任務(wù)說(shuō)明的能力可以在提示詞尾部加一條約定任務(wù)規(guī)則 - 當(dāng)本輪任務(wù)已經(jīng)結(jié)束并等待用戶(hù)輸入下一步指令時(shí)請(qǐng)?jiān)谛碌囊恍休敵鲆恍袠?biāo)記AI_WAIT - 不要在正文中間使用這個(gè)標(biāo)記只有本輪真正結(jié)束時(shí)才輸出它。這個(gè)做法的原理很簡(jiǎn)單你不再主觀判斷“它是不是在等我”而是讓 AI 在下一次與你交互前主動(dòng)給你一個(gè)結(jié)構(gòu)化的狀態(tài)字。腳本只要檢測(cè)AI_WAIT是否出現(xiàn)就能知道這個(gè)窗口已經(jīng)進(jìn)入“等待輸入”階段。它有幾個(gè)明顯的邊界要接受模型不一定會(huì)每次都遵循尤其是被復(fù)雜指令分散注意力時(shí)如果同一個(gè)會(huì)話(huà)里同時(shí)處理多條指令可能會(huì)出現(xiàn)提前標(biāo)記或漏標(biāo)記模型輸出這個(gè)標(biāo)記后如果網(wǎng)絡(luò)中斷或程序崩潰需要兜底判斷。所以結(jié)束標(biāo)記是“主要信號(hào)”但不是唯一信號(hào)。超時(shí)和靜默提醒仍然是必要的兜底。3.2 先開(kāi)啟 monitor-silence讓“安靜很久”的窗口浮出來(lái)tmux 里有一組與“長(zhǎng)時(shí)間無(wú)輸出”相關(guān)的配置雖然不如 activity 常用但更適合 AI 會(huì)話(huà)場(chǎng)景。# 對(duì)指定窗口開(kāi)啟靜默提醒 tmux setw -t work:0 monitor-silence 30 # 開(kāi)啟后視覺(jué)提醒會(huì)顯示在狀態(tài)欄 tmux set -g visual-silence onmonitor-silence 30表示如果這個(gè)窗口在 30 秒內(nèi)沒(méi)有任何輸出狀態(tài)欄會(huì)給一個(gè)提醒。它的價(jià)值在于提醒你“有個(gè)窗口已經(jīng)安靜了”這對(duì)發(fā)現(xiàn)“它可能已經(jīng)等你一會(huì)兒了”很有幫助。代價(jià)是它不知道 AI 是在想你還是在等你。當(dāng)模型進(jìn)入長(zhǎng)思考階段也會(huì)出現(xiàn)持續(xù)沒(méi)有輸出的情況所以不建議把monitor-silence的閾值設(shè)得太低否則你會(huì)在每個(gè)窗口之間頻繁被告知“它不說(shuō)話(huà)了”。它適合當(dāng)輔助提醒不適合當(dāng)唯一答案。先跑通這個(gè)配置你至少能憑直覺(jué)從狀態(tài)欄上看出哪個(gè)窗口安靜異常。3.3 從手工切窗升級(jí)為一條捕獲命令tmux 提供了一個(gè)很關(guān)鍵的能力capture-pane。它可以把某個(gè) pane 當(dāng)前屏幕的內(nèi)容抓出來(lái)以純文本形式交給其他命令處理。# 捕獲 work 會(huì)話(huà)里 0 號(hào)窗口 0 號(hào) pane 的最后 200 行 tmux capture-pane -p -t work:0.0 -S -200 | tail -n 30先手動(dòng)跑一下看看你能不能看到剛才約定的AI_WAIT標(biāo)記。如果能說(shuō)明監(jiān)控鏈路是通的。接下來(lái)可以把這個(gè)命令和 grep 組合起來(lái)做一輪最簡(jiǎn)單的檢測(cè)tmux capture-pane -p -t work:0.0 -S -200 | grep -q AI_WAIT echo 這個(gè)窗口在等你這一步是整套方案中最核心的動(dòng)作。之后不管是寫(xiě)循環(huán)、發(fā)通知還是做狀態(tài)面板都是在這個(gè)捕獲結(jié)果上做文章。3.4 持續(xù)輪詢(xún)并發(fā)送桌面通知一個(gè)簡(jiǎn)化腳本示例下面的 Python 腳本并不復(fù)雜它做三件事每隔幾秒捕獲指定 pane 的文本檢查是否出現(xiàn)結(jié)束標(biāo)記如果出現(xiàn)且之前沒(méi)有通知過(guò)就發(fā)一條桌面通知。#!/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], textTrue, ) 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 會(huì)話(huà)在等你輸入) else: states[host] running time.sleep(5)命令示例python3 ~/bin/tmux_ai_watch.py work:0.0 work:1.0 work:2.0需要說(shuō)明的是notify-send是 Linux 桌面環(huán)境的常見(jiàn)命令macOS 上需要換成osascript或terminal-notifier這類(lèi)工具。如果你的環(huán)境沒(méi)有桌面通知也可以先把打印信息寫(xiě)到一個(gè)匯總文件或者直接用 tmux 的display-message在狀態(tài)欄里提示。邏輯是一樣的。# 捕獲幾個(gè)窗口是否出現(xiàn)等待標(biāo)記 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跑通之后你會(huì)明顯感到一個(gè)變化你不再需要把每個(gè)窗口都看一遍只要等通知過(guò)來(lái)再切到對(duì)應(yīng)窗口去看它接下來(lái)要你做什么。4. 提升可靠性歷史回溯、狀態(tài)去重和卡死兜底最小方案能解決“大部分時(shí)候哪個(gè)窗口在等我”但它離穩(wěn)定好用還有幾個(gè)坑要處理。如果跳過(guò)這節(jié)很容易在實(shí)際使用中覺(jué)得方案還是靠不住。4.1 capture-pane 默認(rèn)只抓當(dāng)前屏幕回溯行數(shù)別省tmux capture-pane默認(rèn)捕獲的是 pane 當(dāng)前可見(jiàn)的那一屏內(nèi)容。如果某段輸出太長(zhǎng)讓標(biāo)記滾到了可視區(qū)域之外你直接 grep 就會(huì)漏掉。因此前面的命令里用了-S -200表示回溯最近的 200 行。這個(gè)參數(shù)可以按實(shí)際情況加大比如你要處理很長(zhǎng)的輸出可以改成-S -1000。實(shí)操建議是先用一個(gè)小命令驗(yàn)證一下你捕獲范圍是否覆蓋了標(biāo)記可能出現(xiàn)的位置tmux capture-pane -p -t work:0.0 | tail -n 3 tmux capture-pane -p -t work:0.0 -S -200 | grep AI_WAIT如果第一條命令里已經(jīng)能看到標(biāo)記說(shuō)明還在屏幕內(nèi)否則就要檢查回溯行數(shù)是否夠大以及 pane 目標(biāo)坐標(biāo)是否正確。4.2 避免同一個(gè)狀態(tài)反復(fù)通知如果腳本每 5 秒檢查一次發(fā)現(xiàn)標(biāo)記存在就通知一次那個(gè) AI 會(huì)話(huà)等待你 3 分鐘你就會(huì)被提醒幾十次。所以需要給每個(gè) pane 加一個(gè)狀態(tài)去重邏輯?？梢岳斫鉃闋顟B(tài)從“running”翻轉(zhuǎn)到“waiting”時(shí)通知一次進(jìn)入 waiting 后不再重復(fù)觸發(fā)直到下一次捕獲不到標(biāo)記才把狀態(tài)重置回 running。上面腳本里的states字典就是這個(gè)作用實(shí)際使用時(shí)也可以改成狀態(tài)文件方便多個(gè)腳本共享。這也改變了監(jiān)控的語(yǔ)義。你收到通知的瞬間代表的是一個(gè)狀態(tài)翻轉(zhuǎn)事件這個(gè)會(huì)話(huà)剛剛進(jìn)入等待輸入。而如果它已經(jīng)等了十分鐘你之前已經(jīng)收到過(guò)通知那就不需要再被轟炸。4.3 加入卡死判斷但要留足“思考余量”等待標(biāo)記解決的是正?；睾系慕Y(jié)束但有一種尷尬情況是AI 既沒(méi)有輸出結(jié)束標(biāo)記也沒(méi)有繼續(xù)輸出只是長(zhǎng)時(shí)間停在那里。它可能卡在 API 請(qǐng)求上可能等某個(gè)子命令超時(shí)也可能只是模型進(jìn)入了一段很長(zhǎng)的靜默推理。不同工具、不同模型靜默行為的差異很大。有些本地模型的思考階段確實(shí)可能十幾秒甚至更久沒(méi)有任何輸出但這不叫“等你”也不一定是“卡死”。所以卡死判斷必須用寬閾值。一個(gè)通用思路是維護(hù)每個(gè) host 的“最后有輸出時(shí)間”如果超過(guò) N 分鐘沒(méi)有輸出并且也沒(méi)有出現(xiàn)等待標(biāo)記才判定為“可能卡死需要人工檢查”。N 的取值要結(jié)合場(chǎng)景不要盲目追求敏感。我一般會(huì)把“提醒可能卡死”的閾值放在 3 到 5 分鐘以上太長(zhǎng)會(huì)漏報(bào)警太短會(huì)把長(zhǎng)思考誤報(bào)為卡死。你可以先跑一周觀察自己的工具典型靜默時(shí)間再據(jù)此調(diào)整閾值。判斷卡死的核心還是“有輸出時(shí)間戳”。每次 capture 到的文本和上一次一樣說(shuō)明界面沒(méi)有變?nèi)绻B續(xù)多次都一樣同時(shí)進(jìn)程還活著那就要懷疑是不是真的卡住了。但要注意如果窗口里恰好有動(dòng)畫(huà)光標(biāo)或進(jìn)度條即使內(nèi)容沒(méi)變化也可能產(chǎn)生活動(dòng)事件這種情況靠文本比對(duì)會(huì)更可靠。5. 再往前走一步與其不斷盯窗口不如把工作流改成任務(wù)閘門(mén)到這里我們已經(jīng)能知道“哪個(gè) AI 在等你”。但如果你的工作流本身設(shè)計(jì)得不好解決這個(gè)問(wèn)題的價(jià)值也會(huì)被抵消。比如同時(shí)開(kāi)六個(gè)會(huì)話(huà)即使通知到了你依然會(huì)面臨一堆待辦判斷這個(gè)會(huì)話(huà)的結(jié)果要不要采納那個(gè)會(huì)話(huà)是不是改壞了代碼另一個(gè)會(huì)話(huà)的結(jié)果和當(dāng)前任務(wù)有沒(méi)有沖突。這已經(jīng)不是 tmux 能解決的問(wèn)題而是任務(wù)調(diào)度思路的問(wèn)題。5.1 先判斷這些任務(wù)適不適合并行多個(gè) AI 會(huì)話(huà)并行并不總是好事。最典型的反面場(chǎng)景是三個(gè) agent 同時(shí)改同一個(gè)倉(cāng)庫(kù)。如果它們?cè)谕粋€(gè)代碼副本里寫(xiě)代碼很容易產(chǎn)生覆蓋、沖突、上下文互相踩踏的問(wèn)題。你收到的可能不是“哪個(gè)在等我”而是“哪個(gè)把我的代碼改成了一團(tuán)亂麻”。真正適合在 tmux 里同時(shí)跑的通常是彼此邊界清晰的任務(wù)不同模塊的文檔分析互相獨(dú)立的日志排查不同目錄下的測(cè)試代碼生成可以用獨(dú)立分支或不同目錄隔離的實(shí)驗(yàn)。如果任務(wù)之間需要共享同一個(gè)工作目錄那更適合讓它們串行處理或者干脆用任務(wù)隊(duì)列而不是讓多個(gè) agent 同時(shí)撲上去。多開(kāi) AI 的計(jì)劃一定要在啟動(dòng)前先確認(rèn)任務(wù)彼此獨(dú)立。5.2 給每個(gè)任務(wù)一個(gè)獨(dú)立目錄讓 AI 變成“結(jié)果生成器”一個(gè)能明顯降低多會(huì)話(huà)管理成本的做法是為每個(gè) AI 任務(wù)分配一個(gè)獨(dú)立工作目錄并把任務(wù)的最終輸出寫(xiě)到固定的結(jié)果文件。work/ ├── job-01-log-analysis/ │ ├── prompt.md │ └── output.md ├── job-02-test-writing/ │ ├── prompt.md │ └── output.md └── job-03-doc-proofreading/每個(gè)窗口只負(fù)責(zé)進(jìn)入對(duì)應(yīng)目錄跑對(duì)應(yīng)任務(wù)。結(jié)束標(biāo)記出現(xiàn)后你只需要切到那個(gè)窗口查看結(jié)果文件決定是否接受、修改或重跑。如果結(jié)果符合預(yù)期這個(gè)任務(wù)就可以關(guān)閉如果不符合把新的反饋?zhàn)芳拥絧rompt.md再讓 AI 繼續(xù)。這種組織方式的好處是狀態(tài)不只存在于 AI 會(huì)話(huà)的上下文里也以文件的形式留到了磁盤(pán)上。即使 tmux 窗口全部誤刪或者你隔了一天才回來(lái)檢查只要任務(wù)目錄還在你就能知道當(dāng)時(shí)讓它做了什么、目前輸出到什么程度。這比靠一串會(huì)話(huà)記錄更踏實(shí)。5.3 真正要管理的不是窗口而是“誰(shuí)有權(quán)占用你的注意力”當(dāng)你把多個(gè) AI 會(huì)話(huà)變成并行任務(wù)后“哪個(gè)窗口在等你”這個(gè)問(wèn)題會(huì)逐漸演變成“哪個(gè)結(jié)果值得我現(xiàn)在投入注意力”。這背后有一個(gè)不太容易被意識(shí)到的規(guī)律你同時(shí)能接收和處理的任務(wù)數(shù)不是無(wú)限的。如果你的工作流是讓 5 個(gè) AI 會(huì)話(huà)同時(shí)產(chǎn)出并且都等著你逐個(gè)人工確認(rèn)那你就成了新的瓶頸。結(jié)果不是效率變高而是你被 AI 的通知牽著走。所以與其無(wú)限增加窗口不如先穩(wěn)住節(jié)奏。更多實(shí)踐里的體面做法是同一時(shí)間只保留一兩個(gè)需要你交互的 AI 會(huì)話(huà)另一批可以批量化、不需要頻繁判斷的任務(wù)用腳本加隊(duì)列去跑。tmux 在這里的價(jià)值不是替你調(diào)度任務(wù)而是提供一個(gè)不會(huì)丟失會(huì)話(huà)的穩(wěn)定底座。真正的調(diào)度邏輯仍然需要你用目錄結(jié)構(gòu)、輸出標(biāo)記和輪詢(xún)腳本來(lái)搭建。6. 排查鏈路、常見(jiàn)誤判與適用邊界這套監(jiān)控方案并不復(fù)雜但它涉及 tmux、終端輸出、桌面通知、提示詞約定四個(gè)環(huán)節(jié)任何一環(huán)出問(wèn)題都會(huì)導(dǎo)致“明明在等你卻沒(méi)提醒”或“根本沒(méi)在等你卻不斷提醒”。遇到問(wèn)題不能靠猜按鏈路一層層驗(yàn)證更高效。6.1 按這個(gè)順序排查捕獲、坐標(biāo)、標(biāo)記、通知我自己的排查順序通常是這樣的先確認(rèn)tmux capture-pane -p -t host能正常輸出內(nèi)容再確認(rèn)host寫(xiě)對(duì)了用tmux list-panes查完整坐標(biāo)然后確認(rèn)標(biāo)記是否在捕獲范圍內(nèi)必要時(shí)加大-S的行數(shù)接著檢查標(biāo)記字符是否完全一致注意大小寫(xiě)、空格、是否被終端轉(zhuǎn)義影響最后再測(cè)試通知命令本身能不能彈出來(lái)權(quán)限是否允許桌面通知。如果腳本里用了grep -q還要注意它在沒(méi)有匹配時(shí)會(huì)返回非 0 退出碼。如果 shell 開(kāi)啟了set -e整個(gè)腳本很容易在半路退出看起來(lái)就像“沒(méi)有發(fā)現(xiàn)問(wèn)題”實(shí)際是腳本已經(jīng)停了。6.2 常見(jiàn)誤判對(duì)號(hào)入座我在使用中踩過(guò)比較典型的幾個(gè)坑列出來(lái)供你檢查monitor-activity在流式輸出時(shí)會(huì)高頻觸發(fā)不適合當(dāng)作“等待我”的信號(hào)monitor-silence能發(fā)現(xiàn)安靜但會(huì)把長(zhǎng)思考和卡死混在一起需要配合超時(shí)閾值結(jié)束標(biāo)記離窗口末尾很遠(yuǎn)時(shí)只抓當(dāng)前屏幕的 grep 會(huì)漏報(bào)模型有時(shí)不按提示詞輸出標(biāo)記需要靠靜默提醒兜底多個(gè) pane 都在等通知時(shí)如果狀態(tài)去重沒(méi)做好會(huì)變成連環(huán)通知轟炸捕獲文本里如果混入大量轉(zhuǎn)義序列會(huì)干擾 grep可以先肉眼觀察一段輸出再判斷。解決轉(zhuǎn)義干擾的辦法不是直接寫(xiě)復(fù)雜過(guò)濾器而是先看輸出是什么樣。如果tmux capture-pane -p得到的文本已經(jīng)可讀就不需要額外處理如果看到了一大堆\x1b[開(kāi)頭的顏色碼說(shuō)明你的終端工具在輸出 ANSI 控制序列可能需要先清洗或者在客戶(hù)端層面關(guān)閉彩色輸出。6.3 這個(gè)方法適合誰(shuí)不適合誰(shuí)如果工作流主要是終端里的 CLI agent比如