阿里巴巴的 SearchQwen3-8B，以及小型搜索智能体的价值

阿里云 PAI 团队以 Apache 2.0 协议在 Hugging Face 上发布了 SearchQwen3-8B：一个拥有 81.9 亿参数的模型，专为多跳搜索与浏览而构建。它具备 40,960 个 token 的上下文窗口，与其说它在生成自由文本，不如说它在输出由搜索后端执行的结构化工具调用。

这个定位本身就是重点。该模型是搜索智能体，而非搜索引擎。它决定要查什么、按什么顺序查，以及如何调和返回的结果。后端由你来提供。

这一区分之所以重要，是因为它把在大多数关于 AI 搜索的讨论中被捆绑在一起的两项工作拆开了。检索是基础设施问题：索引、排序函数、抓取新鲜内容的方式。规划是推理问题：判断这个问题需要三次查询、第四次是多余的、前两个来源相互矛盾。SearchQwen3-8B 正属于第二类系统，这也解释了为什么它永远无法独自回答一个问题，以及为什么它可以被直接接入现有的检索栈而无需将其替换。

它是如何构建的

训练方法才是真正有意思的技术细节。SearchQwen3-8B 使用 EasyDistill 2.0，在与环境对齐且经求解器验证的搜索轨迹上进行蒸馏。该流程并非在人工编写的搜索日志上训练，而是在实时环境中生成轨迹，并保留那些真正解决了任务的轨迹。

求解器验证正是这套方法得以奏效的关键。一条轨迹只有在收敛到正确答案时才有作为训练数据的价值，而对许多搜索任务而言，正确性是可检验的——这在开放式生成中难以做到。这为整个流程提供了可靠的过滤器，也正是所报告提升幅度如此之大的原因。

同批发布的还有一个更小的同门模型 SearchQwen2.5-3B，上下文窗口为 32,768 个 token，同样使用 EasyDistill 2.0 与 SynSearch-Data 蒸馏而来。

所报告的数据

模型卡报告了在相同工具调用接口下，相对于基座 Qwen3-8B 的 LLM 评判准确率提升。在多跳问答上，工具调用准确率从 24.50 升至 35.42；在深度搜索总体指标上，从 40.31 升至 50.31。

而对于 3B 模型，相对提升更为陡峭：多跳问答为 48.58，基座 Qwen2.5-3B-Instruct 为 36.10；深度搜索为 21.40，基座为 7.05。

所有这些数字均属公司自报，尚未经过独立评估——在一个评估异常容易被“刷分”的子领域，这一点至关重要。搜索基准奖励的是“知道该信任哪些来源”，而一个在求解器验证轨迹上微调过的模型，会针对求解器认定的“正确”进行优化。针对 GAIA、HotpotQA 等基准的独立评估，才是值得关注的信号。

在这些数字被视为可用于生产之前，其绝对值也值得再看一眼。多跳问答从 24.50 提升到 35.42 是相当大的相对改进，但仍意味着在该评判器下，模型大约每三次尝试就有两次出错。在已验证轨迹上蒸馏确实带来了真实收益，但它并不会产出一个无需自带验证步骤就能被信任的系统。

小型搜索智能体为何重要

发布一个 8B 搜索智能体、并在旁边再放一个 3B 版本的背后战略逻辑，关乎部署经济性。搜索智能体被调用频繁，且常常是并行调用，这使得按 token 计的 API 成本成为实实在在的约束。一个能在普通硬件上运行、每次调用零成本的模型，会改变哪些应用是可行的。

一个希望让智能体跨内部文档与公开来源调研客户问题的支持团队，可以在自有基础设施上运行 SearchQwen3-8B。一个需要综合众多来源的发现、又不愿把查询发给第三方的研究团队，同样可以照此办理。这两种场景都不需要前沿级别的推理能力，两者都需要可靠的工具调用与低廉的边际成本。

这背后还有治理层面的理由。自托管的搜索智能体把查询模式留在组织内部，这对任何身处受监管行业、其问题会暴露自身工作内容的人来说都很重要。

问题在于，总体拥有成本还包括搜索后端。该模型需要一个外部搜索与浏览服务，而把它跑好本身就是一个独立项目。廉价的模型配上糟糕的检索层，表现会不如昂贵的模型配上良好的检索。

这一权衡值得直白地说清楚，因为它是这类部署最常见的失败方式。团队看到一个基准数据亮眼的 8B 模型，就以为最难的部分已经完成。实际上，模型只是容易的那一半。检索层决定了智能体有可能看到哪些证据，而无论规划能力多强，都无法从一个返回过期或无关结果的后端中挽回局面。规划模型决定何时去看，后端决定看了能找到什么。

工具调用接口才是真正的产品

这里最具影响力的设计决策是输出格式。该模型输出的是结构化工具调用，而非散文式文本。这使它成为已经支持该接口的智能体框架的即插即用组件，也意味着它的职责是规划与证据整合，而非作答。

这样拆分工作对调试也有实际好处。当搜索智能体给出糟糕答案时，你可以检查工具调用轨迹，判断究竟是模型选错了查询，还是后端返回了糟糕的证据。一个直接写出答案的单一模型会掩盖这一区别。在生产环境中，这种可观测性正是“你能改进的系统”与“你只能替换的系统”之间的差别。

值得关注的信号

有两个信号将决定这次发布是否有分量。第一个是独立评估是否证实所报告的提升，因为蒸馏方法的价值取决于验证是否真的站得住脚。第二个是阿里 PAI 是否会公开 SynSearch-Data 训练集或 EasyDistill 2.0 框架。若两者都公开，可以预期其他团队会涌现出一批蒸馏智能体模型，那会让小型专用智能体从利基选择变成默认选项。

时机上还有一个更宏观的模式值得注意。阿里巴巴在以宽松许可证发布专用小型智能体，而前沿实验室则把最好的模型留在 API 之后。这是一种刻意的策略：抓住那些在意部署自己能掌控的东西的开发者，其余人交给托管 API 的按次调用经济性来承接。它是否奏效，取决于自托管在团队实际运营的规模上是否真能省钱——一旦把基础设施和上面提到的检索工作算进去，这并不显而易见。

就目前而言，一个 Apache 2.0 许可、无按次调用费用的搜索智能体，是货架上一件有用的补充。它不会取代前沿模型去做困难的推理。它也不需要。大多数搜索智能体调用都是常规性的，而常规性工作正是小型模型最合适的用武之地。