【2026 最新】ThinkRail Token 排查怎麼做？Skills 自動匯入、目錄與快取四步教學

你才請 AI 整理一份 README，額度卻掉得比想像快。這篇 ThinkRail Token 排查教學，帶你把三件事分開：每次帶進去的技能目錄有多大、哪些輸入被快取重用，以及任務本身跑了幾輪。先找到消耗從哪裡來，調整才有方向。

寫給已經開過 ThinkRail、第一次查看用量的新手。你會學會四步檢查，留下同一小任務的前後紀錄。本文依 2026 年 11 月 7 日查閱的官方版本、原始碼與原始回報整理，提供可照做的診斷方法；本文的操作比較待讀者執行，不預填節省比例或帳戶結果。

先說結論：ThinkRail Token 排查＝目錄大小＋快取分類＋任務輪數

把技能目錄想成每次開會先發的通訊錄；快取像保留已看過的底稿；任務輪數是開了幾次會。通訊錄太厚、底稿未重用、反覆開會，都可能增加消耗，但各自要用不同紀錄確認。

先記版本，再查 Skills，接著做一次只改一組來源的比較，最後分開核對 cache reads、cache writes 與供應商用量。看到很大的 Token 數字，先保留原始欄位名稱，避免把不同計量口徑直接相加。

一、為什麼還沒做事，輸入就很多？

ThinkRail 是把 pi 編碼代理放進圖形介面的開發工具。Skill（技能）可看成一份工作說明書：名稱、簡介與所在位置先幫代理判斷要不要讀完整內容。完整技能尚未被打開，不代表它的目錄介紹完全不占輸入。這就是「我沒有叫它用那些技能」仍值得檢查來源的原因。

官方 0.3.2 README 說明會讀取其他編碼代理的可攜技能；技能來源程式 也列出個人、專案與外掛路徑。實際載入還受專案信任、群組與技能開關影響。磁碟裡找到一個資料夾，與它已進入這次請求，要分開確認。

2026 年 11 月 5 日的 #1210 原始回報 提供了一個線索：回報者在 macOS 26.5、穩定版 0.3.1 的單一工作區，記錄到 1,395 個技能、約 165K Token 的技能區段，首次請求輸入為 171,090 Token；該次 Session 共 141 次請求。他也回報快取問題與額度數小時內耗盡。這是該使用者的環境與估算，不是所有 ThinkRail 使用者的平均消耗。

你要學的是找出固定負擔的方法，而不是把別人的 165K 套在自己的帳單。如果想先補模型與執行層的分工，可以讀 Agent Harness 是什麼；目錄、工具和歷史訊息如何被組裝，正是執行層的工作。

二、ThinkRail Token 排查四步：先記錄，再一次改一件事

① 怕看見修正提案，就以為自己已經修好？先鎖版本

先寫下應用程式版本、更新通道、作業系統、供應商與模型。使用命令列啟動器的人，可在自己的終端機執行 thinkrail --version；這個指令由官方 README 列出。桌面版則抄下應用程式顯示的版本，兩種安裝入口都在用時各記一份。

截至 2026 年 11 月 7 日查核，最新穩定版 為 0.3.2，發布於 11 月 6 日。#1218 的目錄預算與 skill_search，以及 #1221 的其他代理技能預設選擇加入、目錄估算顯示，當時都仍是開放提案。它們適合追進度，不應當作 0.3.2 已有的操作選項。

這一步的完成證據是一行環境紀錄，例如「版本／通道／供應商／模型／日期」。日後更新後，把同一份小任務再跑一次，才知道比較的是設定，還是整個版本一起換了。

② 怕不知道誰帶進來？打開 Skills，保存來源基線

從聊天介面開啟 Skills popup，查看群組、技能與開關。先保存目前狀態與曾明確啟用的工作區技能，再記下你確定會用的專案技能，和暫時不需要的個人或外掛群組。官方 0.3.2 SkillsDialog 把群組開關寫入專案設定；聊天內的單一技能也可能有工作區覆寫。介面會限制關閉群組裡的單項開關；但 admission（載入判定）程式中，工作區明確的 on 覆寫優先於群組停用。因此還要核對工作區覆寫與實際載入結果，不能只靠群組開關判斷已卸載。

