假設兩位工程師討論 Agent 是否能完成一項開發工作。一人試過免費聊天介面，得到幾段有錯的程式；另一人讓付費工具在有測試的 repository 裡跑了數小時，交出可審查的變更。兩人說的都是親身經驗，卻沒有測量同一件事。

Andrej Karpathy 在 2026 年 10 月 11 日的貼文把這種落差稱為愈來愈陡的能力漏斗。他以「粗算」估計，約 60 億人幾乎沒有接觸 LLM、10 至 20 億人偶爾使用免費產品、約 2,000 萬人在數學與程式工作中使用前沿模型，另有約 5,000 人能接觸實驗室內部系統。這些人數是作者的估計，原文沒有提供抽樣方法或可重現的統計來源。 它們適合說明他觀察到的經驗落差，不適合當成市場規模或 AI 普及率的測量值。

本文關心的是漏斗背後的工程問題：一份 AI 能力報告，若沒有交代任務、環境、存取權限與驗收方式，團隊就無法知道結果能否用在自己的工作。以下的評估方法是我的延伸建議，不是 Karpathy 發布的 benchmark。

先定義工作，再談「模型會不會」

Karpathy 把第一個因素歸於問題的野心、規模與時間跨度。能用一段話回答的問題，與需要跨檔修改、跑測試、處理失敗並交接的任務，對系統的要求不同。這個判斷不能簡化成「題目愈大，模型愈好」；大任務也可能只是把錯誤累積得更久。

我會先寫出一個具名工作，而不是問「Agent 能寫程式嗎」：例如「在既有服務加入重試，保留操作 ID 的去重語義，讓回應遺失後再次送達也不重複寫入」。交付條件要包含修改範圍、可執行測試與一個失敗案例。若受測者只有聊天框、沒有 repository 或測試執行權，就記錄為不同環境；不要把它的失敗解讀成所有 Agent 都做不到，也不要把完整工具環境的成功解讀成所有人都能使用。

至少保存四項條件：

  • 任務與跨度：輸入材料、允許的操作、執行多久，以及中斷後能否恢復。
  • 模型與工具：具體模型版本、產品方案、工具權限、上下文與外部資料。模型名稱相同，執行環境仍可能不同。
  • 驗收證據：測試命令與結果、審查發現、未覆蓋的失敗路徑；成功摘要不算驗收。
  • 人力與成本：人工提示、修補、重跑次數、模型費用與等待時間；被丟棄的嘗試也要入帳。

這份紀錄讓團隊能重做一次比較，也能指出差異來自模型、工具或任務設定。若缺任一項，結論只能限定為「在這次未完整記錄的條件下觀察到」，不能外推到整個工作流。

可驗證的領域會放大能力，也會放大評估偏差

Karpathy 的第二個因素是能力的不均勻：他認為數位化、結果可驗證且有經濟價值的工作，往往更容易看到能力高峰。他在同年的 Sequoia 演講整理也討論可驗證性、訓練環境與能力分布。這是對能力形成原因的解釋，不能由一篇貼文直接推得每個產業的效果排名。

程式任務常有測試、編譯器與差異檔可查，正好適合做小範圍評估；但可執行不等於可接受。上一節的重試範例即使測試通過，若測試只涵蓋成功回應，仍不能宣稱回應遺失後不會重複寫入。評估者要先列出失敗案例，再讓 Agent 嘗試，避免看到漂亮的結果才回頭改驗收標準。

非程式領域也可以建立局部可驗證條件，例如資料來源能否追溯、計算能否重做、結論的適用範圍是否寫明。但若工作成敗依賴當事人的感受、組織協商或尚未公開的背景，就必須保留人工判斷。把這些工作硬改成一個分數，會製造虛假的可比性。

存取層級是測試條件，也是採用限制

第三個因素是存取。Karpathy 明確區分免費、付費與內部系統，並描述少數內部使用者看到長時間、多 Agent 協作的成果。原文沒有提供可供外部重跑的內部系統規格；「數千個 Agent 協作數週」及相關成果是他的描述，不能當成本站驗證過的產品能力。

選型時，我會把「有人見過」與「團隊能部署」分開。即使某個示範成立，還要問：相同模型與工具是否可取得？資料能否在允許的邊界內使用？一個任務要多少人工審查？失敗能否回退？當答案是「目前只有內部權限」時，這是研究方向的線索，不是今天可採購的方案。

更實用的做法是用團隊實際可用的方案跑一個完整切片，保留與示範不同的條件。若評估結果需要人手修正三次才通過，就把三次修正算進交付成本。若關鍵資料不能提供給工具，就把資料限制寫進結論，而不是換一份不具代表性的範例後宣稱已驗證。

用一張評估紀錄，讓分歧可檢查

下列模板是本文提出的工作紀錄，可放進 issue 或實驗筆記。它不要求團隊建立新平台；一個任務先填一張即可。

decision: 是否允許 Agent 修改重試邏輯並送交審查
task: 回應遺失後重送同一操作 ID，不得重複寫入
input_materials: <提供的檔案版本與外部資料>
prompt_and_context: <初始指令與執行中補充的資訊>
environment:
  repository_revision: <commit>
  model_and_plan: <模型版本與可用方案>
  tools_and_permissions: <可讀、可寫、可執行範圍>
  time_limit: <時間>
acceptance:
  commands: <實際執行的測試>
  failure_case: 寫入成功但回應遺失後重送
observed:
  result: <通過、失敗或未確認>
  human_interventions: <次數與內容>
  cost_and_duration: <費用與耗時，含失敗嘗試>
  remaining_unknowns: <未驗證條件>

填完後，才能問兩次結果是否有可比性：任務與驗收是否相同？環境與存取差異是否已記錄？人工介入是否一起算？若其中一項缺失，先補紀錄或縮小結論。停止規則：不同存取層級或驗收條件的結果，不合併成「模型成功率」。

這也說明為何能力討論容易僵住：每個人帶來的可能是真實觀察，只是觀察條件不同。下一次團隊爭論「Agent 已經能做」或「Agent 根本不行」時，先選一個可驗收的任務，各填一張紀錄，再比較通過條件與人工成本。若工作已完成，還需要讓接手者理解證據與限制，可接著看〈把人能否理解寫進 Agent 的交付條件〉。