看了騰訊的Hy3 preview，我讀懂了姚順雨

姚順雨自從加入騰訊之后，可算是拿出了一個模型產品了。

雖然說目前騰訊放出來的還只是個preview版本，但也能借此初看端倪。

Hy3 preview這個模型和市面上其他大模型最大的區別在于，它貫徹了姚順雨對上下文獨有的那種“執著”。

當其他廠商都在卷agent 能力、代碼生成、多模態的時候，Hy3把“出色的上下文學習和指令遵循能力”單獨拎出來，寫進了核心能力清單的第一條。

別人模型宣傳的第一張性能天梯圖，放的都是什么SWE-Bench Pro或者Terminal-Bench 2.0這種，以表達模型在agent和代碼上面多么出色。

Hy3 preview不一樣，它一上來放的是AdvancedIF、AA-LCR，以及姚順雨自己弄的CL-bench，這些都是看上下文推理、檢索和指令遵循的榜單。

其實姚順雨加入騰訊后發布的第一個研究成果就是CL-bench，這是一個專門用來測試模型能否從上下文中學習新知識并正確應用的基準。

在論文里，姚順雨的觀點是當前大模型的核心短板不是讀不全、找不到，而是“學不會、用不對、執行不了”。

模型可以在上下文里找到一條規則，但它不會把這條規則真正內化成當前任務的執行邏輯。

Hy3 preview 的設計，就是要解決這個問題。

這是姚順雨對上下文這套敘事在產品層面的第一次完整落地。

不過，讓我們先從模型開始講起。

01

Hy3 preview是一個怎樣的模型？

Hy3 preview是一個295B總參數、21B激活參數的混合專家模型，支持256K上下文長度。

這個模型最核心的特性，是它在上下文學習和指令遵循上的表現。

姚順雨此前為測試模型真實的上下文能力，提出了CL-bench和CL-bench-Life這兩個評測基準，檢查模型能否從上下文中學習新知識并正確應用。

Hy3 preview在CL-bench上的得分是26.7，相比Hy2的19.2提升了39%。在CL-bench-Life上得分22.8，相比Hy2的16.5提升了38%。

這個提升并不是通過給模型增加上下文窗口長度實現的，是靠模型真正學會了如何從雜亂的上下文里，提取出有用的規則，并把這些規則應用到了當前任務中，后面我會列舉出一些例子，讀到的時候你就懂了。

姚順雨對Hy3 preview明確提出了三個原則。

第一條是能力體系化，不推崇偏科，因為即使是代碼Agent這樣的單一應用，背后也需要推理、長文、指令、對話、代碼、工具等多種能力的深度協同。

第二條是評測真實性，主動跳出容易被刷榜的公開榜單，通過自建題目、最新考試、人工評測、產品眾測等方式，去評估模型在真實場景里的戰斗力。

第三條是性價比追求，深度協同模型架構和推理框架的設計，大幅降低任務成本，讓智能用得起、用得好。

這三條原則，本質就是“讓模型真正能在真實場景里工作”這件事的一體三面。

姚順雨知道一個道理，2026年都快過一半了，大家早就清楚這些榜單刷分是沒有意義的，所以模型一定要強調生產環境里穩定運行，在用戶手里真正有用。

Hy3 preview的上下文學習能力、指令遵循能力、長文檔處理能力，其實也都是為了這個目標服務的。

具體來說，Hy3 preview在處理真實場景任務時，展現出了三個關鍵能力。

第一是從冗長文本中準確定位關鍵信息。它不是簡單地做關鍵詞匹配，而是能夠理解信息之間的邏輯關系，知道哪些信息是任務的前提條件，哪些信息是執行約束，哪些信息是優先級標記。

第二是從隱含規則中推導出執行邏輯。很多真實任務的規則不會明確寫出來，而是散落在對話、紀要、文檔的各個角落。Hy3 preview能夠把這些碎片化的信息整合起來，形成一套完整的執行方案。

第三是在多輪交互中保持上下文的連貫性。它不會因為對話輪次增加，就丟失前面的關鍵信息，也不會因為中間插入了其他話題，就忘記當前任務的目標。

這三個能力，恰恰對應了姚順雨在CL-bench論文里指出的問題。

他認為當前大模型的核心短板不是讀不全、找不到，而是“學不會、用不對、執行不了”。

