前兩天大家都在吐槽被元寶紅包活動刷屏了。那一頭，千問又出來整春節(jié)30億紅包的活動。

我倒是不介意大廠們在用戶福利上繼續(xù)競爭，卷一卷的。至少我的3塊2毛6今天是領導了～

不過今天小龍哥好像終于打完高爾夫回來看手機了，微信安全中心出手，認定元寶紅包「誘導用戶高頻分享」，直接把鏈接給屏蔽了。

還能這么玩...

全網(wǎng)都在討論這事，不過我倒是真沒興趣寫長文吃瓜的。

而是我覺得在這個熱鬧里，騰訊AI團隊發(fā)的一篇還挺有趣，甚至未來可能挺重要的論文可能被忽略了。

這是2月3日，姚順雨加入騰訊后的第一篇署名論文。

這事得從去年說起。

2025年4月，還在OpenAI工作的姚順雨發(fā)了一篇博客，叫《The Second Half》（AI的下半場）。

那篇文章里有一句話讓我印象很深：

「下半場將把重心從'解決問題'轉向'定義問題'。我們不再只是問'能不能訓練出一個模型解決X問題？'，而是要問'我們究竟應該讓AI去做什么？又該如何衡量真正的進展？'」

當時看完覺得，說得挺對，但有點虛。因為他只提出了問題，但怎么定義？沒說。

現(xiàn)在算是有階段性答案了。

這篇論文叫《CL-bench: A Benchmark for Context Learning》，做了一個新的benchmark。測試結果是：所有前沿模型，平均分17.2%。最強的GPT-5.1也只拿到23.7%。

集體不及格。

先回顧一下《The Second Half》說了什么

去年12月姚順雨入職騰訊的時候，我寫過一篇文章介紹他的背景和這篇博客。這里再簡單說一下核心觀點。

姚順雨認為，過去幾十年AI的主要精力都放在「上半場」——開發(fā)新的訓練方法和模型。從DeepBlue到AlphaGo，從GPT到o-series，歷史性的突破都來自于「如何訓練出更好的模型」。

但現(xiàn)在，這個配方已經(jīng)基本標準化了：大規(guī)模語言預訓練 + 數(shù)據(jù)和算力擴展 + 推理與行動范式。用這套配方，可以解決軟件開發(fā)、創(chuàng)意寫作、IMO級數(shù)學題等各種任務。

那下半場要做什么？

姚順雨提出了一個關鍵概念：效用問題（Utility Problem）。

他說，AI已經(jīng)在國際象棋和圍棋上擊敗了世界冠軍，在SAT和律師資格考試中超過了大多數(shù)人類?？墒澜绮]有發(fā)生太大改變——至少從經(jīng)濟和GDP的角度來看如此。

為什么？

因為我們的評估方式和現(xiàn)實世界存在根本差異。

比如，現(xiàn)有的benchmark假設任務是「自動運行」的——模型接收輸入，自主執(zhí)行，得到結果。但現(xiàn)實中，AI必須在任務過程中持續(xù)與人類互動。

再比如，現(xiàn)有的benchmark假設任務是「獨立同分布」的——500個測試任務，獨立運行，取平均分。但現(xiàn)實中，任務是連續(xù)進行的。一個Google工程師在同一個代碼庫工作久了，效率會越來越高；但AI在同一個代碼庫解決了很多問題，卻無法獲得這種「熟悉度」。

所以姚順雨說，下半場的新玩法是：開發(fā)新的評估方式，以衡量真實世界的效用。

CL-Bench就是這個思路的第一次落地。

CL-Bench測的是什么？

先說一個反常識的現(xiàn)象。

現(xiàn)在的前沿模型（Frontier Model）在各種長上下文benchmark上表現(xiàn)都很好。標準的「大海撈針」測試，幾乎所有模型都能拿到接近滿分。LongBench v2這種閱讀理解測試，模型得分甚至能以兩倍的水平遠超人類。

但一進入Agent干活模式，模型就不行了。

為什么？我琢磨了一下，發(fā)現(xiàn)這里面有個關鍵的區(qū)分。

因為真實場景需要的不是「從上下文中找到信息」，而是「從上下文中學會知識，然后用這些知識解決問題」。

這是兩回事。

舉個例子。一個律師拿到一份新的監(jiān)管文件，需要立即理解其中的條款并為客戶提供建議。一個工程師閱讀一份剛發(fā)布的產(chǎn)品手冊，需要快速掌握操作流程來排除故障。

這時候，你需要的知識就在手頭的材料里。但你必須真正學會它，才能正確地用起來。

這種能力，騰訊混元團隊稱之為「上下文學習」（Context Learning）。

注意，這和我們更熟悉的「In-Context Learning」（ICL）不是一回事。

ICL是給模型幾個例子，讓它學會一個簡單的模式。比如給三個「英文→中文」的翻譯例子，模型就知道接下來要做翻譯。這是一種淺層的模式匹配。

