Jev Search

Jev Search 是什么

Jev Search 是 Search1API 团队开发并开源的一款 AI 搜索引擎，底层调用 TypeSafe 的 Jev 模型来完成意图判断，搜索执行则交由 Search1API 完成。它主打一种非常克制的产品哲学：用户用口语化的自然语言提问，Jev 自动理解查询意图、挑选合适的搜索来源、划定时效区间并生成最终查询词，随后 Search1API 并行调用 Google、Reddit、Hacker News、arXiv 等 12 个搜索引擎；返回结果会被逐条打出 0 至 100 的相关性评分并流式呈现，相关性偏低的结果则被折叠进分组。Jev Search 只做索引与排序，不生成总结性答案，以此规避大模型幻觉带来的编造与遗漏。

在 AI 搜索赛道普遍走向「答案引擎」的当下，Jev Search 选择站在另一侧。它首页的一句话自我介绍写得很直白——「Judgment by Jev · Search by Search1API · No generated answers.」，即判断由 Jev 负责，搜索由 Search1API 负责，全程不生成答案。这不是一句营销口号，而是写进项目文档的产品边界。对那些需要自己判断材料、不愿把结论外包给模型的研究者、开发者和投研人员来说，这条边界恰恰是最有价值的卖点。

需要厘清的一点是：Jev Search 由 Search1API 团队构建，是一个开源项目，并非 TypeSafe 的官方产品——这一点项目文档中有明确说明。Jev 是 TypeSafe 提供的一个模型，在这个项目里它不充当写手，只充当裁判；Search1API 才是真正去调用各个搜索引擎、把结果抓回来的服务层。两者各管一段，而前端界面把这两段都清清楚楚地暴露给用户看。

为什么「不生成答案」这件事值得单独拿出来说？因为生成式答案有三个绕不开的病。第一是会编：大语言模型生成文字的核心机制是预测下一个最像答案的 token，它给你的不是正确答案，而是最像正确答案的答案，而人类大脑看到一段流畅、完整、结构清晰的信息时，并不会本能地质疑。第二是会漏：模型觉得自己不重要的信息会直接跳过，而「什么重要」这个判断是模型替你做的，你不知道它跳过了什么，却会以为自己看全了。第三是判断力在悄悄外包：越依赖现成的完整答案，就越没有能力自己去判断一条信息值不值得信。Jev Search 的选择是把这三件事原样还给用户——它只负责把该去哪儿搜、用什么词、哪些结果更像你要的这三件事做对。

Jev Search 官网入口为 https://jev.s1.dev/，开源代码托管在 GitHub 的 superagents-lab/jev-search 仓库，采用 MIT 协议开放，任何人都可以拉取源码、配置密钥后一键部署到 Cloudflare Workers 边缘节点，做完全属于自己的私有化搜索实例。

Jev Search 官网首页：自然语言输入框与来源时间胶囊标签

Jev Search 的主要功能

从功能层面拆解，Jev Search 的能力可以归纳为以下几个核心模块，每一个模块都对应着传统搜索流程中被省略或被隐藏的一步。传统搜索引擎把这些步骤全部藏在后台，只把最终的十条蓝色链接交给你；而 Jev Search 的做法是把「意图判断—来源选择—时间限定—查询词生成—并发检索—相关性打分」这条链路完整地摊开，每一步都看得见、改得动。

这种「摊开」带来的直接好处是可控性。当你发现结果不对时，不需要反复猜测该换什么关键词，而是可以立刻定位问题出在哪一环：是来源选错了，还是时间窗口卡太死，还是模型把你的原话改写歪了。定位清楚之后，改一个标签就能重来一次。对经常做深度检索的人来说，这个反馈回路比任何「智能」都更实用。

