Degoog

简要说明#

Degoog 是一个自托管的元搜索聚合器。它自己不建搜索索引，而是把你的查询同时发给多个搜索引擎，把结果收在一个页面里展示。

这件事的背景是 Google 搜索正在变得和以前不一样。2026 年 Google I/O 上发布的 AI Mode 把搜索变成了类似 ChatGPT 的对话界面，AI Overviews 覆盖更多查询，推广内容也更密集。不是每个人都喜欢这种变化。如果你只是想快速看到网页链接，不想要 AI 摘要、不想要推广结果、不想要 Google 告诉你应该看什么，自托管的元搜索聚合器是一个方向。

Degoog 在这个方向上的定位是：比 SearXNG 更轻量、更模块化。截至 2026 年 6 月，它在 GitHub 上有超过 1,300 个 Stars，XDA Developers 等科技媒体也做过专门评测。

部署#

Degoog 的部署非常直接——官方推荐用 Docker Compose。从部署文档看，启动一个实例只需要三步：

mkdir -p ./data
sudo chown -R 1000:1000 ./data
docker compose up -d

默认端口 4444，容器的磁盘占用和内存消耗都比较低（对比基于 Python 的 SearXNG 优势明显）。支持四种部署配置：

配置	适用场景
simple.yml	个人使用、低流量
valkey.yml	加 Valkey 缓存，多副本或公开实例
postgres.yml	高流量公开实例（大索引 + 并发写入）
full.yml	全栈：Valkey + Postgres

不具备 Docker 环境的用户也可以直接装 bun 运行原生版本。项目依赖单纯（bun、git、curl），不需要额外数据库或缓存就可以跑起来。

首次启动后的配置#

第一次打开 Degoog 的设置页时，Store 默认还是空的。新版本把很多能力都移到了扩展仓库里，所以界面会先提示你添加一个 Git 仓库。官方默认仓库是 https://github.com/degoog-org/official-extensions.git。加上之后，下面的商店列表才会开始显示可安装内容。

这里的仓库不是单纯放主题的地方。按官方说明，Repositories 是一组公开的 Git URL，用来提供搜索引擎、自动补全、主题、插件和 transport。除了官方仓库，社区维护的仓库也可以在 https://degoog-org.github.io/community-extensions/ 这个页面里查。社区扩展的数量会更多，但是否要装，还是要自己看维护状态和安全边界。

仓库加好以后，可以先从 Store 里补齐最基础的搜索引擎。官方仓库已经整理了很多现成项目，直接在列表里点 Add 即可，不需要手动写配置。对刚部署完的实例来说，这一步基本就是把 Degoog 从“能打开”变成“能正常搜”。

自动补全也需要单独安装。它的作用是在你输入关键词时给出联想建议，和主搜索结果是两套扩展。官方仓库里已经有不少可选项，装好之后，搜索框就会根据你输入的内容返回候选词。要不要开、装哪几个，取决于你更看重输入体验，还是更在意请求尽量少。

主题和其他扩展也是同样的思路。先加仓库，再进 Store 浏览需要的条目。主题主要影响界面外观，插件和 transport 则会继续改变搜索页能做的事。Degoog 这一套比较像“先部署壳，再按需装能力”，第一次配置时会比传统开箱即用的搜索前端多几步，但灵活性也确实更高。

扩展系统#

这是 Degoog 和 SearXNG 之间最明显的差异。Degoog 把它的可扩展性做成了插件市场的形式。

扩展类型包括：

• 搜索插件 — 输入 !weather London 触发天气查询，!gh degoog 直接搜索 GitHub
• Slot 插件 — 在搜索结果上方或侧边显示自定义面板（比如天气面板、计算器）
• 主题 — 完整的 CSS 自定义，有社区制作的多种主题
• 自定义搜索引擎 — 添加自己的搜索后端适配器
• Autocomplete 提供器 — 根据输入内容返回关键词联想
• 运输层 — 定制 HTTP 抓取策略（默认 fetch、可选 curl、FlareSolverr 等）

