6.8 KiB

Raw Blame History

AI 使用體驗

這份文件記錄 LazyBoy 怎麼讓「AI 用電腦」這件事變得跟人一樣順，以及背後的取捨。三個主題其實是同一件事：系統如果把 AI 使用電腦當成一系列無狀態的請求，AI 就必須每輪重新交代自己在哪裡、在做什麼，界面也只能用輪詢去猜現在發生了什麼。

主題	一句話	細節
任務長度	沒有輪數額度，只有偵測鬼打牆的保險絲	輪次政策
容器內終端機	一台活的 tmux，人和 AI 看同一個 shell	終端機
聊天即時性	事件推送，輪詢只是兜底	本文件下面

輪數不是額度，是偵錯工具

以前一個 run 固定 40 輪，等於假設所有任務一樣長：洗資料這種事情做不完，但也不會因此變成錯誤，只是被腰斬。現在的正常結局是把事情做完（模型提出驗證，或明白說它卡在哪裡），會被停下來的只有鬼打牆：同一個會改變狀態的動作連做六次、同一個錯誤連錯八次、連續十四個動作全部失敗。觀察、等待、輪詢不算重複動作，所以等一個長 build、等下載、輪詢佇列都不會被打斷。

設計上要記住兩件事：

提示（「你已經做同一件事三次了」）永远不會停掉任務，只有重複到像故障才會暫停，暫停也是停在現況、按「繼續」接下去，不重來。
保險絲（budget_exhausted）代表迴圈失控，是故障不是成績；它照樣可以續跑，但值得去看執行記錄。

純聊天仍然是 4 輪上限：那是避免模型在閒聊裡燒額度，跟任務長度無關。

終端機是一台活的 tmux

shell 工具以前每條命令都是一次性的 bash -lc：cd 留不住、export 留不住、背景起的服務跟著一起死，模型每次都要重新走回工作目錄，遇到互動式程式就整個卡死。現在每個終端機名字對應容器內一個 tmux session（lazyboy-main），AI 用的就是人在桌面上會用的那個 shell。

有了持久終端機，模型才做得順這些事：

python -m venv .venv && source .venv/bin/activate 之後，下一條命令還在同一個環境裡。
npm run dev & 之後可以繼續做別的，回來用 log_lines 讀同一個終端機的輸出。
ssh、gdb、psql、Python REPL 這類會問你話的程式，用 keys 回它，而不是直接超時。
按錯 Ctrl-C 只會中斷那台終端機裡正在跑的東西，不會把整個工作環境帶走。

完成是怎麼判定的。 API 進到容器是一次性的 exec（argv 進、stdout 出，沒有串流），所以「跑完了沒」不是看 exec 有沒有結束，而是看終端機裡印了什麼：每次呼叫會在 shell 內 source 一個檔名隨機的腳本，腳本用 trap ... EXIT 印出 LB_END <nonce> rc=<code>；還看到 LB_READY 代表上一件事已經被中斷、終端機是可用的。標記只在行首比對——命令本身會被 shell echo 一次，那行也帶有標記，比錯就會以為已經跑完了。

死了會自己站起來。 exit、exec bash、被 kill 掉都會讓 pane 不見；這時候終端機重新 respawn，並把剛才的工作目錄與 export 過的環境變數還原回去，模型不需要重新交代。

人可以隨時看同一台終端機，或直接接手（指令見容器內終端機）。這不隻是好看：AI 卡在同一個地方時，你看到的就是它看到的那個 shell。

行為用 python3 tests/shell-session.test.py 驗證（10 個案例，含 exit code 還原、自我重生、中斷後可續用）。

聊天是推送，不是輪詢

事件早就寫進 events 表，也有 SSE 端點，但兩端都在猜：伺服器每 750 ms 掃一次資料庫，瀏覽器每 2 秒重刷一次全部狀態（訊息、電腦狀態、螢幕、技能、心跳一起打）。所以一個回覆最快也要兩輪輪詢才被看見。

現在的管線：

寫事件的事實不變——events 表仍然是順序與重放的依據（游標是 threads.next_event_seq，斷線重連用 Last-Event-ID 從資料庫重放，不會漏也不會重複）。
提交之後往進程內的 wake channel 敲一下（WakeBus）。SSE 端點不再固定間隔輪詢，而是等敲；敲不到時（多副本、讀者落後）以 5 秒兜底輪詢補上。
瀏覽器用 EventSource 訂閱 /api/sessions/{id}/events，事件在 120 ms 的窗口裡合流，一回合變動只刷新一次。

實測（本機 loopback、丟棄式資料庫、同一台機器）：

事件	以前	現在
自己發的訊息出現在畫面	最多 2 秒	送出去後約 25 ms
「思考中」指示出現	最多 2 秒	約 32 ms（worker 也被敲醒，不再等 200 ms 定時器）
模型回覆出現	寫入後最多 2.75 秒	寫入後約 25 ms（模型本身要幾秒是另一回事）

順帶把浪費掉的工作拿掉：分頁藏在後面時不再刷新（回到前景立刻補一次），心跳從 2 秒改成 60 秒——一次心跳買的是 15 分鐘控制租約、避免 10 分鐘閒置暫停，60 秒是很寬的餘裕。

壞了會怎樣。 SSE 被 proxy 擋住或斷線，瀏覽器察覺後自動回到 2 秒輪詢，等於退回以前的行為，不會變成不更新；伺服器端事件順序仍然只以資料庫為準，wake 不見得可靠，只是慢。

自己量一次：

curl -N -b cookies.txt http://127.0.0.1:3101/api/sessions/<id>/events
# 另開一個終端機送訊息，看事件幾毫秒後出現在這條串流裡

已知取捨

模型回覆還是「整個完成」才出現，沒有串流 token。思考中的狀態有顯示，但要像 ChatGPT 那樣逐字冒出，需要把 completion 換成串流並處理中斷/接續，這是下一件事。
電腦狀態（執行中／暫停、誰在控制）沒有自己的事件，只能靠兜底輪詢更新，LIVE_POLL_MS 目前是 4 秒；桌面畫面本身是即時串流，只有狀態列會慢幾秒。要真正事件化得把 computers 的狀態變更也寫進 events（狀態是 bot 層、事件是執行緒層，要先決定寫到哪條執行緒）。
滑鼠停在頭像上看到的執行記錄泡泡，開啟時仍是輪詢（它只在滑鼠停留時開啟，量很小）。
wake channel 是單進程的。多副本部署時，其他副本靠 5 秒安全輪詢追上；真要横向擴充應改用 Postgres LISTEN/NOTIFY。
持久終端機需要桌面映像檔裡的 tmux；舊映像檔會退回一次性 shell，docker compose build computer 之後就有了。
容器執行檔仍以 uid 1000、限制環境變數的方式進入容器，持久化的是 shell 狀態，不是憑證。

6.8 KiB Raw Blame History Unescape Escape