派工到底省了什麼——三臂實驗現況報告

一、這個實驗在問什麼（白話版）

派工兵這件事，直覺上是「找人幫忙比較省」。實際上不一定。

主 session 自己動手做完一件事，吃掉的是一份 Claude 額度。改成寫一張施工卡、 把工作發包給子代理，額度會變成幾份：施工卡要寫、工兵的回報要讀、 成果要驗收，而工兵自己也在燒同一本帳。所以「發包」可能比「自己做」還貴。

巴哲 2026-08-20 已經量過這件事，結論是委派吃掉 5.268 倍 token、2.368 倍成本， 而且沒有減輕主模型的脈絡負擔（1.200 倍），要任務放大到 1.50 倍以上才划算。

但他的實驗有一個我們用得上、他卻量不到的缺口：他的工兵全是 Claude 自家的子代理， 帳記在同一本上。本環境 2026-08-19 起的預設是派 mini-agent（MiniMax M3）， 那是另一本帳、另一份月費。他的 5.268 倍講的是「總 token」， 對我們而言大半根本不落在 Claude 額度上。

所以本實驗把同一份契約跑三種做法：

要回答的一句話：把工作移到別本帳上，Claude 這邊真的省下來了嗎，代價是什麼。

⚠️ 兩邊都是月費吃到飽（MiniMax 那本 NT$1,500／月），所以錢不是決策變數。 真正稀缺的是那個六條 LINE 線共用的 Claude 額度視窗——報告裡的美金是照 API 價目表換算的名目價，不是實付。

二、兩種跑法：Windows 原版與 macOS 港版

同一份契約有兩個版本，因為原版綁死 Windows。

改動只有四處，全在外殼：GUI 框架、建置指令、進入點、regex 引擎語法轉換。 之所以損失比看起來小，是因為封存測試打的是工具吐出來的 plan.json， 判定對象是資料不是語言——真正綁死 Windows 的只有殼。

代價要講清楚：換棧之後工作量不完全等價，我們的 A／B 與他的 C1／C3 關係由「可直接對照」降為「同量級參考」。但本實驗的主問題（C 相對 A、B 的位置） 完全落在我們自己三臂之間，不受這件事影響。

還有兩個平台差異值得記：

• 脈絡視窗實測 1,000,000（modelUsage.contextWindow），不是 200,000。 「怕爆脈絡才要委派」這個直覺在這個環境不成立——委派的門檻是分工經濟，不是容量。
• 移植時抓到一個評分器缺口：G3 原本檢查有沒有 .csproj 檔，Python 專案永遠不可能滿足， 每一臂會固定少一分。已改成等價問法（有沒有原始碼真的在用 tkinter 做 GUI）。 這個改動由技術棧決定，不是看了成績才調的。

三、目前跑到哪

跟巴哲並排：委派比自己做貴幾倍

三組共用同一把尺，所以棒子長度可以跨組直接比。虛線＝獨力 1.00×，落在線左邊的做法比自己做便宜。

並排不等於可直接對照：巴哲跑 C# WinForms、每臂 n=4 已完成；我們跑 Python 港版，多數臂還沒跑滿 n=4，倍數是觀察值不是結論。

四張圖：同一份工作，三種做法的代價

每張圖以當下最大值為滿格；切到本頁才長出來，每臂目前的筆數標在名字後面。

逐筆結果（每補完一筆就重跑本表）

← 左右滑看其餘欄位（第一欄固定不動）

完成度：5/12 筆。未跑完的格子寫「待跑」不寫 0——空目錄評出來的 0 分會被讀成「這一臂做不出來」，那是假資料。

分臂彙總（以 A 臂為 1.00）

← 左右滑看其餘欄位（第一欄固定不動）

⚠️ 每臂最少只有 1 筆，還不到 n=4。n=4 vs n=4 的 Mann-Whitney 下限是 p=2/C(8,4)=0.0286，低於 4 筆在組合上就不可能達到 p<0.05——所以上面的倍數是觀察值不是結論，不得拿去改派工預設。

四、目前看到的三件事（是觀察，不是結論）

第一，發包給自家子代理最貴。 B 臂在 Claude 額度上吃掉 3.98 倍， 名目成本 3.33 倍。方向與巴哲的結論一致（他量到 token 5.268 倍、成本 2.368 倍）， 倍率比他更陡——量到的東西不同（他算總 token，我們算與額度直接相關的新鮮 token）， 而且我們的施工卡把工作切給多個子代理，切得愈細、複述契約的次數愈多。 兩邊都指向同一件事：在自家池子裡發包，帳單會膨脹一倍以上。

第二，發包給 MiniMax 幾乎不花 Claude 額度。 C 臂只比獨力多 9%。 那 9% 是施工卡與驗收的成本——主 session 還是得寫卡、讀回報、驗收， 只是工兵那一段的算力搬到別本帳上了。

第三，代價出現在時間與脈絡，不在錢。 C 臂跑了 62.4 分鐘， 是獨力（18.3 分）的 3.41 倍；主線峰值脈絡 150,603， 反而比獨力（128,622）還高——因為工兵的產出要讀回主線驗收。 B 臂也一樣（149,532，1.16 倍）。所以「派工兵可以減輕主線脈絡」這個直覺， 兩種發包方式都不成立，跟巴哲在委派上量到的 1.200 倍是同一個現象。

五、限制（讀這份報告前必須知道）

1. 筆數不足。 每臂 n=4 才有可能達到 p<0.05（Mann-Whitney 下限 p=2/C(8,4)=0.0286）。 現在的倍數只是觀察值，不得拿去改 rules/model-dispatch.md 的派工預設。
2. 品質那一半還沒做。 契約層目前三臂都是滿分，但巴哲研究裡最重要的限制就是 「契約層滿分、GUI 層卻交出連資料夾都載不進去的介面」。每一筆都要人工開一次 GUI 才算數。
3. MiniMax 側量不到 token。 CLI 不回報、log 沒有計數器、額度表那兩個 *_time 欄位 實測是倒數毫秒不是餘額。C 臂只量得到請求數。
4. 美金是名目價，訂閱制下不是實付金額。
5. 共用額度池與共用機器是兩回事。三臂跑在服役中的帳號店面上（伊森 2026-08-21 13:22 核可）， 那是額度軸；另外它們與五條 session 同住一台 M2，那是機器資源軸—— 2026-08-21 15:45 全線被砍是後者，與額度無關。

六、下一步

• 補完剩下的筆數，每補一筆就重跑 tools/report_lifeos.py，本報告的表格自己長。
• 12 筆到齊後跑人工 GUI 篩檢，把品質那一半補上。
• 兩件都齊了才動 rules/model-dispatch.md。