原本的大綱寫的是「拿掉 grep/find/ls 的代價」。實際動手之後發現前提就錯了:Pi 預設根本沒開這三個工具(Day12),預設只有 read、bash、edit、write。
所以今天要問的是反過來的問題:把這三個搜尋工具打開,有沒有比較好?
DEFAULT_PAGE_SIZE 拆成 LIST_PAGE_SIZE(25)和 SEARCH_PAGE_SIZE(10),而且改完之後專案裡不能再出現舊常數。這個任務刻意需要跨檔案搜尋。grep/find/ls。gpt-5.6-luna。| 條件 | 成功 | 成本中位數 | tokens 中位數 | 工具呼叫中位數 |
|---|---|---|---|---|
| 預設四個工具 | 5/5 | $0.0070 | 61,261 | 23 |
| 加上 grep/find/ls | 5/5 | $0.0059 | 60,664 | 24 |
中位數看起來有差,但把十次執行的成本全部攤開就很清楚:
| 條件 | 五次的成本 |
|---|---|
| 預設四個工具 | $0.0043、$0.0065、$0.0070、$0.0075、$0.0089 |
| 加上 grep/find/ls | $0.0050、$0.0055、$0.0059、$0.0074、$0.0079 |
完全重疊。 tokens 也一樣(中位數 61,261 vs 60,664,差 1%)。這個任務在這個環境下,開不開搜尋工具沒有可測量的差別。
有意思的是它怎麼達成一樣的結果:

| 條件 | read | bash | edit | grep | find | ls | 合計 |
|---|---|---|---|---|---|---|---|
| 預設四個工具 | 9.6 | 4.6 | 8.8 | — | — | — | 23.0 |
| 加上 grep/find/ls | 8.8 | 1.2 | 7.8 | 3.8 | 1.0 | 0.2 | 22.8 |
沒有搜尋工具的那一組,5 次執行全部都用 bash 跑了 rg(每次 2–3 個搜尋指令,其中兩次還用了 find)。開了搜尋工具的那一組,bash 從平均 4.6 次掉到 1.2 次,grep 接手 3.8 次,而且 bash 裡一個搜尋指令都沒有。
也就是說:
這三個工具不是給 agent 新能力,是換一條路做同一件事。
Day14 會看到,Pi 的 system prompt 其實也知道這件事——沒開搜尋工具時,它會自動多加一行 guideline:「Use bash for file operations like ls, rg, find」。harness 早就把繞路的路標放好了。
工具不是加了不用錢。每個工具的 JSON schema 都會跟著每一次請求送出去。量一下第一輪的輸入 token:
| 條件 | 第一次模型呼叫的輸入 |
|---|---|
| 預設四個工具 | 1,520 tokens |
| 加上 grep/find/ls | 1,905 tokens |
五次執行,每一次都是這兩個數字,一個不差。三個搜尋工具的 schema 固定佔 385 個 token。
這個數字剛好可以跟 Day9 對照:那份寫了五條專案規則的 AGENTS.md 是 354 個 token。三個搜尋工具的「自我介紹」,比整份專案規則還貴。
依這次的資料:
rg 的開發機上:開不開差不多。 agent 會自己用 bash 繞過去,而你要為此付 385 tokens/次請求。Pi 把它們設成預設關閉,是合理的選擇。rg、甚至沒有 bash 的環境下,結論應該會反過來。 這正是我對這個結果最不確定的地方——我的環境裡 rg 一直都在(那是 Pi 第一次啟動時自己下載到 D:\pi-agent\bin 的,見 Day5),Git Bash 也在,所以繞路的成本幾乎是零。如果把 agent 關進一個只有基本指令的容器裡,或是為了安全把 bash 直接關掉,那這三個工具就從「多餘」變成「唯一的路」。這是一個可以驗證的預測,也是這個系列後面講 sandbox 時會回來的題目。
grep 工具的結構化輸出可能比 rg 的純文字更省 token。Day14 把 system prompt 整份攤開來看:它到底寫了什麼、有多長、在成本裡佔多少,以及為什麼它其實是一個「函式」而不是一份文件。