好想派 13 個 subagent 代聊
好想派出 13 個 subagent 代聊，節省人類這個 main agent 的 context window。
這句話是玩笑，但它其實把問題講完了。派 subagent 出去的當下，感覺像是把工作量分出去了；可是那 13 條線最後都要回到同一個地方收斂，而那個地方是我。
一個人操控 1000 個
一個人操控 1000 個 subagent；大家都來寫 HTML 當文檔取代 markdown 吧。
這是同一個荒謬往上乘。13 個已經收不完了，1000 個只是把「收不完」放大到看得見的規模。
面對面不說話
我需要一個社交 agentic AI 俱樂部：面對面不說話，用我手中的 Claude Code 跟對面的 Codex 吵架，互相審查代碼撕逼。門票要收。
這是第三種變形。前兩個是把 agent 往外派，這個是把人聚起來，然後讓 agent 在人與人之間互相攻擊。兩個人坐在一起，誰都不開口，桌上兩台機器吵得不可開交。門票我還是想收。
瓶頸不在模型
這三件事其實是同一件事的三種畫法。派 13 個、派 1000 個、把兩邊的 agent 放在同一張桌子上，共同的假設都是「agent 多一點就快一點」。但增加的每一個 agent，都會生出更多需要我裁決的東西。模型可以無限開下去，我的 context window 不行，我在單位時間內能做的判斷更不行。
這跟額度燒掉是不一樣的問題。額度那次是 subagent 遞迴繁殖，有些 subagent 都當阿公了，燒的是錢。這次燒的是我自己。
先去重去衝突，再派 agent team
真正有用的順序是這樣的：先提供材料，切分段落使用語意向量比對，來做去重跟衝突化解（我來裁決），然後再根據去重去衝突後的材料派 agent team（可以互相溝通的 agent）討論結構跟順序，最後再由我來定奪做微調。
重點在前半段。去重跟衝突化解發生在派工之前，這一步把要裁決的量壓下去了，後面的 agent team 才有意義。順序反過來——先派一堆 agent，再回頭處理它們各自帶回來的重複與矛盾——就是前面那三種幻想的下場。
裁決權還是在我手上，兩次：中間一次，最後一次。這件事沒有辦法外包。