技术解读

以下内容由 GitRead 中文社区 编辑团队基于项目 README 与官方资料整理, 结合中文开发者的常见使用场景补充技术选型建议。具体以项目官方文档为准。

dsh-free-search:给 DeepSeek Harness 装一个不要钱的搜索插头

项目背景与痛点

凡是给大模型接过联网搜索的人,都踩过同一类坑:模型明明有能力调用工具,卡住流程的却是一张 API Key。Bing、Google、Serper、Tavily、Brave——搜索 API 生态几乎清一色要求注册、绑卡、配额、环境变量。这在产品里尚可接受,到了评测和复现场景就非常难受:你写好一个跑 DeepSeek 的 harness,想把"模型是否会正确使用搜索工具"作为一项能力指标来测,结果别人 clone 下来第一件事是问你申请了哪家 key。

dsh-free-search 的定位很直接:为 DeepSeek Harness 提供一个零凭证的搜索 provider,后端走 DuckDuckGo,不需要 API Key,也不需要账号。它解决的不是"搜得更好",而是"搜得了、且任何人一分钟内都能搜得了"。

核心技术揭秘

从项目定位反推,技术栈几乎可以确定:Python + HTTP 客户端(requests 或 httpx)+ HTML 解析器(BeautifulSoup / lxml / selectolax),大概率同时提供同步与异步两套入口,以便适配 harness 里不同的调用路径。

真正的实现核心在于一条"抓取—解析—还原"的链路,而 DuckDuckGo 的 server-rendered HTML 端点正是这条链路能成立的前提:

graph TD A[Harness 工具调用] --> B[SearchProvider 适配层] B --> C[查询构造与参数归一化] C --> D[DuckDuckGo HTML 端点] D --> E{"响应状态"} E -->|"正常 HTML"| F[DOM 解析抽取结果] E -->|"验证码或挑战页"| G[退避重试与 UA 轮换] G --> D F --> H[uddg 跳转链接解码] H --> I[同域去重与广告过滤] I --> J[结构化结果对象] J --> K[回填至模型上下文]

链路上有四步值得细看:

其一,参数归一化。 Harness 传下来的是结构化的查询参数,而 DDG 只认 q、kl(地区)、df(时间范围)、s(偏移量)这套原始字段。这一层做的是"协议翻译",顺带把分页请求合并成多页聚合,避免上层感知 DDG 的翻页细节。

其二,结果抽取。 DDG 的 SERP 里 result__a、result__snippet、result__url 这几个 class 是相对稳定的锚点,但它终究是"契约之外的接口"——HTML 随时可能漂。因此健壮实现不会只写一组 selector,而是多组兜底 + 容错解析,遇到结构性缺失就丢字段而不是抛异常。

其三,链接还原,这是最容易被忽略的一步。 DDG 返回的结果 href 并不是真实 URL,而是 //duckduckgo.com/l/?uddg=<percent-encoded> 形式的跳转壳。必须做一次 unquote 才能拿到目标地址;漏掉这一步,等于把一堆 DDG 跳转链接喂给模型,后续的网页抓取会全部跑偏。

其四,反爬对抗。 无 Key 的另一面就是无配额契约,DDG 只能靠匿名速率和行为指纹来判断。所以工程上必须准备指数退避、User-Agent 轮换、超时重试,以及可选的代理出口——这些不是加分项,而是能不能跑通的门槛。

架构层面,它采用的是典型的 Adapter + Registry:定义一个搜索 provider 的抽象接口,把 DuckDuckGo 作为一种实现注册进去。这个设计比"硬编码一个 search 函数"高一个维度,因为它让 Tavily、Bing 或本地索引可以平替进来,也让"失败降级到备用 provider"成为可能。

功能亮点与差异

零凭证、零账单。 这是它最硬的差异点。CI 里不需要 secret,评测脚本天然可复现,这对 benchmark 类项目是刚需而非锦上添花。

原始结果而非加工结果。 Tavily、Serper 这类商业 API 卖的是"LLM-ready"的结果——正文抽取、答案摘要、相关性重排。DDG 给的是裸 SERP。对做 agent 产品的人来说这是劣势;但对评测来说恰恰是优势:你测的是模型使用搜索工具的能力,不该让搜索引擎的摘要能力替你答题。这个定位差异,才是它真正的立足点。

依赖极轻。 没有 SDK、没有 OAuth 流程、没有控制台配置,一个函数调用就能拿到 [{title, url, snippet}]。

应用场景与落地建议

适合:评测 baseline、本地 agent 原型、教学演示、受限网络环境下的兜底搜索源。

不适合:高 QPS 生产服务、需要 SLA 承诺的场景、需要正文抽取与语义重排的深度检索。

落地时建议守住几条线:

  1. 限速:并发压到 1–2,QPS 控制在 1 以内,批量任务务必上指数退避,否则封得很快。
  2. 缓存:以 query + locale 为 key 落本地 SQLite 或 Redis,评测场景通常能砍掉大半重复请求。
  3. 熔断降级:3–5 秒超时,失败时降级到备用 provider,而不是让异常穿透整个 agent loop。
  4. URL 安全:uddg 解码后必须校验 scheme 与内网地址,搜索结果来自第三方,直接信任就是 SSRF 入口。
  5. 结果清洗:同域去重、snippet 截断、保留 domain 字段供模型自行判断可信度。
  6. 合规:遵守 DuckDuckGo 的使用条款与 robots 约定,别把它当作免费爬虫入口滥用。

综合评价

优点:精准命中"凭证摩擦"这个真实痛点;架构上是可插拔的 provider 而非一次性脚本;依赖极轻、开箱可复现;对隐私敏感场景天然友好。

缺点:稳定性完全寄生在 DDG 的 HTML 结构上,属于无契约集成,改版即可能失效;无 SLA、无配额保障,规模化必然触发反爬;结果质量天花板偏低,缺少正文抽取与重排,深度检索仍需二次加工。

一句话总结:它是一个做得相当克制的"搜索垫片"——价值不在于搜索做得多好,而在于把接入搜索的门槛压到了零。拿来跑评测和原型是上策,拿来当生产搜索基建则是误用。

关于

GitHub 原始描述(英文)

Free web search provider for DeepSeek Harness - DuckDuckGo backend, no API key needed

描述取自 GitHub 官方 API,保持仓库作者书写的原文。

简要分析

热度分
1317
价值分
726
活跃状态
活跃

语言占比

Batchfile
HTML
JavaScript
PowerShell

Release