kimi-webbridge-dsh 怎么安装？

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

kimi-webbridge-dsh 兼容性怎么样？

自动检查通过：npm 包已发布且 engines 声明满足基线（声明 Node >=20）；该结论来自程序自动检查，未经人工实机验证。

kimi-webbridge-dsh 有中文文档吗？

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

kimi-webbridge-dsh 还在维护吗？

GitHub 1 星。最近一次上游提交在 2026/10/12。

Kimi 浏览器桥接 cfanmaoli/kimi-webbridge-dsh

DeepSeek Harnessv1.4.11

cfanmaoli20 天前有提交已提供中文文档扫描：含敏感能力

在 GitHub 查看 ↗

把 Kimi 浏览器扩展Kimi Browser Extension，原 Kimi WebBridge接进…

30.7/100

综合分

GitHub 星标

1,059

npm 周下载

—/5

用户评分

数据截至 2026/10/14 · 周下载取自 npm 全网（含 CI / 镜像），非本站安装数；综合分由星标、活跃度与兼容性检查合成。

安装命令 · 需先装 dsh CLI 引擎

dsh plugin --profile web add kimi-webbridge-dsh

npm 源 · kimi-webbridge-dsh 的发布者账号已校验与本仓库一致

状态速览

判定依据：实装验证 · 静态安装检查 · 自动扫描 · 仓库维护状态

信任档位：已验证

是什么

dsh 原生插件 · search

装得上吗

本站已在 dsh 0.2.1-rc.2 下真实安装成功（非静态推断）；本次验证针对插件 v1.5.0，当前版本为 v1.4.11

L4 · 真实安装等级说明 →

安全吗

本站尚未对该插件做风险分级

暂未覆盖，不等同于无风险

还在维护吗

活跃：最近一次提交在 20 天前

档位由哪些信号合成

本站实装验证（真实安装 L4 覆盖全站；L5 为运行时冒烟或实机截图，覆盖范围小于 L4） · 验证所用 dsh 版本 · 静态安装检查 · 风险分级 · 仓库维护状态。下方各区块是它的证据明细。

验证判据与等级说明 →

社区实装还没有人打卡 · 装过的第一个就是你

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

展开查看检查明细 ↓

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

✓npm 包kimi-webbridge-dsh @ 1.4.11

✓Node 引擎要求 >=20 · 基线 Node 22.19 满足

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

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

验证方式：npm registry 存在性 + package.json 静态校验 · 最后检查 2026/10/14 13:13:53

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

v2.7.0

🔵 扫描：含敏感能力尚无人工评估

展开查看扫描说明与证据 ↓

静态扫描发现插件具备触达本地系统的能力：执行外部命令、读写/删除本地文件、读取剪贴板或密钥类环境变量（至少其一）。这是能力清单，不是危险判定——具体能力项与证据见下方，安装前请自行判断是否需要。

可执行外部命令读写/删除本地文件发起外部网络请求

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