安装方式是在 Settings → Store 中添加扩展仓库，然后浏览安装。官方仓库是默认起点，社区扩展也有独立仓库，不过维护者明确提醒过：社区插件只做了初步审查，安装后需要自行评估安全风险。

与 SearXNG 的比较#

Degoog 的开发者承认自己站在 SearXNG 的肩膀上——没有 SearXNG 就不会有这个项目。从外部评论看，两者各有侧重：

• Degoog 更轻量：TypeScript + Bun 运行时，资源占用比 SearXNG 的 Python 栈低。XDA 的评测也提到它的响应速度让人满意。
• 扩展系统更灵活：SearXNG 也支持自定义引擎，但 Degoog 的插件系统（bang commands、slot 面板等）提供了更丰富的扩展点。
• SearXNG 更成熟：多年迭代（13,000+ Stars）、更完善的引擎适配、更大的社区。自 2026 年 3 月发布的 Degoog 在功能覆盖和边缘情况处理上还有差距。
• 隐私方面：两者都是自托管，数据都不离开你的服务器。Reddit 上有人问过这个问题，从架构设计上看 Degoog 没有数据外传的逻辑，但项目较新，经过了多长时间的安全审查是个合理顾虑。

使用场景#

Degoog 解决的最直接的问题是：搜索结果太”脏”了。如果你有以下情况，它可能会实用：

• 受够了 Google 搜索里越来越多的 AI 摘要和推广链接
• 做技术调研时需要在多个引擎间跳转对比结果
• 有自托管的环境（NAS、家庭服务器、VPS）
• 希望搜索结果中能直接嵌入常用工具的快捷搜索（GitHub Issues、文档站点、论坛等）

从 XDA 的评测看，作者用一天就完全适应了把 Degoog 设为默认搜索引擎，没有觉得搜索质量有明显下降，反而因为结果更直接减少了搜索时间。

局限性#

• 自托管门槛：Degoog 需要 Docker 或服务器运行环境，不是浏览器扩展或 SaaS 那种开箱即用的工具。没有自托管经验的用户需要先部署。
• 引擎依赖：搜索结果的质量取决于你配置的搜索引擎可用性。部分搜索引擎可能会对频繁查询做 rate limit，需要自己观察和调整配置。
• 无跨设备同步：这里没有 Google 那种跨设备的历史和设置同步。当然，这也可以说是隐私的代价——你的搜索数据不会出现在别人的设备上，但也不会出现在你自己的另一台设备上。
• 项目还比较新：3 个月的年龄意味着社区资源、故障排查案例、第三方集成都还在积累中。如果遇到问题，可参考的资料少于 SearXNG。

AI Agent 调用#

如果你想把 Degoog 接到 AI Agent、工作流平台或自建助手里，它是有官方搜索 API 的，不需要去抓网页结果。文档里已经列出了可直接给外部程序调用的接口，默认和 Web UI 跑在同一个地址上。

最常用的是 GET /api/search，返回 JSON 结果，里面会带标题、链接、摘要、来源引擎、合并后的评分，以及相关搜索建议。对 Agent 来说，这种结构比直接解析 HTML 更省事，也更稳定。自动补全也有单独接口 GET /api/suggest?q=...，适合做输入联想，但通常不是主搜索流程的必需部分。

curl "http://127.0.0.1:4444/api/search?q=site%3Agithub.com%20degoog"

如果你在 Settings → Server 里给搜索接口启用了保护，请求时还要带上 Bearer Token：

curl -H "Authorization: Bearer YOUR_API_KEY_HERE" \
  "http://127.0.0.1:4444/api/search?q=site%3Agithub.com%20degoog"

从官方 API 文档看，Degoog 还兼容 Open WebUI 里的 SearXNG 搜索接法。也就是说，只要你的 Agent 或搜索插件本来支持 SearXNG 风格的查询地址，很多时候可以直接把 URL 改成 Degoog 的 /api/search 来试，不一定要单独写一套适配层。至于流式接口、指定引擎列表、按图片或新闻类型搜索这些能力，文档里也有，不过更适合留到后续集成时再展开验证。