前言¶
团队里常见这样的情况：Agent 要在本地跑构建、跑测试，代码和数据却放在远端机器上。传统做法是手动 sshfs 挂载一次，把路径写进文档，从此每台新机器、每个新 profile 都要重来一遍；命令行工具（如 nrs-tools/lib/autosshfs.js）能批量挂载，但没有界面，状态不直观，也没法让 Agent 安全地操作。
下面介绍 shudingbo/dsh-plugin-autosshfs。它是 DeepSeek Harness 的客户端插件，维护者 shudingbo，把 autosshfs 的 sshfs 挂载 / 卸载能力做成 Harness 主界面里的独立管理页，同时以 autosshfs 工具把同一套逻辑暴露给 Agent。社区目录把它归在「客户端」分类，当前星标为 0。插件纯 JavaScript，MIT 许可，package.json 版本 1.0.3。
这是什么¶
一句话定位：在 Linux / macOS 上用 sshfs 挂载、卸载远端目录，界面上点按钮操作，Agent 侧也能调用。
几个关键点：
- 入口是左侧栏的全局面板按钮，和「插件」「自动化任务」同一排。点击后在主界面打开独立页面，不是设置弹窗。
- 配置文件沿用命令行版的
~/.autosshfs.json，位置和格式都不变。已经用命令行版攒下的配置可以直接复用。 - 所有操作（列表、状态、增删改、挂载 / 卸载、依赖检测）界面和 Agent 工具共用同一套逻辑，不存在「界面能做、工具做不到」的落差。
核心功能¶
界面与 Agent 工具 autosshfs 的能力一一对应：
| 功能 | 界面 | Agent 工具 |
|---|---|---|
| 查看所有配置项与实时挂载状态 | 支持 | action: "state" |
| 新增 / 编辑 / 删除配置项 | 支持 | add / update / remove |
| 启用 / 停用单项 | 支持 | enable |
| 挂载 / 卸载单项 | 支持 | mount / umount + name |
| 全部挂载 / 全部卸载 | 支持 | mount / umount（不带 name） |
| 查看单项详情（挂载来源、挂载选项等） | 支持 | detail |
| 系统依赖检测与自动安装 | 支持 | check（install 仅限界面） |
界面侧补充几点：顶栏有标题、sshfs 版本徽标、已挂载/总数 徽标和配置文件路径；顶部有依赖提示条；列表页支持按名称 / 主机 / 挂载点搜索和全部 / 已启用 / 已挂载筛选；点击「详情」就地展开挂载来源、文件系统、挂载选项和认证方式。界面中英双语，随 Harness 语言切换。
install 这个动作刻意只放在界面上，避免 Agent 擅自改动机器权限。
相对命令行版的两处加固¶
README 明确写了两点改动，值得单独说：
- 不再拼接 shell 字符串。所有命令以 argv 数组直接执行，主机名、路径、密码里的任何字符都不会被 shell 解释。使用
password字段的场景下这点尤其重要。 - 挂载状态按挂载表精确匹配挂载点。Linux 读
/proc/self/mounts，macOS 解析mount，替掉了原来在mount输出里做includes(path)的子串比较。/mnt/a不会再被误判成/mnt/ab已挂载。
另外，配置写入采用「临时文件 + rename」的原子写，文件权限固定 0600，因为配置里可能存着密码。
安装与启用¶
插件是基于 dsh.bundle.patch + dsh.client 的 Harness bundle，没有构建步骤，index.js / client.js / host/ 就是可直接运行的源码。
方式一：从 GitHub 安装¶
在 Harness 会话里执行：
plugin_manager(action: "install_bundle", target: "github:shudingbo/dsh-plugin-autosshfs")
也可以把同一串 github:shudingbo/dsh-plugin-autosshfs 粘贴到 Harness Web 界面「插件 → 添加插件」的安装框里。安装结果里出现 application: applied 表示已生效。
底层是 pnpm 的 git 依赖，所以本质上等同于：
cd ~/.dsh/profiles/<profile>
pnpm add github:shudingbo/dsh-plugin-autosshfs
方式二：从本地目录安装¶
用于开发调试：
git clone git@github.com:shudingbo/dsh-plugin-autosshfs.git
plugin_manager(action: "install_bundle", target: "/绝对路径/dsh-plugin-autosshfs")
方式零：从 npm 安装¶
README 标注的方式零是发布到 npm 后可用的方式，只有它能享受插件页的「检查更新 / 一键升级」：
plugin_manager(action: "install_bundle", target: "@shudingbo/dsh-plugin-autosshfs")
安装之后¶
左侧栏点击 Autosshfs 挂载 面板按钮，主界面切换到独立管理页。不想让它常驻一行时，点该行右侧的固定按钮，它会收进「更多」菜单，再点固定即可放回。Agent 此时可以直接调用 autosshfs 工具。卸载用：
plugin_manager(action: "remove_bundle", target: "@shudingbo/dsh-plugin-autosshfs")
典型用法¶
安装完成后，Agent 侧的调用示例如下：
// 列出现状
{ "action": "state" }
// 挂载全部启用的配置
{ "action": "mount" }
// 只挂载某一项
{ "action": "mount", "name": "project" }
// 新增配置
{ "action": "add", "entry": { "name": "p", "host": "h", "user": "me", "remotePath": "/srv", "mount": "/mnt/p" } }
// 修改（只传要改的字段，password 省略 = 保持，传 "" = 清除）
{ "action": "update", "name": "p", "entry": { "allowOther": false } }
// 同名项可改用位置定位
{ "action": "detail", "index": 4 }
// 查看依赖问题
{ "action": "check" }
返回值是 JSON：{ ok, action, data | error, summary }，error.code 和结果项的 code 是稳定标识，hint / command 给出下一步可执行动作。
界面上的操作顺序一般是：先在「新增挂载」里填好连接信息和挂载选项，再用开关或按钮手动挂载；之后任何一次「全部挂载」都会跳过 enable 为 false 的项。
配置与挂载选项¶
默认配置路径 ~/.autosshfs.json，可用环境变量 AUTOSSHFS_CONFIG 覆盖，两者都支持 ~ 展开。结构示例：
{
"list": [
{
"enable": true,
"name": "project",
"host": "example.com",
"port": 22,
"user": "me",
"password": "",
"IdentityFile": "~/.ssh/id_ed25519",
"remotePath": "/srv/project",
"mount": "/mnt/project",
"allowOther": true,
"uid": "1000",
"gid": "1000",
"extraOptions": ["reconnect", "ServerAliveInterval=15"]
}
]
}
常用字段：
name：界面与工具按它定位配置项，新建时校验唯一性。历史配置若存在同名项，界面按「位置 + 名称」定位。host/port/user：SSH 目标，user为空时使用当前本地用户。password：可选，存在时用-o password_stdin通过 stdin 传入。明文保存在配置文件中，不建议长期使用，优先IdentityFile或 ssh-agent。IdentityFile：私钥路径，支持~/。remotePath：远端目录。mount：本地挂载点，绝对路径，不存在会自动创建。enable：是否参与「全部挂载」，缺省视为false。allowOther：是否附加allow_other，默认true。uid/gid：透传uid=/gid=。extraOptions：额外-o选项，数组或以逗号 / 空格分隔的字符串。
未识别的字段在保存时会原样保留，方便手工扩展。
系统依赖¶
插件会在「使用帮助 → 系统依赖」里显示依赖状态。Linux 上若检测到包管理器且 sudo -n 可用，页面上的「自动安装」按钮可直接安装，否则展示需要手动执行的命令。
Linux 各发行版安装命令：
# Debian / Ubuntu
sudo apt-get install -y sshfs
# Fedora / RHEL
sudo dnf install -y fuse-sshfs
# Arch
sudo pacman -S --noconfirm sshfs
# openSUSE
sudo zypper --non-interactive install sshfs
# Alpine
sudo apk add sshfs
非 root 用户使用 allow_other 前，需要在 /etc/fuse.conf 中启用 user_allow_other：
sudo sed -i 's/^#\s*user_allow_other/user_allow_other/' /etc/fuse.conf
容器内还要把 /dev/fuse 传入容器，并确保 FUSE 内核模块可用（sudo modprobe fuse）。
macOS 上 Homebrew 已不再提供官方 sshfs 公式，需要自行选一套 FUSE 实现：
# 方案 A：FUSE-T（无需内核扩展）
brew tap macos-fuse-t/homebrew-cask
brew install --cask fuse-t
brew install fuse-t-sshfs
# 方案 B：macFUSE（内核扩展，需重启并在「系统设置 → 隐私与安全性」中允许）
brew install --cask macfuse
brew install gromgit/fuse/sshfs-mac
macOS 的 allow_other 需先在 FUSE 提供方设置里允许其他用户，否则插件会自动退回不带 allow_other 的挂载方式并给出警告，此时只有当前用户能访问挂载点。
适用场景与注意¶
适合的场景：Linux / macOS 上的 DSH 使用者，已经有命令行版 autosshfs 配置想平移到界面和 Agent；需要在 Agent 工作流里按需挂载远端目录，而不是每次手动执行 shell。
几条限制需要提前知道：
- 插件以当前 DSH 进程的权限运行，挂载、卸载、依赖安装都直接作用在本机。安装前先读一遍源码，确认
host/sshfs.js、host/config.js里的实现符合预期；许可证是 MIT，作者 shudingbo。 - 只支持 Linux 与 macOS，Windows 不支持。
- 从 GitHub 安装的插件没有「检查更新」入口，DSH 本身也没有后台自动更新。更新方式是先卸载再安装，让 git 依赖重新解析默认分支的最新提交：
plugin_manager(action: "remove_bundle", target: "@shudingbo/dsh-plugin-autosshfs")
plugin_manager(action: "install_bundle", target: "github:shudingbo/dsh-plugin-autosshfs")
想控制升级节奏，可以固定到 tag 或提交，例如 github:shudingbo/dsh-plugin-autosshfs#v1.0.1。已安装的包不能直接用 install_bundle 覆盖，带 HMR 的 profile 会抛 already-installed，所以升级一律先卸载再安装。本地 link: 安装是例外，改动即生效。
小结¶
这个插件做的事不复杂：把 sshfs 挂载管理从命令行搬进 Harness 主界面，同时以 autosshfs 工具暴露同一套操作。配置格式沿用 ~/.autosshfs.json，命令行版的存量配置直接可用；argv 执行和挂载点精确匹配两处加固降低了使用 password 和相似路径时的风险。适合想在 Agent 工作流中按需挂载远端目录、又不希望每次都手工敲 sshfs 的人。
目录页：https://www.skillhub.cn/plugins/shudingbo/dsh-plugin-autosshfs
GitHub：https://github.com/shudingbo/dsh-plugin-autosshfs
