AllSpark Research把兩個搜尋代理人的權重放上了Hugging Face，名字叫Iris。體型較小的Iris-mini是從Qwen3.6-35B-A3B後續訓練而來，總參數350億、推論時啟用30億；較大的Iris-pro基座是Qwen3.5-397B-A17B，總參數3970億、啟用170億。兩者都採用混合專家（MoE）架構，脈絡窗口256K，權重依Apache 2.0授權釋出，配套的技術報告9月3日掛上arXiv。
搜尋代理人和一般對話模型的差別在於，它得自己判斷要搜尋什麼、看完結果後要不要繼續搜、以及什麼時候證據夠了可以收手。過去兩年這項能力幾乎被閉源產品包辦，開源陣營拿得出手的對照案例並不多。
四項基準的成績
論文給出的是四個基準：BrowseComp、BrowseComp-ZH、DeepSearchQA與HLE。Iris-mini的成績是82.2、84.8、86.9、52.3，Iris-pro則是88.6、85.1、92.9、56.4，其中DeepSearchQA以F1計分。兩個模型都在各自的參數量級裡拿下開源搜尋代理人的最佳成績，差距最大的一項是BrowseComp。
有個數字不太符合直覺。在中文的BrowseComp-ZH項目上，350億參數的小模型拿84.8分，3970億參數的大模型拿85.1分，只差0.3分；同一組模型在英文BrowseComp上的差距卻是6.4分。中文這一項，參數規模幾乎沒換來什麼優勢。
論文裡另一組對照實驗把重點講得更直接。團隊測了三種推論時的脈絡管理策略：什麼都不做；「discard-all」，脈絡一旦超過門檻就把累積的工具呼叫紀錄全部清空、從原始問題重新開始；以及「retry」，把已經排除的線索先摘要一遍再繼續。開啟脈絡管理後兩個模型都拿到更高分，而且Iris-mini漲幅比Iris-pro更大。換句話說，對小模型而言，如何管理那條越滾越長的搜尋紀錄，比堆參數更有效。
訓練資料從超連結結構裡反推出來
多跳搜尋題最難造。人工寫一道要跨三四個網頁才答得出來的題目，成本高得離譜，還很容易被模型用字串比對繞過去——題目裡留了某個專有名詞，模型一搜就直接命中答案頁。
Iris的做法反過來：先從網頁語料的超連結結構裡挑一個種子頁面，順著它的對外連結萃取出一張實體圖，再在圖上編出多跳鏈條，最後把題目改寫一遍，確保每條線索都無法靠字面比對解決。
訓練本身是論文稱為「SFT-RL climbing」的流程，監督微調與強化學習交替進行。強化學習這段跑的是即時搜尋，而非離線快照；負責評分的獎勵模型與彙整觀察結果的模組都部署在訓練叢集內部。這套設定意味著訓練時每一步都要真的發出網路請求，工程成本並不低。
Our policy is optimized by RL against live search.
開源陣營終於有了像樣的對手
拉開來看，開源模型在一般對話與程式碼上追閉源已經追得差不多了，搜尋是掉隊最久的一塊。原因不難理解：搜尋代理人的能力一半在模型本身，一半在外圍那套調度工具的框架裡，閉源產品把兩者一起調校，開源陣營往往只放模型、不放框架。
Iris這次把模型權重、脈絡管理策略和資料建構方法一次講清楚，訓練流水線的程式碼標註為「即將釋出」。GitHub倉庫的致謝名單裡有MiroThinker、Relax、ms-swift與slime，前兩者都是過去一年做搜尋代理人的開源嘗試。
報告把Iris和GPT-5.5 Pro、Gemini 3.1 Pro這類閉源模型放進同一張BrowseComp表格裡比較過，但論文正文對「同規模領先」的說法限定在開源範圍內，閉源那幾個的逐項數字並未在摘要中攤開。另一件沒有公開的事，是AllSpark Research這個團隊的機構隸屬——公開報導把它和一家中國內容平台連結在一起，但arXiv頁面和GitHub倉庫都沒寫明所屬單位，九位作者的個人頁面也沒有標註。
對想自己跑一套深度搜尋的人來說，350億參數、啟用30億這個規格是個合適的尺寸，搭配論文裡那套脈絡管理，單機就能跑起來。Apache 2.0的授權範圍也留了足夠的商用空間。
參考來源：arXiv論文2609.04304、AllSpark-Research/Iris倉庫、CocoLoop、Hugging Face模型頁面；四項基準成績與兩檔模型的參數口徑以論文表格為準。