Context Learning要求更高——模型需要從上下文中學習復雜的、結構化的知識體系，然后在新的場景中正確應用這些知識。

打個比方：ICL像是看幾道例題就去做作業(yè)，Context Learning像是讀完整本教材再去考試。

四類任務：學生、數(shù)學家、操作員、科學家

CL-Bench設計了四類任務，難度遞進：

1. 知識獲?。M學生）

給模型一份虛構的百科全書，考察它能不能準確記住并應用這些知識。

比如給一個虛構國家的完整法律體系，然后問：在這個國家，某種行為是否違法？

這是最基礎的——能不能把知識「背下來」。

2. 形式推理（模擬數(shù)學家）

給模型一套陌生的公理系統(tǒng)，考察它能不能用這些公理進行邏輯推導。

比如創(chuàng)建一個新的編程語言，有獨特的語法和語義規(guī)則，讓模型用這套規(guī)則寫代碼。

這考驗的是「在一個封閉的邏輯閉環(huán)里嚴絲合縫地推導」的能力。

3. 流程任務執(zhí)行（模擬操作員）

給模型一份復雜的SOP手冊，考察它能不能嚴格按照流程執(zhí)行任務。

比如給一個無人機物流系統(tǒng)的詳細API文檔，讓模型生成操作代碼。手冊里寫了什么能做、什么不能做，模型必須完全遵守。

這考驗的是「長鏈條的執(zhí)行紀律」——錯一步，滿盤皆輸。

4. 經(jīng)驗發(fā)現(xiàn)（模擬科學家）

這是最難的。給模型一堆雜亂的實驗數(shù)據(jù)，讓它自己歸納出背后隱藏的規(guī)律。

比如給一組物理實驗的觀測結果，讓模型發(fā)現(xiàn)其中的物理定律。

這是從「應用知識」到「發(fā)現(xiàn)知識」的跨越。

說實話，這個benchmark做得挺重的。500個復雜上下文、1899個任務、31607個驗證標準。每個上下文平均對應63.2個驗證條目，每個任務平均有16.6個評估標準。

為了保證模型不能靠預訓練知識作弊，采用了「無污染」設計：所有上下文要么是完全虛構的（比如為虛構國家設計一套完整的法律體系），要么是對現(xiàn)有知識的修改（比如創(chuàng)建具有獨特語法的新編程語言），要么是極其小眾的長尾內容。

專家平均花了20小時來標注單個場景。51.1%的任務有序列依賴關系——后面的問題依賴前面問題的答案，不能跳著做。

研究團隊做了驗證：讓GPT-5.1在不提供上下文的情況下嘗試解答1000個隨機任務，成功率只有0.9%。說明沒有上下文，這些任務對模型來說幾乎無解。

最慘的發(fā)現(xiàn)：模型不會歸納

測試結果挺殘酷的。

模型

任務成功率

GPT-5.1 (high)

23.7%

Claude Opus 4.5

19.9%

Gemini 3 Pro

18.9%

DeepSeek-R1

16.6%

Llama 4 Maverick

12.9%

平均分17.2%。

而且，模型的錯誤很有規(guī)律。論文統(tǒng)計了三類主要錯誤：

• 漏用上下文：55.3%

• 誤用上下文：61.5%

• 格式不遵守：35.3%

論文里有個具體案例：Gemini 3 Pro被要求為一個無人機物流系統(tǒng)生成操作偽代碼。系統(tǒng)文檔提供了詳細的API說明，用戶的請求故意違反了安全協(xié)議。

Gemini的表現(xiàn)怎么樣？

它正確地拒絕了非法請求——這是對的。但它沒能生成完整的合規(guī)替代方案：它忽略了文檔中明確要求的替代函數(shù)，也沒有綁定任務中給出的具體參數(shù)。

換句話說，模型「知道什么不能做」，但「不知道應該怎么做」。它讀了手冊，但沒學會手冊。

更重要的發(fā)現(xiàn)是：在四類任務中，模型在「經(jīng)驗發(fā)現(xiàn)」（歸納）上的表現(xiàn)最差——任務成功率通常低于10%。

這個數(shù)字挺有意思的。

之前寫DeepSeek的Engram論文時，我引用過博爾赫斯的短篇《博聞強記的富內斯》。富內斯能記住一切，但無法思考——因為思考需要抽象，需要忘記差異。

CL-Bench的發(fā)現(xiàn)正好是反過來的：模型能做總結（一種復述和組織），但不擅長歸納（需要建模和泛化）。

總結是「把已有的東西換個說法」，歸納是「從已有的東西發(fā)現(xiàn)新規(guī)律」。前者是壓縮，后者是創(chuàng)造。

模型在前者上表現(xiàn)還行，在后者上一塌糊涂。

這個benchmark不是用來刷的

看到這個17.2%的平均分，你可能會想：那接下來各家肯定會卷這個分數(shù)吧？

但姚順雨可能不這么想。

《晚點》有篇報道提到，姚順雨在騰訊內部會上說，希望團隊以后不要打榜，也不要盯著榜單做事。