若你願意查看本機 Session（一次對話的工作紀錄），原回報是在 ~/.pi/agent/sessions/ 的 JSONL 內檢查系統訊息的 sections.skills。JSONL 是一行一筆的紀錄格式。先在本機編輯器找這個欄位與技能路徑，記錄區段字元數、來源與當次用量；這是回報者的檢查位置，若你另設 pi 設定目錄，先確認應用程式實際採用的位置。

停用個人或外掛群組，也不等於停掉 pi 原生的全部來源；例如 ~/.agents/skills 要另查實際載入。字元數只是區段大小的線索，Token 數要看使用模型的分詞與用量回報。Session 可能包含工作內容、路徑與工具結果；對外求助時整理必要數字和去識別片段，別直接公開整份紀錄。這一步要得到的是「哪些來源進入這個專案」的基線。

③ 怕一口氣關太多，工作反而做不好？一次停一組

透過 Skills 的群組開關，暫停一組確定不需要的來源。例如只做 README 摘要，先保留專案需要的技能，再挑一個無關外掛群組關閉。不要為了這次比較搬走、刪除其他工具的技能資料夾，也先別改系統的家目錄或環境變數。

如果聊天提示技能資源已變更，等目前回合結束，再按 Skills 裡的 Reload；0.3.2 原始碼顯示代理執行中會停用這個按鈕。接著開一個新的聊天做 B 組，避免把 A 組已讀進歷史的內容混進來。測試前後截圖留存，才能回復原來的開關。

觀察的不是「技能變少就一定成功」，而是首次輸入是否下降、目錄是否真的縮小、任務能否照原標準完成。若摘要漏了必要資訊，就恢復該組，再用更細的單項開關重試。這和 技能路由教學 的問題相鄰，但本文操作的是 ThinkRail 現成開關，沒有要求你自己開發路由器。

④ 怕目錄縮了，帳單卻還是快？把快取與輪數另開一欄

查看聊天上方用量區，把輸入、輸出、cache reads、cache writes、成本與上下文占用分開抄下。官方 GUI overview 展示這些欄位。0.3.2 用量列程式 使用 Session 累計統計，零值欄位可能省略。用回合前後差額記錄；沒有顯示 R，單憑這點不足以判定快取故障。先記精確標籤及累計範圍，再對照供應商帳戶的同一時段；介面估算成本與訂閱額度消耗，不要直接當成同一種數字。

以 Anthropic API 的 Prompt caching 官方文件 為例，快取重用的是相符的提示前綴，讀取、建立快取與一般輸入有各自的計量及價格。這說明「請求帶著同一大段內容」與「整段按一般輸入價格付費」是不同命題；不能拿目錄 Token 數直接乘請求次數，就宣布那是實付成本。其他供應商則查各自的欄位定義。

調整技能來源會改變提示內容，因此設定變動後的第一回合，和後續穩定回合要分開看。再記代理實際呼叫模型的次數、工具讀出的內容及重試。若單次固定負擔下降，總用量卻上升，下一個要查的是新增了多少工作輪數，而不是反覆切換技能開關。

三、跟著做一次：同一份 README 的 A／B 紀錄

準備一個只有可公開內容的練習專案，固定 README 版本、供應商、模型與推理設定。先在便條紙寫好完成標準：「三點摘要都能在 README 找到依據，沒有修改檔案」。下面是待執行的比較流程，結果欄由你的實際畫面填入。

A 組保留原來的 Skills 設定，開新聊天，貼上：只讀取 README.md，用繁體中文列出專案用途、啟動方式、測試方式三點；找不到就寫未載明，不修改檔案，不執行安裝。完成後記第一次請求的輸入、快取分類、輸出、模型呼叫次數與品質。

緊接著在同一聊天貼：根據剛才讀過的 README，把三點各縮成一句；不讀新檔案、不執行指令。這一輪用來觀察相同設定下的重用情形，仍要看實際工具及用量紀錄，不把「我叫它別讀」當成它確實沒讀的證據。

