答案是主張，這些區塊才是證據。

一般的聊天網頁只給你文字，別無其他。Pi Agent 除了文字，還多給你一份紀錄，因為它不只是在講話——它會讀你的檔案，也會改動它們。

這三種都有正式名稱，值得記住，因為軟體出狀況時就是用這幾個詞來講的。

每一行都值得比上一行看得更仔細一點。

一輪對話可以同時帶著這三種。一個真實的 session 可能會把灰色方塊放在最終答案上面、把工具呼叫顯示成白色卡片、再用紅綠呈現檔案的變動——每一種都能展開看細節。你實際上會拿到哪幾種，取決於你選的模型跟這次請求需要什麼。單靠記憶就能回答的問題，可能三種都不會出現。

容易被忽略，也容易被過度信任

思考塊是灰色的，通常標著 Thinking 或對應的翻譯，通常一出現就是收合狀態。展開後，你會看到這個模型走的路線願意提供的思考文字——可能是一大段、一份簡短摘要，或只有用量的中繼資料。

只有支援的推理模型、走支援的路線，才會有這個東西。答案很奇怪、跟你講過的東西衝突，或是你想看請求怎麼被拆解的時候（例如一個燈光請求怎麼拆成觸發、條件、動作）就展開看。單純查資料、風險低而且你自己就能檢查、或者答案根本用不上的時候，就跳過不看。

你選了推理模型，卻沒有思考塊

照這個順序查三件事：

• reasoning 選項沒開。 如果一個模型設定裡有個 reasoning 核取方塊，那個開關就決定思考塊會不會被獨立顯示出來。第 3 篇講過這個模型設定。
• 供應商的 thinkingFormat 設錯了。 這是供應商層級的欄位： zai 給 GLM 用， deepseek 給 DeepSeek 用， qwen 給相容的 Qwen 路線用， openai 只給適用的直接相容 OpenAI 路線用。直接連 Anthropic 的路線通常留空，因為 SDK 用的是它自己的 thinking 內容區塊。解析器選錯了，思考內容就是分不出來。
• 這個模型根本不是推理模型。 系列名稱會騙人。目錄裡可能把推理版跟非推理版並排列出來，而 Kimi K2-Instruct 這個項目走的是 Instruct 路線，不是 Thinking 路線。要確認精確的模型 ID。

記錄真實動作的那個區塊

當 agent 需要動手做而不只是寫字的時候，就會出現工具卡。它帶著工具名稱、送出去的輸入，跟拿回來的結果，過程中會顯示 Running…，然後是成功或失敗。

核心套件 @earendil-works/pi-coding-agent，內建七個工具，全部小寫：

像是 read_file、 web_fetch 或 search 這種名字屬於別的 agent 系統。這裡沒有內建的網頁擷取；要連網得靠一個 Skill，包在類似 curl 或 playwright這樣的工具外面，或是單純用 bash: curl … 指令。

跑的時候每張卡片都會即時計時、計費，session 的累計總額就在頂部工具列。進行中的工作區

• 每張卡片標著 自己的工具跟檔案 —— write notes.md 花了 5 秒， read notes.md 花了 2 秒——下面各自有一行費用，不用自己算，慢的或貴的那一步一眼就看得出來。
• $0.02 在頂部工具列，是這個 session 目前累計的總額。這是整場對話的金額，不是一個月的用量。
• Waiting for model… 是最後一個工具結果跟寫出來的答案之間的空檔。沒有卡住。
• 訊息框會變成 Steer now / queue follow-up ，帶著 Steer 跟 Follow-up 按鈕，而右下角的紅色 Stop 則是你的手煞車，留給你讀到一個沒預期到的 bash 指令的那一刻用。

跑完之後，這一輪會收合成一行摘要，隨時能重新打開。

跑完之後兩則訊息、兩次工具呼叫、一個新檔案——左邊的檔案總管顯示得出來。進行中的工作區

