三臂受控實驗|現況報告
派工到底省了什麼——三臂實驗報告(n=4 定版)
Claude 新鮮 token,以獨力為 1.00
完成度 12/12 筆(A 4/B 4/C 4)
左右滑動或按方向鍵換頁
一、這個實驗在問什麼(白話版)
派工兵這件事,直覺上是「找人幫忙比較省」。實際上不一定。
主 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 額度上。
所以本實驗把同一份契約跑三種做法:
| 臂 | 做法 | 白話 |
|---|---|---|
| A | 主 session 獨力做完 | 自己做 |
| B | 主 session 出施工卡,發包給 Claude 自家子代理 | 找同事幫忙,錢從同一個口袋出 |
| C | 主 session 出施工卡,發包給 MiniMax M3 工兵 | 找外包,錢從另一個口袋出 |
要回答的一句話:把工作移到別本帳上,Claude 這邊真的省下來了嗎,代價是什麼。
⚠️ 兩邊都是月費吃到飽(MiniMax 那本 NT$1,500/月),所以錢不是決策變數。 真正稀缺的是那個六條 LINE 線共用的 Claude 額度視窗——報告裡的美金是照 API 價目表換算的名目價,不是實付。
二、兩種跑法:Windows 原版與 macOS 港版
同一份契約有兩個版本,因為原版綁死 Windows。
| 巴哲原版(win) | 我們的港版(mac) | |
|---|---|---|
| 技術棧 | C# WinForms on .NET 8(net8.0-windows) | Python 3 標準庫,GUI 用 tkinter |
| 建置檢查 | dotnet build -c Release | python3 -m compileall -q . |
| 命令列進入點 | BatchRenameStudio.exe | python3 batch_rename_studio.py |
| 契約規則 1–16 | 原文 | 逐字不動 |
輸入 rules.json/輸出 plan.json | 原格式 | 逐字不動 |
| 封存測試集與評分器 | holdout/score.py | score_lifeos.py,只改兩處平台綁定,G1/G2/G3 判定逐字未動 |
| 臂數 | 兩臂(C1 獨力/C3 委派) | 三臂(多一個 MiniMax 外包臂) |
| 每臂筆數 | n=4 | n=4(已跑滿,2026-08-22 00:30 收工) |
改動只有四處,全在外殼: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×,落在線左邊的做法比自己做便宜。
他量的是總 token(含子代理),我們量的是與額度直接相關的新鮮 token——同方向但不是同一把尺。
兩邊都照 API 價目表換算的名目價,訂閱制下都不是實付金額。
兩邊問的是同一件事:委派有沒有減輕主模型的脈絡負擔。
並排不等於可直接對照:巴哲跑 C# WinForms、每臂 n=4 已完成;我們跑 Python 港版、三臂各 n=4 已跑滿。並排的倍數是同量級參考,不是同一把尺量出來的。
四張圖:同一份工作,三種做法的代價
每張圖以當下最大值為滿格;切到本頁才長出來,每臂目前的筆數標在名字後面。
跟額度視窗直接相關的那一份——這條實驗真正在省的東西
照 API 價目表換算的名目價,訂閱制下不是實付
從開跑到收工的實際時間,含子代理跑的那一段
主 session 吃到最滿的那一刻——委派本來被期待能壓低它
逐筆結果(每補完一筆就重跑本表)
| run | 臂 | 做法 | Claude 新鮮 token | 名目 US$ | 牆鐘 | 請求數 | 子代理請求 | 主線峰值脈絡 | 契約分 |
|---|---|---|---|---|---|---|---|---|---|
| A-01 | A | 獨力 | 205,129 | 4.79 | 18.1 分 | 36 | 0 | 127,463 | 100% |
| A-02 | A | 獨力 | 207,016 | 5.12 | 18.5 分 | 41 | 0 | 129,781 | 100% |
| A-03 | A | 獨力 | 162,977 | 3.81 | 12.5 分 | 33 | 0 | 104,073 | 100% |
| A-04 | A | 獨力 | 190,330 | 4.58 | 16.8 分 | 37 | 0 | 120,548 | 100% |
| B-01 | B | 自家子代理 | 488,917 | 10.88 | 15.5 分 | 121 | 66 | 122,728 | 100% |
| B-02 | B | 自家子代理 | 1,150,863 | 22.09 | 62.1 分 | 179 | 130 | 146,307 | 100% |
| B-03 | B | 自家子代理 | 1,158,685 | 28.21 | 27.8 分 | 250 | 117 | 202,001 | 100% |
| B-04 | B | 自家子代理 | 1,456,654 | 30.58 | 56.9 分 | 300 | 250 | 150,105 | 100% |
| C-01 | C | MiniMax 工兵 | 224,867 | 7.25 | 62.4 分 | 71 | 0 | 150,603 | 100% |
| C-02 | C | MiniMax 工兵 | 152,806 | 3.59 | 29.4 分 | 36 | 0 | 105,649 | 100% |
| C-03 | C | MiniMax 工兵 | 154,720 | 3.97 | 42.9 分 | 45 | 0 | 109,114 | 100% |
| C-04 | C | MiniMax 工兵 | 275,547 | 8.80 | 72.4 分 | 78 | 0 | 174,854 | 100% |
← 左右滑看其餘欄位(第一欄固定不動)
完成度:12/12 筆。未跑完的格子寫「待跑」不寫 0——空目錄評出來的 0 分會被讀成「這一臂做不出來」,那是假資料。
分臂彙總(以 A 臂為 1.00)
| 臂 | n | Claude 新鮮 token 平均 | 相對 A | 名目 US$ 平均 | 主線峰值脈絡平均 | 契約分 |
|---|---|---|---|---|---|---|
| A/獨力 | 4 | 191,363 | 1.00× | 4.57 | 120,466.25 | 100% |
| B/自家子代理 | 4 | 1,063,779.75 | 5.56× | 22.94 | 155,285.25 | 100% |
| C/MiniMax 工兵 | 4 | 201,985 | 1.06× | 5.90 | 135,055 | 100% |
← 左右滑看其餘欄位(第一欄固定不動)
四、看到的三件事
第一,發包給自家子代理最貴。 B 臂在 Claude 額度上吃掉 5.56 倍, 名目成本 5.02 倍。方向與巴哲的結論一致(他量到 token 5.268 倍、成本 2.368 倍), 倍率比他更陡——量到的東西不同(他算總 token,我們算與額度直接相關的新鮮 token), 而且我們的施工卡把工作切給多個子代理,切得愈細、複述契約的次數愈多。 兩邊都指向同一件事:在自家池子裡發包,帳單會膨脹一倍以上。
第二,發包給 MiniMax 幾乎不花 Claude 額度。 C 臂只比獨力多 6%。 那 6% 是施工卡與驗收的成本——主 session 還是得寫卡、讀回報、驗收, 只是工兵那一段的算力搬到別本帳上了。
第三,代價出現在時間與脈絡,不在錢。 C 臂跑了 51.8 分鐘, 是獨力(16.5 分)的 3.14 倍;主線峰值脈絡 135,055, 反而比獨力(120,466)還高——因為工兵的產出要讀回主線驗收。 B 臂也一樣(155,285,1.29 倍)。所以「派工兵可以減輕主線脈絡」這個直覺, 兩種發包方式都不成立,跟巴哲在委派上量到的 1.200 倍是同一個現象。
五、統計檢定(每臂 n=4,精確 Mann-Whitney,雙尾)
n1=n2=4 時分割方式只有 C(8,4)=70 種,所以精確檢定的 p 下限就是 2/70 = 0.0286—— n=4 是「p<0.05 在組合上有可能」的最小值,不是預算選擇。以下窮舉全部 70 種分割算出, 不用常態近似。U=0 或 U=16 代表兩組完全分離(一組的每一筆都比另一組的每一筆極端)。
Claude 新鮮 token(頭條)
| 臂 | 四筆值 | 中位數 |
|---|---|---|
| A/獨力 | 162,977, 190,330, 205,129, 207,016 | 197,730 |
| B/自家子代理 | 488,917, 1,150,863, 1,158,685, 1,456,654 | 1,154,774 |
| C/MiniMax 工兵 | 152,806, 154,720, 224,867, 275,547 | 189,794 |
| 對比 | U | 精確雙尾 p | 中位數比 |
|---|---|---|---|
| A vs B | 0(完全分離) | 0.0286 | 5.840× |
| A vs C | 8 | 1.0000 | 0.960× |
| B vs C | 16(完全分離) | 0.0286 | 0.164× |
牆鐘(秒)
| 臂 | 四筆值 | 中位數 |
|---|---|---|
| A/獨力 | 748, 1,009, 1,089, 1,109 | 1,049 |
| B/自家子代理 | 929, 1,665, 3,417, 3,728 | 2,541 |
| C/MiniMax 工兵 | 1,761, 2,576, 3,747, 4,344 | 3,161 |
| 對比 | U | 精確雙尾 p | 中位數比 |
|---|---|---|---|
| A vs B | 3 | 0.2000 | 2.423× |
| A vs C | 0(完全分離) | 0.0286 | 3.015× |
| B vs C | 4 | 0.3429 | 1.244× |
主線峰值脈絡
| 臂 | 四筆值 | 中位數 |
|---|---|---|
| A/獨力 | 104,073, 120,548, 127,463, 129,781 | 124,006 |
| B/自家子代理 | 122,728, 146,307, 150,105, 202,001 | 148,206 |
| C/MiniMax 工兵 | 105,649, 109,114, 150,603, 174,854 | 129,858 |
| 對比 | U | 精確雙尾 p | 中位數比 |
|---|---|---|---|
| A vs B | 2 | 0.1143 | 1.195× |
| A vs C | 6 | 0.6857 | 1.047× |
| B vs C | 10 | 0.6857 | 0.876× |
名目 US$
| 臂 | 四筆值 | 中位數 |
|---|---|---|
| A/獨力 | 3.81, 4.58, 4.79, 5.12 | 4.68 |
| B/自家子代理 | 10.88, 22.09, 28.21, 30.58 | 25.15 |
| C/MiniMax 工兵 | 3.59, 3.97, 7.25, 8.80 | 5.61 |
| 對比 | U | 精確雙尾 p | 中位數比 |
|---|---|---|---|
| A vs B | 0(完全分離) | 0.0286 | 5.369× |
| A vs C | 7 | 0.8857 | 1.198× |
| B vs C | 16(完全分離) | 0.0286 | 0.223× |
⚠️ 多重比較的誠實邊界:頭條指標做了三組兩兩比較。若把這三組當一個家族做 Holm 校正, 最小的 p 是 0.0286,乘 3 得 0.0857,已經高於 0.05。工單當初沒有預先寫明三臂要怎麼 處理多重比較,這是設計上的缺口。所以本節穩健的部分是完全分離與效果量(B 臂的 Claude 額度是 A 臂的 5.8 倍、C 臂是 B 臂的 0.16 倍),不是 p 值本身。
品質那一欄(契約層自動評分)12 筆全部 100%,三臂在自動評分層分不出高下; GUI 層未評分,需人工 UAT(各臂 MANUAL_UAT.md)。所以「省額度會不會換來品質下降」 這個問題,本實驗在契約層的答案是「沒有」,在 GUI 層還沒有答案。
六、限制(讀這份報告前必須知道)
- 筆數剛好踩在下限。 每臂 n=4 已跑滿,這是精確 Mann-Whitney 讓 p<0.05 成為可能的 最小值(下限 p=2/C(8,4)=0.0286),不是充裕。三組兩兩比較未預先寫明校正方式, Holm 校正後最小 p 是 0.0857(見 §五)。在人工 GUI 篩檢補上、且伊森裁示之前, 不得拿去改
rules/model-dispatch.md的派工預設。 - 品質那一半還沒做。 契約層目前三臂都是滿分,但巴哲研究裡最重要的限制就是 「契約層滿分、GUI 層卻交出連資料夾都載不進去的介面」。每一筆都要人工開一次 GUI 才算數。
- MiniMax 側量不到 token。 CLI 不回報、log 沒有計數器、額度表那兩個
*_time欄位 實測是倒數毫秒不是餘額。C 臂只量得到請求數。 - 美金是名目價,訂閱制下不是實付金額。
- 共用額度池與共用機器是兩回事。三臂跑在服役中的帳號店面上(伊森 2026-08-21 13:22 核可), 那是額度軸;另外它們與五條 session 同住一台 M2,那是機器資源軸—— 2026-08-21 15:45 全線被砍是後者,與額度無關。
七、下一步
- ~~補完剩下的筆數~~ 12/12 已到齊(2026-08-22 00:30:38 收工)。本報告的表格與 §五 的檢定都是從
results-lifeos/現算的,之後補跑或重跑仍會自己更新。 - 還沒做:人工 GUI 篩檢。 契約層三臂都是滿分,但巴哲研究裡最會出事的就是這一層 (契約滿分、GUI 卻連資料夾都載不進去)。12 筆各開一次 GUI 才算把品質那一半補上。
- 還沒做:多重比較的處置方式要補寫進工單,並決定頭條的主要對比是哪一組—— 這件事本來該在跑之前寫明。
- 這三件齊了、且伊森裁示之後,才動
rules/model-dispatch.md§4/§4.5。