【2026 最新】T3 Code Mac 記憶體排查：卡住怎麼辦？新手必學五步降並行技巧

你在 T3 Code 同時交辦幾項修改，每個 Agent 都顯示正在工作，Mac 卻開始轉彩球，連切換視窗都慢。這篇 T3 Code Mac 記憶體排查，要帶你找出：是對話本身、測試 Worker，還是它們一起把電腦擠滿？

本文寫給第一次接觸程序與資源監控的讀者。先用「活動監視器」看懂訊號，再照著唯讀指令追查來源；會調整測試的人，可接著限制 Worker。最後留下的成果，是一份能比較前後差異的紀錄，以及一個電腦仍能正常回應的工作排程。

2026 年 10 月 23 日的 GitHub 回報描述了一台 16 GB Mac 在多個 Agent 與測試、瀏覽器子程序交疊時失去回應。這是單次觀察，回報者也明說未做受控重現。本文於 10 月 24 日查閱原始回報與官方文件，提供排查方法，不把它當成所有 Mac 的共同故障。

先說結論：先減同時開工，再減每份工作的幫手

主機負擔＝同時開工的 Agent × 每個任務的子程序負擔＋其他應用程式。這是幫你找旋鈕的概念式，不是精確的記憶體計算公式。Agent 像工頭，Worker 像工頭叫來的助手；只數工頭，會漏掉真正占滿現場的人。

• 已經卡頓：先停新任務，讓重測試排隊，不要繼續加並行。
• 仍能操作：看記憶體壓力與 Swap 趨勢，再沿程序樹找啟動它的命令。
• 恢復後：從一個 Agent、一個測試 Worker 起步，每輪只改一個設定。

一、T3 Code Mac 記憶體排查：四個數字先分清

RAM 是電腦眼前的工作桌；虛擬位址空間像辦公室的座位編號。軟體可以先保留一大片編號，實際資料才由系統安排在記憶體或其他後備位置。Apple 的 虛擬記憶體原理區分了位址空間與實體記憶體。因此，看到很大的 Virtual Size，先別把它讀成真的占用了同等 RAM。

「實體記憶體」是裝在機器裡的容量；「已使用記憶體」是系統目前使用的量，還可細分應用程式、固定與壓縮記憶體。壓縮就像把桌上不常翻的文件裝進壓縮袋，仍需要空間。觀察單一程序時也會遇到 RSS（resident set size，常駐記憶體），它回答目前在實體記憶體中的部分，與虛擬大小用途不同。

打開「活動監視器 → 記憶體」。依 Apple 記憶體頁面，記憶體壓力綜合可用記憶體、交換速率等條件；Swap Used 則是啟動磁碟用於交換的空間。一起看壓力曲線、Swap 是否持續增加，以及操作是否變慢。不要只憑一張截圖的剩餘 RAM 或非零 Swap 判定事故。

同樣地，主程序的 RSS 變小也不是整台電腦恢復的證據。你還要看測試、編譯與瀏覽器，以及整機狀態；程序間有共用頁面，直接加總各程序的數字也可能重複計算。白話說，先判斷桌子是否塞住，再問誰帶來最多文件。

二、畫出程序樹：Agent 後面還有誰？

T3 Code 把編碼助手放進同一個工作介面，但你交辦「改完跑測試」，可能同時啟動供應商程序、Shell、Node 測試、TypeScript 檢查與無頭瀏覽器。無頭瀏覽器就是不開可見視窗、仍在執行網頁的瀏覽器。它們是否出現，要看實際命令，不是每次都會有。

在「活動監視器」選「顯示方式 → 所有程序，依階層顯示」（英文為 View → All Processes, Hierarchically），再展開相關程序。Apple 的程序檢視指南說明了這個模式。先找記憶體或 CPU 較高的程序，記下 PID（程序編號），再看父程序。

喜歡終端機的人，可先執行下面這條唯讀指令。它只列編號、父編號、RSS 與命令名稱，不會停止程序；RSS 的單位是 KiB。PPID 是父程序的 PID，像往上追主管的員工編號。

ps -axo pid,ppid,rss,comm

例如某一列的 PPID 是另一列的 PID，就把兩列連起來。若想只看某個已確認的程序，將下面的 12345 換成自己的 PID：

ps -p 12345 -o pid,ppid,rss,comm