模型可以在上下文里找到一條規則，但它不會把這條規則真正內化成當前任務的執行邏輯。它更像是在做檢索和拼接，但在實際任務中，模型應該是對上下文在做理解。

而Hy3 preview的設計，就是要解決這個問題。

騰訊混元團隊在內部做了大量真實場景測試，來驗證Hy3 preview的上下文學習能力。

一個典型場景是會議紀要提取待辦事項。給模型一份幾千字的會議紀要，里面散落著七八條隱藏前提：某個同事這周請假，某個項目的預算在討論中被調整，某個任務的優先級在多輪討論后被重新排序。模型需要從這些雜亂的信息里，準確提取出所有待辦事項，不能漏掉任何一條，也不能瞎猜任何一條。

Hy3 preview在這類任務上的表現，明顯好于之前的模型。它能夠準確識別出哪些是已經確定的任務，哪些是還在討論中的想法，哪些是被否決的方案。

另一個場景是旅行計劃整理。

用戶可能在多輪對話里，陸續提出各種需求，比如預算限制、時間安排、同行人員、偏好類型。這些信息不是一次性給出的，而是在對話過程中逐步補充和修正的。

Hy3 preview能夠在每一輪對話后，更新自己對任務的理解，并根據最新的約束條件，調整輸出方案。它不會因為前面說過“預算5000”，后面又說“最多4000”，就輸出一個自相矛盾的計劃。

這種上下文學習能力，在Hy3 preview的agent應用中發揮了關鍵作用。

騰訊在CodeBuddy和WorkBuddy的實際部署中，Hy3 preview已經能穩定驅動495步的復雜工作流。

在這長達495步的任務鏈之中，每一步都能正確理解當前的上下文狀態，并根據這個狀態做出合理決策。

這個任務的難點就在于，如果模型在第50步就理解錯了上下文，那后面的445步就會全部偏離目標。

Hy3 preview之所以能做到這一點，靠的就是它在每一步都能從前面的執行結果里，學到新的約束條件，并把這些約束條件應用到后續行為中。

Hy3 preview的另一個特性，是它在指令遵循上的穩定性。

很多模型在面對復雜指令時，會出現理解偏差或執行偏離。用戶要求輸出JSON格式，它可能輸出Markdown；用戶要求只列出前三項，它可能列出五項；用戶要求不要加任何解釋，它可能在最后加一段總結。

這些問題看起來是細節，但在生產環境里，每一個細節偏差都可能導致下游系統出錯。Hy3 preview在指令遵循上做了專門優化，它能夠準確識別指令中的格式要求、數量限制、輸出范圍，并嚴格按照這些要求執行。

騰訊混元團隊在元寶產品上的測試結果顯示，Hy3 preview在意圖理解精準度、文本創作質量、深度搜索等指標上，都有明顯提升。

你在和模型對話時，它能夠在第一次交互中，就準確理解用戶想要什么，并給出符合預期的結果。

Hy3 preview在長上下文處理上的表現，也體現了姚順雨對上下文的理解。

騰訊內部產品ima的測試結果顯示，Hy3 preview在處理幾萬字文檔時，無論是知識庫問答還是通用問答，都能準確找到需要的信息，并且總結得全面。它不會因為文檔太長，就只關注開頭或結尾，也不會因為信息分散，就遺漏關鍵細節。

更重要的是，Hy3 preview在長上下文中的推理能力是穩定的。很多模型在處理長文本時，會出現“上下文稅”問題。

簡單來說就是，隨著上下文長度增加，模型的推理質量會下降，輸出的準確性會降低。

Hy3 preview的設計，就是要讓模型具備這種“現場學習”的能力。它不是靠增加預訓練數據量來覆蓋更多場景，而是靠提升上下文學習能力，讓模型能夠在任何場景里，都能從眼前的材料里學會新東西。

這種能力一旦建立起來，模型的適應性就會大幅提升。它不再需要為每一個新場景都做一次微調，也不再需要為每一種新任務都準備一套專門的提示詞。它只需要在上下文里給出足夠的信息，模型就能自己學會如何執行。

這就是Hy3 preview和其他模型的本質區別。

02

姚順雨為何執著于上下文？

姚順雨對上下文的執著，其實也不是從CL-bench才開始的。

往前推幾年，他在普林斯頓和谷歌聯合研究時提出的ReAct框架，就已經在探索一個核心問題：如何讓模型在推理和行動之間建立有效的反饋循環。

