TokenLab Request Console：從單一儀表板除錯 AI API 呼叫

失敗的 AI API 呼叫很少會明確地通知您。您通常只會收到狀態碼、可能的一串錯誤訊息，以及一個支援頻道，裡面有人問：「請求 ID 是什麼？」如果您手邊沒有這個 ID，調查工作在開始前就會陷入停滯。

TokenLab Request Console 的存在就是為了縮小這個差距。它將請求層級的詳細資訊（模型、金鑰、快取狀態、計費狀態、時序以及經過遮蔽的酬載預覽）整合到單一儀表板視圖中，讓您可以從「此呼叫失敗」直接轉向「失敗原因」，而無需從三個不同的地方拼湊日誌。

本文將引導您了解控制台顯示的內容、發生問題時應優先檢查的項目，以及它如何與使用量匯出功能配合，以滿足需要成本層級報告的團隊需求。

重點摘要

• Request Console 是 TokenLab API 儀表板內的一個請求層級除錯介面，而非計費報告。
• 每個請求都有一個可以直接搜尋的 ID，您可以使用 URL 中的 requestId 深度連結到特定請求。
• 控制台顯示近期請求的路由、計費狀態、快取狀態、模型/金鑰上下文以及經過遮蔽的酬載預覽。
• 存取權限範圍限於您的組織，並由儀表板成員權限管理——團隊成員僅能看到其角色允許的內容。
• 若要進行單一事件除錯，請使用控制台。若要進行跨時間範圍的批次成本審查，請改用使用量匯出功能。

什麼是 Request Console

您可以透過 https://tokenlab.sh/en/dashboard/api?tab=requestConsole 存取它，該頁面位於 TokenLab 儀表板的 API 區塊內。它的核心前提是：當請求失敗時，最快的修復方式是讓您掌握完整的上下文，而不是僅憑錯誤訊息進行猜測。

儀表板說明將控制台描述為近期請求的檢查器，涵蓋路由、計費、請求/回應主體以及模型供應商上下文。實際上，它分為幾個工作區塊。

列表視圖 (List view)。 一個可篩選的近期請求表格。當您還沒有特定的請求 ID 時，這是您的起點——您可以從中掃描失敗或異常的呼叫。

檢查器面板 (Inspector panel)。 一旦您選擇了一個請求，檢查器就會開啟並顯示完整細節：由哪個模型提供服務、使用了哪個 API 金鑰、是否命中快取，以及最終狀態為何。

錯誤上下文 (Error context)。 如果請求失敗，控制台會顯示與該特定呼叫相關聯的錯誤資訊，因此您無需交叉比對單獨的錯誤日誌。

路由與計費狀態 (Route and billing state)。 顯示請求是如何路由的，以及它是已計費、待處理、已退款還是已失敗——當客戶詢問「我是否因為該錯誤而被收費？」時，這四種狀態最為關鍵。

酬載預覽 (Payload preview)。 在可用時，請求和回應主體會以遮蔽後的預覽形式顯示，讓您在不暴露主體中原始機密的情況下，了解其形狀與結構。

模型供應商與模型金鑰上下文 (Model vendor and model key context)。 顯示處理該呼叫的供應商與特定模型——當您在單一整合後方執行多個模型並需要確認是否調用了正確模型時，這非常有用。

這一切都不需要您在 API 之上建立自己的日誌管線。它已經按組織呈現，並由儀表板成員權限進行篩選，因此擁有適當存取權限的團隊成員可以看到與您相同的請求資料。

優先檢查的項目

當 API 呼叫失敗時，檢查順序是有邏輯的。在確認請求是否確實到達正確端點之前，直接跳到「模型是否當機」只會浪費時間。

五欄位分類檢查

檢查項目	說明
請求 ID (Request ID)	確認您正在查看的是該特定呼叫，而非類似的呼叫
狀態 (Status)	已計費、待處理、已退款或已失敗——告訴您這是成本問題還是技術問題
模型 (Model)	實際服務該請求的模型（若您跨多個模型路由，此項很有用）
快取狀態 (Cache state)	提示詞快取命中或未命中是否改變了成本或延遲
金鑰來源 (Key source)	使用了哪個 API 金鑰，當多個金鑰或環境共享一個整合時很有用

