Cline 的 AI 負責人 Nik Pash 在這場演講中，直言不諱地指出當前 AI Coding Agent 領域的核心矛盾：開發者花太多精力在巧妙的工程技巧上，但真正推動模型進步的是 benchmark 和 RL 環境，而非 agent 的架構設計。他同時宣布了開源的 Cline Bench，呼籲社群共同貢獻真實的軟體開發數據來訓練更好的模型。

原影片連結：https://www.youtube.com/watch?v=I8fs4omN1no

影片重點

• 前沿模型的能力已經超越了精巧的 agent 架構，過度工程化反而會阻礙模型表現
• Gemini 3.0 在沒有任何專用 harness 支援的情況下，就在 Terminal-Bench 排行榜上擊敗了大多數模型 + agent 組合
• 真正的瓶頸不是 agent 設計，而是如何改善底層模型本身
• Benchmark 決定了前沿模型下一步學習什麼，RL 環境則負責實際改善模型
• Cline 建立了一套 RL 環境工廠（RL Environments Factory），將真實編碼數據轉化為訓練環境
• 好的 verifier 應該測試任務的「精神」（outcome），而非過度規定實作細節
• 各大 agent 實驗室都在私下收集類似數據，但沒有人公開分享
• 宣布開源的 Cline Bench，基於真實軟體開發任務，任何人都可以使用

詳細內容

[00:21] 殘酷的真相：模型能力勝過架構設計

Nik 開場就丟出一個尖銳的觀點：過去幾年，開發者們為了彌補弱模型的不足，發明了各種精巧的 scaffolding（腳手架）——RAG 索引系統、搜尋樹、工具呼叫框架等。然而，前沿模型（Frontier Models）直接碾壓了這些抽象層。現在你不再需要那些腳手架了，它們反而會擋住模型的去路。

他舉了一個生動的例子：Gemini 3.0 在發布當週就立刻統治了 Terminal-Bench 排行榜，而且完全沒有任何 agentic harness 的支援。Terminal-Bench 本身就是一個極簡的測試工具——沒有圖搜尋、沒有 RAG、沒有索引，就只給模型一個終端機，讓它自己搞定。結果它的表現超越了世界上絕大多數的模型 + agent 組合。

核心結論：能力勝過架構（Capability beats scaffolding）。如果你讓開模型的路，它自己就能表現得很好。

[02:08] 別再過度工程化了

Nik 直言，如果你在建構 agent，放輕鬆就好。別再搞那些花俏的工程技巧了，別想太多，就這樣。他認為 Twitter 上那些關於 context 技巧和各種 hack 的討論已經玩膩了，這些內容大多只是在賺取社群互動，實際上沒有太多有價值的信號。

他展示了一張建構有效 coding agent 的「playbook」（劇本），表示 Cline 作為一個模型無關（model agnostic）的工具，每兩週就要支援一個新的大型模型發布。從 Sonnet 4 到 Sonnet 4.5、從 Gemini 2.5 到 Gemini 3、從 GPT-5 到 GPT-5.1，調整 agent 的方法基本上都是同一套劇本。這些微調是瑣碎的，收益也是邊際的。

[03:43] 真正的瓶頸：模型本身的改進

接下來是演講的核心議題。Nik 指出，你可以建造世界上最乾淨的 agent，但這不會讓模型的能力提升哪怕 1%。模型只有在實驗室用困難的任務訓練它們時才會變得更好。

決定前沿模型下一步學習什麼的不是 agent 的巧妙設計、不是精緻的 RAG pipeline，而是 benchmark。模型的工具使用能力不是魔法般地提升的——它們是因為有人建構了 RL 環境，強迫模型練習特定行為，例如處理失敗模式和重試。每一次推理能力的跳躍都來自 benchmark，每一次 agent 可靠性的提升都來自 RL 環境。

因此，真正重要的問題是：什麼是 benchmark？如何把真實的 agent 編碼數據轉化為 RL 環境？什麼才是好的 verifier？如何偵測真正的困難度？如何訓練模型解決工程師真正關心的問題？

[05:07] Benchmark 與 RL 環境的解析

Nik 用簡單的方式解釋了什麼是 benchmark：它本質上就是一個環境，在 Cline 的案例中就是一個 Docker 容器，讓 agent 在裡面自由發揮。它包含三個要素：

1. 起始狀態（Starting State）：開始處理真實編碼任務時的程式碼快照
2. 起始提示（Starting Prompt）：任務描述
3. 驗證器（Verifier）：在結束時檢查最終狀態是否正確或可接受

那 RL 環境有什麼不同呢？其實幾乎沒有差別。唯一的區別在於 reward（獎勵）的用途：benchmark 用來測量模型表現，RL 環境用來改善模型。在 RL 環境中，分數不只是停留在排行榜上，而是被用來更新策略模型（policy model）的權重。

[06:06] Cline 的 RL 環境工廠

Cline 建立了一套稱為「RL Environments Factory」的系統，用來將真實的編碼數據轉化為可用的 RL 訓練環境。這個流程分為兩個階段：

第一階段：任務資格審查（Task Qualification）

使用子代理（sub agents）平行工作，判斷一個任務是否適合轉化為 RL 環境。審查包含三個面向：

• 來源（Origins）：驗證 repository 是否存在、起始 commit 是否可存取、是否為開源
• 旅程（Journey）：理解用戶的起始提示、後續追問，以及任務的「精神」——用戶真正想完成什麼
• 結果（Outcome）：能否找到真實修復問題的 commit 或 PR

