dsh-crw 怎么安装？

在已安装 dsh CLI 引擎的环境中，进入插件页复制安装命令一键执行即可；自动检查通过：npm 包已发布且 engines 声明满足基线（声明 Node ^22.19.0 || >=24.0.0）；该结论来自程序自动检查，未经人工实机验证。

dsh-crw 有中文文档吗？

已提供中文翻译 README（由 DeepSeek 最新模型翻译生成），本站可切换中英文对照阅读。

dsh-crw 还在维护吗？

GitHub 2 星。最近一次上游提交在 2026/9/24。

← 返回列表

fastCRW 网页抓取fastcrw/dsh-crw

DeepSeek Harnessspec-screened扫描：中风险websearch在 GitHub 查看 ↗

✓ 可直接安装

基于 fastCRW 的 websearch 和 webfetch，用于

自动检查通过：npm 包已发布且 engines 声明满足基线（声明 Node ^22.19.0 || >=24.0.0）；该结论来自程序自动检查，未经人工实机验证。 · 最近上游提交 2026/9/24 · 已提供中文文档

为DeepSeek Harness（ctx.web）提供由fastCRW支持的web_search和web_fetch提供程序

综合分

31.4

GitHub 分

31.4

用户评分

—

★ Stars

周下载量

—

安装插件（需先安装 dsh CLI 引擎：npm install -g @deepseek-ai/dsh）

dsh plugin --profile web add dsh-crw

npm 包 dsh-crw 已校验归属本仓库，走 npm 安装最省事

信任档位：已验证本站已于 3 天前真实安装成功（L4 · 真实安装）

是什么: dsh 原生插件 · chat
装得上吗: 本站已真实安装成功（L4 · 真实安装，非静态推断）
安全吗: 本站尚未对该插件做风险分级（暂未覆盖，不等同于无风险）
还在维护吗: 活跃：最近一次提交在 1 天前

档位由下列信号合成：本站实装验证（真实安装，当前最高到 L4）· 验证所用 dsh 版本 · 静态安装检查 · 风险分级 · 仓库维护状态。下方各区块是它的证据明细。验证判据与等级说明 →

🟢实装验证通过· 2026/9/22

由本站实装验证器在真实 dsh 环境安装成功，非静态推断。

数据截至 2026/9/25（元数据每日更新 · 实装验证按队列轮转，单条结论的验证时间见上方）

安装兼容性检查✓ 自动检查通过

以下结论由程序自动检查 npm 包、engines 声明与入口文件得出，未做人工实机验证——能装不等于用着没问题。

✓npm 包dsh-crw @ 0.1.0

✓Node 引擎要求 ^22.19.0 || >=24.0.0 · 基线 Node 22.19 满足

✓dsh CLI 依赖未声明 dsh 版本约束

✓入口文件main/exports/bin 已声明

验证方式：npm registry 存在性 + package.json 静态校验 · 最后验证 2026/9/19 03:10:12

依赖的 DSH / Cordis 模块

@deepseek-ai/schemastery@deepseek-ai/cordis@deepseek-ai/dsh-web

用户评分

还没有人投票，来当第一个

订阅周报，不错过优质插件更新

每周一封 · 高评分插件 + 新用户活动

装之前先看这里

ℹ️ 暂无已知风险记录。注意：dsh 与插件都处于 developer-preview 阶段，装任何插件前建议先备份 ~/.dsh 配置，出问题好回滚。

装完遇到问题了？反馈一下（可选填报错关键词）：

安全扫描自动 · 静态分析源码

v2.7.0

🟡 扫描：中风险尚无人工评估

静态扫描发现可执行固定命令，或会写入/删除本地文件，或读取剪贴板与密钥类环境变量。

读取剪贴板或密钥环境变量发起外部网络请求

查看扫描证据（共 3 处，展示前 3 条）

