bailynlove/web-search-opencode-responses

web-search-opencode-responses

一个 DeepSeek Harness (dsh)
WebSearchProvider 插件，它通过 OpenCode Zen Go 网关上的 OpenAI Responses API
在服务端运行网络搜索——因此 web_search 会计入你的 OpenCode 套餐，而不是消耗
DeepSeek API 配额。

官方的 web-search-deepseek 提供程序绑定于 Anthropic：它使用 DeepSeek 的
Anthropic 兼容 Messages API（https://api.deepseek.com/anthropic/v1 上的
POST /messages），这条线路只能到达 DeepSeek 自己的端点——它无法指向
OpenCode。本插件的存在就是为了绕过这一限制：它换用 OpenAI Responses API
（使用原生 web_search 服务端工具的 POST /responses），对接
https://opencode.ai/zen/go/v1，因此同一个 WebSearchProvider 接缝可以在
OpenCode 套餐上运行搜索。从官方提供程序沿用的唯一东西就是工作原理——一次搜索就是
一次模型调用，其推理后端执行搜索；而线路、端点和计费则完全不同。

来源是如何推导的

该网关不会填充 url_citation 注解，因此提供程序按如下方式映射：

1. open_page 类型的 web_search_call 动作——服务器实际打开的页面（可信度最高；
#ws_call_id=… 跟踪片段会被剥离）；
2. url_citation 注解，当网关提供它们时（它们会覆盖主机名回退标题，并可以添加
摘要片段）；
3. 作为回退，最终答案文本中的绝对 URL——即模型报告在搜索后找到的内容。

如果这些都没有产生来源，搜索会大声失败（WEB_PROVIDER_ERROR），而不是返回
一个没有来源的答案。

安装（到 web 配置文件中）

该包以 dsh bundle 形式发布：一条安装命令既添加插件依赖，又应用补丁层，将 web
接缝指向此提供程序。

从配置文件目录（或使用 --profile ），从 GitHub 安装：

dsh plugin --profile web add github:bailynlove/web-search-opencode-responses

这会链接该包，将其追加到 dsh.profile.bundles，并应用其 cordis.patch.yml——
插入 web-search-opencode-responses 行并设置
web.searchProvider: opencode-responses。验证该层，然后启动：

dsh --profile web --dump-config   # shows a "# == web-search-opencode-responses" layer
dsh --profile web

要固定到特定发布版本，而不是移动的默认分支，请使用某个提交：

dsh plugin --profile web add github:bailynlove/web-search-opencode-responses#

对于开发期间的本地检出，保留较旧的 file: 接线方式：在配置文件 package.json
中声明
"web-search-opencode-responses": "file:./plugins/web-search-opencode-responses"，
并将相同的两行补丁（插入插件，设置 web.searchProvider: opencode-responses）
添加到配置文件的 cordis.patch.yml 中。

配置
该插件在 Host 上注册了一个设置区段（web-search-opencode-responses）。注意： dsh web 的插件配置标签页只显示 web 客户端自带的提供商命名空间卡片（DeepSeek、Shell、Agent loop）——像本插件这样的第三方命名空间还没有客户端卡片，因此请改为通过设置文档进行配置：

- key — 可视化操作：dsh web Settings → Models，写入 OPENCODE_GO_API_KEY 凭据（存储在 ~/.dsh/.credentials.yaml）。
- endpoint / model / key reference — 编辑设置文档 ~/.dsh/settings.yaml，可通过 web UI 中的 Open configuration file 按钮打开：

web-search-opencode-responses:
baseURL: https://opencode.ai/zen/go/v1   # optional; /responses is appended
model: deepseek-v4-flash                  # optional; server-side search model
apiKeyEnv: OPENCODE_GO_API_KEY            # optional; credential reference
apiKey: ""                                # optional; literal key over the ref

该文件会热重载，因此更改会在下一次搜索时生效；提供商每次搜索都会读取该区段，无需重启。

等效的静态值可以在插件的 cordis.patch.yml 条目（组合基础）中编写；设置文档会覆盖它。请参阅下方的配置字段表：

| field       | default                          | meaning                                   |
| ----------- | -------------------------------- | ----------------------------------------- |
| apiKey    | –                                | literal key; prefer the credential store  |
| apiKeyEnv | OPENCODE_GO_API_KEY            | credential reference resolved per search  |
| baseURL   | https://opencode.ai/zen/go/v1  | gateway endpoint; /responses appended   |
| model     | deepseek-v4-flash              | Responses model with server-side search   |

该密钥首先通过 dsh 的凭据服务解析（web Models 页面会写入 ~/.dsh/.credentials.yaml），然后才是启动环境；存储的密钥永远不会离开本机——传输层会将其脱敏。

测试

node --test test/mapping.test.mjs test/provider.test.mjs   # unit, offline
node test/integration.mjs                                  # real API, needs the key

说明

- 未文档化的路由。 OpenCode 的 go 文档 仅在 chat/completions 下列出 deepseek-v4-flash，并在 /v1/responses 下列出 Grok/GPT/Muse。根据实际经验，该网关也会在 /v1/responses 上路由 deepseek 模型，并在那里执行服务端 web_search（已用新鲜的、真实的结果反复验证），这与 DeepSeek 自己的 Responses API 一致，其中 web_search 被记录为服务端执行。如果 OpenCode 将来将路由限制为文档所述的矩阵，搜索将开始以 WEB_PROVIDER_ERROR 失败——响亮报错，绝不伪造。请注意官方列出的 responses
- 模型不是后备方案：grok-4.5 接受了工具但未执行任何搜索，而是凭记忆作答。
- 每次搜索消耗一轮模型调用；服务器将搜索结果注入模型上下文（观察到约 25k 输入 token）——由 OpenCode 计费。
- 搜索质量取决于模型：它会在多轮中自主改写查询并打开页面。
- 答案文本 URL 后备机制仅在输出包含至少一个已执行的 web_search_call 操作时才会启用——来自从未搜索过的模型的 URL 是记忆，而非来源。