【2026 最新】METR Time Horizon 是什麼？AI 能做幾小時任務（50%／80% 教學）

你在社群上看到一條陡峭上升的曲線，旁邊寫著「AI 已能完成數小時的任務」，很容易把它讀成：模型可以不間斷工作幾小時，甚至很快就會接手一整份工作。問題是，圖上的「小時」不是 AI 的執行時間；50% 與 80% 也不是兩種畫圖風格。門檻、對數軸與任務樣本只要讀錯一個，結論就可能完全相反。

這篇 METR Time Horizon 教學專為第一次看這張圖的人寫。我會先把座標、曲線與信賴區間翻成白話，再用一組合成資料，在 Google 試算表或 Excel 重建 50%／80% 門檻。最後，你會得到一套能測自己 AI 工作流的方法，而不是背下一個看似精確的模型時數。

全程不需要寫程式。你只要會貼公式、記錄成功與失敗，就能分清楚「benchmark 能證明什麼」與「它沒有證明什麼」。

先說結論：這是可靠度邊界，不是 AI 工時表

一句話定義：Time Horizon(p) = 擬合曲線上成功率等於 p 時，對應的人類專家任務工時。例如 80% Time Horizon 是 40 分鐘，意思是：在這套評測任務與固定代理設定下，人類專家約需 40 分鐘完成的任務，模型被估計有 80% 機率成功。它不表示模型會跑 40 分鐘，也不表示所有 40 分鐘工作都能交給 AI。

• 50% 門檻是擬合曲線在該人類任務時長上預測 50% 成功的位置；它不代表每一道題都像丟硬幣，也不適合直接作為無人看守的交付門檻。
• 80% 門檻要求較高可靠度，所以在正常向下傾斜的成功率曲線上，一定比 50% 門檻短；它是成功率門檻，不是 80% 信賴區間。
• 任務時數是人類基準工時，不是模型 wall time（從啟動到結束的實際經過時間）。
• 一個數字是許多任務與多次嘗試擬合出的整體位置，不是每一題都在那個時數突然由會變不會。

如果你已熟悉 benchmark，但常被單一分數牽著走，可以先補上 AI Evals 的測試與回歸觀念；若你想知道排行榜為何不能直接等同產品體驗，則接著看 AI 模型排行榜判讀教學。

先拆開四個常被混在一起的量

把 Time Horizon 想成登山路線的難度標尺：人類完成時間只是拿來排列任務難度的代理量，模型成功率才是被觀察的結果。要讀對圖，請把四欄分開記。

1. 人類專家工時：多數任務以具相關專業者成功完成任務的時間取幾何平均；部分任務改用專家估時或 QA 執行時間。這些基準多屬低情境條件，不等同熟悉專案的在職維護者工時。
2. 模型 wall time：AI 實際跑了多久。它會受供應商速度、推理預算、工具等待與重試影響；無論出現在圖的哪個軸，Time Horizon 都不是這個時間。
3. 成功率：同一模型加同一 scaffold（把模型接上工具、提示、權限與執行環境的外殼）多次嘗試後，通過預先定義驗收的比例。
4. 人類介入：中途提示、修錯、選答案或重啟，都可能把「自主成功」變成「人機協作成功」。兩者有用，但不能放在同一欄比較。

METR 的目前方法頁也直接提醒：Time Horizon 不是自主運行時間；成功的代理往往比人類基準更快完成，但執行時間會隨設定改變，因此沒有被當成這個指標的定義。這也是為什麼「AI 能做幾小時」是一句方便的簡稱，卻不是字面答案。

METR 頁面其實有兩類圖

問題一：同一模型遇到更長任務，成功率怎麼變？

METR 把每次「模型 × 任務」嘗試記成成功或失敗，再讓成功機率隨人類任務時間的對數變化。白話說，越靠右的任務通常越難，曲線便由接近成功滑向接近失敗。曲線穿過 50% 的位置就是 p50；穿過 80% 的位置就是 p80。

成功率 = 1 / (1 + EXP(-β × (LN(h) - LN(人類工時))))
h = 50% Time Horizon，且 h > 0
β = 曲線斜率，且 β > 0；β 越大，成功率下降得越突然

由這個式子可得 p80 = h × (1/4)^(1/β)。p80 不是另一場獨立的「80% 實驗」，而是同一條兩參數曲線的另一個交點；它也不是把 p50 乘上固定折扣，因為曲線斜率不同，兩者距離就不同。METR 的正式流程還會處理任務家族權重與分層 bootstrap（重抽樣估計不確定性），稍後的試算表只保留最容易理解的骨架。