1. 自然语言交互：用户不必再费心提炼关键词，直接用日常说话的方式描述需求即可。比如「这个月 Hacker News 上大家在怎么讨论 Rust 异步运行时」，系统会自行把它翻译成可用于检索的结构化参数，省去了人工拼凑检索式的过程。
2. 深度意图感知：依托 Jev 模型的语义理解能力，系统会自动解析用户真实诉求，判断这次检索的核心议题是什么、应该走哪些信息渠道、需要限定在多长的时间窗口之内。这些判断不是黑盒结论，而是以标签形式直接呈现在页面上。
3. 12 引擎强力并发：一次请求可以同时联动 Google、DuckDuckGo、Yandex、Hacker News、Reddit、GitHub、X、arXiv、YouTube、Wikipedia、IMDb、微信等 12 个异构来源。所有调用并发发出，单个引擎超时或故障不会拖垮整体结果，也不会让某一条通道的失败变成全局的空结果。
4. 量化相关性评分：每一项抓取到的内容都会被 Jev 模型量化评估，给出 0 至 100 的相关性分数。高分内容直观呈现，低分内容自动隔离到折叠分组，信息过滤井然有序，用户一眼就能看出哪些值得优先读。
5. 极速流式传输：结果不是等全部搜完才一次性吐出，而是随到随显。哪个引擎先响应，那个引擎的结果就先出现在页面上，用户在最初几秒里就能看到进展，而不是盯着一个转圈的空白页。
6. 实时人工接管：来源标签、时间跨度、底层查询词，全部支持随时手动微调与覆盖。模型的判断被定位成一个「起点」而不是「默认值」，用户可以随时它，这一点是 Jev Search 与传统 AI 搜索最本质的差别之一。
7. 恪守纯净索引：坚持只索引、不总结的极简主义，只提供精准链接与原始摘要，从根本上杜绝大模型凭空捏造、遗漏关键信息的顽疾。项目文档甚至主动承认摘要本身可能不准、不全、过期，而不是把这一点藏起来。
8. PWA 安装与自托管：既可以把官网添加到主屏幕、安装成 PWA 应用使用，也可以从 GitHub 拉取源码自托管到 Cloudflare Workers，把数据握在自己手里。

如何使用 Jev Search

Jev Search 的使用门槛很低，整个流程不需要任何配置即可上手，同时在需要深度控制时又留出了足够的干预空间。标准流程如下。

1. 访问站点并安装：打开 Jev Search 官网 https://jev.s1.dev/，也可以选择「添加到主屏幕」把它安装成 PWA 渐进式网页应用，iOS 上可以加到主屏幕，Chrome 与 Edge 上可以安装为桌面应用。
2. 用大白话提问：在搜索栏里像和助手对话一样描述心中所想，不必提炼关键词，也不必指定去哪个站点搜。
3. 观察 Jev 的判断：系统会立刻完成意图解构，被选中的目标源、时间过滤条件以及生成的查询关键词，都会以醒目的胶囊标签实时展示在页面上。这一步让「这次该怎么搜」的过程变得可见。
4. 手动调整（可选）：如果对模型的初始判断有异议，点击对应的来源或时间标签即可增删修改，底层查询词也可以直接点开编辑。改完会触发一次新的检索，额度计入同一份限流。
5. 浏览流式结果：结果以瀑布流形式持续涌来，每条结果旁边清晰挂着 0 至 100 的相关性得分，优劣一目了然；先返回的引擎先展示，无需等待全部完成。
6. 查阅次要线索：被判定为低相关的长尾结果会自动收纳进分组区域，点击即可展开深度查阅，既保证主列表干净，又不丢失长尾线索。
7. 自托管部署（进阶）：从 GitHub 克隆仓库，复制 .dev.vars.example 为 .dev.vars 并填入 Search1API 的 API Key 与 Jev Provider Key，执行依赖安装与开发服务器启动，再一键部署到 Cloudflare Workers 即可。

值得注意的是，Jev Search 提供了多个 Jev 服务入口，任意一个可用即可运行，其余作为备选。降级条件卡得很严格：只有 HTTP 402（额度耗尽）、429（被限流）或 5xx 服务端错误才会切换到下一个 provider，400、401 这类客户端错误不重试，请求已取消也不重试。每次切换都会留下日志，说明是谁挂了、换成了谁，最终由谁完成判断会写在 intent 的 judge 字段里。

Jev Search 的 12 个搜索来源与四档时间窗口

Jev Search 最有意思的一处设计是：12 个来源并不是一张写死的清单，而是 12 道送给模型回答的是非题。每个来源都带有自己的判据，交给 Jev 逐条作答，答完之后才决定这次检索要不要开这条通道。理解这一点，就能理解它为什么能在「该不该去 Reddit 看看」这类问题上表现得比规则引擎更灵活。

这里的分工其实很清晰：Jev 负责判断层，把模糊的自然语言请求翻译成精确的搜索参数——查询词、来源、时间范围三件套；Search1API 负责执行层，把这三个参数变成真实的多引擎并发调用。而对结果的打分则是判断层的第二项工作：把「可能相关的一堆链接」变成「按相关度排好序的列表」。同一个模型，被当成生成器用和被当成判断器用，可靠性完全不是一回事，这正是这个项目的核心洞察。

