把 Search1API 作为 LobeHub 的搜索服务商
Search1API 已经内置在 LobeHub 里，既是搜索服务商也是网页抓取器。在自建部署上，把三个环境变量指过来，LobeHub 原生的 Web Search 就开始查找最新来源并读取其背后的页面。
打开之后有什么
对话里能拿到最新来源
LobeHub 的 Web Search 技能会去取实时结果，而不是依赖模型已有的知识。
连结果页面一起读
Search1API 同时充当抓取器，所以 LobeHub 可以取到结果页的正文，而不是只拿摘要。
不用装插件
LobeHub 里本来就有服务商的位置。配置是服务端的环境变量，不是从市场里装东西。
配置服务端
把下面这些加进 LobeHub 服务端的环境，然后重启或重新部署，让进程读到新值。
服务端环境变量 — bash
几点值得知道
这适用于自建的 LobeHub。LobeHub Cloud 有自己的搜索基础设施，不会读取这些变量。
key 要留在服务端，不应出现在浏览器代码或代码仓库里。
CRAWLER_IMPLS 是按顺序排列的，所以 "search1api,naive" 在页面取不到时会退回内置抓取器。
如果你想要的是一组独立的 agent 工具，而不是补齐内置的 Web Search，那应该用 MCP 服务器。
大家拿它做什么
自建的助手，回答时带上最新来源并附链接。
需要联网搜索、又不想把流量经过厂商云的内部部署。
把用户贴进对话的页面整篇读完。
常见问题
LobeHub Cloud 上能用吗？
不能。这些变量是配置自建部署用的。LobeHub Cloud 运行自己的搜索基础设施，不会读取它们。
CRAWLER_IMPLS 是干什么的？
它按顺序列出 LobeHub 读取结果页时可以使用的抓取器。设成 search1api,naive 表示优先用 Search1API，失败时退回内置抓取器。
这和装 MCP 服务器是一回事吗？
不是。这是把 LobeHub 内置 Web Search 的位置填上，搜索发生在那个功能内部。MCP 服务器则是给模型一组独立的、可调用的工具。想让 LobeHub 自己的搜索好用就选前者，想要工具就选后者。