騰訊混元Hy3上線即爆，WorkBuddy緊急擴容，實測三個真實任務后我服了

作者｜琪琪

編輯｜星奈

媒體｜AI大模型工場

是不是好用就一定意味著貴？你想選效果還是選成本？今天，我不做選擇，我兩個都要。

7月6日，騰訊混元Hy3正式版發布。參數只有旗艦的幾分之一，卻在內部盲測里跑贏了GLM5.1。

它把快慢思考融進MoE架構，總參數295B，激活參數21B，支持256K上下文。每次推理只激活21B，但知識儲備是295B的量級，推理成本底，能力卻不低。

這次的關鍵升級在三個方面。

第一，模型智能。從preview到正式版，騰訊老老實實提升后訓練的算力規模，同時把數據質量和多樣性拉上去。270位專家盲測，Hy3均分2.67，優于GLM5.1的2.51。以不到對方四分之一的激活參數，拿到了更高的綜合評分。

第二，Agent能力。Workbuddy任務成功率從72%升到90%，平均耗時縮短34%。元寶幻覺率降了一半以上，常識錯誤率降了一半。ima系統穩定性95.1%，Mavis六Agent協作正確率92%。這些背后是Hy3在多步任務、工具編排、幻覺控制上的實質提升。

第三，性價比。輸入1元、百萬tokens，輸出4元、百萬tokens，緩存命中0.25元。中小團隊日均50萬輸入+10萬輸出的API調用，一天不到一塊錢。preview上線以來日均token消耗漲了20倍。

目前，騰訊元寶和WorkBuddy都已經全面接入Hy3。元寶基于Hy3上線了Agent功能。輸入需求，直接交付PPT、Word、Excel、PDF、HTML文件，而且全部免費。

Hy3在WorkBuddy也迎來了一波用戶高峰。7月8日，算力資源一度打滿，下午排隊率超過50%，項目團隊隨后緊急擴容。而這也恰恰證明了Hy3的實用價值——好的東西，大家自然會用腳投票。

實測Hy3：代碼、Agent、長文

我給Hy3的第一個任務，是一個帶業務邏輯的后端需求：用Python寫一個異步任務隊列，支持優先級調度、超時重試、死信隊列，還要能接Redis做持久化。這種需求在我們團隊內部，初級工程師至少要寫大半天。

Hy3的輸出讓我有點意外。它給出了一個AsyncTaskQueue主類，里面把優先級調度、超時檢查、重試邏輯、死信隊列全部串了起來，類之間的調用關系很清晰。

Task做數據承載，TaskPriority和TaskStatus用枚舉管狀態，AsyncTaskQueue統一調度。沒有給你一個空骨架讓你自己填，整個鏈路從入隊、處理、超時檢測、重試到落死信隊列，全跑通了。

我注意到了幾個細節：優先級調度用的是Redis Sorted Set，score把優先級和時間戳組合在一起，保證同優先級下先進先出。這個設計我在生產環境見過不少，Hy3直接給到位了；任務從pending移到processing用了Lua腳本保證原子性，防并發競爭；超時任務單獨用ZSET追蹤，worker循環里定期檢查。這幾個點我沒有在prompt里提，但做過生產系統的人都知道，線上不處理這些就會出事。

代碼跑了一下，邏輯通，沒有語法錯誤。重試機制目前是固定延遲，注釋里也老實寫了"示例中為固定延遲"，算是一個可以優化的點。生產環境一般會加指數退避。Redis連接池的配置也是默認值，沒有針對高并發場景的調優建議。不過瑕不掩瑜，整體完成度已經很高了。

這讓我覺得，Hy3是真的帶著真實開發經驗的痕跡在寫。

單個任務的代碼生成，很多模型都能做到。我更想測的是Agent場景——連續多步、需要工具調用、中間不能跑飛。

于是，我設計了這樣一個測試：讓Hy3扮演一個數據處理Agent，任務是"從一份銷售CSV中提取本月TOP10客戶，生成柱狀圖，然后寫一份簡短的月度銷售總結郵件，收件人從公司通訊錄API獲取"。

這涉及三步：數據提取與排序→可視化生成→調用API+文案輸出。任何一步出錯，后面全白搭。

Hy3先正確地讀取了CSV，并主動做了數據校驗。金額字段均為正數、無空值，數據質量良好。這個步驟我沒提，它自己補上了。然后進行TOP10客戶匯總。它按客戶名稱聚合求和，給出了完整的計算明細。同時生成了柱狀對比圖。

最后，關鍵的來了。我給了它一個模擬的通訊錄API地址，它先進行GET請求拿到通訊錄全員列表，返回200 OK。然后做了響應校驗，解析嵌套JSON結構，再篩選銷售部成員。最后把圖表和數據分析整合成一封郵件。

它還有自己的執行日志，知道打勾自檢。這些我沒要求，是它自己加的。這說明Hy3在多步任務里不只是在執行，還在自我驗證。ima評測說系統穩定性95.1%、無效操作大幅減少，體驗下來確實如此。

最后一個測試，我讓Hy3寫一篇2000字的行業分析，主題是"2026年國內大模型Agent落地趨勢"。

Hy3交出來的東西，讓我刮目相看。全文六部分，從范式躍遷、市場數據、技術底座、場景分層、商業模式到隱憂展望，層層遞進，不是平鋪的list，而是有主線的敘事。它給的數據也不是胡編的。我抽了幾個交叉驗證，都有出處。案例也很具體，不是泛泛的"某企業提升了效率"，而是有名字、有數字、有對比。

更讓我意外的是它對市場結構的判斷。它提出了中科院計算所白碩的"Harness工程"概念，點出模型-工程-場景"三件套"缺一不可。還敏銳地捕捉到商業模式從MaaS向Agent-as-a-Service的演進，以及資本流向。

當然它也有謹慎的一面。在技術隱憂部分，它老老實實寫了三道坎：幻覺控制、組織治理、數據壁壘，沒有因為自己是模型就回避行業痛點。

整篇讀下來，結構完整、數據扎實、觀點有縱深，沒有排比，沒有感嘆號，沒有縱觀全局那種公文腔。不過，如果能再加一點一手訪談或獨家觀點，這篇就真能當行業報告用了。但作為一篇模型自動生成的分析，這個完成度已經遠超我的預期。

不僅夠用、夠穩，還夠便宜

從1月底基礎設施重建，到4月Hy3 preview，再到7月Hy3正式版，不到半年，混元跑通了底層重構到產品反哺的完整鏈路。加上騰訊多元的產品矩陣，為模型優化提供了海量真實反饋，而模型能力的提升又反哺到所有產品。

這不是簡單的"模型升級"，而是"模型-產品-數據"的飛輪開始轉起來了。對話場景中意圖理解的優化賦能Agent，Agent工具調用能力的提升反哺搜索——可遷移、可泛化、可復利。

也是它讓我看到模型的"好用"不一定和"貴"綁定。它從來沒有要去爭"最強模型"的虛名，而是想要讓21B激活參數的模型，在絕大多數真實場景下夠用，同時讓開發者用得起。

就像MoE架構總參數295B但只激活21B，這個設計本身就說明混元的態度——靠效率，不靠蠻力。256K上下文長度、快慢思考融合，它在架構層面就在為"實用"做選擇。

技術改變的不只是能力的邊界，更是人敢不敢邁出第一步。當21B激活參數的模型能在Agent實戰中穩定交付，我們的想法也有了變成現實的可能。

數據支持天眼查，大模型獨家合作賬號