Jev Search 搜索结果页：多通道结果与相关性百分比

按通道类型划分，这 12 个来源可以分为三类。第一类是开放网络单引擎：Google、DuckDuckGo、Yandex，三者各自代表一个的网页视角，其中 Yandex 额外覆盖了俄语页面，默认开启。第二类是双通道来源：Hacker News、Reddit、GitHub，它们同时走「Google 限定站点搜索」和「自家专用引擎」两条路，兼顾覆盖面与专业性。第三类是垂直引擎：X、arXiv、YouTube、Wikipedia、IMDb、微信，分别对应社交短帖、预印本论文、视频、百科条目、影视条目和中文公众号内容。

源码里有一处很细的差别值得单独说：Wikipedia、IMDb 和微信这三个引擎不接受时间范围过滤，源码中直接给它们标了 timeFilter: false；IMDb 还额外标了 entityQuery，因为它要的是「名称或标题」而不是一句完整问句。同一套时间窗口参数套到不同引擎上是有例外的，这说明参数设计并非粗暴地一刀切。

来源的开启与否由概率决定。源码中的阈值是 SOURCE_PROB_THRESHOLD = 0.6：Jev 对某个来源给出不低于 0.6 的概率才真的开一条搜索通道；如果 12 个来源一个都没过线，系统会回落到默认的三个开放网络引擎，而不是返回空结果。换句话说，「这次该不该去 Reddit 看看」不是写死在代码里的规则，而是每次提问时现问现答的一道题——改判据就改行为，不需要改逻辑分支。

时间窗口共四档：不限时间、过去 24 小时、过去一周、过去一个月。由于底层引擎的时间过滤一向偏松，Jev Search 还补了一手：把确定性早于「窗口 × 1.5」的结果直接丢掉，并计入一个 stale 计数而不参与排序。丢了多少条是可见的，不是静默消失——这种「连自己丢掉什么都告诉你」的做法，在整个项目里反复出现。

输入侧的校验也做得很克制但很硬：可选来源列表最多只能列 12 个，超过就在调用任何 provider 之前返回 400，而不是静默截断；重复写同一个来源会被合并、只保留第一次出现，因此重复项既不会放大搜索调用，也不会放大打分调用。校验发生在花钱之前，而不是花钱之后。默认限流为每分钟 10 次，按 IP 按位置计算，改来源或改时间筛选触发的搜索同样计入这一额度。

Jev Search 的相关性评分、去重与排序机制

Jev Search 的排序环节同样值得拆开看。每条结果被送到模型面前的问题只有一个：这条结果讲的是用户问的那个题目吗？返回的「是」的概率被直接当作相关性分数使用，页面上看到的就是这个百分比。工程细节上有三处格外讲究：每批最多处理 40 条结果（RERANK_BATCH = 40）；多个批次并行发出而不是串行；当返回的概率缺失或类型不符时，记为 0，而不是猜一个中间值。

最后一条尤其能说明项目的取向：打分失败时宁可显示 0，也不要伪造一个看起来合理的分数。于是你在界面上看到的那个百分比，本质上是一个模型判断，不是经过验证的准确率——这句话是项目自己写在文档里的。这种自我定位的准确度，比多加一层伪装出来的确定性有用得多。

「最佳匹配」的排序规则依次比较四件事：是否已完成打分、相关性百分比（取整后比较）、被几个引擎同时命中、该引擎内的原始排名。第三条是这套排序的灵魂——两个来源都返回了同一个链接，说明两个互相的搜索系统都认为它相关，这个交叉信号比任何单一来源给出的高分都更稳。把「引擎一致数」放在相关性之后、原始排名之前，是一个很克制的次序安排。

去重做了两层，而不是简单比对链接。URL 归一化层会统一域名（去掉 www.，并把 twitter.com 归一成 x.com）、去掉路径尾部斜杠、剔除追踪参数（utm_ 前缀、fbclid、gclid、igshid、share_id、rdt 等）后重新排序查询串；标题归一化层则小写化处理，剥掉「- Reddit」「: r/xxx」「· GitHub」这类平台后缀，取前 8 个词。两者任一相同即视为同一簇，只保留一条做代表，其余收进折叠分组。源码注释把动机写得很直白：同一个故事不该占掉五个位置。