從請求 ID 開始。如果您從用戶端日誌、支援票證或錯誤報告中獲得了該 ID，請使用深度連結模式：

https://tokenlab.sh/en/dashboard/api?tab=requestConsole&requestId=<request_id>

這會直接在該請求上開啟檢查器，完全跳過列表視圖。當有人給您一個 ID 並詢問「這裡發生了什麼事」時，這是最快的途徑。

如果您還沒有請求 ID，控制台的篩選器可讓您按模型、時間範圍、提示詞快取狀態、金鑰來源和狀態進行縮小範圍。常見模式：篩選過去一小時內「失敗」狀態的請求，然後掃描列表以找到使用者詢問的特定呼叫。

正確解讀狀態欄位

四種狀態（已計費、待處理、已退款、已失敗）回答了不同的問題：

• 已計費 (Billed) 表示呼叫已完成並消耗了點數。如果使用者回報錯誤但請求顯示已計費，則值得單獨標記，因為這暗示失敗發生在收到成功回應後的用戶端。
• 待處理 (Pending) 表示請求仍在傳輸中或等待結算。請勿過早將其視為失敗。
• 已退款 (Refunded) 表示 TokenLab 已撤銷該筆費用，通常與供應商或路由端的失敗有關。
• 已失敗 (Failed) 表示呼叫未成功完成且未被計費。

在升級問題之前了解適用哪種狀態，可以節省與支援團隊來回溝通的時間。

確認模型與快取狀態

如果您透過共享整合對 Claude Sonnet 5、DeepSeek V4 Pro 或 Gemini 3.5 Flash 等模型執行請求，確認控制台顯示的是您預期的模型非常重要。設定錯誤的用戶端、過時的環境變數或路由覆寫都可能在沒有明顯用戶端錯誤的情況下，將流量發送到錯誤的模型。

快取狀態對成本和延遲都很重要。如果您預期命中快取卻發生未命中，通常意味著提示詞前綴發生了變化，即使是很細微的變化——例如時間戳記、重新排序的欄位或額外的空格字元。控制台的快取狀態篩選器可讓您並排比較命中與未命中的請求。

它如何與使用量匯出功能配合

Request Console 和使用量匯出功能解決的是不同的問題，明確界定邊界很重要，這樣您才不會用錯工具。

控制台是為單一請求調查而建：一個呼叫、一個錯誤、一個計費問題，都在檢查器面板中解答。當特定請求失敗且您需要立即知道原因時，請開啟它。

使用量匯出功能是為總體審查而建：跨時間範圍的支出、按模型或金鑰分類的明細，以及您會交給財務利害關係人或用於每月對帳的報告。如果您試圖回答「我們上週在 DeepSeek V4 Pro 上花了多少錢」，這是匯出功能的問題，而非控制台的問題。請參閱 TokenLab 儀表板使用量匯出指南以了解該工作流程。

簡而言之：控制台用於處理事件，匯出功能用於統計總數。有些團隊會依序使用兩者——匯出功能顯示總支出異常，而控制台則是您深入調查導致該異常的特定請求的地方。

實用的除錯常規

臨時除錯在壓力下會變成猜謎遊戲。一套可重複的常規可以防止事件拖延過久。

檢查清單：當請求失敗時

