在 Day 22 一開始我們對於 Heimdall 的期待其實只有三個：看成本與快取的 Dashboard、審視執行軌跡的 Step Timeline，以及看模型上下文的 Context，所以其實已經滿足我的基本期待了。不過我也在想還能再做些什麼？或許有，在看完前幾天 Heimdall 呈現的數據後，我確實有個疑問：「所以具體怎麼樣的操作是花 Token 的？」

因此，Heimdall 又多了第四個頁面：Insights。這個功能目前更像是一個還在摸索的小實驗，我其實也不確定實用性，今天反正就亂亂做亂亂聊吧～

一、以「User Task」為核心

要回答「具體怎麼樣的操作是花 Token 的？」，首先得定義什麼叫做「一次操作」。

當使用者在終端機輸入一次 Prompt 要求 AI Agent 做事（一個 User Step），AI Agent 背後往往會展開一連串的 ReAct 循環，包含「思考、調用工具、再思考、再調用工具 ... 」，甚至中間可能還經歷了一次 Checkpoint 壓縮，最後才完成這次的要求。如果只看單次模型呼叫，很難看出我們那一次具體要求到底消耗了多少資源。因此，我們將觀察單位定義在 「User Task（使用者任務）」：

• 什麼是一個 User Task？
  從一個 User Step 開始，到下一個 User Step 前結束，這整個區間定義為一個完整的 User Task。也可以說是一個 完整的 ReAct 循環，中間可能包含多次 Model、Tool 與 Compaction，直到 AI Agent 結束這輪任務。

• 一個 Task 消耗了很多 Token 代表什麼？
  可能代表任務較複雜，需要較長的 ReAct 循環來完成；也可能代表問題定義較模糊，模型需要思考的次數較多，就會有較多 Thinking 的流程。

因此，Insights 的定位很單純，它做的事情就是 把 Token 消耗最大的前幾筆任務列出來，方便我們循著線索回到該輪任務，分析 Token 消耗的由來。

二、四大觀察維度

在 Insights 頁面中，透過 h / l（或左右方向鍵）可以在四個分類之間切換，每個分類回答一個單純的問題：

• Task Usage（任務總處理量）：
  • 回答問題：哪些使用者任務讓模型處理了最多 Token？
  • 計算方式：該任務區間內所有可觀測模型呼叫所累積的 Cached Input、Uncached Input、Thinking Output 與 Content Output Token 總量。由於每一次模型呼叫中重複傳入的 Context 都會再次計入，因此這裡的總 Token 量會比較大，但也確實代表了每次推論實際送進模型被處理的總量。
  • 實際例子：以下面 4830 這個花費最多 Token 的任務為例，首先我們可以看到右下角的 Context Start 有 201,227 Tokens，表示這輪一開始發送 Request 所帶的 Context 就已經非常龐大，所以總 Token 量自然偏多。接下來的 4000、1239、4245 也是類似情形。但我們可以看到 4054 那輪，總共有 77 個 Steps 但為什麼 Token 消耗量反而較少呢？原因是中間有做一次 Compact，如果我們實際去看他當時在做什麼，我記得是我請他幫我規劃一下這 30 天鐵人賽的題目要怎麼切，所以他要每篇文章都跑過，所以花了很多 Steps，看了很多文件哈哈。

• Task Output（任務可見回答）：
  • 回答問題：哪些使用者任務累積產出了最多最終可見的文字回答？
  • 計算方式：累加該任務區間內所有可觀測模型呼叫所產生的 Content Output Token 總和。
  • 實際例子：這裡的 4000、4349 這幾輪輸出較多文字給我看的任務，這些任務當時也是類似請 AI 規劃第 N 版的鐵人賽 30 天主題，只是那時候已經賽中了，它就根據過去幾天規劃一下未來有哪些方向可以走，或是調整未來幾天的架構。過程中因為要重構與摘要好幾天的內容，還要總結給我聽，所以就產生了很多 Output Token，但至少知道是個健康的流程。

• Task Thinking（任務思考量）：
  • 回答問題：哪些使用者任務累積了最多思考 Token？
  • 計算方式：累加該任務區間內所有可觀測模型呼叫所累積的 Thinking Output Token 總和。
  • 實際例子：這裡就比較有趣了，我在這裡也確實很好奇是什麼情況會讓模型想這麼多。那以 5607 為例的話，當時的 User Prompt 大概是：「幫我看一下 Day 20 ，md 結構是不是跑掉了。然後我有改個標題，檔名幫我更新一下。然後引言我有調整請不要動，其他請根據 Day18, 19 的內容口吻，潤飾 Day20 的內容。」這裡可以大概推測原因可能是我在一次 User Prompt 裡面叫他做了多個不是很相關的事情，並且當中還有模仿口吻這種較模糊的任務，當時我就只是單純想到很多事要叫它做，希望能一次做好這樣。很明顯遇到這樣的情況，他就會需要比較多輪的思考。4349 則是剛剛上面提到的規劃類型任務，當然他也做了多輪的思考。

• Tool Outputs（本機工具輸出）：
  • 回答問題：哪些本機工具執行的輸出字數最多？
  • 計算方式：使用本地分詞器（例如：cl100k_base）進行本地 Token 估算。這裡純粹衡量工具吐出的結果，不包含模型本身的推論與回答。
  • 實際例子：這裡也很有趣，我就好奇到底什麼樣的 Tool Call 結果會很大，想說或許後續就可以針對一些特定 Output 來做處理。以 2439 跟 2045 為例，當初請 AI 針對 Excalidraw 的內容做一些調整，因為 Excalidraw 在背後是用 Markdown 存了很多處理過的長字串，光是把那個字串讀進來，就花了非常多的 Token 量。4190 這次同樣是在規劃 30 天的內容，所以 Edit 了一整份檔案。（比較讓我意外的是我以為讀跑 Test 的結果會很耗 Token，但可能因為是個小專案，所以 Test 的量沒有到很多，印出來的結果就沒有到很多）

在操作上，只要在清單中用 j / k 選中某個任務後，按下 Enter 鍵，畫面會直接切換到 Step Timeline 頁面，並自動跳到該 Task 的起始 User Step。這樣如果看到某個任務特別龐大，按一下 Enter 就能直接查閱當時的使用者需求與後續步驟。

完了突然覺得這樣好赤裸，會不會被你們發現我下 Prompt 的方式非常簡單暴力啊 XDD

Heimdall 這個篇章竟然到 （九） 了！當初規劃想做的三個主要觀測畫面，加上這次額外嘗試的 Insights 頁面，其實大致就是這樣了。回顧一下吧！我們從最一開始調查散落在本機裡的各種 Antigravity CLI 資料，到最後組裝出一個可以隨時查看成本、Step History、Context Prompt 與一些小分析的終端介面，整個過程雖然花了不少時間摸索，但確實變得更了解 Antigravity CLI 的運作，也更能掌握它的思考脈絡與 Token 消耗。

Finally，剩最後三天！我也還沒確定接下來的內容（其實有大概的想法啦，畢竟你們也看到了，我請 AI 幫我規劃了好幾次 XDD），最後一哩路，有興趣的話就陪我一起走完吧！感謝一直看到現在的讀者們，辛苦了 <3