搜索智能体与聊天机器人的差别
普通问答像闭卷考试：题目与上下文一开始就摆在眼前。深度搜索更接近在陌生环境里追一条线索——路牌会过期，网页会互相转载，权威来源常常藏在搜索结果后面。模型只要在某个岔路口偷懒，后面的结论就会一路跑偏。
这决定了搜索智能体需要学会的不只是回答，而是一连串决策：搜什么关键词、读哪些页面、证据不足时是否继续深挖、什么时候停下来给出答案。它要自己判断什么时候应该承认找不到，而不是把猜测包装成结论。过去这类能力主要掌握在闭源服务手里，9 月 14 日，小红书 AllSpark 团队把 Iris 开源，权重与评测框架一并放出。
规格与开源范围
Iris 采用混合专家架构，分两个版本。Iris-mini 总参数 35B、激活 3B，基座为 Qwen3.6-35B-A3B；Iris-pro 总参数 397B、激活 17B，基座为 Qwen3.5-397B-A17B。两者都支持 256K 上下文。
开源范围比常见的权重发布更完整。Hugging Face 提供两个版本的权重，按 Apache 2.0 协议可商用；GitHub 上的 Iris-Harness 包含完整的智能体循环、内置工具、上下文管理策略、四个评测基准与评分器，并支持任何 OpenAI 兼容端点。团队表示训练数据与配方将陆续公布。配套技术报告《Iris: Climbing the Search Frontier》已于 9 月 3 日挂上 arXiv，编号 2609.04304。
把 harness 一起开源是一个有分量的决定。只放权重时，复现结果依赖各家自己的工具链与提示词，分数往往无法对齐；把评测框架也放出来，等于把「用什么工具、怎么管上下文、怎么打分」这些隐藏变量一并交代，后续的复现与二次开发才有共同基准。
成绩要先打两处折扣
官方报告的成绩是：Iris-mini 在 BrowseComp 上 82.2、BrowseComp-ZH 84.8、DeepSearchQA 86.9、HLE 52.3；Iris-pro 对应为 88.6、85.1、92.9、56.4。其中 mini 版本在 BrowseComp 上的表现被认为接近体量远大的模型，而自身参数只有对方的很小一部分。
两处折扣必须同时说明。其一，这些成绩为团队自报，第三方复测暂缺；论文口径也只是「在各自参数档位中表现领先」，团队自己在报告里承认与最前沿系统仍有差距——这类自我评价通常比榜单数字更值得参考。其二，MoE 的激活参数不等于部署成本。3B 激活并不意味着只需要装下 3B 权重：模型权重、量化精度、KV 缓存、256K 长上下文与并发请求都会向显存伸手。宣传数据上的轻盈与实际部署的资源占用是两件事。
最有价值的一组对照实验
如果只能从这篇论文里带走一件事，应该是上下文管理的量化收益。一次深度检索会产生大量工具调用历史，很快撑满上下文窗口，这是搜索智能体最现实的工程瓶颈。
官方给出的对比是：不做上下文管理时，Iris-mini 在 BrowseComp 上只有 64.7；启用一种名为 discard-all 的策略——当运行上下文超过阈值后清空累积的工具历史、从问题重新开始——直接升到 82.2，提升 17.5 个点。在此基础上再叠加 retry 策略（在没有解析出答案时携带摘要重试），Iris-pro 的 BrowseComp 进一步到 90.3，DeepSearchQA 到 93.4，HLE 到 56.6。
这组数字的意义在于它把一个常被当作工程细节的环节，量化成了与模型能力同量级的变量。论文的表述是：推理时的上下文管理，比大多数系统之间报告的性能差距更值钱。对已经在用长上下文模型做检索类应用的团队，这意味着优化提示词与换更大模型的收益，可能都不如先把历史清理规则设计好。
不过 discard-all 这种策略粗暴之处也很明显：它丢弃的是全部工具历史。论文没有说明它在需要跨多轮引用早期证据的任务上是否同样有效。选择什么时机丢弃、丢弃后保留什么，本身就是需要按业务调优的决策。
题库怎么造才不算泄题
训练搜索智能体的真实难点在数据。想让模型学会边搜、边读、边推理，并自己决定何时收工，需要足够难又确实可解的题目。问题在于网上流传的问答对早已被模型见过：考它某公司成立于哪一年，它闭卷也能答对，训练信号等于零。
Iris 的做法是从网页超链接结构反向构造任务。流程大致是先从种子页面及其外链中蒸馏出实体图，在图上编写多跳链路，再把题面中每个非答案实体改写成描述性指称。这样处理后，任何一条线索都无法靠字符串匹配直接命中——模型不能把题面里的关键词原样丢进搜索框，必须理解指称指向什么。团队还设定了一道筛选题标准：只有闭卷答不出、但拿到证据后能指向确定答案的问题才会被保留。
这套构造方法对任何做检索类智能体的团队都有迁移价值。它同时解决了两个问题：一是污染，确保题目没有在网上以现成答案的形式存在；二是捷径，避免模型靠词汇重叠而非推理找到答案。多数团队拿不到这样规模的数据，但构造思路本身是可借用的。
训练层面，官方披露的路径是数据构造、监督微调、再用强化学习对齐「何时停止检索」这一决策。停止判断被单独拿出来作为训练目标，说明它被视作与答案质量同等重要的一环——搜得太少会漏证据，搜得太多会烧掉预算，而这个权衡在多数产品里并没有被显式建模。
账单的结构比总分更值得看
另一项容易被忽略但影响商业可行性的观察，是搜索智能体的成本结构。相关分析指出，这类任务的输入与输出 token 比例约为 25 比 1，也就是说开销几乎全部来自把检索到的内容喂进模型，而不是生成答案。不同实现之间的成本差距可以拉到 20.7 倍，而差距主要来自读了多少内容、是否重复读取。
这个结构解释了为什么上下文管理如此关键：它不仅影响分数，也直接影响账单。把已经读过的内容清理掉再重新提问，看起来是在丢信息，实际上同时降低了每轮的输入规模。分数与成本在这里的方向是一致的，这与很多工程优化中「质量换成本」的取舍不同。
对打算用开源权重替代闭源检索服务的团队，这意味着两件事需要分开算。一是部署侧的固定成本，取决于量化方案、上下文长度与并发规模；二是运行侧的可变成本，取决于每次任务平均读多少内容。只比较单轮生成速度会漏掉联网搜索与长轨迹等待带来的时间，评估时应以真实任务的端到端耗时与调用次数为准。
需要观察的三个问题
其一是独立复现结果。当前所有分数均为团队自报且使用统一工具与评测设置，第三方在不完全相同的 harness 与提示词下能否得到接近的数字，是判断这套基线可靠程度的关键。其二是训练数据与配方的公布进度，团队已表示会陆续开放，这决定了它能否被真正用于二次训练而非只是推理。其三是长上下文场景下的权衡，256K 窗口与 discard-all 式的清理策略在需要跨轮引用早期证据的任务上如何共存，目前缺少公开对照。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
结语
Iris 带来的启发并不神秘：搜索型能力的竞争，正在从谁更会写答案，转向谁更会找答案，以及谁找得更省。这一点对开发者的直接价值在于，它把两个此前说不清的问题变成了可计量的对象——上下文管理值多少分，题库的构造方式决定了模型学到的是检索还是背诵。接下来值得追踪的不是分数能否再涨，而是这套上下文管理方案在别人手里复现时，是否同样有效。