AllSpark Research 把两个搜索智能体的权重放到了 Hugging Face 上，名字叫 Iris。小的那个 Iris-mini 从 Qwen3.6-35B-A3B 后训练而来，总参数 350 亿、推理时激活 30 亿；大的 Iris-pro 基座是 Qwen3.5-397B-A17B，总参数 3970 亿、激活 170 亿。两个都是混合专家结构，上下文窗口 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 模型页；四项基准成绩与两档模型参数口径以论文表格为准。