AI 代理連續工作一天半，是否就代表它能可靠完成任務？Third Moment Research 的案例讓長時間運作有了具體規模，但執行多久、同時啟動多少代理，回答的是系統能運轉到什麼程度；任務是否正確完成，仍要看另一組證據。
一、長時間運作能證明 AI 代理可靠嗎？
不能只用執行時長判定可靠度。 還要知道任務成功條件、完成率、失敗如何處理，以及結果能否重複驗證。
OpenAI 於 2026 年 10 月 14 日發布 Third Moment Research 案例，描述該團隊同時運行 10,000 個代理，研究工作階段約 36 至 48 小時，並使用多種 OpenAI 模型、Codex 與 Daybreak。
這是值得觀察的長時間、多代理系統案例，但數字的單位要分開看：10,000 指同時運作的代理數量，36 至 48 小時指研究工作階段長度，兩者都沒有直接提供單一任務的成功率。
「在單次工作階段中，GPT-6.1 Sol 能在數天的運算期間維持連貫的計算研究脈絡，不會偏離方向。」Adam Khakhar，Third Moment Research 共同創辦人（OpenAI 報導引述）
也要分清「牆鐘時間」，也就是從開始到結束經過的實際時間，與代理有效工作的時間。工作階段可能包含等待運算、工具回應、代理交接與人工檢視；並行代理則可能各自處理不同子任務。若團隊只報總時長和代理數，外界仍無從知道每個任務做了多少有效工作、是否達成預定結果。
METR 的任務時間跨度評測也提醒，研究中的「時間跨度」通常是任務難度的估計，例如一項工作需要人類專家多久完成，並依多次嘗試估算代理達到某個成功機率的任務長度。它不等同代理實際自主執行了多久，也不能直接拿來替特定企業工作背書。其任務主要來自軟體工程、機器學習與資安，網站也註明目前任務集對超過 16 小時的估計不可靠。
二、長任務為什麼會在中途失去可靠度？
狀態累積、工具失敗、任務偏移和重試循環都可能讓結果逐步偏離目標。 時間越長，越需要保存中間狀態並驗證每個關鍵步驟。
代理每完成一步，就會留下新的檔案、查詢結果、待辦項目或工具狀態。若下一步讀錯版本、漏記已做事項，錯誤便可能沿著後續流程擴大。上下文整理也有代價：濃縮紀錄若漏掉限制條件，代理可能仍然持續操作，卻已忘記任務最初的要求。
2026 年一篇 Long-Transduction（長序列轉換）研究以受控診斷測試檢視長流程中的可靠度。摘要指出，流程拉長、上下文增加、子任務複雜度提高，以及途中出現新資料，都可能形成不同的失敗軸線。
這些因素會讓原本看似單一的任務，在執行後段面臨更多狀態與判斷變化；若只測固定輸入、短流程或單一難度，就可能漏掉部署時才出現的問題。團隊可以把這些軸線轉成自己的測試條件，分別記錄錯誤在哪個階段發生、是否影響後續步驟，以及代理能否在新資料加入後維持原定要求。
測試時可把任務拆成數個可驗收的里程碑，保存每一段開始前的狀態與輸入，再逐步增加流程長度或加入新資料。如此才能看出問題是在上下文累積後才出現，還是某個子任務本身就容易失敗，也能避免只憑最終輸出猜測故障原因。
這項研究不代表所有代理系統的部署預測，卻提醒評測不只要看模型能否讀入長上下文，也要檢查它處理到後段時是否仍遵守操作規則。不同產品的工具、任務和失敗代價並不相同，因此研究結果適合用來提出測試問題，實際門檻仍須由團隊依使用場景訂定。
重試與多代理協作同樣要留意。自動重試可能修復暫時性錯誤，也可能讓相同失敗反覆消耗資源；拆分工作可以提高並行速度，卻增加交接、重複任務和互相矛盾的結果。要檢查每次重試的理由、停止條件，以及不同代理提交的成果是否經過一致驗證。
三、哪些證據能驗收代理完成任務的能力？
先訂成功條件，再記錄多次試驗的完成率、錯誤恢復、人工介入與完整執行軌跡。 單次成功案例只能說明那次執行，不足以代表穩定表現。
第一，將成功條件寫成可檢查的結果。例如研究任務需交付哪些資料、引用是否可驗證、程式修改要通過哪些測試、哪些副作用不可發生。若結果靠人工主觀判斷，就先制定評分規則與抽查方式，避免執行後才改變「完成」的定義。
第二，在固定任務集與相同環境下重複測試，分開報告成功、部分完成、失敗及需人工接手的比例。平均分數可能掩蓋少數高風險失敗，因此也要列出失敗類型、重試後是否恢復，以及不同任務難度的表現。
METR 在自己的任務集對每項任務進行六次獨立執行，以估計成功機率；這是該評測設計的一部分，不代表企業照做六次就能得到穩定結論。企業應按任務差異、失敗代價和需要的信賴程度，安排試驗次數與抽樣方式，並公開試驗條件，避免把測試程序誤當成通用門檻。
第三，保留可追溯軌跡：輸入版本、代理採取的行動、工具回應、狀態變更、重試原因、人工介入時間與最終驗證結果。若無法從紀錄重建代理如何得到答案，團隊就難以分辨錯誤來自模型、工具、資料或流程設計。
METR 的評測方法以人類專家完成任務所需時間衡量任務難度，並估計代理在該任務集達到特定成功機率的時間跨度；這項指標不代表代理實際自主執行的時長。（METR 評測方法說明，意譯）
四、監督方式、安全邊界與成本要怎麼一起看？
把代理本身、外層協調器和人工監督分別記錄，並以總成本對照任務價值。 若有人在關鍵步驟接手，結果就應標示為人機共同完成。
OpenAI 的案例頁面指出，Third Moment 將 Codex 放在外層協調流程之下；當工作未完成時，外層流程會檢查執行軌跡，再決定重試、終止或升級人工審查。這種設計能提供補救和停止機制，但也代表評估時要揭露誰做了哪些決定。把協調器或人工修正後的成果，全算成代理自主完成，會高估自動化程度。
安全評估則要看代理可存取的資料、網路與工具權限，並測試它是否能突破預定執行環境。Third Moment 表示使用 Daybreak 測試研究環境的安全性。這項資訊描述其做法，不能代替各團隊對自身系統的滲透測試、權限檢查與資料保護審查。
成本也不止模型 token（模型處理文字時使用的計量單位）。驗收表應納入模型與工具費用、等待運算的資源、協調器重試、人工監看時間，以及失敗後檢查和修復所需的成本。再將這些成本與合格交付的任務數、節省的人工作業或其他可量化價值對照。只比較單次模型費或運行時間，可能看不出長流程為了達標反覆重跑所付出的代價。
若把代理用在醫療、財務或其他高影響工作，還須依錯誤後果重新設定人工覆核、資料隱私與適用規範；一般軟體研究任務的驗收門檻不能直接移用。這類 AI 代理評測與自動化議題不涉及藥物或保健成分交互作用。
五、團隊如何把展示主張轉成可驗收的試行？
從一組代表性任務開始，先訂成功與停止條件，再用相同環境重複測試並記下失敗。 只有在品質、人工負擔與總成本都符合需求時，才逐步擴大範圍。
試行前先選任務：它應有明確輸入、可驗收產出，也能涵蓋實際會遇到的例外狀況。接著設定完成率、不可接受的錯誤、最大重試次數、人工升級規則與權限邊界。每次試驗保留版本、軌跡、成本及結果，讓團隊能比較不同模型、提示、工具或協調方式。
- 列出代表性任務及可驗證的成功條件。
- 固定資料、工具、權限和評分規則，安排多次獨立試驗。
- 分類失敗、重試、人工介入與安全事件，保存完整軌跡。
- 計算每項合格交付的模型、工具、監督和修復總成本。
- 依任務風險設定部署範圍，定期複測並保留人工停止權。
- 代理數量與工作階段時長描述系統規模，不能代替任務成功率。
- 可靠度要看重複試驗、錯誤恢復、人工介入和可追溯紀錄。
- 導入決策應同時衡量安全邊界、總成本與任務價值。
長時間展示可以作為設計試行的線索，真正的採用依據仍應來自團隊自己的代表性任務。對 AI 代理設計、長時間任務驗收或企業流程自動化有興趣的團隊，可先整理任務條件、成功標準及人工介入紀錄，再依實際情境交流評估方法。
常見問題
Q1：同時運行 10,000 個 AI 代理代表什麼？
它代表案例所描述的並行規模，不代表單一任務有 10,000 次成功，也不等於任務完成率。
Q2：代理工作 36 至 48 小時，能稱為自主完成嗎？
要看這段時間內是否有外層協調器重試、人工檢查或接手。應分別揭露代理執行、系統監督與人工處理的工作。
Q3：長時間任務至少要記錄哪些資料？
記錄成功條件、每次試驗結果、工具回應、重試與人工介入、完整軌跡，以及模型、工具和修復成本。
Q4：AI 代理評測的成功率門檻有通用標準嗎？
沒有單一門檻適用所有任務。團隊應按錯誤後果、任務價值、人工覆核能力及部署環境訂定要求。