1. 取得請求 ID。 從您的用戶端日誌、錯誤回應或使用者報告中取得。如果您目前沒有記錄請求 ID，現在就開始——這是您擁有的最快查詢鍵。
2. 使用深度連結開啟控制台。 使用 requestId 查詢參數直接跳轉到檢查器。
3. 首先檢查狀態欄位。 已計費、待處理、已退款或已失敗——這為後續調查奠定了基礎。
4. 確認實際服務該請求的模型。 將其與您預期發送的模型進行比較。
5. 檢查快取狀態。 預期命中卻未命中可以解釋意外的延遲或成本。
6. 檢查金鑰來源。 確認使用了正確的 API 金鑰和環境，特別是在測試與生產環境並存的設定中。
7. 閱讀錯誤上下文與路由資訊。 這裡通常是實際根本原因顯現的地方。
8. 檢閱遮蔽後的酬載預覽。 確認請求形狀與您的用戶端發送的內容相符——格式錯誤的參數通常會先在這裡顯示，然後才出現在其他地方。
9. 必要時參考 API 參考文件。 TokenLab 聊天完成 API 參考文件記錄了預期的請求與回應形狀，這對於確認酬載是否在用戶端格式錯誤非常有用。
10. 如果是模式而非單一事件，請切換到使用量匯出。 單一失敗請求是控制台的問題。一小時內十個失敗請求則是一個值得匯出並進行總體審查的模式。

遵循這個順序——ID、狀態、模型、快取、金鑰、錯誤、酬載——可以防止您跳過真正解釋失敗原因的欄位。

後續步驟

如果您目前是透過 grep 搜尋自己的用戶端日誌並交叉比對單獨的計費儀表板來除錯 AI API 失敗，Request Console 可以減少該迴圈中的步驟。請從尋找最近一次失敗的請求並直接開啟它開始。

• 開啟控制台並透過 ID 定位請求：https://tokenlab.sh/en/dashboard/api?tab=requestConsole
• 在 tokenlab.sh/en/dashboard/api 建立 TokenLab API 金鑰，開始從您自己的控制台或指令碼發出請求。
• 如果您懷疑酬載格式錯誤，請檢查聊天完成請求/回應形狀：https://docs.tokenlab.sh/api-reference/chat/create-completion
• 若要進行總體支出審查，請使用使用量匯出而非控制台：https://tokenlab.sh/en/blog/tokenlab-dashboard-usage-exports
• 如果您在切換前正在比較模型的成本或能力，模型目錄有最新的定價與上下文視窗詳細資訊：https://tokenlab.sh/en/models

常見問題 (FAQ)

什麼是 TokenLab Request Console？ 它是 TokenLab API 儀表板內的一個請求層級除錯視圖。它顯示近期請求的路由、計費狀態、快取狀態、模型與金鑰上下文以及遮蔽後的酬載預覽，範圍限於您的組織。

我可以透過請求 ID 檢查請求嗎？ 可以。使用深度連結格式 /dashboard/api?tab=requestConsole&requestId=<request_id> 直接在特定請求上開啟檢查器，或從列表視圖中按請求 ID 搜尋。

控制台會取代使用量匯出嗎？ 不會。控制台用於調查個別請求——單一失敗、單一計費問題。使用量匯出用於跨時間範圍的總體支出審查。當匯出功能揭示了您需要深入挖掘的模式時，請同時使用兩者。

當 AI API 請求失敗時，我應該先檢查什麼？ 從請求 ID 開始以確認您查看的是正確的呼叫，然後檢查狀態欄位（已計費、待處理、已退款、已失敗）、實際服務該請求的模型以及快取狀態。從那裡，錯誤上下文和酬載預覽通常會讓根本原因顯現出來。

來源與時效性

• TokenLab Request Console — https://tokenlab.sh/en/dashboard/api?tab=requestConsole — 觀察日期 2026-07-09
• TokenLab Chat Completions API 參考 — https://docs.tokenlab.sh/api-reference/chat/create-completion — 觀察日期 2026-07-09
• TokenLab 儀表板使用量匯出 — https://tokenlab.sh/en/blog/tokenlab-dashboard-usage-exports — 觀察日期 2026-07-09
• TokenLab 公開模型目錄 — https://tokenlab.sh/en/models — 觀察日期 2026-07-09

所引用的模型範例（Claude Sonnet 5、DeepSeek V4 Pro、Gemini 3.5 Flash）反映了截至 2026-07-07 的當前模型單一事實來源 (SSOT)。如需確切的當前定價與可用性，請在做出路由決策前與上述模型目錄連結進行核對。