這份清單是當下快照。父程序可能已退出，子程序可能被重新接手；共用供應商服務也可能同時服務多個對話。看到同一個父程序，不足以把全部消耗歸給某一個 Agent。回到對話中的命令紀錄核對時間與工作目錄；不確定的項目先標成「來源待查」。想繼續建立任務、工具與時間的對照，可讀 Agent 可觀測性教學。

三、T3 Code Mac 記憶體排查的五步操作

①「先清出走道」：停止增加新工作

整台機器已經變慢，還要再開任務測上限嗎？先凍結外層並行。暫停新交辦，記下哪些任務正在跑測試、建置或瀏覽器。能正常操作時，先在各任務的原介面中止重工作，並核對相關程序是否真的退出。可觀察成果是壓力停止惡化、視窗重新能回應，而非追求 Swap 立刻歸零。

②「先記帳」：保留現場與工作進度

怕重啟後忘記做到哪裡？先做復原筆記。存好檔案，記下專案分支、各工作目錄、已改與未驗收項目、最後一條命令。Git 專案可在自己的目錄執行 git status --short，只讀取變更清單；它不會替你提交或備份檔案。重要未提交內容另行保存，別在排查時混入清空工作目錄。

資源紀錄寫下：機型與 RAM、macOS、T3 桌面與伺服器版本、供應商 CLI 版本、Agent 數、測試命令、Worker 設定、壓力顏色、Swap 前後值、完成時間與失敗。截圖或紀錄要交給別人前，遮掉帳號、專案私密路徑與金鑰。

③「縮小測試班」：先把內層 Worker 降下來

只剩一個 Agent，卻還有很多測試程序？在實際測試命令限制 Worker。以下適用於專案已安裝相應工具、使用 pnpm 的情況；先在該工作目錄執行 pnpm exec vitest --version 與 pnpm exec vitest --help，確認本機版本接受旗標，再跑測試。

pnpm exec vitest run --maxWorkers=1 --no-file-parallelism

依 Vitest CLI 文件，maxWorkers 控制測試 Worker 上限，--no-file-parallelism 關閉測試檔之間的平行執行，run 則跑完本輪就結束。這裡把設定寫明，是為了建立容易比較的基線。檔案內的 concurrent 測試、測試自行啟動的服務與瀏覽器，要另外檢查。

若專案跑的是 Playwright，使用它自己的設定；不要把 Vitest 旗標塞過去。先用 pnpm exec playwright --version 與 pnpm exec playwright test --help 核對，再執行：

pnpm exec playwright test --workers=1

Playwright 平行執行文件提供單一 Worker 的用法；這控制的是該次測試的 Worker，不等於整台電腦只剩一個瀏覽器程序。若你使用別的測試框架，查它的官方 Worker 設定。驗收時保留同樣測試範圍與通過條件，再比較程序數及壓力。

④「排隊驗收」：把重工作集中到一條通道

多個 Agent 都需要跑完整測試，該先改哪裡？把重驗收串行排程。先只留一項重測試，其他 Agent 暫停建置與瀏覽器工作，等它完成才換下一項。限制是每個測試命令各自生效；若多個 Agent 同時各開一個 Worker，它們依然同時占用主機。

可在專案協作指示寫下：「各任務先完成修改與必要的局部檢查；全套測試、型別檢查與瀏覽器驗收排隊執行，同時只跑一項重工作；保留測試結果再交棒。」這是工作約定，仍要看命令紀錄確認大家遵守。測試隔離、資料庫與共用埠號的問題，也不會因記憶體壓力下降就自動解決。

⑤「一格一格加」：用完成結果決定並行數

你真正想知道的是「能順利完成幾件工作」，不是「能開幾個視窗」。從一個 Agent、一個 Worker 的小任務開始。選可丟棄的練習分支，用同一份測試、同樣背景應用程式與相同驗收條件跑一輪；穩定後才試兩個 Agent，Worker 先保持不變。這是一個保守起點，不是 16 GB Mac 的保證值。

每輪記錄開始與結束時間、通過與失敗、壓力和 Swap 的變化。若持續進入紅色壓力、操作明顯延遲、Swap 快速增加，或原先可完成的任務開始超時，就停止加量，回上一個穩定設定。這些是本流程的提前停手條件，別為湊齊測量把電腦推到失去回應。

四、完整走一遍：兩個 Agent 都說「測試中」