ReAct的全稱是“Reasoning and Acting”，它的設計思路是讓模型在執行任務時，不斷地“思考-行動-觀察”，每一步的觀察結果都會成為下一步推理的輸入。

這個框架在2022年提出時，就已經成為agent領域的經典范式。

姚順雨認為，模型不能只會推理，也不能只會調用工具，它必須能夠把推理能力和行動能力協同起來。

但這種協同的前提是什么？

是模型能夠從每一步的執行結果里，提取出對下一步有用的信息，并且把這些信息正確地整合到當前的推理鏈條里。換句話說，模型必須能夠從動態變化的上下文中持續學習。

這就是為什么姚順雨加入騰訊后，第一件事就是推出CL-bench。

他不是在否定ReAct，他是在補足ReAct框架里一個更底層的能力缺口。

如果模型連靜態上下文里的新知識都學不會，那它在動態的Agent工作流里，就更不可能根據執行反饋做出正確調整。

CL-bench測的就是這個最基礎的能力，給你一份材料，里面有你從沒見過的規則，你能不能現場學會并用對。

Hy3 preview的深層邏輯就是把這兩個方向打通。

姚順雨的“底層代碼”是只有讀懂了上下文，agent才能真正干活。

所以Hy3 preview才有了這種“context-first、agent-facing”的設計。

別的模型在agent任務上的提升，靠的是單獨優化工具調用或任務規劃。Hy3 preview在這些agent任務上的提升，是通過提升底層的推理、長文、指令、對話能力，讓Agent的整體表現變強。

姚順雨的這種把模型給體系化思路，和當前主流的agent存在本質區別。

很多團隊在做Agent時，會專門針對某一類任務去優化，比如專門做代碼生成，或者專門做信息檢索。這樣做的好處是能在特定榜單上快速拿到高分，但壞處是模型的能力會變得很窄，一旦任務稍微偏離訓練場景，表現就會大幅下降。

姚順雨是反過來，他不追求單項第一，他要讓模型在多種能力上都達到可用的水平，然后讓這些能力在實際任務里協同工作。

Hy3 preview在騰訊內部產品上的部署效果，就是這種思路的驗證。

CodeBuddy和WorkBuddy的數據顯示，Hy3 preview的首token延遲降低了54%，端到端時長縮短了47%，成功率提升到99.99% 以上。

這三個指標放在一起看，說明模型不只是變快了，它還在保持高成功率的前提下變快了。

姚順雨的道路很清晰，模型的推理能力保證了任務規劃的正確性，長文能力保證了上下文理解的準確性，指令遵循能力保證了執行的穩定性，代碼能力保證了輸出的可用性。

姚順雨在去年提出的“AI下半場”判斷里，提出了一個觀點，他說真正決定模型能否走出demo的，是你到底有沒有把系統放進真實世界的約束里，并用真實世界的方式去評估它。

現在看來，這個觀點在Hy3 preview的開發過程中得到了徹底貫徹。

騰訊混元團隊構建了50多套內部評測體系，覆蓋了從基礎能力到產品場景的各個層面。他們還專門去跑最新的考試，比如清華大學求真書院的數學博士資格考，全國中學生生物學聯賽，用這些真實考場的成績來驗證模型的泛化能力。

這種評測思路和主流做法完全不同。大部分團隊在做模型評測時，會優先選擇那些已經被廣泛使用的公開榜單，因為這些榜單的結果容易對外傳播，也容易和競品做對比。

但問題是，這些公開榜單往往已經被過度優化，模型可以通過各種技巧在榜單上刷出高分，但這些高分未必能轉化成真實場景里的可用性。

從ReAct到CL-bench，再到Hy3 preview，姚順雨的研究路線一直沒變。

如何讓模型在真實場景里，能夠根據當前的上下文，做出正確的推理和行動。

這個問題看起來簡單，但它觸及了當前大模型的一個根本性短板。大部分模型在預訓練階段記住了大量知識，但它們不會在推理時從眼前的材料里學習新知識。這種能力的缺失，直接限制了模型在動態場景里的適應性。

Hy3 preview的價值，就是在這個方向上邁出了實質性的一步。

03

Hy3正式版是啥樣的？

說到preview，我第一時間想到的就是谷歌的Gemini。