在时序上，项目还做了一处名为「投机启动」的工程取舍。常规流程是先问模型、拿到改写后的查询词、再去搜索，中间模型推理的那几百毫秒到几秒里搜索引擎是闲着的。Jev Search 的做法是：在你的原话上先发一次 Google，与模型推理并行进行。如果模型最终保留了原话、且没有附加时间窗口限制，就直接复用这次结果，一次多余的调用都没浪费；如果没命中，就丢弃这次结果，按模型的判断重发一次。源码注释写得很清楚——多数事实性问题上会命中，所以这次投机大多数情况下是净赚的，最坏情况也只是白跑一次。

结果返回采用换行分隔的 JSON 流，而不是等全部搜完才吐出的响应体。只有四种，它们的顺序就是用户看到界面的顺序：intent（模型理解成了什么，内含 judge 字段）、found（某个引擎刚答完，先把条数报出去）、lane（这条通道的结果已经打完分，可以排进列表）、done（总结总耗时与 token 用量）。关键在 found 和 lane 之间那一步：引擎答完先报数，再打分，所以用户先看到「有几条」，再看到「排序算完了」。时间上限也是硬的：单个引擎 15 秒，整个请求 30 秒，超了就放弃这条通道，而不是让一条慢引擎拖垮整次搜索。缓存方面，成功且非空的引擎响应会按查询缓存，时长取决于所选时间窗口，窗口越短缓存越短，大致在 10 分钟到 6 小时之间。

Jev Search 的核心优势

把这些设计细节串起来看，Jev Search 的竞争优势并不体现在「更聪明地回答你」，而体现在「更诚实地帮你找」。

Jev Search 开源项目主页

1. 拒绝幻觉与篡改：坚决不通过 AI 生成二手结论，只做优质信源的搬运工与索引者，确保信息的原汁原味与绝对可靠。整个链路里没有文本的生成环节——模型被问的是概率和索引，拿回的也是概率和索引，没有「模型发挥」的空间，自然也就没有把模型措辞当成事实来引用的风险。
2. 检索全自动化：把大白话完美转化成高阶、精准的组合检索式，自动决定查询词、来源与时间范围，省去繁琐的手动筛选与逻辑拼凑。这一步对于不擅长构造高级检索语法的用户尤其友好。
3. 排序完全透明：每一条内容都有据可依，0 至 100 的分数直接可见，排序规则依次比较打分状态、相关性、引擎一致数与引擎内原始排名；同时控制权百分之百掌握在用户手中，来源、时间、查询词随时随地可以按需干预。
4. 生态广泛全覆盖：一次请求打通 12 个维度的内容池，兼顾宏观网页、深度社区、代码托管、学术前沿、视频与中文公众号，容错率极高。一个引擎挂掉只损失一条通道，不会让整次搜索归零。
5. 极致的速度体验：得益于边缘计算、投机启动与流式输出架构，全球任何角落访问都能秒级响应；用户在最初几秒就能看到结果与计数，而不是等待全部通道完成。
6. 完全开源自主：支持一键私有部署到 Cloudflare Workers，敏感检索数据不必落地第三方商业服务器，隐私安全更有保障。项目采用 MIT 协议，代码可审计、可修改、可二次开发。
7. 故障边界清晰：某个来源整体失败时，界面显示的是一条警告而不是一个 0 结果；打分失败时显示 0 分而不是伪造一个看起来合理的分数；来源全都没过线时回落到默认三引擎而不是返回空页。这些边界处理共同构成了它的可靠性基础。

把这几条放在一起看，会发现 Jev Search 的取舍非常一致：它宁可承认自己没把握，也不愿意给出一个看起来漂亮但来路不明的结论。在一个「答案越来越便宜、可信度越来越贵」的环境里，这种取向的价值正在被重新认识。尤其是当你检索的内容会直接进入报告、论文、投资决策或产品方案时，一条可追溯的链接远比一段流畅的总结更有分量。

Jev Search 的使用场景

Jev Search 并不适合所有检索需求。它最擅长的，是那些「答案必须由你自己判断、但找到答案的过程可以被加速」的场景。