• Process details · 2 messages · 2 tool calls 是這次執行收合後的紀錄。點開那一行就能拿回所有卡片。
• EXPLORER 裡的 notes.md 在左邊，就是這個檔案現在真的存在的證明。答案旁邊那個小標籤也標出了它的名字。
• 費用那一行最後寫著 1,152 cache R ——這部分輸入是從快取拿的，這也是為什麼同一個 session 裡的追問，常常比第一則訊息便宜的原因之一。

你這邊最後一道人眼把關

刪掉的行是紅色，前面帶一個 -。新增的行是綠色，前面帶一個 +。中間白色的行是沒改動的上下文，就跟程式碼託管網站上的 diff 一模一樣。

當 agent 對一個它有基準版本可比對的檔案，提出或執行一次編輯時，就會出現 diff。一段獨立的程式碼範例沒有基準版本，所以不會產生 diff——這本身就是個訊號，代表沒有東西真的跟你實際的檔案比對過。

把整個修補讀完，不要只看螢幕裝得下的部分。像 Show details、 Apply、 Copy 跟 Compare HEAD 這類控制項，有沒有、長什麼樣，要看你的 pi-web 版本跟啟用的防護機制，你看到的可能不一樣。

處理一個 diff 有三種做法

一輪對話從頭到尾實際長什麼樣

假設你要求一個晚上十點的客廳燈光自動化。這個 session 有檔案工具，還有 home-assistant-best-practices 這個 Skill——它加的是指引，不是新工具，會把 agent 推向用 edit 而不是整個重寫 automations.yaml。這一輪回來的東西，可能分成五個部分。

flowchart TD
  A["1 · 思考塊
22:00 觸發、light.turn_off
目標 light.living_room"] --> B["2 · 工具卡：read
path: /config/automations.yaml"]
  B --> C["3 · 工具卡：edit
加上新增項目的內嵌 diff"]
  C --> D["4 · 同一張卡片裡的結果
成功，或 old_string 沒對上"]
  D --> E["5 · 最終答案
一份摘要，加上重新載入的指引"]
  E --> F["6 · 你驗證設定
並安全地測試這個自動化"]

如果你只讀「完成了」這幾個字，你就從沒看過路徑、entity ID、精確的 YAML，或這個工具到底有沒有真的成功。這四件事，就活在這些區塊裡。

每個區塊都是 token

這三種都可能增加你的用量，只是各家路線計費方式不同。一個思考塊可能就多出幾百到幾千個 token。一個很大的 read 會把很多檔案內容塞進你的 context，而這個 context 下一輪還會再繞回來一次。

真正會改變數字的，是這三個：

• 只有任務真的需要時才用 reasoning。 單純查資料或風險低的問題，從你的目錄裡選一個目前比較便宜、不推理的模型就好。
• 問之前先想清楚它需要多少檔案內容。 如果只有某個範圍重要，就要求那個範圍就好，不要把幾千行不相干的內容都塞進 context。
• 一個 session 變長了，就開新的。 舊的思考塊跟工具輸出會一路帶進之後的每一輪。盯著 contextUsage 這個指標看，如果你的版本有顯示 context window 用掉的百分比。

至於能不能把它們藏起來：官方文件記載的 0.8.4 版本基準，沒有一個保證能壓住所有思考塊的全域開關。有的只是「一開始要不要展開」的顯示偏好設定。

Settings → General是顯示偏好，不是計費開關。

• Expand thinking blocks by default 就是大家在找的那個開關。這裡是關閉的，所以思考塊一出現就是收合狀態。它決定的是顯不顯示，不是有沒有在推理。
• Appearance ——Light、Dark 或 System，這裡設成 System，跟著你瀏覽器本來的主題走。
• 這個分頁其餘的部分是 Chat content width 設成 820px，還有 Chat font size 設成 14px。這些是閱讀舒適度，跟一輪對話花多少錢無關。

真的想省下推理的花費，就在路線支援的地方改模型設定裡的 reasoning 選項，或者選一個不推理的模型 ID。畫面整潔一點，不會讓帳單變少。

六種會出狀況的情形

接下來往哪走