假設你正在修登入與搜尋，兩個 Agent 分別開了一套測試。以下是判斷示例，不是本站量得的效能結果：第一步先不再交辦，打開記憶體頁；第二步由高負載程序的 PID 往上追，核對兩邊的測試命令；第三步讓搜尋測試先停，登入測試改用單 Worker 跑相同範圍。

登入完成後，把通過結果存好，再讓搜尋接棒。若操作恢復順暢，而且兩件工作最後都通過，你找到的是一個可用的排程；還不能據此斷定是哪個軟體漏記憶體。若單任務仍持續增加，就保留同一工作與時間紀錄，分別檢查測試、編譯或瀏覽器的生命週期。

10 月 18 日的 原始實驗留言也把不同 Agent 並行數放在同一台 16 GB Mac 上比較，並回報高並行下完成狀況惡化。留言註明由 Agent 代筆，負載包含測試、型別檢查與瀏覽器；它支持「值得檢查交疊負載」這個方向，不能替你的專案決定安全上限。本文不搬用它的時間當速度承諾。

五、恢復與版本核對：重啟後還要驗收什麼？

如果目標程序失去回應，先確認已保存其他工作，再到活動監視器選取已確認身分的程序，先嘗試「結束」。Apple 結束程序說明區分正常結束與強制結束：後者會立即退出，開啟中的檔案可能遺失。只有正常中止失敗、且你理解影響範圍時才用強制結束；不要依名稱一口氣殺掉所有 node 或瀏覽器程序。

重新開啟 T3 Code 後，先核對自己的工作目錄與待辦，再檢查測試、開發伺服器及瀏覽器是否仍有殘留工作。若整機仍不穩，保存可保存的內容後使用 macOS 正常重新啟動。接著回到單任務基線，而不是立刻恢復原本的全部並行。

截至 2026 年 10 月 24 日查閱，官方穩定發布頁列出 v0.1.2，而 10 月 23 日回報使用桌面 0.1.0、診斷 CLI 0.1.2。這正是要分別記版本的原因。透過官方發布渠道核對更新後，仍用相同小任務重驗；版本較新本身，不是這次記憶體問題已修好的證據。

也別把 Linux 的 systemd 資源設定當成 Mac 操作步驟。作業系統隔離機制有別；對 Mac 讀者，本篇可直接採取的是工作排程、測試 Worker 與程序歸因。若要理解 Agent 為什麼會啟動工具與子任務，先補上 Agent Harness 的運作原理。

常見問題：八個直接答案

1. 虛擬記憶體數字巨大，就等於記憶體洩漏嗎？

不等於。先分清位址保留、常駐記憶體與整機壓力；洩漏需要同一工作隨時間反覆累積等更具體證據。

2. Swap 不是零，就該立刻重啟嗎？

不一定。連同壓力曲線、增長速度與操作反應一起判斷；保留前後紀錄，比追求某個單一數字有用。

3. 16 GB Mac 最多能開幾個 Agent？

要用自己的負載找穩定設定。改文字、全套測試與型別檢查差很多，背景應用程式也會改變可用空間；本篇不給通用上限。

4. 雲端模型為什麼還會讓本機卡？

因為模型回覆與工具執行可能在不同位置。即使推論在遠端，Agent 仍可能在你的 Mac 跑測試、建置與瀏覽器；先核對每條命令在哪執行。

5. maxWorkers=1 就限制整台電腦了嗎？

它限制的是該次 Vitest 的 Worker。其他測試、其他 Agent、檔案內並行及額外服務仍要各自管理。

6. 要先升 RAM，還是先減並行？

先做能回復的排程與 Worker 調整，找到實際瓶頸。若必要工作在單任務下就長期超出資源，再用紀錄評估換設備或搬走工作。

7. 關掉 T3 視窗，就代表全部測試結束了嗎？

要再查程序與任務紀錄。對話、供應商服務與命令可能有不同生命週期，尤其背景或脫離啟動者的工作；別把視窗消失當作驗收完成。

8. 更新後不卡，就可以宣布永久修好了嗎？

先說「這份設定與負載下恢復穩定」。保留版本、命令與結果，之後改並行、測試或背景環境時再重驗。

給新手的三個重點

• 先看整機壓力，再看哪條命令與哪些子程序一起工作。
• 外層 Agent 與內層 Worker 各有旋鈕，一次只改一層。
• 保住進度、保存證據、回到小任務基線，完成率比開工數更值得追。