1. 硬核技术调研：输入「Rust async runtimes on Hacker News this month」，系统会临时开启 Hacker News 双通道并限定到本月，瞬间剥离软文营销，直达全球极客社区在 HN 上的真实口碑与技术探讨。相比直接在通用引擎里翻页，这种「先定来源再搜」的方式命中率高得多。
2. 前沿学术追踪：键入「New papers on speculative decoding」，Jev 会锁定 arXiv 数据库，第一时间捕获全球最新的学术洞察与预印本论文。对于需要长期跟踪某个方向的科研人员，这类查询几乎每天都要跑一次。类似的学术检索需求，也可以配合 复旦AI搜索 这类面向学术场景的检索工具交叉使用，中文文献与英文预印本各取所长。
3. 真实口碑甄别：搜索「What do Reddit users think of the Framework laptop?」，可以一网打尽海外真实社区中消费者对该笔记本的吐槽与赞誉。评论区的双通道设计让「帖子 + 评论」都被纳入检索范围，而不是只看主帖。
4. 敏锐的市场监测：设定严格的时间限定条件捕获行业风向词，以流式动态视角穿梭于各大引擎之间，洞察瞬息万变的市场动态。过去 24 小时这一档尤其适合追踪突发新闻与舆情。
5. 重大多维交叉核查：针对热点议题同时调动主流媒体、社交圈层及垂直硬核站点进行交叉比对，多视角还原，彻底摆脱单一信源造成的认知偏见。「引擎一致数」参与排序这一设计，恰好为交叉验证提供了量化抓手。
6. 代码与开源项目定位：GitHub 双通道同时覆盖仓库、Release、Issue 与 PR，适合快速定位某个库的实现细节、版本变更说明或已知缺陷讨论，比单纯在站内搜索更省事。
7. 中文内容检索：微信垂直通道专门覆盖中文公众号文章，教程、分析与观点类内容都在这里。对于习惯在中文语境下检索资料的用户，也可以配合 中文搜索机器人 使用，把公众号内容与更广的中文网页结果拼接起来看。
8. 开源项目与版本追踪：想知道某个库最近一次 Release 改了什么、某个 Issue 下有没有官方回应，GitHub 双通道比站内搜索更快，时间窗口还能把范围压到最近一周。
9. 影视与百科类事实核对：IMDb 与 Wikipedia 两条垂直通道分别处理影视条目与百科式背景事实，前者要的是名称而不是句子，后者不参与时间过滤，检索口径与通用网页完全不同。
10. 视频教程与演讲检索：YouTube 通道专门覆盖演讲、可看的教程与频道内容，适合找那种「看一遍比读十页文档快」的操作型资料。

反过来说，Jev Search 也有它明显不擅长的场景。如果你只是想快速知道「今天天气怎么样」「这个缩写是什么意思」，一个会直接给答案的工具显然更省事；如果你需要的是批量、高频的自动化调用，每分钟 10 次的默认限流也会成为瓶颈，这种情况下更合理的选择是自托管后按自己的额度规划，或者直接调用底层的 Search1API 服务。工具没有高低之分，只有适配与否的差别。

Jev Search 同类工具对比

在 AI 搜索这个品类里，Jev Search 常被拿来与 Perplexity 比较，但二者的产品取向其实差别很大：一个是不生成答案的判断器，一个是生成答案的答案引擎。下面这张表按六个维度做了对比。

如果你更看重「拿来就能用的结论」，Perplexity 这类答案引擎显然更省事；但如果你需要的是可追溯、可干预、可自托管的检索过程，Jev Search 的取舍就更对味。市面上走类似路线、强调把检索过程摊开给用户看的还有 SearchAny AI搜索引擎、MemFree – AI搜索引擎、SearchGPT – AI搜索引擎、XAnswer – AI搜索引擎、秘塔AI搜索（metaso.cn） 等，它们切入的角度各有不同，可以根据自己的主要检索场景做取舍。如果你主要搜的是文献类内容，Lumina AI学术搜索引擎 与 Suppr超能文献 — AI文献搜索引擎 会更聚焦；如果检索需求带有明显的中文口语特征，AI搜索【纯英文】【Lepton】 与 Heck AI搜索 也值得横向试一试。在企业级知识检索方向上，Qatalog: 企业级AI搜索与知识智能 与 pgvector 向量搜索引擎实战 代表了另一条以私有知识库为核心的技术路径。作为这一波 AI 搜索浪潮的起点，perplexity 本身依然是绕不开的参照系。

Jev Search 的自托管部署与边界说明