問題二：不同發布日期的模型，Time Horizon 如何移動？

另一張常被轉貼的圖，是把各模型的 Time Horizon 放到發布日期上，再擬合歷史趨勢。Y 軸若採對數尺度，垂直距離相同代表「乘上相同比例」，不是「增加相同幾小時」。曲線在過去看起來接近固定倍增，只是在描述特定資料窗內的擬合；它不是產品時程表，更不能把線直接延伸成某一天必然抵達 AGI。

想把「研究指標」與「AGI 宣稱」分開，可以搭配 AGI 與 benchmark 證據落差閱讀。重點不是否認進步，而是要求每一個外推都說清楚任務分布、模型設定與誤差帶。

看 METR Time Horizon 圖的 6 個步驟

1. 先選 50% 或 80%，再看數字

痛點：只說「幾小時」會隱藏可靠度。解法：先固定門檻，在圖表控制項選 50% 或 80%，再讀交點。在 β > 0 的同一條向下曲線上，p80 應低於 p50；若資料擬合不出 β > 0，或出現 p80 ≥ p50，就停止並報「資料無法識別 horizon」，不要硬算數字。

2. 確認「時間」代表人類基準，並先辨認它在哪個軸

痛點：人會自然把分鐘看成模型運行時間。解法：逐題成功率圖把 human task duration 放在橫軸；歷史趨勢圖則把 Time Horizon 放在縱軸、發布日期放在橫軸，兩者都不是 AI wall time。在筆記欄直接寫 human_minutes，另開 ai_wall_minutes，就不會用「AI 跑了 12 分鐘」去解釋「人類 2 小時任務」。

3. 分清線性軸與對數軸

痛點：對數軸會讓長時間區間看起來被壓縮。解法：在歷史趨勢圖切換 Log scale 與線性顯示，記住它改的是 Time Horizon 的縱軸；若你自己畫單一模型成功率曲線，則把 human task duration 的橫軸設成對數。此時 30→60 與 60→120 分鐘都是 2 倍，因此距離相近；在線性時間軸上，第二段的分鐘差是第一段兩倍。

4. 看點，也看信賴區間

痛點：一個點估計很像精確量測。解法：若官方估計或資料表提供信賴區間，就與點估計一起讀；注意目前逐題 logistic 互動圖本身不顯示 bootstrap 信賴區間。METR 在 2026 年的方法敏感度分析指出，目前任務分布是主要不確定性來源，許多估計的信賴區間在倍數尺度上仍很寬；p80 尤其會受曲線尾端與短任務偶發失敗影響。實務上，先問「合理範圍是否跨過我的決策門檻」，比比較兩個小數點更有意義。

5. 檢查任務分布，而不是只看模型名

痛點：把軟體任務成績外推到所有職業。解法：打開任務說明，確認領域、可驗收性與情境量。METR 的現行套件主要是軟體工程、機器學習與資安，任務相對自足，且能用程式化方式判分。因此，這套結果不足以證明談判、組織記憶、長期客戶關係、模糊審美或多人協調能力也同步提升。

6. 把模型與 scaffold 當成一個受測系統

痛點：以為分數只屬於底層模型。解法：記下模型版本、代理外殼、工具、提示、預算與執行環境。換了其中一項，就視為新的測試條件。這和 Agent harness 交換測試的核心相同：先控制外殼，才知道差異來自模型還是系統。

試算表實驗：親手算出 p50 與 p80

先建立五列合成資料：人類工時依序填 30、45、60、90、120 分鐘；假設每列有 10 次嘗試，成功數填 9、8、5、2、1。這組數字只用來學讀法。以下預先採 add-half（加 0.5 次）教學修正，讓模板日後遇到 0／10 或 10／10 時，不會讓 logit 變成無限大；目前五列本身不需要修正，而且 METR 的現行估計也不是這種平滑後的 OLS。

1. A 欄填 human_minutes，B 欄填 successes，C 欄填 runs。
2. D2 算平滑成功率：=(B2+0.5)/(C2+1)，向下填滿。
3. E2 算時間對數：=LN(A2)；F2 算 logit：=LN(D2/(1-D2))。
4. 任一空白儲存格算斜率：=-SLOPE(F2:F6,E2:E6)，把結果命名為 beta；若 beta<=0，立即停止並回報無法識別。
5. 算 p50：=IF(beta<=0,NA(),EXP(INTERCEPT(F2:F6,E2:E6)/beta))，把結果命名為 h。
6. 算 p80：=IF(beta<=0,NA(),h*POWER(0.25,1/beta))。