读取本地文件
lib/index.js:233
const { description, version, body } = parseFrontmatter(readFileSync(SKILL_PATH, "utf8"));
发起网络请求
lib/index.js:308
const response = await fetch(url, {
写入本地文件
lib/index.js:356
const file = createWriteStream(dest);
发起网络请求
lib/index.js:358
const response = await fetch(url, { signal: controller.signal });
写入本地文件
lib/index.js:397
await mkdir(dirname(bin), { recursive: true });
读取本地文件
lib/index.js:414
const actual = createHash("sha256").update(await readFile(tmp)).digest("hex");
写入本地文件
lib/index.js:419
await rename(tmp, bin);
删除本地文件
lib/index.js:422
await rm(tmp, { force: true }).catch(() => {});
写入本地文件
lib/index.js:425
if (process.platform !== "win32") await chmod(bin, 0o755);
执行外部命令来自配置/变量
lib/index.js:432
const child = spawn(daemonBinPath(), ["start"], {
读取本地文件
lib/index.js:514
if (!existsSync(bin)) {
执行外部命令来自配置/变量
lib/index.js:520
child = spawn(bin, ["upgrade"], { stdio: ["ignore", "pipe", "pipe"], windowsHide: true });
读取本地文件
lib/index.js:710
if (!existsSync(daemonBinPath())) {

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

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

依赖的 DSH / Cordis 模块

@deepseek-ai/dsh-tools@deepseek-ai/dsh-llm@deepseek-ai/schemastery

给这个插件打分还没有人投票↓

用户评分

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

广告精选好物

飞利浦 TAH6519 主动降噪耳机 ¥299

头戴式无线 anc 主动降噪，蓝牙连接，久戴舒适向。

·anc 主动降噪 · 头戴式无线
·价格与库存以商品页实时为准

去淘宝看看→

广告MCP 兼容手册

装完插件，给 AI 接上 MCP

Cursor、Claude Code、VS Code 逐个核对：能不能装、配置怎么写、装不上是什么原因。

·按客户端逐格核对
·结论标注依据与风险等级

查 MCP 兼容性→

功能亮点

接入Kimi扩展
模型操控本地浏览器

最近更新

在 GitHub 查看全部 →

v1.5.02026-10-26

· 守护进程不再需要手动升级

浏览器扩展跟着商店自动更新，守护进程却没有自更新机制：上游只提供 upgrade，而它会停掉、换二进制、再拉起守护进程——所以插件此前只把这条命令交给用户，机器就可能一直停在旧版本（本机就停在 v2.0.22，扩展已经 2.0.24）。

现在 kimi_webbridge 的 status 会在守护进程落后时直接把它补齐：

| 触发条件 | 行为 |
|---|---|
| 有更新版本的发布（update_available） | 调用 kimi-webbridge upgrade |
| 已连接的扩展版本高于守护进程 | 同上（上游的配对规则会装与扩展匹配的版本，不是最新版） |
| 守护进程高于扩展（商店还没放新版） | 不动——那会让 upgrade 按规则把守护进程降级，属于用户决定 |

约束与安全边界：

· 每进程最多一次，且在开始浏览器任务的那次 status 上执行，重启代价最小
· 失败不会循环重试：auto_update 里带上 { reason, from, to, ok, error }，载荷里仍保留手动命令，渲染会提示模型把命令交给用户
· 想全程手动：autoUpdateDaemon: false，行为与之前一致

upgrade 本身仍是上游那份实现：校验 SHA-256、换二进制、重启，并顺带刷新其他 agent 运行时里的技能副本。

· 验证

新增 16 项自动更新断言（假 HOME + 桩守护进程 + 记录调用的假二进制），覆盖：成功升级、每进程只升一次、autoUpdateDaemon: false、扩展领先触发、守护进程领先不触发、当前一致不触发、升级失败如实上报并保留手动命令。真实 dsh 0.2.1-rc.3 服务下的 29 项集成断言仍全通过。

Full changelog:

v1.4.132026-10-26

· 内置官方上游技能包升级到 v2.0.27

上游 2.0.27 仍然没有改任何说明文字：SKILL.md 与 2.0.26 逐字节相同（仅 metadata.version 变成 2.0.27），references/ 七个文件全部未变。重新内置让 skill/UPSTREAM.json（tar f5c09b77939f…）与技能里的来源戳跟到当前发布。

· 漂移告警改成「只在说明文字变化时才报」

每周的 upstream drift 任务已经连续两次因为纯版本号跳动而变红（2.0.24–2.0.26 一次、这次一次），而这两次对插件来说都是空操作。--check 现在区分两类移动：

| 情况 | 行为 |
|---|---|
| 文件集合变化，或内容差异超出 frontmatter 的 release 戳 | 仍然非零退出，并在日志里列出具体文件 |
| 只有版本戳（上游为守护进程/扩展构建发布的版本） | 打印「release stamp only」并正常退出，附上重新内置的命令 |

本地完整性检查不变：--verify-local（包含在 npm run check 与 CI 里）仍然逐字节比对 manifest，手工改动照样失败。

验证：造了两个方向的用例——把 --check 指向内容确实不同的旧发布（v2.0.22）仍然 exit 1 并指出 changed SKILL.md；当前 2.0.26 → 2.0.27 的戳变化则 exit 0。

· 宿主兼容

本机 dsh 已到 0.2.1-rc.3，peer 范围无需改动：0.1.0-rc.7 → 0.2.9-rc.3 全部可加载，bundle skippedBundles 为空；真实服务集成测试 29/29 通过。

Full changelog**:

v1.4.122026-10-19

· 内置官方上游技能包升级到 v2.0.26

上游 2.0.24 → 2.0.26 没有改任何说明文字：SKILL.md 与 2.0.23 逐字节相同（仅 metadata.version 从 2.0.23 变成 2.0.26），references/ 七个文件全部未变。这几个版本发布的是守护进程 / 浏览器扩展的构建。

本次重新内置是为了让两处记录跟上上游：

· skill/UPSTREAM.json 的 release 与 tar digest（e0b14f98683a…）
· 注册技能时追加的「vendored verbatim from the official upstream release v2.0.26」来源戳

同时把 README、skill/README.md、取用脚本里的 v2.0.23 示例更新为 v2.0.26。

· 顺带的宿主兼容核对

本机 dsh 已从 0.2.0-rc.2 走到 0.2.1-rc.2，peer 范围无需改动：

· evaluatePluginCompatibility / loadProfileDirectory（dsh-app-boot 0.2.1-rc.2）：0.1.0-rc.7 → 0.2.9-rc.3 全部可加载，bundle skippedBundles 为空
· 真实服务集成测试：29/29 通过（技能注册、工具 schema、系统提示段落、描述 498 ≤ 500、render 各分支）

Full changelog**:

数据来自仓库的 GitHub Release，可能与插件实际版本不一致。

README

由 DeepSeek 最新模型翻译生成

kimi-webbridge-dsh 把 Kimi 浏览器扩展（Kimi Browser Extension，原 Kimi WebBridge）接进 dsh：供应守护进程 + 注册官方技能包。插件本身不代理浏览器操作——浏览器能力全部由官方技能文档描述，模型照它驱动本地守护进程。 | 职责 | 说明 | | 守护进程供应 | 按官方清单下载对应平台二进制（SHA-256 校验），未运行时自动拉起；落在 ~/.kimi-webbridge/bin/ | | 技能注册 | 随包内置官方技能文档（含 references/），启动时注册为 kimi-webbridge skill | | 健康锚点 | 瘦工具 kimi_webbridge，只有 status 一个动作（守护进程 + 扩展 + 已装技能副本） | 安装 dsh plugin --profile web add kimi-webbridge-dsh 自带 bundle patch，无需手改 cordis.patch.yml；重启一次 dsh 生效。用法 1. 需要真实浏览器时加载 kimi-webbridge skill（触发词：browser / 网页 / 截图 / ……

展开完整文档（README 剩余 1 节）

kimi-webbridge-dsh

把 Kimi 浏览器扩展（Kimi Browser Extension，原 Kimi WebBridge）接进 dsh：供应守护进程 + 注册官方技能包。插件本身不代理浏览器操作——浏览器能力全部由官方技能文档描述，模型照它驱动本地守护进程。

| 职责 | 说明 |
| 守护进程供应 | 按官方清单下载对应平台二进制（SHA-256 校验），未运行时自动拉起；落在 ~/.kimi-webbridge/bin/ |
| 技能注册 | 随包内置官方技能文档（含 references/），启动时注册为 kimi-webbridge skill |
| 健康锚点 | 瘦工具 kimi_webbridge，只有 status 一个动作（守护进程 + 扩展 + 已装技能副本） |

安装

dsh plugin --profile web add kimi-webbridge-dsh

自带 bundle patch，无需手改 cordis.patch.yml；重启一次 dsh 生效。

用法

1. 需要真实浏览器时加载 kimi-webbridge skill（触发词：browser / 网页 / 截图 / ……，也包括「给某个网站做个可复用 CLI」）；
2. 先调 kimi_webbridge 的 status 确认守护进程 + 扩展健康（会自动补装 / 拉起）；
3. 按 skill 文档 POST http://127.0.0.1:10086/command，请求体 {action, args, session}；
4. Windows 必须用临时文件承载 JSON 请求体（shell 会破坏非 ASCII），skill 里有说明。

工具清单、参数与注意事项一律以 skill 文档为准。

配置

在 ~/.dsh/profiles/web/cordis.patch.yml 按 id 覆盖（整份替换，未给出的键取默认）：

- id: kimi-webbridge
config:
daemonVersion: v2.0.23

| 键 | 默认 | 说明 |
| baseUrl | http://127.0.0.1:10086 | 守护进程地址 |
| requestTimeoutMs | 120000 | 单次请求超时（ms） |
| autoStartDaemon | true | 未运行时自动启动 |
| autoInstallDaemon | true | 二进制缺失时自动下载安装 |
| daemonVersion | latest | 自动安装的版本，带 v 前缀，建议与扩展版本一致 |
| registerSkill | true | 注册 kimi-webbridge skill |

要求与提示

- 浏览器扩展：需自行安装并连接（Chrome Web Store）；status 显示 extension_connected: true 即可用。
- 守护进程：无需预装，插件自动供应；与官方安装器共用 ~/.kimi-webbridge/bin/（Windows %USERPROFILE%\.kimi-webbridge\bin\）。
- dsh 版本：只 import 宿主提供的 @deepseek-ai/*（声明为 peer，不打包副本），已在 0.2.0-rc.1 验证，peer 范围覆盖 0.1.0-rc.7 起的整个 0.1.x / 0.2.x。dsh 换代后如果 kimi_webbridge 工具、系统提示段落和 skill 一起消失，通常就是插件版本还没覆盖新 dsh——升级本插件再重启即可。
- status 里的 version_mismatch / update_available / skill_mismatch：把其中的 command 原样交给用户执行；不要自行 upgrade / stop / restart / uninstall，它们会杀掉正在运行的守护进程。
- status.skills 为空是正常的：守护进程只识别 Claude Code / Codex / Hermes / OpenClaw / Kimi，dsh 拿到技能的唯一途径就是本插件。

移除

dsh plugin --profile web remove kimi-webbridge-dsh

重启后生效；skill 随插件注册，移除即消失。