一個 session 手上的工作太大，你把一半交給第二個 session。到這裡都很順，這也是大家想試多 agent 的原因。真正決定這樣安不安全的，是第二個 session 也得出同樣結論的那一刻：它也覺得工作太大，也想再分一半出去。
這時候能攔住它的，不該只是它指示裡的一句話。我們拿自己做的 Clawdline 當例子，它是本機常駐服務加網頁主控台，負責在本機的 Claude Code 和 Codex session 之間派工；不過這裡的道理，適用於任何能啟動 agent 的東西。
先說結論：限制要放在發放資源的那一端。Clawdline 的數量上限做到了，「只有一層」這條規則還沒有，下面會老實講。
第二次派工，通常沒有人同意過
會把工作交出去的 session，遲早會交出一份你沒同意過的工作。它用的其實是你的推理：這件事超過一個 context window，拆開來做。差別在於，執行這個推理的東西手上有你的工具和權限，卻看不到你的帳單。
接著是乘法。一件事變成五件，五件變成二十五件，每一件都是一個真的終端機分頁，跑著一個真的助理，花著真的 API 費用。等到一台 Mac 上開了六十個分頁，而你看不出是哪一個起的頭，這已經不是規模問題，是一場事故。所以這棵樹需要一個底。
在 prompt 裡寫「不要再開」，擋得住嗎？
把「不要再開新的 session」寫進 system prompt，這條規則只在模型還記得它的時候成立。讀指示的東西可以被說服、會被帶偏，也可能搞錯哪條規則適用。這不是在批評哪個模型，指示本來就是這樣。
我們自己的紀錄可以說明。有好幾個月，每個子任務的簡報都附了大約兩萬八千個字元、講「怎麼派工」的說明。兩百多次派工裡，沒有一個子任務真的派出任何東西，那段時間它們也派不出去。說明寫了這麼長，用上的次數是零。簡報適合用來解釋規則，不適合用來保管規則。
規則應該交給真正發放資源的那個東西保管：開終端機分頁的、拿著 API key 的、花預算的。在 Clawdline，這個東西就是常駐服務。
那 Clawdline 的常駐服務到底擋了什麼？
我們的規則很簡單：root 可以開子任務；子任務只做自己那件事，不再開別的。每份子任務的簡報都寫明「你是這棵樹的最底層，不能再派 Clawdline 任務；需要平行處理時，用助理自己的 subagent」。照著指示走的 session，不必撞牆才知道界線在哪。
不過我們得老實說，深度這一條目前只寫在簡報裡。2026 年 10 月 7 日我們對照 Clawdline 的原始碼確認過：派工進來時，常駐服務會確認發問的 root session 真的存在、真的在跑，也會檢查名額和頻率，但不會檢查這個 session 自己是不是別人的子任務。所以一個不照簡報走、拿自己的 session 當 root 送出派工的子任務，常駐服務不會因為它是子任務而拒絕它。
那為什麼還說擋得住失控？因為數量上限放在常駐服務裡。名額滿了、派得太快，常駐服務會在開分頁、登記任務之前直接拒絕，並告訴對方一分鐘後再試，完全不需要那個 session 配合。越界的子任務開出來的 session，也一樣算在整台機器的總數裡。
如果你也在用 agent 組裝什麼東西，可以拿這個問題檢查自己：碰到一個完全不理指示的 session，我的哪些限制還站得住？只有放在「發放 process、金鑰、分頁或預算」那一端的才站得住，其他的都只是建議。我們的數量上限屬於前者，深度限制目前還屬於後者。
沒有底線
底線就在第一層
最壞會開出幾個？安裝前就能先算
這棵樹一旦沒辦法無限長大，最壞的情況就不必靠判斷，加一加就知道。下面是我們派工的上限，你可以拿去跟自己現在跑的東西對照：
| 被限制的東西 | 數字 | 能不能調 |
|---|---|---|
| 一個 session 同時開著的子任務 | 五個 | 可以，一到十 |
| 一個子任務再開的子任務 | 照規則是零個 | 沒有設定能加；但目前只寫在簡報裡，常駐服務沒有另外檢查 |
| 整台 Mac 同時開著的被派出 session | 第一列的四倍，預設二十個，等於四個 root 的量 | 不能單獨調，跟著第一列一起變 |
| 任意十分鐘內的派工次數 | 等於整台機器的總數，預設二十次，最少十次 | 不能單獨調，跟著第一列一起變 |
| 一個任務最長跑多久 | 最多四小時，預設三十分鐘 | 可以，每個任務各自設定 |
除了第二列，其他四列都是常駐服務的程式在擋，超過就拒絕。所以就算有子任務不守第二列，你那台 Mac 上同時最多還是二十個被派出去的 session，十分鐘內最多二十次派工。在迴圈裡一直開 agent 的 shell script 沒有這種數字，客氣請 agent 自律的 prompt 也沒有。上限管不了會不會出錯，但管得了錯到多大。
想平行跑，該在哪一層拆？
只給一層，代價只有一個：session 不能做到一半才決定「這件事還要再找四個人」。那就把這個決定提早到最上面做。先拆寬，再談深：兩個子任務各做一半，比一個子任務再把一半轉手出去好。
因為開出四個 session 的 root，手上有切出這四份工作的計畫，也接得住它們交回來的東西。一個私下再開第五個的子任務，等於把規劃接了過去，結果最適合檢查成果的，反而變成下單的那個子任務。
一個任務內部想平行處理的工作，完全不受這條規則影響。那些就交給助理自己的 subagent，例如 Claude Code 的 Task tool、Codex 的 subagents。它們在發問的那個 session 裡面跑，不開分頁，也不佔深度。
| 助理自己的 subagent | 被派出去的 session | |
|---|---|---|
| 在哪裡跑 | 發問的那個 session 裡面 | 自己的終端機分頁 |
| 常駐服務有沒有登記 | 沒有 | 有：task id、任務憑證、逾時、結果檔 |
| 佔不佔子任務名額和深度 | 都不佔 | 兩個都佔 |
| 答案回到哪裡 | 直接回到對話裡 | 寫進一個檔案，要有人去等 |
| 你看得到、能打字進去、能取消嗎 | 不行 | 可以 |
這張表是分流規則，不是排名。這一輪就要拿到答案的，走左邊；有人可能想看、想接手的，走右邊，代價是佔一個名額。
這套限制管不到什麼？
它不會告訴你這件工作該不該拆，而這反而是比較常犯的錯。能拆成彼此不必溝通的幾塊，交給好幾個 session 會做得好；每一步都要等上一步的，拆開反而做得差，因為每次交接都會切斷一條本來該連著的線。
它限制的是 session，不是寫入。任務開始前會先宣告可能寫到哪些路徑，跟別人衝突的派工會在門口被拒絕。但那是門口的檢查，不是鎖：任務跑起來之後，沒有東西擋得住它寫到宣告以外的地方。這件事的代價，另一篇專門在講。
它也發現不了走錯方向的 session。一個守著每條上限的任務，照樣可以花半小時做錯的事。那要靠另一個機制：第三分鐘的那一句話，在工作開始之前就問，而不是做到一半才發現。
還有，關掉 root 會連帶犧牲底下的任務。明確關閉一個 root，會取消它底下的子任務；直接用手關掉分頁則不會，因為終端機暫時失去權限的時候，看起來也是這個樣子。2026 年 8 月 27 日，我們自己的一次關閉，在十四秒內帶走了四個已經收到簡報的任務。
回到開頭那個場景。第二個 session 也覺得工作太大、想再分一半時，照我們的規則，它不會再派工，而是把那一半交給自己的 subagent，或在結果裡寫明還沒做的部分，留給 root 決定要不要再開。就算它不照做，整台機器的總數也會替你擋下來。
工作在 session 之間還有另一種移動方式：不是把一件任務往下交，而是把一整條工作線交給一個從頭到尾都不在場的 session。那是交接帶走的東西。