這和他在《The Second Half》里的觀點完全一致。他說過，當智能程度較低時，提升智能通常能提升效用。但現(xiàn)在不是了——我們需要重新設計評估框架，以推動真實應用突破。

這里有個更大的背景。

現(xiàn)在很多AI能力benchmark都被刷爆了。MMLU、HumanEval、各種考試，模型動輒90多分，早就超過人類水平了。但這些高分并沒有轉化成真實世界的價值——模型考試厲害，干活還是不行。

問題出在哪？可能不是模型不夠強，而是我們問的問題不夠對。

CL-Bench的思路是：與其在舊問題上繼續(xù)卷分數(shù)，不如提出一個新的、正確的問題。用一個好的benchmark來驅動模型改進，而不是讓模型去適應一個已經(jīng)不再有區(qū)分度的benchmark。

這可能就是「下半場」的演進方式，咱就先別急著跑分了，而是先比比誰能提出更好的問題。

所以CL-Bench的意義不在于「又一個可以刷的榜單」，而在于「標記出了一個真正的能力短板」。

這個短板是什么？

論文最后一段寫得很直接：

「只有當模型能夠快速內化完全陌生的上下文，并精確地應用那些知識來解決問題時，人工智能才能超越知識庫的限制，演變成真正的推理Agent?！?/blockquote>

換句話說，現(xiàn)在的模型本質上還是「知識庫的調用者」。它們能做的，是把預訓練時學到的知識重新組合、輸出。

但真正的Agent需要的是「從上下文中學習新知識」的能力。這個能力，現(xiàn)在的模型幾乎沒有。

往大了說：誰提供context，誰掌握主動權

論文的Discussion部分給了四條可能的改進方向：

1. 訓練數(shù)據(jù)要強上下文學習——在預訓練階段就加入需要從上下文學習的任務

2. 更好的位置編碼——讓模型更好地理解上下文中的結構

3. 更長的上下文窗口——但這只是必要條件，不是充分條件

4. 新的注意力機制——讓模型更有效地從長上下文中提取和應用知識

但我覺得更有意思的是論文里的一句話：

「一旦上下文學習能力變得可靠，人類將不再是主要的數(shù)據(jù)提供者，而是context提供者。競爭的焦點將從'誰能訓練出更好的模型'轉向'誰能為任務提供最豐富、最相關的context'?！?/blockquote>

這個判斷我覺得挺重要的。

現(xiàn)在的AI競爭主要在「模型層」——誰的模型更大、訓練數(shù)據(jù)更多、效果更好。但如果context learning問題解決了，競爭焦點可能會轉向「context層」。

誰擁有最好的專業(yè)知識庫？誰能把這些知識組織成模型能學會的形式？誰能在對的時機提供對的context？

論文還提到一個更遠的愿景：模型如何「記憶」，可能成為2026年的另一個核心主題。

現(xiàn)在的模型有個問題：學完就忘。你在一個session里教會它某個規(guī)則，關掉窗口，下次還得重新教。這在長期協(xié)作場景里是致命的。

說到這個，最近很火的Clawdbot（OpenClaw）就是個有意思的案例。很多人覺得它體驗特別好——懂你、有人味、能長期使用、上下文不爆。其實核心就是他們在memory和上下文工程上做了大量工作。

但這是「工程層」的解決方案：通過更聰明的context管理、記憶壓縮、檢索增強來繞過模型本身的限制。

CL-Bench指向的是另一條路——「模型層」的改進。讓模型本身學會從context中學習，而不是靠外部系統(tǒng)來補。這條路更難，但可能更本質。

長期來看，兩條路可能都需要。但如果模型層的context learning能力上來了，工程層的很多workaround可能就不需要那么復雜了。

最后

回到開頭。

2025年4月，姚順雨寫了一篇博客，說AI下半場的重心是「定義問題」和「設計評估」。

2026年2月，他交出了第一個具體的答案：一個平均分只有17.2%的benchmark，精確地標記出了模型在「上下文學習」上的短板。

這個benchmark某種程度上算是一個提醒：我們以為模型已經(jīng)很強了，但在這個能力上，它們還差得很遠。

姚順雨在入職騰訊之前說過一句話：「真正決定模型價值的，不是它能在benchmark上刷多高的分，而是它能不能解決真實世界的問題?！?/p>

CL-Bench算是這句話的一個注腳。

從博客到論文，從理念到落地，50天時間。

這可能就是騰訊看中他的原因之一，不只是會寫論文，更重要的是知道該寫什么論文。這個時代正在獎勵提出正確問題的人。

參考資料：

• CL-Bench論文：https://arxiv.org/abs/2602.03587

• CL-Bench代碼與數(shù)據(jù)：https://github.com/Tencent-Hunyuan/CL-bench

• 姚順雨《The Second Half》：https://ysymyth.github.io/The-Second-Half/

• 騰訊混元技術博客：https://hy.tencent.com/research