對 Claude Code 使用情況的詳細分析顯示，AI 代理人消耗的電力，可能遠高於人們常用來描述 AI 能源足跡的簡單聊天提示。氣候科學家 Zeke Hausfather 追蹤了自己為期八週的程式設計代理活動，估算 1,138 次手動輸入約消耗 170 千瓦時的資料中心電力。

換算下來，每次輸入約為 150 瓦時——大約是 Google 和 OpenAI 所引用典型文字查詢 0.24 到 0.34 瓦時的 600 倍。這個比較並不是對所有代理工作負載的普遍測量，但它凸顯出：當軟體代理反覆呼叫模型、處理大量上下文並自主運作時，單一使用者請求背後可能隱藏多少能源消耗。

Hausfather 在 Claude Code 中測量了什麼

Hausfather 透過 The Climate Brink 發表了他的發現，The Decoder 也有報導。他的本機 Claude Code 日誌記錄了八週使用期間的 token 數與模型呼叫。1,138 個提示觸發了超過 14,000 次模型呼叫——平均每次輸入約 12 次呼叫——並處理了約 32 億個 token。

這些處理中最大的一部分來自上下文管理，而不是顯示給使用者的文字。根據分析，約 96% 的 token 是快取讀取，因為代理在連續步驟中反覆重讀其累積的上下文。畫面上可見的模型輸出僅占處理 token 的約 0.4%。

Hausfather 估算總耗電量為 170 kWh，但也給出 70 到 330 kWh 的寬廣不確定範圍。token 數據來自 Claude Code 日誌；要把這些數字轉換成用電量，則需要三種不同的估算方法，以及對每個 token 能耗的假設。

最後呈現出的工作負載並不平均。中位數工作階段約耗電 0.6 kWh，而每日平均耗電達到 3.0 kWh，範圍在 1.2 到 5.9 kWh 之間。最密集的一天涉及多個平行代理處理地理資料分析，估算耗電 11 kWh。

為什麼簡單的提示比較不夠

Google 表示，Gemini 的中位數文字提示耗電 0.24 瓦時。OpenAI 執行長 Sam Altman 則估算，ChatGPT 的平均查詢耗電 0.34 瓦時。這些數值描述的是狹窄的查詢類型，未必能與一個透過多步推理完成任務的程式碼代理相比。

這個區別很重要，因為「一次提示」是使用者介面上的事件，而不是一個一致的運算單位。根據 Hausfather 的比較，一般聊天往返大約涉及 1,000 個 token。他的 Claude Code 輸入平均處理了約 290 萬個 token，包括重複的上下文和中間呼叫。

推理模型、網路搜尋、影像與音訊處理、程式碼生成，以及多代理工作流程，都可能改變一次請求背後的運算量。代理在回傳結果前，還可能重試操作、檢查檔案、執行測試、修訂程式碼並呼叫工具。因此，只顯示初始提示的產品儀表板，可能會掩蓋實際工作負載。

這並不代表每一次使用 AI 代理人 都會比聊天請求多消耗 600 倍電力。這個數字是根據單一重度使用者的 Claude Code 模式，與已公開的低端查詢估算做比較而得出的推估。不過，它確實說明了為什麼平均每次提示的數字不能被視為代理式 AI 的完整核算。

證據、不確定性與碳排放問題

這項分析提供了異常具體的使用資料，但並未直接測量資料中心的耗電量。Hausfather 的不確定範圍相當大，而每個 token 的能耗假設也無法由 AI 公司外部獨立驗證。The Decoder 也指出，外部人士無法得知領先商用模型每個 token 的精確能源成本。

碳影響不只取決於電力總量。Hausfather 預估，若要把這種使用水準維持一年，資料中心電力需求約為 1.1 兆瓦時，範圍在 0.4 到 2.2 MWh 之間。以美國平均電力結構計算，他估算每年約排放 370 公斤二氧化碳當量。

若在大多數電力都屬清潔能源的電網中，這個數字會更低；若電力來自高碳發電，則會更高。Hausfather 估計，若以大致清潔的電力運行同樣工作負載，其碳足跡可降低約 90%。他的結論是，相較於要求少數重度使用者停止使用代理，電力來源或許是更重要的槓桿。

他也認為，小型模型適合日常任務，因為根據他的分析，它們每個 token 的能耗比前沿模型低約五到七倍。這是一項方向性的建議，而不是普遍適用的採購規則：模型效率、品質、延遲、硬體以及重試次數都會影響最終結果。

這些發現對 AI 建構者與採購者的意義

對開發者而言，最直接的教訓是：應測量完整的代理執行過程，而不是只計算使用者提示。團隊應追蹤模型呼叫、輸入與輸出 token、快取讀取、工具呼叫、重試、平行工作者，以及任務總耗時。這些指標可以揭露：看似便宜的功能，實際上可能在後端產生大量工作。

這些發現也讓路由策略變得更關鍵。較小的模型可以處理分類、檔案查找、格式化或簡單程式碼變更，而更強大的模型則保留給真正需要深度推理的任務。上下文裁剪、檢索設計、快取，以及對自主迴圈的限制，都可能同時降低成本與耗電量，不過過度嚴格的限制也可能降低可靠性。

企業採購者應該詢問供應商，他們如何計算能源與碳排聲明。每次查詢的數字可能排除了隱藏推理、快取上下文、工具呼叫或資料中心額外開銷。評估程式碼助理或工作流程代理部署的買家，需要的是與工作負載相關的估算，而不只是輕量聊天流量的平均值。

這項分析也引出一個部署問題：那些設計為可運行數天或數週的產品，若持續執行更長時間的自主任務，能源需求可能遠遠超出 Hausfather 記錄到的使用模式。這不是預測，但它提醒我們，在組織大規模導入之前，應先在代理架構中納入能源、成本與終止控制。

接下來要觀察什麼

下一個有用訊號，將是針對不同模型家族、硬體配置與代理框架所做的每個 token 能耗獨立測量。若 AI 實驗室能更清楚地報告，供應商的聲明就會更具可比性，特別是當公司揭露數據是否包含推理、快取、工具呼叫與冷卻額外成本時。

產品團隊也應關注實用控制，例如模型路由器、上下文預算設定、代理步驟上限，以及工作負載層級的能源儀表板。在基礎設施方面，由天然氣提供的新建資料中心電力占比，以及對清潔能源、電網擴建、地熱或核能的投資，將決定新增電力有多少會轉化為排放。

Creati.ai 觀點

Hausfather 的分析並未顯示 AI 代理天生浪費，也沒有推翻簡單聊天較低的能耗估算。它只是說明：被衡量的單位很重要。對代理而言，使用者的提示可能只是漫長計算工作流程的開端。

對建構者與企業買家來說，務實的回應是更好的記帳：測量完整任務、把工作路由到最小可行模型，並為自主執行設計限制。當產品層級的報告能反映代理實際做了什麼，而不只是使用者輸入了什麼時，能源辯論才會變得更有意義。