Gemini的preview和正式版之間，有一個清晰的演化路徑。谷歌在2025年發布Gemini 2.5 Pro時，先推出了一個preview版本，這個版本在各項能力指標上都很激進，推理深度、上下文長度、多模態理解都做到了當時的頂級水平。

但preview版本有很多問題，比如成本高、延遲長、穩定性不夠。到了正式版發布時，谷歌做了大量優化，把推理效率提升了一大截，token消耗降下來了，響應速度也快了很多。

谷歌告訴我們，preview版本是用來驗證能力上限的，正式版是用來做生產部署的。preview可以不計成本地把各項能力推到極致，但正式版必須在能力和成本之間找到一個可以大規模商用的平衡點。

谷歌在Gemini 2.5 Pro的迭代過程中，就是在不斷調整這個平衡點。他們在6月5日更新的preview版本里，LMArena的Elo評分提升了24分，WebDevArena的評分提升了35分，但同時也在優化推理框架，降低延遲，為正式版的發布做準備。

Hy3 preview的定位，和Gemini的preview版本有相似之處，但也有明顯區別。

相似的地方在于，Hy3 preview也是騰訊混元重建后的第一個版本，它的主要任務是驗證新的預訓練框架、強化學習流程、能力體系是否能跑通，能達到什么樣的上限。

騰訊混元團隊明確表示，Hy3 preview是混元大模型重建的第一步，他們希望通過這次開源和發布，獲得來自開源社區和用戶的真實反饋，幫助提升Hy3正式版的實用性。

但Hy3 preview和Gemini preview的區別也很明顯。

Gemini的preview更像是一個能力展示版本，它會把各項指標都推到很高，但不太考慮成本和部署的問題。Hy3 preview從一開始就把性價比作為核心設計目標之一。

從Hy3 preview的實際表現來看，它已經具備了在生產環境里大規模部署的條件。

騰訊內部的多個主線產品，包括元寶、ima、CodeBuddy、WorkBuddy、QQ、QQ瀏覽器、騰訊文檔、騰訊樂享，都已經上線了Hy3 preview。

微信公眾號、和平精英、騰訊新聞、騰訊自選股、騰訊客服、微信讀書等產品也在陸續接入。這種大規模的產品部署，在preview階段就完成，說明Hy3 preview的穩定性和成本控制已經達到了可以商用的水平。

那么Hy3正式版會是什么樣？參考Gemini的演化路徑，我感覺應該是如下幾個方向。

第一是能力上限會進一步提升。

騰訊混元團隊已經在持續擴大預訓練和強化學習的規模，更大尺寸的模型也在訓練中。

正式版可能會在推理深度、知識覆蓋、多模態理解等方面，比preview版本有明顯提升。

第二是穩定性會進一步增強。

preview版本在實際部署中收集到的反饋，會被用來優化正式版的對齊策略、指令遵循能力、邊界情況處理能力。

第三是成本會進一步降低。

preview版本已經把推理效率提升了40%，正式版可能會通過更激進的模型壓縮、更高效的緩存策略、更優化的推理框架，把成本再降一個臺階。

但Hy3正式版和Gemini正式版可能會有一個關鍵區別，那就是Hy3不會為了降低成本而犧牲能力的全面性。

Gemini在從preview到正式版的演化過程中，有時會做一些取舍，比如縮短推理鏈條、減少思考深度，用更少的token量給出一個差強人意的輸出。這種做法可以大幅降低成本，但會導致模型在復雜任務上的表現下降。Hy3的路線更可能是保持能力的均衡性，通過架構優化和推理框架改進來降低成本，而不是通過削減能力來降低成本。

姚順雨的理解是，實用性不應該只是成本低，更重要的是能力全面、穩定可靠、真實場景里能用。Hy3 preview已經在這個方向上做出了示范，正式版大概率會延續這個思路，在能力、成本、穩定性之間找到一個更優的平衡點。

當然，這些都是基于當前信息的推測。

Hy3正式版的實際能力，還要等騰訊混元團隊完成更大規模的預訓練和強化學習之后才能確定。

Hy3的正式版和preview版之間不會有太大的能力落差，用戶在preview階段體驗到的能力，在正式版里基本都能保留。

壞處是，這種路線對團隊的技術積累和工程能力要求更高，需要在架構設計、推理優化、系統集成等多個層面都做到位，才能真正實現能力和成本的雙贏。