dsh-web-search-provider

内置的 web-search-deepseek 插件在工作时，需要另起一个内部会话来执行搜索，再把结果和页面摘要塞回主会话——这意味着更长的等待和成倍的 token 开销。dsh-web-search-provider 换了个思路：它不经过 DSH 内部的 web_search 工具，而是让模型直接把联网搜索请求发到模型服务商的端点，由服务端原生执行搜索并返回结果。实测中，同样的五次指定搜索任务，该插件平均耗时 14.5 秒、输出 token 约 822，而内置插件需要 47.5 秒和 4,446 token，差距相当明显。任务搜索量越大，优势越突出。

核心能力取决于你连接的服务商 API 类型。对接 OpenAI Responses API 时，模型不仅能发起搜索，还能直接查看某个 URL 的页面内容、在页面内定位特定文本，省去了 AI 用 bash/curl 逐字抓取整页的环节。对接 Anthropic 兼容 Messages API 时则仅提供搜索能力。插件支持按提供商白名单、base URL、模型、超时等参数精细配置，也能在会话开始前自动探测端点是否真正支持原生搜索，避免首次调用时直接报错。由于不占用 DSH 内部的 web_search 工具位，它可以与 web-search-deepseek 等其他搜索插件并存，按需切换。

适合以下场景：你的 DSH 会话频繁需要联网查证、对响应速度和 token 成本敏感，且当前服务商确实提供了原生搜索能力。如果你在 OpenAI Responses API 生态中（例如 Deepseek 官方、OpenCode Go、OpenAI 中转站），体验最为完整。需要注意的是，部分服务商对搜索能力额外计费；若服务商虽走 Responses/Message API 却不支持搜索，首次调用会报错，但 DSH 本身仍可正常使用，只是少了联网搜索这一项。