這組合成資料會得到 β ≈ 2.83、p50 ≈ 61 分鐘、p80 ≈ 38 分鐘。若 G2 放待預測分鐘，可用 =IF(OR(G2<=0,beta<=0),NA(),1/(1+EXP(-beta*(LN(h)-LN(G2))))) 畫出預測曲線。請把它視為教學用的直線化近似：METR 的正式估計使用每次二元結果、任務家族權重與分層重抽樣，不是把這六條公式貼進表格就完全重現。

想更接近官方流程，可到 METR 公開分析程式庫查看資料與擬合方式；若你只是要做工作決策，上述近似已足以暴露「樣本太少、門檻不穩、設定被偷換」這三種常見問題。

自建 30 分鐘到 2 小時的任務籃：先 smoke test，再畫曲線

真正有用的問題不是「全世界最強模型能做幾小時」，而是「在我的資料、工具、權限與驗收下，哪一段任務值得繼續測」。你可以先用 10 題、每題三次做 workflow smoke test，只報原始成功與失敗；若要畫探索性曲線，再擴成五個 task families、每個 family 橫跨五個時間帶。兩者都不是 METR p80 的重現或正式估計。

1. 痛點：時間和任務類型混在一起。解法：先選五個 benign families，例如離線資料轉換、seeded bug 修復、小型 CLI、schema migration、靜態報表；每個 family 各做 30／45／60／90／120 分鐘附近的變體，共 25 題。
2. 痛點：作者替題目貼時間標籤。解法：每題至少兩位、理想三位合格且彼此分開的人類 baseliner；以實際成功時間決定落在哪個時間帶，保存完成品與離散程度。
3. 痛點：「看起來不錯」無法重跑。解法：在執行前寫二元驗收，例如測試全過、指定欄位齊全、沒有編造引用；若看過答案後才改規則，就標記 protocol deviation、排除主分析，並改用未見過的新題或 variant 在新批次重測。
4. 痛點：一次成功被當成穩定能力。解法：每題用全新對話與乾淨狀態分開嘗試六次，共 150 次；即使如此也只畫探索性曲線，不能宣稱已證明 80% 可靠度。
5. 痛點：中途救援或設定變動污染結果。解法：記錄每次執行時間戳並限定測試視窗；凍結供應商、模型 ID、system prompt、scaffold、工具、權限、token／時間上限；預先約定 intervention_count，中途追加提示就在自主欄記為失敗。
6. 痛點：只剩一個漂亮數字。解法：保存 human_minutes、ai_wall_minutes、human_review_minutes、total_cost、passed、intervention_count 與輸入／輸出快照，並做 leave-one-family-out 敏感度檢查。

執行環境也要先縮小爆炸半徑：使用一次性 container 或 VM、非 root 帳號與唯讀輸入，不放真實工作 repo、個資或 secrets；網路預設關閉，必要時只開 allowlist。Grader 與 hidden tests 不掛載到代理可見環境，只由外部 evaluator 在交卷後執行。基礎設施故障可以依預先規則重跑，但有效環境裡的 timeout、拒答或提早交卷都應保留為失敗。

判讀時，先把目標成功率 q 的交點寫成 T_q，例如 T_0.5 = p50、T_0.8 = p80。若 T_q 跑出 30–120 分鐘觀察範圍，只能報 T_q<30 或 T_q>120，不要刊出區間外的精確外插值；若 β 無法辨認，也要誠實停止。擴大任務籃中觀察到約 80% 通過的時長區間，仍只是需要人工驗收的探索性邊界；在同一擬合模型與任務分布內，p80 名目上對應約 20% 預測失敗，不保證部署後的長期實際失敗率，更不是安全門檻。若你準備把實驗變成固定流程，AI Agent Harness會補上狀態、工具與停手條件。

四種最容易把圖讀壞的外推

