Agent 的持續學習

TL;DR

• 權重動不了,就動 harness。 持續學習通常被連結到模型訓練,但多數公司用的是 closed-weights 模型;Replit 的做法是直接把手放在 agent 周邊的 harness 與生態系上。
• Eval 很好但太窄,production traces 才是金礦。 他們用兩根支柱:evaluation + 持續 A/B testing 與即時 trace 分析。production 的 long-tail 事件才是黃金——那是使用者把產品推到邊界、也正是你原本以為會動的東西壞掉的地方。
• 流程:分群 → 前沿模型分析異常 trace → 自動生成 PR → 人做取捨。 這條 pipeline 原則上很早就能蓋,但前沿模型是最近半年左右才好到能分析 trace。

重點整理

前提:你碰不到權重,但你碰得到 harness(約 02:58–02:59)

Continual learning 是研究界追了很久的聖杯:我們不要靜態的 AI 系統,我們要會從使用中學習的系統。 但現實是大量公司使用 closed-weights 模型——碰不到權重,要怎麼讓系統真的演化?

他的答案:還有另一條路,而那正是 Replit 這幾個月一直在做的事——把手直接放在 agent 周邊的 harness 與生態系上。

至於做法,他先誠實評價 eval 的位置:產業長期依賴 evaluation,benchmark 也很棒,他很尊敬做這件事的人——輸出極度乾淨:跑一次 eval、拿到一個數字、判斷 harness 的改動是進步還是退步。 但eval 按定義就是窄的,只涵蓋你 agent 能力的一個子集,大量訊號在那裡流失了。

而一旦達到 product-market fit,平台承接的純粹用量本身就是一座資料金礦。這座金礦常被直接聯想到「拿去訓模型」,但能做的遠不只如此:分析 traces 可以學到什麼有效、什麼無效、使用者為什麼被你的 agent 惹毛,以及其他很多事。

所以他們的架構是兩根支柱:一根仍然重度依賴 evaluation;另一根是持續跑 A/B testing + 即時分析 traces,直接從資料理解什麼真的在運作、什麼該立刻改。

為什麼 long-tail 才是重點(約 02:59–03:00)

他強調 continual learning 的原因與訊號量的量級差有關:流量越大,收到的訊號與固定尺寸的 eval 之間的差距就是好幾個數量級。

• 他們最近推出自己的 benchmark(端到端 vibe coding 評測,規模是數十個應用)。尺寸固定,所以他們早就精確知道自己的 agent 在上面會怎麼表現。
• 但 production 系統每天遇到的是一連串無法預測的 long-tail 事件。「那些 long-tail 事件才是黃金」——它們告訴你使用者正在怎麼推擠產品的邊界,而且通常正是那些把你原本設計成能正常運作的行為弄壞掉的情境。

A/B test 不是銀彈(約 03:00–03:01)

他直接吐槽:做過 A/B test 的人都知道,結果往往長成「沒有明確結論」的樣子——你操作了 harness 的某個環節,結果有些追蹤指標上升、有些下降。

• 可能你在優化成本,結果 agent 能力掉了。
• 可能你在優化速度,結果使用者情緒變了。

你幾乎不會拿到一個乾淨到可以直接出貨的答案。

實際 pipeline:分群 → 分析 → 自動生成 PR(約 03:01–03:02)

所以正確的做法是把整批 production workload 拿來處理,但不是逐筆分析——他們每天有數以百萬計的 trace,逐筆跑會貴到不切實際、也太慢。

1. 先分群(clustering)。他強調用的是非常基礎的機器學習技巧:找 traces 之間的語意相關性。絕大多數群集會被丟掉,因為那些是預期內的行為;但每天總會有幾個群集冒出來,凸顯出某些他們從未在 agent 上見過的 tail 行為。
2. 異常 trace 進分析系統。分群之後,系統把每一筆異常 trace 丟進他們的分析系統(裡面當然包含前沿模型 / LLM),理解出了什麼問題,然後立刻生成一個 PR。
3. 人做取捨。 他特別想給大家「AI engineer 的工作依然極度重要」的圖像——至少未來幾個月內他不認為這會被自動化。 拿到這串 PR、套用上去之後,你會跑 A/B test,而其中一些會像前面說的那樣沒有結論;此時身為帶 AI 團隊的人,你的工作就是決定哪些改動該進 production、哪些該等、哪些該整個丟掉。 - 也就是說:harness 的絕大多數改動由 AI 系統自動產生,但人的決策層仍然存在。

他補充了一個重要的時間點:這條 pipeline 原則上很早就能蓋,但他是最近幾個月才開始講,因為前沿模型「大約在最近半年」才變得極度擅長分析 trace。 他的類比:軟體工程師這邊經歷的「大量程式碼由 agent 撰寫」的革命,在 production workload 這一側也同樣正在發生。

具體案例:虛擬機開機比 harness 慢(約 03:04–03:05)

為了不流於抽象,他給了一個真實案例:

• Replit 每天為使用者啟動數十萬台虛擬機,而且是完全透明的。
• 一個 long-tail bug:有時候虛擬機完全開機所需的時間,比 agent harness 準備就緒的時間還長。
• 而 agent 非常熱衷於 debug,所以每次發生時,agent 就開始空轉,試圖搞清楚自己為什麼無法執行程式碼、為什麼無法呼叫某些工具。
• 由於agent 本質上是非確定性的,每一筆 trace 呈現的錯誤都不一樣——agent 各自選了不同的 debug 策略——但它們的共同點都是「虛擬機開機不夠快」。
• 關鍵:光靠人工看 log 絕對不會抓到這個問題;因為是 long-tail,它也不會出現在他們的 Datadog dashboard 上。 但分群之後,他們發現這件事發生的頻率足夠高,系統立刻生成了 PR、當場修掉。

收尾(約 03:05)

「今天我希望你帶走的一句話是:不要再把 evaluation 當成上線前的最後一道檢查。它不是一個告訴你『這個 PR 能不能出』的布林旗標。應該把它想成一具引擎——一具幫你每天出貨一個更好的 agent 的引擎。」

金句

"When you don't have access to weights, how do you make your AI system actually evolve?"(約 02:58)

整場的問題設定:closed-weights 時代的持續學習該長什麼樣。

"Evals are by definition very narrow. They capture only a subset of capabilities."(約 02:59)

benchmark 好用,但它給你的訊號量級遠低於 production。

"Those long-tail events are actually golden."(約 03:00)

它們同時告訴你使用者在哪裡推擠邊界、以及你哪裡壞了。

"You never get a crystal clear answer that allows you to immediately ship that change in product."(約 03:01)

A/B test 的真實樣貌:成本、速度、能力、使用者情緒互相拉扯。

"We would have never spotted this just by analyzing the logs manually. It would have never shown in our Datadog dashboard, because it was a long-tail error."(約 03:05)

傳統可觀測性的盲區,正是 trace 分群要補的位置。

"Stop thinking about evaluation as just the last check before shipping … think of it as an engine that helps you ship a better agent every single day."(約 03:05)

全場的收束。