同時，他們積極排除不適合的任務：vibe coding 產出的低品質程式碼、過於簡單的任務（例如從零建一個 Next.js 應用）、以及沒有可靠起始或結束狀態的任務。

第二階段：建構 RL 環境

1. 考古（Archaeology）：在本地重建起始和結束兩個狀態，拉取程式碼，嘗試自己實作，驗證 bug 和解決方案確實存在
2. 記錄障礙和依賴
3. 容器化（Containerize）：用 Docker 封裝，移除 Git（防止 agent 進行 reward hacking）
4. 定義驗證器（Verifier）

[08:24] 茶壺哨子的比喻：什麼是好的 Verifier

Nik 用茶壺（tea kettle）來解釋好的 verifier 應該是什麼樣子。假設用戶的目標是「我要煮開水」，一個好的 verifier 就像茶壺上的哨子——它是純粹的結果驗證（outcome verification）。水要嘛達到沸點，要嘛沒有。茶壺不在乎你是用瓦斯爐、電磁爐還是營火，它只是發出結果的信號。

但在建構 verifier 的過程中，很容易出現糟糕的測試。例如子代理可能會注意到「在之前的測試中，爐火被設定為大火」，就認為應該檢查火力大小。但我們都知道小火也能把水煮開。類似的壞測試還有「是不是在左前方的爐口？」「是不是過了 5 分鐘？」

關鍵原則：不要基於 ground truth 過度規定，要測試任務的精神，測試任務的結果。

[10:01] 自動化之路與元 Benchmark 的構想

這整個流程最初完全是手動的，第一個 RL 環境花了 Nik 大約 16 小時。現在每個任務只需不到 20 分鐘。團隊正在朝著全自動化的 RL 環境工廠邁進，屆時瓶頸將從工程轉移到收集高品質任務。

Nik 提出了一個有趣的思想實驗：如果我們建構 RL 環境來測試 agent 建構 RL 環境的能力呢？這就像一個「元 benchmark」（meta benchmark）。如果模型變得非常擅長基於真實用戶數據建構自己的 RL 環境來訓練自己，那就完成了一個自我改進的閉環。

[11:13] 真相炸彈：Agent 實驗室的公開秘密

Nik 接著投下了他所謂的「truth nuke」（真相核彈）。他指出一個不被公開討論的事實：Cline 並不是唯一在建構這類系統的公司。每一個主要的 agent 實驗室都在收集這類數據，都在幕後做著某種版本的相同工作，但沒有人公開談論。

這些公司引用內部 benchmark 來為它們花了數月維護的遺留系統辯護，但你永遠無法研究或檢視這些 benchmark，因為它們不公開發布。這些數據極其珍貴，卻沒有人分享。而它是唯一真正能推動進步的東西。

Nik 的核心論點是：agent 實驗室站在真實工程師和模型之間，擁有世界上最豐富的真實工程工作數據集。我們可以建更好的 prompt、更好的工具，但這些都無法改善底層模型。保持這些數據封閉，正在拖慢前沿研究的進展。

[12:29] 宣布 Cline Bench：社群驅動的開源 Benchmark

最後，Nik 宣布了 Cline Bench。這是他們嘗試建立一個「不是 cosplay 工程」的 benchmark——不是那種「寫一個生成 Fibonacci 序列的伺服器」的玩具題目。這是真實的軟體開發，被封裝成標準化的 RL 和 eval 環境。

Cline Bench 的特點：

• 完全開源，沒有秘密配方或鎖定的數據集
• 任何人都可以自行運行和檢視
• 可用於 SFT、RL、eval 等任何用途
• 目標是為整個生態系統提供真實的基準，而不只是洩漏的程式碼謎題

參與方式很簡單：在你的開源專案上使用 Cline provider，並選擇加入 Cline Bench 計畫。如果前沿模型卡住了而你介入修復，那就是一個理想的 benchmark 候選任務。Cline Bench 將永遠保持免費、完全開源和自由存取。

我的想法

這場演講最有價值的地方在於它把焦點從「如何建更好的 agent」轉移到了「如何建更好的模型」。Nik 的觀點在 AI 圈算是相當逆流的——大多數 agent 開發者都在推銷自己的架構有多精巧，但 Nik 直接說這些都是邊際改善，真正的進步來自底層模型的訓練數據。

RL 環境工廠的概念特別值得關注。從 16 小時到 20 分鐘的效率提升很驚人，但更重要的是他提出的「元 benchmark」構想——讓 agent 自己建構訓練環境來訓練自己。這種自我改進的飛輪效應如果真的實現，可能會是 AI 能力提升的重要加速器。

茶壺哨子的比喻非常精準地點出了 verifier 設計中的常見陷阱。這個原則不只適用於 benchmark 設計，對於一般的軟體測試也很有啟發：測試應該驗證行為的結果，而不是過度規定實作的過程。

不過，Cline Bench 能否成功，最終還是取決於社群的參與度。開源 benchmark 面臨的挑戰是數據品質控制——如何確保收集到的任務確實代表了真實的、有難度的軟體工程問題，而不是被低品質的任務稀釋。此外，「agent 實驗室壟斷數據」這個批評雖然有道理，但各公司不分享數據的原因可能不只是自利，也涉及用戶隱私和商業競爭的考量。