• 「8 小時＝一個工作日都能自動化」：錯。工作不是一條自足、可自動判分的連續題目，還包含背景知識、溝通、等待、責任與多目標取捨。
• 「能做 1,000 個一小時任務＝1,000 小時 horizon」：錯。可平行或可獨立重複的工作只增加吞吐量，不會自動變成一條更長、不可拆的連續推理鏈。
• 「歷史倍增速度＝未來倒數計時」：錯。任務套件、涵蓋範圍、統計模型與可用資料都會改變；在觀測區間外延伸得越遠，不確定性越大。
• 「p80 比 p50 更接近真實，所以只看 p80」：不完整。p80 更符合高可靠度問題，卻也更依賴曲線斜率與短任務的偶發失敗；兩個門檻應並列，並一起看誤差帶。

METR 2026 年 3 月的方法敏感度說明很值得在看到精確時數時重讀：替代曲線、任務家族權重、人類工時誤差與公開／非公開題目都可能移動估計，p80 通常比 p50 更敏感。正確姿勢不是放棄量測，而是把點估計當成「目前資料下的最佳定位」，不是自然常數。

2026 年版本變動：不同圖不能直接拼接

METR 在 2026 年推出 TH1.1，擴充並更新任務套件，也更換部分評測基礎設施。TH1.1 公告列出的套件由 170 題變為 228 題，其中 8 小時以上任務由 14 題增至 31 題，且 31 題中只有 5 題使用實測人類基準，其餘依賴估時。這讓長任務覆蓋較好，卻不會消除長尾樣本稀少的問題。截至官方儀表板 2026 年 5 月 8 日更新，METR 明確標示：現行套件對高於 16 小時的 Time Horizon 估計不可靠。

此外，METR 在 2026 年 3 月 3 日修正一項正則化建模錯誤，使部分近期模型的 p50 估計最多下修約 20%。這不是「模型突然退步」，而是方法修正改變了估計。比較兩張社群截圖前，至少先核對 task suite、method version、reliability 與 scaffold 四個欄位；其中任一不同，就不要只比點的高低。

METR Time Horizon 常見問題

1. Time Horizon 是 AI 可以連續運行的時間嗎？

不是。它的時間來自人類專家完成任務的基準，不是模型從開始到停止的 wall time。請把兩個時間放在不同欄位。

2. 50% Time Horizon 達到 2 小時，代表一半的 2 小時工作都能做嗎？

不代表。它是特定任務分布上的擬合交點；同樣是人類 2 小時，有些題幾乎總成功，有些幾乎總失敗。

3. 為什麼 80% Time Horizon 一定比 50% 短？

因為可靠度要求更高。在任務越長、成功率越低的擬合下，要維持 80% 成功就必須退回較短任務；差多少由斜率 β 決定。

4. p80 是否比 p50 更適合企業決策？

p80 比 p50 提供更嚴格的成功率觀察，但不能因此視為企業委派門檻。在同一擬合模型與受測任務分布內，它名目上對應約 20% 預測失敗，不保證部署後的實際長期失敗率，且對模型選擇與樣本不足更敏感；應連同失敗成本、可驗證性、信賴區間與失敗型態決定所需可靠度。

5. 對數軸是不是在誇大 AI 進步？

不是，前提是標示清楚。對數軸適合呈現跨多個數量級的倍數變化；誤導發生在讀者把相同距離誤認成相同小時。

6. 這張圖可以預測 AGI 日期嗎？

不能單獨做到。它量的是特定、可評分的長軟體任務能力；AGI 還牽涉跨領域泛化、現實互動、可靠性與定義本身。趨勢線只是一項證據。

7. 我可以用自己的工作資料做類似評測嗎？

可以做受 Time Horizon 啟發的本地重複評測，而且能輔助內部決策。但 10 題、30 次的練習不足以稱為 METR p50／p80 或研究級可靠度曲線。

8. 哪個數字最值得每天追？

沒有單一數字。正式設計可放 p50、p80 與經合格階層 bootstrap 得到的 horizon 信賴區間；小型 smoke test 則只放原始成功／失敗、樣本數與 leave-one-family-out 或基準時間敏感度範圍。兩者都要標任務範圍、模型＋scaffold 版本與失敗原因。

給新手的 5 個重點

1. 圖上的小時是人類專家基準工時，不是 AI wall time。
2. 先選可靠度；p80 比 p50 短，而且通常更不穩。
3. 對數軸讀倍數，線性軸讀差值；切換一次再下結論。
4. METR 主要量低情境、可驗收的軟體／ML／資安任務，不能直接代表所有職業。
5. 真正可行的應用，是用相同概念建立自己的任務籃紀錄，再以權限與驗收限制委派範圍。