這 30 天其實只做了一件事

把「我覺得這樣比較好」換成「我量過，差多少，有多不確定」。

Day1 到 Day8 拆 harness 的構造，Day9 到 Day17 開始量，Day18 到 Day21 補上可觀測性，Day22 逼出 compaction、Day23–24 補上統計，Day25 到 Day28 換方向去量「限制 agent」的代價，Day29 回頭把記錄變成可以重算的資產。

今天把所有東西攤開：可以直接用的清單、完整資料、我做錯的事、以及沒能回答的問題。

一、有把握的結論（bootstrap 區間不含 0）

21 組比較裡，只有這 6 組的 95% 區間不含 0：

如果你只想帶走一句話：

把「這個專案的流程」寫成 Skill，是這 30 天量到 CP 值最高的一件事。
它不給模型新知識，只是省掉它自己摸索流程的那幾輪——而那幾輪佔了一半的帳單。

二、量不出成本差、但行為明顯不同的事

這些比較的區間都含 0，成本上我不敢下結論，但它們改變了 agent 做事的方法，而且是可重現的觀察：

三、不需要統計就成立的事實

這些是從原始碼、文件或單次量測直接得到的，沒有不確定性的問題：

四、完整資料集

全部在 howisyour/my_first_pi_agent_project（MIT）。

附帶 168 份完整 session（6,129 筆事件、10 MB）、每次執行的 diff、以及所有圖表的產生程式。路徑、使用者名稱、主機名稱都已經過濾。

repo 導覽：

bench/fixtures/taskapp/   受測專案（64 個檔案、5 條專案慣例）
bench/tasks/              6 個任務，每個都有參考解與隱藏測試
bench/runner/             harness 無關的 runner（adapter / 判定 / 指標 / 重算）
bench/extensions/         Day25-26 的刪除閘門 v1、v2 與單元測試
lab/trace/                Day19-20 的 OTel adapter 與 trace 包裝
analysis/                 所有表格與圖表的產生程式
experiments/              設定檔、原始結果、圖
docker/Dockerfile         Day28 的容器

重現任何一組數字：

python -m bench.runner.cli run experiments/configs/e11_skills.json
python -m analysis.evals

不想花錢、只想驗算我貼出來的數字：

python -m bench.runner.recompute      # 從存下來的 session 重算全部指標，0.3 秒

五、我做錯的六件事

這一段我認為比上面的結論更有用。

1. 先做保護，才去驗證風險存不存在。
Day25 我花了一整天做刪除閘門，Day26 才發現沒有閘門的五次執行，agent 一次都沒有想刪那個受保護的目錄——它五次都先用 git ls-files 查過。順序反了。

2. 閘門不懂 shell，擋掉了正確的指令。
v1 把 rm -rf .cache tmp && git status && python check.py 整條擋掉，因為它把 && 後面的字都當成刪除目標。9 次攔截裡有 8 次是誤擋，成功率從 100% 掉到 40%。 修法不是憑想像補 regex，而是把 session 裡 agent 真的下過的指令抄出來當測資。

3. 帳單漏算了一整筆。
compaction 產生摘要那次模型呼叫的 usage 掛在 compaction 記錄上，不在 assistant 訊息裡，而我的指標只走 assistant 訊息。Day22 的結論因此從「+22%，沒把握」變成「+45.7%，有把握」。

4. 設計了一個測不到目標的實驗。
Day22 想測「agent 被摘要之後會不會失憶」。跑完才發現壓縮永遠在 agent_end 之後發生——摘要從來沒進到任何一次請求裡。要測的東西一次都沒測到。

5. 照著不存在的功能寫大綱。
原本 Day23–24 要用 pi evals。它不存在，是我憑印象寫下的。Day19 的 telemetry 也一樣——契約完整到讓我以為它已經在跑了。

6. 拿 n=3 的校準數字當初步結論在講。
Day9 的校準跑了 3 次，T3 量到 +63.8%；正式用 5 次跑，同一個比較變成 +28.7%。點估計掉了一半以上，只有方向站得住。Day23 做完 bootstrap 才看清楚這件事有多不牢靠。

這六件事有一個共同點：它們全部是被「記錄」抓出來的，不是被我想出來的。

六、沒能回答的問題

1. 摘要之後會不會失憶。 Day22 沒測到，互動模式下的 compaction 我完全沒碰。
2. 惡意 agent 能不能繞過閘門。 Day26 的 agent 一直在努力完成任務，不是在攻擊我。字串比對面對後者只會更脆弱。
3. 換模型會怎樣。 全系列只有 gpt-5.6-luna。所有百分比都可能隨模型改變，撐得住的只有方向。
4. micro-VM 等級的隔離。 Gondolin 是 Linux micro-VM，我在 Windows 上跑不了。
5. n=5 的天花板。 這批任務對 luna 太簡單，168 次裡只失敗 4 次，成功率完全失去解析度——而 5 次全對的 Wilson 區間永遠是 57%–100%。要讓成功率有意義，得先設計會失敗的任務。
6. 那 47% 的 harness 開銷裡面是什麼。 Day20 只證明了它存在，沒有拆開。

七、如果你明天要自己做一個 harness

把 30 天濃縮成一張清單：

1. 第一天就把事件記錄寫對。 append-only、每筆有 id 和 parentId、狀態用 fold 算出來。所有花錢的動作，usage 要放在同一個層級（我就是栽在這）。
2. 衍生指標放下游。 記錄原始事件，指標用可以隨時重跑的程式算。量錯了就只是改程式，不是重做實驗。
3. 工具開關要影響 system prompt。 工具不是加上去就好，指示要跟著變（Day12）。
4. 錯誤訊息是 prompt 的一部分。 被擋下來的理由會變成 agent 下一輪的輸入，要寫替代做法（Day25）——但也要記得，寫得好的錯誤訊息會讓它有效率地執行一個錯誤的規則（Day26）。
5. 限制 agent 的規則，要當產品程式碼測，測資從真實 trace 來。
6. 說得出邊界在哪。 「我有用 Docker」不是安全宣稱；把掛了什麼、網路通不通、用哪個身分跑列出來才是（Day28）。
7. n=5 就講 n=5 的話。 貼區間，不要只貼中位數。21 組比較裡有 15 組其實分不出差別——這件事本身就是結論。

最後

這 30 天最讓我意外的不是任何一個百分比，而是：

我原本以為在寫一個「怎麼調教 agent」的系列，結果寫成了一個「怎麼量自己有沒有在亂講」的系列。

harness engineering 真正的內容，好像就是這個：agent 的行為是隨機的，你唯一能控制的是它的輸入和你的量尺。前者決定它做什麼，後者決定你知不知道自己做了什麼。

所有程式碼、資料與圖表都在 howisyour/my_first_pi_agent_project，歡迎拿去改、拿去跑、或是拿去證明我哪裡量錯了——那正是把資料全部公開的原因。