对很多技术用户来说，Jev Search 最有吸引力的部分不是在线体验，而是可以把它完整地搬回自己手里。自托管的流程相当标准：克隆 superagents-lab/jev-search 仓库，把 .dev.vars.example 复制为 .dev.vars，填入 Search1API 的 API Key 以及 Jev Provider Key（免费额度可在 typesafe.ai 申请），再执行依赖安装与本地开发服务器启动，最后部署到 Cloudflare Workers 即可。

在隐私部分，项目没有写「我们非常重视你的隐私」这类空话，而是逐条列出数据去了哪里：搜索请求会发给 Search1API，以及回答你这次提问的那个 Jev provider，后者还会收到结果的标题与摘要，用于打相关性分；Cloudflare KV 会存下由查询派生的缓存键和结果摘要，保留到设定的缓存时长；应用自身不记录搜索文本、推理出的查询词，也不记录结果点击；托管演示站加载 Cloudflare Web Analytics 统计页面浏览，不使用 cookie，也不记录 URL 查询串；限流使用客户端 IP。另外文档还主动说明，Workers 的请求日志是另一个开关，开启后调用日志里会包含请求 URL——其中可能含有查询词。这一条通常不会被写进项目文档，因为它对项目没好处，但写出来才让上面那句「应用自身不记录查询」变得可信。

关于离线能力，文档给了一个反直觉的答案：它支持从浏览器安装成应用，但装完仍然必须联网。安装包只缓存了一个离线页面，不缓存任何搜索结果；生产构建注册的 Service Worker 只在网络失败时接管顶层导航，并且从不拦截搜索接口。文档还专门解释了为什么本地开发不注册 Service Worker——怕影响 Vite 的热更新。此外，项目在 SEO 处理上也有自己的取舍：站点地图只列首页，搜索页面发送 noindex, follow，让示例查询和真实搜索不会被当成文档收录，但 robots.txt 并没有对搜索路径做 Disallow，这样仍然能看到那条指令。

Jev Search 的常见问题解答

Jev Search 会直接给出答案吗？

不会。Jev Search 坚持「只索引、不总结」的产品边界，只返回链接、摘要和一个可见的相关性百分比，不生成替你写好的答案。这是设计约束而不是功能缺失，目的是从根本上避免大模型的编造与遗漏。

可以自己部署一套 Jev Search 吗？

可以。项目基于 MIT 协议开源，从 GitHub 克隆 superagents-lab/jev-search 仓库后，配置 Search1API 与 Jev 的 API Key，即可部署到 Cloudflare Workers 边缘节点，实现数据完全归属自有的私有化实例。

结果旁边的 0 至 100 分是怎么来的？

这是 Jev 模型对「这条结果讲的是用户问的那个题目吗」给出的判断概率，直接作为相关性分数使用。它是一个模型判断而非经过验证的准确率，打分失败时记为 0 而不是猜一个中间值；排序时还会依次参考引擎一致数与引擎内原始排名。

Jev Search 的一次完整检索示例

把抽象的流程放进一个具体例子里会更好理解。假设你输入的是「最近一周 Hacker News 上关于 Rust 异步运行时的讨论」，Jev Search 内部大致会经历下面这些步骤。

1. 意图推断：模型被问四类问题——时间窗口选哪一档（这里会命中「过去一周」）、十二个来源各自要不要开（Hacker News 会以一个高概率被选中，GitHub 可能也会被带上，Wikipedia 与 IMDb 的概率则很低）、候选查询词里哪个最适合直接发给搜索引擎、以及哪个候选是所查事物的纯名称。拿回来的是概率与索引，不是文章。
2. 投机启动：在你原话上先发一次 Google，与模型推理同时进行。如果模型最终保留了原话且没加时间限制，这次结果会被直接复用；本例因为加了时间窗口，命中概率较低，这一次大概率作废。
3. 并发检索：按模型的判断，Hacker News 同时走「Google 限定站点搜索」与「专用引擎」两条通道，GitHub 可能也开一条，其余来源按概率阈值决定是否开启。所有调用并发发出，单引擎 15 秒、整请求 30 秒封顶。
4. 流式回传：先收到 intent ，页面上出现来源与时间胶囊；随后某条通道完成，先发 found 报条数，界面显示「已找到若干条」；打分完成后发 lane，这批结果带着分数进入列表；最后 done 汇总耗时与 token 用量。
5. 打分与排序：每条结果被问一句「这条讲的是用户问的那个题目吗」，概率直接作为分数；缺失记为 0。排序时依次比较是否已完成打分、相关性百分比、被几个引擎同时命中、引擎内原始排名。
6. 去重与折叠：URL 归一化与标题归一化两层比对之后，重复簇只保留一条代表，其余进折叠分组；同时确定性早于「一周 × 1.5」的结果被剔除并计入 stale 计数。
7. 人工干预：如果你觉得不该限定一周，点掉时间胶囊；如果你觉得还应该看看 Reddit，手动加上来源标签。改动会触发一次新的检索，并计入同一份每分钟 10 次的额度。

