前面幾堂談的是方法：怎麼多產生候選、怎麼驗證、怎麼把回饋寫回權重。真的拿這些方法去做產品的人，卡在哪裡？CS329A Autumn 2025 第 18 堂由 Reflection AI 執行長 Misha Laskin 客座，題目是「Building Agentic Systems for Autonomy: Lessons & Open questions」。讀完本文，你應能說出他認為程式 Agent 缺的是哪一塊、為什麼他說這個領域受限於獎勵，並能判斷一個任務的獎勵訊號屬於哪一類。先備是知道強化學習用獎勵調整行為，以及 LLM-as-judge 是請模型當評審。
先讀第 13 堂：軟體工程 Agent與第 17 堂：長任務評估。
影片狀態：這一場沒有公開錄影或投影片。 2026-10-13 查過 Stanford Online 播放清單、官方課表與其修改歷史、兩位授課老師的頻道，以及講者的個人網站，都沒有這一場的材料。本文改用講者題目類似的公開材料：他 2025 年 7 月在 No Priors 第 123 集的訪談逐字稿，全集讀完，比 CS329A 那一場早四個月。逐字稿是第三方網站的自動轉錄，人名與產品名有錯字，本文沒有對過原音；下文的引述是意譯，不代表該場實際講了什麼。
八成的問題在理解，不在生成
Laskin 介紹的產品 Asimov 是一個程式碼研究 Agent，定位是「大型 codebase 的 deep research」。他的理由來自對企業客戶的觀察：程式工具帶來的生產力提升比預期低很多，有時甚至是負的。
他的診斷是比例放反了。現在的工具大約八成心力放在產生程式碼、兩成放在理解；但工程師在組織裡的時間分配正好相反，八成花在弄懂複雜系統和找同事問問題。知識也不只在程式碼裡，還散落在聊天紀錄、專案管理工具和工程師腦中。
他舉了一個自家的例子。他們內部稱為 environment jobs 的一類訓練用批次工作，突然慢了五倍。原因是基礎設施團隊與研究團隊各送了一個 pull request，兩個都通過測試，合在一起卻造成 race condition。這種題目沒有檔名、沒有函式名可以搜尋，他稱為語意型查詢，通常要兩三位工程師花幾天才找得到。
評估要從客戶的問題反推
怎麼知道系統變好了？Laskin 說這是前沿實驗室最少談、但可能最重要的工作。他的作法是從客戶的痛點反推：例如大公司新進工程師要幾個月才能上手，那就設計能反映「上手所需問題答不答得出來」的評估，再回頭找系統缺哪項能力——可能是對上億 token 的 codebase 做長脈絡推理，也可能是工具使用。
他特別強調要能調整整個系統：產品功能、Agent 設計、模型訓練都要動得了。只能改產品和 Agent 設計的話，就受制於第三方通用模型的能力。這也是他對 benchmark 的保留：模型在競賽型程式題上已接近世界頂尖，但走進公司問「有幫上忙嗎」，答案並不一致；主持人接話說是參差不齊，他表示同意。這和第 17 堂問的是同一件事。
團隊記憶需要審核機制
Asimov 讓工程師把口耳相傳的知識教給系統，例如「我們說的 environment jobs 指的是哪一種批次工作」，之後別人問到同一個詞，系統就知道意思。這是整個團隊共用的記憶，和第 14 堂談的單一 Agent 記憶不同，多了一層問題：誰可以改、誰可以看、寫錯了怎麼辦。
他描述的作法借自程式碼管理。客戶通常先讓一小群資深工程師當守門人填入記憶，再逐步擴大；修改團隊記憶的流程會像 pull request，由真正懂那個系統的人核准。他把它比喻成替「關於程式碼的知識」做版本控制。
獎勵是瓶頸，而且沒有捷徑
訪談中最接近「Open questions」的一段，是他解釋為什麼 RL 還無法像預訓練那樣放大規模。Laskin 在 Gemini 1 與 1.5 負責獎勵模型，他的看法是：如果有一個獎勵能準確描述任何任務的結果，剩下的就只是演算法進步，現有的簡單 RL 方法也能走很遠。
現實是沒有這種獎勵，所以大家都在妥協。請模型依評分規準當評審有一定效果，但帶雜訊的獎勵遲早會被鑽漏洞。有標準答案的任務獎勵乾淨，但數量少，只能期待在它們上面訓練會泛化到別處。他的結論是這個領域受限於獎勵，而且不會有突然的突破，因為能準確驗證任何結果的模型本身大概就是超級智慧。這是第 1 堂那個生成與驗證落差的業界版說法。
他另外點出演算法上的缺口：現在的 RL 方法只會讓成功的軌跡更常出現、失敗的更少出現，不會分辨一條推理鏈裡哪一段對、哪一段錯。所以模型的推理常常繞路。
關於泛化，他講了一句自稱 hot take 的話：沒有泛化這回事，只有把測試分布帶進訓練。意思是使用者感受到的泛化，多半來自訓練環境本來就長得像他們要問的事。
訪談尾聲他把這個看法推到部署：每個夠大的工作類別都會有自己的環境、工具與 Agent，通用的基礎模型只是起點，還要針對該類別另外做 post-training。他舉的例子是程式 Agent 與深度研究產品背後的模型，都是為各自的環境訓練的。所以他預期技術藍圖會在幾年內成形，實際鋪到各行各業則是以十年計的事。
一個完整例子：替三個任務分類獎勵
以下是本文自擬的練習，不是訪談內容。「有標準答案」與「帶雜訊」兩類是他在訪談中的區分，第三類「真實結果」是本文依他談客戶導向評估的段落加上的。
| 任務 | 獎勵來源 | 類別 | 主要風險 |
|---|---|---|---|
| 修好失敗的單元測試 | 執行測試 | 有標準答案 | 任務種類少，靠泛化 |
| 回答「為什麼工作變慢五倍」 | 模型依規準評分 | 帶雜訊 | 評審被鑽漏洞 |
| 新人能否兩週內上手 | 客戶實際結果 | 真實結果 | 回饋慢、樣本少 |
推理過程：第一個任務可以直接執行檢查，獎勵比模型評審乾淨；但它仍可能被刪掉測試這類手法繞過，要另外檢查。第二個任務沒有可執行的標準答案，只能請模型判斷答案是否指出了那兩個互相衝突的 PR，這個評審可能被長篇但空洞的回答騙過。第三個任務才是客戶真正在意的，但一次要等幾週，無法當成每一步訓練的訊號。
結果的意思是：訓練只能直接用前兩種訊號，而前兩種與第三種之間的落差，就是 Laskin 說要靠客戶導向的評估去盯的地方。
變式檢查與答案
你的評審模型給分與人工抽查的一致率是九成。可以放心拿它當 RL 的獎勵嗎？答案：不能直接放心。 一致率是在目前的回答分布上量的；RL 會把模型推向評審給高分的方向，包括那一成評審會看錯的地方。要在訓練過程中持續抽查高分樣本，並保留評審沒看過的保留題。這個答案是本文依他「帶雜訊的獎勵會被鑽漏洞」的說法推得。
常見誤解是把這場訪談讀成「RL 沒用」。他的立場相反：他認為 RL 是通往超級智慧的路，問題在獎勵與評估。今晚可以做的事：把你 Agent 專案的成功條件寫成上表的一列，標出它屬於哪一類獎勵。
英文閱讀與表達
本文自擬句：A noisy reward will eventually be exploited.（帶雜訊的獎勵遲早會被鑽漏洞。）Engineers spend most of their time understanding systems, not writing code.（工程師多數時間在理解系統，不是寫程式。）練習用兩句說明第二個任務的評審為什麼有風險；這是閱讀／表達練習，沒有原音跟讀。
參考資料
Loading...