B 組只關閉一個無關技能群組，套用變更後另開新聊天，照原文字跑同樣兩個回合。新聊天仍要再查工作區覆寫；它能減少歷史干擾，並不保證群組停用一定涵蓋所有技能。分別記「B 首回合」與「B 後續回合」。A 首回合對 B 首回合，看固定輸入；各組自己的首回合對後續回合，看快取分類變化。一次改一項，才比較容易定位原因。

每筆紀錄保留：版本與設定、來源開關、Session 識別、精確用量欄位、請求次數、耗時、成本／額度、三點摘要是否合格。若畫面只有累計值，就記每回合前後的差額，並標示這是「回合差額」，不要冒稱為第一個模型請求。需要更完整的工作紀錄觀念，可接著讀 Token 用量稽核教學。

如果 B 輸入較少且摘要同樣合格，保留設定、換一個你平常真的會做的小任務再驗一次。如果輸入相近，回頭確認群組是否套用、是否開了新聊天，以及輸入主要是否來自檔案和歷史。如果快取讀取偏低，先查供應商、間隔與提示內容變動；這些結果都不需要預設「一定省幾成」。

四、容易踩的三個坑：專案、搜尋與快取各管一段

第一個坑：把一個專案的設定，當成所有新專案的預設。0.3.2 的群組開關依專案保存；換一個新專案時重新打開 Skills 核對。#1221 提議的全域預設，應等它合併、進入你安裝的版本，再按該版說明驗收。

第二個坑：把目錄預算，當成技能已被禁止載入。#1218 提議限制先列給模型看的介紹，並透過搜尋找到其他已獲准的技能；可載入權限與先顯示多少介紹，是兩道控制。這裡教的是辨認提案機制，不提供尚未發布的設定指令。

第三個坑：把快取命中，當成上下文已變小。快取處理重用及計價；減少目錄處理的是提示內容大小。即使一大段能被重用，你仍應檢查上下文占用與任務品質。想長期管理技能來源，可讀 Agent Skill 生命週期，把新增、停用、驗收與回復一起保存。若還想整理其他使用情境，可接著讀 Claude Token 使用技巧，再依你自己的產品入口逐項核對。

五、常見問題：八個先講答案的判斷

1. 看到 165K，代表我的每個請求也這麼大嗎？

不代表。那是 #1210 回報者單一工作區的估算。先看自己的 Skills 來源與用量欄位，再判斷是否碰到同類問題。

2. 更新到 0.3.2，就等於有 skill_search 嗎？

不能據此判定。截至本文查核，#1218 仍開放；要依合併狀態、發布紀錄與安裝版本逐一核對。

3. Skills 開關變少，就能保證帳單下降嗎？

不能保證。還要確認提示真的變小、模型呼叫輪數、快取分類與任務是否完成。每項都留下同一時間範圍的紀錄。

4. 可以直接刪掉其他代理的技能資料夾嗎？

先用產品開關。刪除共用來源會連帶影響其他工具；受控比較要能回復，一次停一組已足夠開始定位。

5. Reload 之後，還需要新聊天嗎？

做 A／B 比較時需要。新聊天可減少前一組歷史內容的干擾；Reload 則用來套用技能資源變更，兩個動作處理不同問題。

6. cache reads 很多，就表示成本是零嗎？

不表示。以 Anthropic API 為例，快取讀取有自己的價格；訂閱額度還要對照該方案的使用規則。

7. 換新專案後要再查一次嗎？

要。先核對群組開關與實際來源，再跑相同小任務。不要把專案內的成功紀錄，直接外推成所有資料夾都已套用。

8. 我不會讀 JSONL，也能開始嗎？

可以。先用 Skills、聊天用量區、版本紀錄與同一份 README 做比較。缺少單次請求資料就明寫為回合累計差額，保留量測邊界。

給新手的三個重點

先鎖版本：開放中的 PR 是待追蹤方案，發布版才是你能操作的對象。再縮來源：一次停一組，保留回復紀錄與完成品質。最後拆帳：目錄大小、快取分類、模型輪數、實付或額度各自記清楚。