前言¶

DSH 的模型可以直接读纯文本文件，但日常碰到的文档大多是 .docx、.xlsx、.pptx、.pdf 这类二进制容器。要让模型分析季度报告、投标资料或电子书，开发者通常要先在外部跑一套转换工具，把结果再喂回上下文；另一种做法是让模型直接读字符串，二进制容器里的文字、表格和公式根本进不来。

下面介绍的 dsh-anydoc 试图把这步收敛到一个插件里：它基于 Firecrawl AnyDoc 的本地 Rust 解析引擎，把本地办公文档、电子书、CSV 与文本型 PDF 转换为 GitHub-Flavored Markdown，并注册成 DSH 模型可直接调用的原生 Tool。插件由社区维护者 kevinasworks 开发，上游解析能力全部来自 Firecrawl AnyDoc 0.2.4，本项目只做 DSH 集成层，是独立社区项目，不是 Firecrawl、DeepSeek 或任何机构的官方插件。

定位：它解决什么问题¶

插件把 AnyDoc 的解析能力挂进 DSH 的工具注册表，调用链路是：

用户提问 → 模型调用 anydoc_convert → 插件本地解析 → Markdown 写入文件 + 预览返回 → 模型基于内容继续分析

关键是全过程不联网、不上传文档。AnyDoc 唯一的联网路径是显式传 ocr: 'hosted'，本插件从不传这个参数。扫描版 PDF 会返回 NEEDS_OCR 与页码，由用户自行决定后续动作，插件不会自动上传或启用 hosted OCR。

三个原生工具¶

插件注册三个 Tool，覆盖单文件、批量与自检三条路径。

支持的格式¶

以 AnyDoc 0.2.4 官方支持表为准，插件已逐项实测。

几个容易踩的点：

• 格式由文件内容判定，扩展名只是提示。把 report.docx 改名成 report.bin 仍能转换，插件会给出「扩展名不在支持表内」的警告。
• .csv 没有内容签名，靠扩展名识别，因此 formatSource 会是 extension 而不是 content。
• .pdf 只覆盖文本层，扫描版返回 NEEDS_OCR。

安装¶

插件以 DSH 官方 Bundle 方式安装，不修改 DSH 核心源码，也不手改 profile 文件。

推荐通过 npm 包名安装：在 DSH 的「插件」→「添加插件」中输入：

dsh-anydoc

如需固定版本，输入 dsh-anydoc@0.2.1。npm 包地址见 dsh-anydoc。首次发布后中国大陆镜像可能尚未同步，可先切 npm 官方源。

也可以输入 GitHub 完整地址安装：

https://github.com/kevinasworks/dsh-anydoc

此方式获取 GitHub 源码，但不显示 npm 安装所具有的版本更新区块。仓库与 npm 包均不包含 node_modules/，安装时需要能访问所选源以拉取插件、AnyDoc 依赖及当前平台的原生绑定；文档转换本身仍为本地离线执行。

从本地目录安装时，先装运行依赖：

cd /path/to/dsh-anydoc
npm install --omit=dev

随后让 Agent 调用 plugin_manager，target 换成插件目录的实际绝对路径：

{ "action": "install_bundle", "target": "/path/to/dsh-anydoc" }

Windows 用户请使用实际的 Windows 绝对路径，JSON 中反斜杠写为 \\。

安装后用一次自检确认：

anydoc_capabilities → {"selfTest": true}

应看到 native binding: ok、engine: worker、self test: passed。

典型用法¶

单文件转换，指定预览长度：

{ "sourcePath": "~/Documents/季度报告.docx", "previewChars": 12000 }

返回形如：

Converted /Users/me/Documents/季度报告.docx -> /Users/me/.dsh/anydoc-output/季度报告.md
format: docx (content) · 13,902 chars · 37,767 input bytes · 41 ms · engine: worker
--- markdown preview ---
# 季度技术评审报告 …

大文件只返回截断预览，预览末尾说明已显示 N/M 字符、完整内容见 outputPath，避免超长正文撑爆模型上下文。

批量转换，默认不递归，这里显式打开：

