AI 程式碼代理在追蹤時間方面表現吃力，研究發現

Anthropic 的 Claude Code 與 OpenAI 的 Codex 可以完成軟體任務，但一項新研究顯示，它們對這些任務需要多久的理解很薄弱——而且判斷自身表現的能力更弱。這項發現很重要，因為 AI 程式碼代理正從短暫的互動式提示，走向可自主執行數十分鐘甚至數小時的工作。

根據 The Decoder 對該研究的報導，兩位在 MATS 研究計畫中工作的獨立研究者，針對 ProgramBench 的 200 項任務與另外 18 項基準測試進行了測試。研究要求代理在開始前估計所需時間，並在完成工作後回報已經過了多少時間。兩套系統經常高估任務時間，同時對失敗工作的評分遠高於測試結果所能支持的程度。

這項研究並未顯示模型在任何軟體環境中都真的無法取得時間資訊。相反地，它凸顯了目前 AI 代理 如何感知經過時間，以及如何利用這些資訊來管理工作的實際弱點。當研究人員提供一個能回報經過時間的工具時，據稱代理幾乎每次都變得準確。

短程式碼任務中的巨大誤差

The Decoder 報導指出，在 ProgramBench 上，兩個代理通常都預測任務大約會花 90 分鐘，無論難度如何。在第二組測試中，Claude Code 的估計平均約差了三倍，而 Codex 則差了六到十倍。

最大的誤差出現在短任務上。根據報告，只有當工作延伸到數小時範圍時，預測才開始接近現實。這種模式在 عملی作層面很重要：如果一個代理把幾分鐘就能完成的任務預測為 90 分鐘，它可能會在何時停止、何時求助、或何時啟動另一個動作上做出錯誤決策。

結果也會因每個模型周圍的軟體環境而有明顯差異。Claude Code 會持續工作，直到它判定任務完成，報告的中位執行時間約為 90 分鐘。Codex 在許多情況下約半小時後就停止，即使任務難度改變也是如此。

研究者將差異的一部分歸因於代理的「harness」——也就是圍繞語言模型的工具、指令、執行限制與控制邏輯。據報，相同的底層模型在 Claude Code 中平均比在 Codex 中多了 2.5 倍的步驟。這表示執行時間不只是模型本身的屬性，也受到部署它的產品架構影響。

自我評估是另一個弱點

除了時間估計之外，測試還發現了其他問題。根據 The Decoder，模型平均高估了自身工作品質約 20 個百分點。有時候，即使任務大致失敗，它們仍會給自己很高的分數。

在一個例子中，兩個系統據稱都將自己的工作評為約 70% 成功，但實際測得結果只有 7% 與 14.5%。來源將相關模型描述為 Opus 4.8 與 GPT-5.5。由於目前可取得的證據是關於研究的報導，而非研究全文或原始資料，因此這些模型名稱與精確的評估條件應視為報導中的發現，而非經獨立驗證的事實。

自我評估是自主軟體工作的核心。程式碼代理可能需要決定是否繼續迭代、宣布任務完成、修正補丁，或將問題升級給人類。如果它的信心與測試結果脫節，工作流程可能看起來很健康，實際上卻產出不完整或有缺陷的程式碼。

為什麼 harness 對部署很重要

對開發者來說，核心教訓不只是 Claude Code 與 Codex 預測不準，而是代理行為高度依賴模型周圍的控制機制。選擇 AI 程式碼助理的產品團隊，不僅應評估基準測試表現，也應評估系統如何處理截止時間、重試、工具失敗、測試回饋與明確停止條件。

研究中關於經過時間工具的結果，提供了一個相對直接的工程回應。代理不應被期待從對話歷史、 token 生成量或工具呼叫次數來推斷時間。執行時間應由可靠的外部時鐘提供，並由協調層強制執行。

但這並不能解決所有監督問題。計時器可以告訴代理已經過了兩小時，卻無法判定產生的程式碼是否安全、完整，或是否值得部署。團隊仍可能需要獨立測試、變更審查、沙盒隔離、支出上限與升級規則。當代理被允許在沒有持續監督的情況下工作時，這些控制就更加重要。

這項發現也讓不同 AI 程式碼產品之間的比較變得更複雜。Codex 較短的觀察執行時間與 Claude Code 較長的步驟序列，可能反映的是不同預設值，而非單純的智慧或生產力差異。比較產品的買家應該詢問代理被允許做什麼、允許執行多久，以及完成情況如何驗證。

證據與主張的限制

這些證據來自 The Decoder 報導的、由兩位獨立研究者在 MATS 框架下進行的研究。報導中的測試集結合了 ProgramBench 與另外 18 項任務的基準套件。該報導提供了時間估計、執行時間、步數與自我評估的數值結果，但此處可取得的資料並未包含完整的方法學、任務定義、統計分析或獨立重現。

因此，這些發現應被視為特定評估弱點的證據，而非對所有 AI 代理所有版本的普遍測量。結果可能會隨模型更新、系統提示、可用工具、上下文視窗、任務類型與 harness 設計而改變。關於經過時間工具可帶來近乎普遍準確性的說法，作為工程訊號尤其有價值，但它仍來自報導中的研究，還需要更廣泛的測試。

時間估計與時間追蹤之間也有一個重要差別。代理在獲得適當工具時，也許能讀取時鐘，但仍可能無法預測一項陌生任務需要多久。產品團隊應分開測試這兩種能力。

接下來要關注什麼

據報導，研究人員計畫測試代理是否能遵循像是持續工作指定時長之類的指示。這項實驗可以顯示，外部時間資訊是否不僅改善事後回報，也改善即時任務控制。

後續評估也應測試較新的模型版本、更長的軟體專案、失敗復原，以及不同的 harness。一個有用的基準應衡量代理是否能在截止時間停止、在截止前產出可用結果，並準確回報哪些工作尚未完成。

對企業買家而言，實際訊號會體現在產品設計中：持續顯示經過時間、嚴格的執行預算、獨立驗證，以及清楚的交接機制。能夠公開這些控制措施可重現數據的供應商，會更容易讓人區分真正的自主性，與那些只是一路運行到隱藏限制為止的代理。

Creati.ai 觀點

這項研究指出了語言模型與自主軟體交界處的一個控制問題。時間感知不是產品必須以某種方式模仿的人類抽象特質；它是可衡量的系統能力，可以由協調層提供，並與外部事件比對。

對 AI 建構者來說，重點是把時間估計與自我回報的成功都視為不可信訊號。長時間運作的代理應該擁有外部時鐘、明確預算、獨立測試與升級路徑。在這些機制成為標準之前，「自主」程式設計仍只是一種工作流程主張，必須逐項任務加以驗證。