jev-research-mcp

我每天都在用编码 Agent 工作，一直观察到同一个浪费模式：

Agent 做网页研究 -> 抓取 20 个完整页面 -> 把导航栏、Cookie 横幅、广告和重复的文档直接塞给循环中最贵的模型。

这很慢，消耗大量上下文，而且模型读到的东西有一半是它根本不会用到的废料。

JEV Evidence MCP 就是我为解决这个问题做的尝试。它是一个自托管、开源的 MCP 服务器，只提供一个工具：research(query)。

它不返回原始页面，而是用 TypeSafe JEV 进行两次过滤：

1. 抓取前：这个搜索结果是否相关且有用？如果不是，我们根本不去抓取——不为垃圾浪费网络请求。

2. 解析后：这个文本块对编码 Agent 来说是否相关且可操作？如果不是，我们就裁掉。

你拿到的结果是带有溯源信息的紧凑证据块——保留原样的代码、还原后的标题、附带 URL。不改写、不总结、不臆造引用。下游模型仍然负责推理，只是获得了干净的推理素材。

隐私也是核心考量。这是 local-first（本地优先）的 BYOK 方案。除了发往 Brave（用于搜索）、TypeSafe（用于判断）以及你选择的目标 URL 之外，你的密钥、查询和文档都留在你自己的机器上。我这边什么都收不到——没有遥测，没有托管服务。

在这次发布的过程中，你的方法或流程是如何演进的？

三大转变：

1. 从生成到筛选。

我最初的本能反应是"总结网页"。我很快否定了这个方向。总结器会破坏代码格式并捏造事实。原则变成了：JEV 负责判断，代码负责处理。JEV 回答语义层面的 yes/no 问题，确定性的代码负责其他所有事——HTTP、解析、批处理、预算控制、去重。我们筛选证据，从不生成证据。

2. 从激进过滤到保守保留。

早期版本裁得太多。我后来意识到，漏报造成的损害远大于误报——丢掉唯一正确的资料源会让 Agent 直接崩溃。所以现在如果 JEV 不确定，我们就保留。策略是明确的：保留 = 相关且有用，不确定的区间默认保留。所有阈值都可配置。

3. 从宣称到实证。

我拒绝以"减少 90% token！"这种营销话术上线。所以我构建了一个基线模式（不使用 JEV）和一个实时基准测试，在完全相同的查询上对比基线 vs. JEV——避免的抓取数、看过/保留的块、token 数、延迟。不用固定测试数据。在你自己的负载上跑，用你自己的数字说话。

我还加了一个 localhost 仪表盘，因为漏斗本身就是产品——你可以真正地看着 搜索 -> 筛选 -> 抓取 -> 看过/保留的块 -> 证据 这一整个流程。如果你看不到什么被裁掉了、为什么被裁掉，你就不会信任它。

这就是我要发布的东西：过滤两次，少抓一些。