{ "directory": "~/Documents/投标资料", "recursive": true, "concurrency": 2, "exportAssets": true }

带图片导出：

{ "sourcePath": "report.docx", "exportAssets": true }

图片等内嵌资源写到 <输出目录>/<文件名>.assets/，并在 Markdown 末尾追加 ## Exported assets 索引。插件只导出原始字节，不做图像语义分析、不会伪造图片描述。

默认值与限制¶

完整配置项见仓库内 CONFIGURATION.md。

兼容性与平台¶

插件的 engines.dsh 声明并实测了三条 DSH 线：

>=0.2.0-rc.2 <0.2.1-0 || >=0.2.1-rc.2 <0.2.2-0 || >=0.2.2-rc.1 <0.2.3-0

0.2.0-rc.2、0.2.1-rc.2 ~ rc.5、0.2.2-rc.1 ~ 0.2.2 均已实测；范围外的 0.2.0-rc.1、0.2.1-alpha.*、0.2.3+、0.3.x 等会被 DSH 的准入检查拒绝。@firecrawl/anydoc 仍精确锁定 0.2.4，向下兼容针对的是 DSH 宿主，不放开解析引擎版本。

平台支持范围严格等于上游 AnyDoc 0.2.4 的 7 个预编译目标：macOS arm64 / x64、Windows x64、Linux glibc x64/arm64、Linux musl x64/arm64。Windows on ARM 原生进程不支持，上游没有 ARM64 绑定，自检会报告 platformSupport: unsupported。README 给出的 CI 验证边界是 macOS Apple 芯片 107/107、Intel Mac 107/107、Windows Server runner 104 通过 0 失败 3 项既有跳过、两种架构的 Ubuntu 与 Alpine 各 107/107；CI 运行验证不替代完整 DSH 桌面界面验收，Intel Mac 的 x64 Electron 宿主、Windows 10/11 的交互与文件占用、SMB 场景仍需单独验证。

隐私与数据流¶

本地文件 → 插件（进程内或子进程）→ @firecrawl/anydoc → Rust 解析 → Markdown → 本地文件

插件不自动上传文件、不调用 Firecrawl Parse、不发送遥测；日志只记录源路径、格式、字符数、耗时、输出路径，不写文档内容。npm install 拉取依赖属于公网流量，与文档内容传输无关。仓库的 TEST_REPORT.md 给出的证据是静态扫描加上在禁用 fetch 的进程内/子进程内完成转换。

适用场景与注意¶

适合需要在 DSH 里把本地办公文档、电子书、CSV 转成 Markdown 后再让模型分析的场景，尤其是对文档内容有本地处理要求、不希望内容离开本机的开发者。macOS（Apple 芯片）是作者日常使用并做过真实 DSH Tool Call 验证的主要平台，其余受支持目标主要靠 CI 覆盖。

几点需要留意的：插件以当前 DSH 进程权限运行，可以直接读用户有权访问的文件路径，安装前建议先检查源码与许可证（自身 MIT，AnyDoc 为 MIT，版权 Sideguide Technologies Inc.）。它是独立社区项目，不代表 Firecrawl 或 DeepSeek 官方立场。停用可用：

{ "action": "set_bundle", "target": "dsh-anydoc", "enabled": false }

卸载用 remove_bundle，会从 profile 的 package.json 移除依赖与 bundle 选择，不影响其他插件。插件不会删除用户输出文档，~/.dsh/anydoc-output 需自行清理。安装前的 profile 快照保存在 .backup/pre-install-<时间戳>/，异常时可对照恢复。

结尾¶

dsh-anydoc 做的事情比较集中：把 AnyDoc 的离线解析能力封装成 DSH 原生 Tool，让模型用一次调用就能拿到 Markdown 正文，同时用进程隔离、超时、大小上限和格式探测把集成的边界守住。如果你在做 DSH 文档处理方向的插件选型，可以从这里入手。

• 社区目录页：https://www.skillhub.cn/plugins/kevinasworks/dsh-anydoc
• GitHub：https://github.com/kevinasworks/dsh-anydoc