读取密钥环境变量
lib/index.js:32
apiKey: config.apiKey ?? process.env.CRW_API_KEY ?? '',
发起网络请求
lib/providers.js:117
async fetch(request, signal) {
发起网络请求
lib/providers.js:147
response = await fetch(`${options.baseURL}${path}`, {

扫描于 2026/9/26（0 天前） · 范围入口闭包 + 全包扫描 · 来源 npm 发布包

静态扫描只反映源码中出现的调用，不构成安全背书；人工评估与自动扫描相互独立、互不覆盖。

DeepSeek Harness Hub

fastcrw/dsh-crw

为DeepSeek Harness（ctx.web）提供由fastCRW支持的web_search和web_fetch提供程序

https://dpharness.com/plugin/fastcrw/dsh-crw

粘贴到微信 / 小红书 / 微博等，链接会自动带上本站预览图。

广告WorkBuddy 天津胜凌

WorkBuddy 官方合作伙伴 · 天津胜凌

有意合作请致电 185 2226 8817 —— 代理合作或直接购买。

致电联络→

广告WorkBuddy 海外版

WorkBuddy 海外版 · 注册立得 350 积分

通过邀请链接注册即得 350 积分（100 邀请积分 + 250 新人积分），可用于平台内 AI 能力调用。

领取 350 积分→

README

由 DeepSeek 最新模型翻译生成

dsh-crw

基于 fastCRW 的 web_search 和 web_fetch，用于
DeepSeek Harness。

该 harness 将 Web 访问视为一个能力接缝（ctx.web），并支持可插拔的
提供方。本包在 id crw 下注册了其中两个提供方，因此模型保持完全相同的
web_search / web_fetch 工具，只有后端发生变化。

为什么

基础组合默认开启 web_search，而关闭 web_fetch。它自己的
配置说明了原因：

Fetch 保持禁用，且未挂载任何 fetch 提供方：该提供方推迟了
SSRF 防护，而模型会选择请求目标。

这是一个合理的决定。内置的 HTTP fetch 提供方在 harness
进程中运行 fetch()，其 README 直接指出了这一缺口：不阻止私有、回环、
链路本地或组播目的地，不进行 DNS 解析后再验证。一个选择 http://169.254.169.254/ 的模型
会拿到你的云元数据端点。

fastCRW 在服务端解析并验证目标，并拒绝私有地址范围，
因此 harness 进程永远不会打开模型选择的连接。这正是让
开启 fetch 变得合理的原因，也是为什么 fetch: true 位于此 bundle 中
而不是上游。

第二个原因是，纯 HTTP 已不再是开放网络的读取方式：

| URL | 内置 HTTP 提供方 | dsh-crw |
| --- | --- | --- |
| producthunt.com | 403，一个 Cloudflare 中间页 | 200，27,559 字符的 markdown |
| zillow.com | 403，“Access to this page has been denied” | 200，真实页面内容 |
| news.ycombinator.com | 200，供工具转换的原始 HTML | 200，来自源站的 markdown |

fastCRW 会按页面从纯 HTTP 逐级升级到其浏览器层级，仅在
页面需要时才升级，因此常见情况保持快速，困难情况仍能得到答案。
并非每一堵墙都会倒下：交互式 Cloudflare 挑战有时仍会获胜。

安装

export CRW_API_KEY=...          # fastcrw.com, 500 free credits, no card
dsh plugin --profile default add dsh-crw
dsh --profile default

在 fastcrw.com 获取密钥。免费层级是一次性 500
额度，无需信用卡；一个页面为一个额度。

若要直接从本仓库安装，请固定一个提交并允许构建。
git 安装会获取源代码，因此 pnpm 必须运行本包的 prepare
脚本来生成 lib/，而 pnpm 10+ 要求你明确说明这一点：

$DSH_HOME/profiles//pnpm-workspace.yaml
allowBuilds:
dsh-crw: true

dsh plugin --profile default add github:fastcrw/dsh-crw#

该许可会在安装时于你的机器上运行本包的构建，因此
请固定提交，而不是跟踪分支。

在启动前验证该层：

dsh --profile default --dump-config    # shows a "# == dsh-crw" layer

该 bundle 的作用

随附的 cordis.patch.yml 在 @deepseek-ai/dsh-base 之上应用了三项更改：

- 将 web.searchProvider 和 web.fetchProvider 指向 crw
- 开启 tool-web 的 fetch 并提高两个超时时间，因为位于 JS 或反机器人墙之后的页面在应答之前会逐级升级浏览器层级
- 挂载此插件，读取 $CRW_API_KEY

基础层自带的 DeepSeek 搜索提供程序保持挂载，因此将搜索切换回去只需在你配置文件的 cordis.patch.yml 中改一行：

- id: web
config:
searchProvider: deepseek-official
fetchProvider: crw

配置

| 键 | 默认值 | 含义 |
| --- | --- | --- |
| apiKey | $CRW_API_KEY | fastCRW API 密钥。针对云端端点时必填；自托管时留空即可。 |
| baseURL | https://fastcrw.com/api | 端点基础地址；会追加 /v1/search 和 /v1/scrape。 |
| search | true | 注册搜索提供程序。 |
| fetch | true | 注册抓取提供程序。 |
| answer | false | 让 fastCRW 在结果之上合成一个答案，作为 seam 的 content 返回。每次搜索会增加一次 LLM 调用。 |
| maxBodyChars | 100000 | 返回页面字符数的上限，与内置提供程序一致。 |

- id: crw
name: dsh-crw
config:
apiKey: !!js process.env.CRW_API_KEY
answer: false

自托管

fastCRW 采用 AGPL-3.0 许可，且引擎是单个二进制文件，因此整个 Web 层都可以留在你自己的机器上：

crw serve

- id: crw
name: dsh-crw
config:
baseURL: http://127.0.0.1:3002

自托管端点不需要凭据，因此 apiKey 可以为空。只有当提供程序指向云端端点时，它才会强制要求密钥。

映射说明

- 搜索。 POST /v1/search。每个结果映射为一个 WebSearchSource：url、title 和 snippet 取自结果的 snippet，若没有则取自其 description。没有 URL 的结果会被丢弃，而不是赋予一个虚构的 URL。开启 answer 时，合成的答案会成为 seam 的 content。最终的 maxResults 截断由 seam 负责。
- 抓取。 POST /v1/scrape，使用 formats: ['markdown']。正文类型是 text，而不是 html：fastCRW 已经返回 markdown，而 html 会将其再次送入该工具的 turndown 处理流程，去转换已经转换过的输出。
- 非 2xx 目标。 fastCRW 将 404 目标报告为 success: false，同时仍返回它获取到的内容。seam 的约定正好相反，因此携带状态码的信封始终是一个结果。WebError 仅保留给完全无法检索资源的情况：URL 被拒绝、密钥错误、余额耗尽。
- 不发送渲染器提示。 fastCRW 的升级阶梯会逐页决定纯 HTTP 是否足够。

开发

bun install
bun test
bun run build

许可证

MIT。