整个过程中，没有任何一步涉及「把读到的内容改写成一段总结」。模型从头到尾只做了两件事：决定去哪儿搜，以及判断搜回来的东西相不相关。这就是它与答案引擎最本质的分工差异，也是它敢于宣称不生成答案的底气所在。

Jev Search 适合谁、不适合谁

任何工具都有自己的适用半径，Jev Search 尤其如此，因为它主动放弃了一部分用户最想要的东西。判断自己是否属于它的目标用户，可以从下面几个问题入手。

1. 你是否愿意自己读原文？如果你需要的是「一句话告诉我结论」，那 Jev Search 会让你失望；但如果你本来就要点进原文核对细节，它帮你省下的正是找原文的那段时间。
2. 你的检索是否涉及多个信源？技术讨论在 Hacker News、实测口碑在 Reddit、论文在 arXiv、中文观点在公众号——如果一次检索需要横跨这几类地方，多引擎并发的价值会非常明显；如果只查一个站点，收益就没那么大。
3. 你是否在意时效性？四档时间窗口加上「窗口 × 1.5」的过期剔除，让它很适合追踪近期动态；反过来，如果你常做跨度数年的历史检索，这个功能的存在感就很低。
4. 你是否需要干预检索过程？能手动改来源、改时间、改查询词，意味着它适合那些「知道自己要什么、只是懒得手动拼检索式」的人；如果你更希望工具替你决定一切，这个功能反而是负担。
5. 你是否有私有化需求？对需要把检索行为留在自有环境里的团队来说，MIT 协议加上 Cloudflare Workers 部署路径，几乎是这类工具里门槛最低的方案之一。

Jev Search 官网网址

以下是 Jev Search 的官方入口与开源仓库地址，可直接访问体验或拉取源码自托管。

官方体验站点：https://jev.s1.dev/

GitHub 开源仓库：https://github.com/superagents-lab/jev-search

Search1API 官方站点：https://s1.dev/

OpenI AI时代点评

Jev Search 的特别之处，在于它把「不做什么」写在了最显眼的位置。当大多数 AI 搜索产品争相把答案写得越来越长、越来越像一篇小作文时，它反其道而行，只交付链接、摘要和一个可见的相关性百分比，把阅读与判断的权利完整交还给用户。这种克制在短期内可能显得「不够聪明」，但对真正依赖检索做决策的人来说，可追溯性远比流畅度重要。

从工程角度看，这个项目值得学习的地方也很多：把模型当作判断器而非生成器使用，拿回的是概率和索引而不是文本，从源头上压缩了幻觉空间；投机启动让搜索引擎在模型推理的间隙就开始工作；两层归一化去重避免同一个故事占掉五个位置；provider 降级只对 402、429、5xx 生效，把「值得重试的故障」与「重试也没用的错误」区分开来。这些都不是炫技，而是对成本、延迟与可靠性做了认真权衡之后的结果。

当然也要看到它的适用边界。Jev Search 不适合想要「一句话拿到结论」的轻量需求，默认每分钟 10 次的限流对高频批量调用也不友好；相关性分数是模型判断，需要用户自己保留一份审慎。但如果你正好需要一款能看见检索过程、能手动干预每一步、还能自己托管的搜索工具，它几乎是目前开源生态里最干净的选择。建议先到 Jev Search 官网 用几条自己真实的查询试一试，再决定是否值得为自己的工作流部署一套私有实例。

横向来看，AI 搜索这一赛道已经分化出多条路线：追求即时答案的 Heck AI搜索引擎，主打聚合与比对的 GenSpark AI搜索引擎，面向垂直资源的 短剧搜索，以及以向量库为核心的 pgvector 向量搜索引擎实战。Jev Search 在其中占据的是一个很独特的生态位——它不是回答者，而是判断者；而这个生态位，恰恰是当下最容易被忽视、也最不该被忽视的一个。