DeepSeek harness 的 pdf 解析插件是什么原理。v4.1f 只支持原生图片

回复 群友 8714： 先纠正一个前提：dsh 官方并没有一个叫"PDF 解析插件"的东西。官方在 v0.1.5 做的只是两件事——Web 支持上传任意类型文件，右侧 Sidebar 支持 PDF/Markdown/HTML/图片的预览。那个预览是给人看的（前端渲染），跟模型能不能读没关系。模型读文件走的是通用文件工具，而 DeepSeek-V41-Flash 这个 adapter 声明支持的模态只有 text 和 image，PDF 不在里面。所以"PDF 解析插件"基本全是社区补的，而且思路高度一致。 核心原理一句话：模型永远不接触那个 PDF，插件在本地把 PDF 转成文字，再把文字当工具结果喂进去。 拿我看到的 dsh-pdf 这个插件举例，它的 read_pdf 管线是这样： 一是进文件。用 ctx.fs.readBytes 直接读字节，绕开宿主默认的 64KB 单文件上限，它自己设的上限是 200MB。 二是抽文本层。用 pdfjs-dist 逐页解析，取每一页的文本层，Unicode 完整保留，中文英文和其它文字系统都能拿到。这一步是纯解析，速度快，不涉及识别。调用时可以指定 pages，比如 "1-3"、"2"、"1,3-5" 或 "all"。 三是判断这页是不是"假 PDF"。扫描件、图片型页面、手写笔记，文本层基本是空的。它就设了个阈值 ocrMinChars（默认 120 字），auto 模式下某页文本层少于这个数，就判定为需要 OCR，走回退分支。 四是 OCR。把这一页用 @napi-rs/canvas 按 scale 2（约 144 DPI）渲染成 PNG，然后识别。默认引擎是 Windows 自带的 WinRT OCR，通过 powershell.exe 调系统里的 zh-Hans-CN + en-US 语言包识别器，零安装；备选是 tesseract.js（WASM），但要你自己放 chi_sim.traineddata 这类训练数据进去才能用。 五是回收。每页结果带一个 source 字段标来源：text（只用文本层）、ocr（纯识别）、mixed（两者都有，对应上面那个例子），单页字符数超过 maxCharsPerPage（默认 ）就截断，结果进缓存。模型最终拿到的是一段结构化 JSON，里面全是文字。 所以关键点在这：它不是把 PDF 页面渲染成图片塞给模型，而是先抽文本、只对图片页做 OCR 兜底。之所以这么设计，正是因为你提到的那个约束——v4.1f 只吃原生图片。要让模型"看" PDF 只有两条路：把每页渲成图喂进去，页数一多上下文直接爆、token 也贵；或者本地先转成文本再喂，省 token、还能让模型按页检索。插件选的是后者，OCR 只是兜底分支，不是主路径。 同类还有几个，玩法一样：dsh-pdf-reader（同样注册 read_pdf，强调纯本地、不上传不联网）、dsh-read-pdf（做成 MCP server + CLI 的版本，兼容 dsh 和 Claude 等客户端）。挑的时候注意三点：都是社区插件不是官方；OCR 质量取决于引擎和语言包，中文手写别期望太高；以及 Windows OCR 是零安装但绑系统识别器，跨平台就得靠 tesseract.js 那套。