它是什么
dsh-univer-office 给 DSH 会话一个可用的办公环境：Agent 可以创建和编辑电子表格、文档、演示文稿、多维表格（Base）与画布，导入已有的 .xlsx / .docx / .pptx 文件，校验自己的产出，并把结果留在会话里供你审阅。它编辑的一切都保存在会话工作区内的 .univer 文件里。
最容易误读的一点是能力从哪来：它不是某个在线办公服务的客户端。包里自带运行时——一个内置的 Gateway HTTP/WebSocket 服务、一个内置 Viewer、一次性执行的 Unit Content Worker，以及用于布局检查、截图与 PDF 打印的 render machine 页面——Univer 的 JavaScript SDK 在构建时被内联进去。只有原生与体积大的包（libsql、@univerjs-pro 绑定、puppeteer-core、@puppeteer/browsers）才从 npm 安装。两份 README 与架构文档里都没有出现账号、登录、API key 或云端项目。
作者是 Univer 背后的公司：DreamNum Co., Ltd.，同时也是开源电子表格引擎 dream-num/univer 的维护方，包里的 author 字段写的就是这个。仓库主页是 https://office.univer.ai。
五类内容
Sheet（公式、图表、透视表、筛选、数据验证、图片）、Doc（富文本、表格、图片、图表、页眉页脚、分页）、Slide（页面、文本、形状、图片、图表、SVG 版式）、Base（数据表、字段、记录、视图，含公式字段、筛选、分组）与 Board（形状、连接线、图片、图表、连线路由）。Sheet 与 Doc 可双向读写 .xlsx 与 .docx，Slide 双向 .pptx，Base 可导出 .xlsx/.csv/.tsv，Board 既不支持导入也不支持文件导出。五类都支持结构化检查与截图；Sheet、Doc、Slide、Board 可打印 PDF，布局 lint 只覆盖 Slide。
这里的「worktree」是什么
README 里的「isolated worktrees for multi-agent collaboration」不是 git worktree——架构文档里没有一处提到 git。机制落在文件自己的存储层：.univer 是通过 libsql 打开的 SQLite 数据库，有 v0/v1/v2 三个格式版本、带备份的迁移路径，以及分别存放协作、worktree、历史与资源的表。一次写入从 draft worktree 开始，提交审阅时变成 ready，最终进入 merged 或 discarded；trunk 是主线，Gateway 被描述为已提交版本的唯一依据。
于是「按版本管理的改动」就是同一个数据库里按 Unit 记录的 changeset，由一张从核心 changeset 重建出的 history@1 表做索引：五类 Unit 都有按时间分组的历史，只读视图可以查看，可编辑的 trunk 视图可以显式恢复某个版本。草稿之间可以做语义对比，一侧固定为 trunk，也可以是同一文件里的另一个活动 worktree。merge 与 discard 不由模型决定——架构文档写明必须由用户明确要求，并经过 DSH 的 tools/pre-execute 审批。
文件与数据落在哪里
.univer 文件建在 Agent 被要求创建它的位置，也就是会话工作区内。每条工具路径都绑定该工作区，并在 Provider 边界再按 realpath 范围复核；来自浏览器的文件请求必须先绑定一个存活的 DSH 会话并通过同样的检查。导出、截图与 PDF 写到已授权的工作区路径，截图还会额外保存为持久的 DSH 图片附件，好让支持视觉的模型读回来。下载的 SVG 缓存在 $DSH_HOME/cache/dsh-univer-office/resources，遥测去重状态在 $DSH_HOME/telemetry/dsh-univer-office/ 下。
Gateway 监听 127.0.0.1，从 9080 端口起步，被占用就逐号上移。它只绑定回环地址，但 README 明确写着它「不校验 DSH 会话身份」：远程 DSH 用的 viewerBaseUrl 需要一层反向代理把 HTTP 与 WebSocket 流量转发到 Gateway，并把该 origin 限制在可信用户范围内。
安装，以及会执行的脚本
安装命令是 dsh plugin --profile web add dsh-univer-office，之后重启 DSH 并刷新浏览器页面。dsh plugin 会把参数转交给 pnpm，因此这一步解析到的是已发布的 tarball，里面已经带有构建好的 lib/ 与 artifacts/。
package.json 里声明了两个生命周期脚本，从源码安装时都要注意：
prepare：pnpm run build && simple-git-hooks。构建会编译五个目标（Host 库与浏览器客户端、Unit Content Worker、Gateway、render machine 页面、Viewer），simple-git-hooks则安装一个运行 commitlint 的commit-msg钩子。它在你从 git 或本地路径安装时执行，而不是从 registry 安装时；执行需要 pnpm 和完整工具链（package.json里列了 195 个 devDependencies）。README 称发布包刻意不声明postinstall，架构文档把这一点与 DSH profile 的依赖构建脚本审批策略联系起来。uninstall：node scripts/telemetry-entry.mjs uninstall，会拉起一个脱离的lib/telemetry-entry.js进程发送卸载遥测事件。
遥测默认开启：dsh_plugin_activated、dsh_plugin_daily_active、dsh_plugin_uninstall_hook 三个事件发往编译进包里的 Univer 端点；我在已发布的 0.2.14 的 lib/build-info.json 里核实到它是 https://univer.ai/api/telemetry/cli。payload 白名单是一个随机 UUID、事件名、包名与版本、构建 commit、platform、arch、Node 主版本号、事件来源与 state schema 版本；README 说「绝不含文件内容与路径」。用 DO_NOT_TRACK=1 或 telemetry: false 关闭。另一条出网路径是资源库：SVG 通过 HTTPS 从 @univerjs-pro/cli-assets 的 manifest.json 里的地址下载，这些地址指向 cdn.jsdelivr.net 与 cdn.undraw.co。没有记录到其他出网行为。
体积，以及内置的 Univer 许可证
这是一个重插件。npm 记录的已发布 0.2.14 tarball 解包后是 270 个文件、179,562,863 字节；它还会安装六个运行依赖：@univerjs-pro/cli-assets（33,811,356 字节）、puppeteer-core（约 5.8 MB）、@puppeteer/browsers（约 438 KB）、libsql（约 44 KB），以及两个通过 optionalDependencies 拉取对应平台包的原生绑定。部分 Slide 布局检查与 SVG 文本测量还需要本机有 Chrome/Chromium，用 UNIVER_RENDER_BROWSER 指定；README 没有说插件会自己下载浏览器，安装耗时也未说明。
包里还带了一份许可证：src/workers/unit-content/license.ts 自称是「Application-owned 90-day development license. Issued 2026-08-14 and must be replaced on the 90-day rotation」，其字符串 payload 记录的域名是 localhost、到期时间 2026-11-15。到期后会发生什么，来源没有说明。插件自身的许可证在 README、LICENSE、package.json 与 GitHub API 四处都是 Apache-2.0；另外我查到的 @univerjs-pro/* 包在 npm 元数据里没有 license 字段，而 @univerjs/core 是 Apache-2.0。
运行要求
Node >=22.19.0（来自 engines），以及按 main 分支 README 与 main 的 peerDependencies，需要 0.1.5-rc.1 及之后的 0.1.5 版本（^0.1.5-rc.1）。注意 main 并不是 npm 上发布的那个版本：上面记录的 dshTarget 引用的是已发布的 0.2.14 README，它只承诺 0.1.1-rc.2 与 0.1.2-rc.1。客户端平台是 web；没有描述 headless 或纯 CLI 用法，也没有权限模型或支持的操作系统列表。
安装前值得留意一处「发布物与源码不一致」。npm 上的 latest 是 0.2.14（2026-09-04 发布），它的 README 写「Supported DSH versions are 0.1.1-rc.2 and 0.1.2-rc.1」，peerDependencies 钉的也是这两个版本。main 分支（2026-09-15 推送）在两处都声明 ^0.1.5-rc.1，但 package.json 里的 version 仍然是 0.2.14。也就是说，今天从 npm 装到的并不是那份 README 描述 0.1.5-rc.1 支持的构建。
已知限制
- Board 不支持文件导出，Base 与 Board 也没有导入路径。Slide 的母版页、版式页与演讲者备注不在编辑范围内，Board 的思维导图、表格、墨水与高级编辑同样不支持。
- 导入导出在 trunk 视图里是 Ribbon 操作；draft 预览不提供。
- 文档的校验靠读回、布局 lint 与截图，而不是有人真的用 Excel 或 PowerPoint 打开它——这不等于渲染保真度保证。
- 项目只有大约一个月大（2026-08-15 创建），运行时却很重：一个后台服务进程、一个带迁移的 SQLite 格式，以及原生依赖。
什么时候用它、什么时候不要用
当交付物是真的办公文件——带公式和图表的表格、逐页检查过布局的演示文稿、排好版的报告——而你想看着 Agent 把它做出来、再决定合入还是丢弃，而不是事后发现文件被覆盖，就用它。草稿、对比与审阅这条链路是它比较特别的部分，也是两个 Agent 同时改一个文件还能推进的原因。
不要期待它是一个轻依赖：如果你只是要「写一个 .xlsx 再读回来」，有体积小得多的插件可选。也不要把它当成备份机制——审批发生在合入之前，而内置许可证过期后对现有文件会有什么影响，来源没有说明。
本站另一个办公插件 kw78/dsh-office-tools 是不同作者、不同机制的项目——它自带一套无依赖的 OOXML 引擎与八个 word_* / excel_* / ppt_* 工具。两份 README 都没有提到对方，本插件也不依赖它，两边文档里的工具名没有重叠。
FAQ
它需要账号、云服务或联网吗？
没有记录任何账号或云端项目。编辑、存储与渲染都在本地：内置 Gateway、工作区里基于 SQLite 的 .univer 文件，以及从 npm 安装的原生包。有两条出网路径：编译进包里的遥测端点，以及使用资源库时从 cdn.jsdelivr.net 与 cdn.undraw.co 下载 SVG。
「worktree」是 git 吗？
不是。来源里没有一处提到 git。draft、ready、merged、discarded 是 Univer 协作层持久化在 .univer SQLite 文件表里的状态，trunk 是其中的主线。
安装时会执行代码吗？
声明了两个脚本。prepare（pnpm run build && simple-git-hooks）会构建全部五个目标并安装一个 commitlint 的 git 钩子，它在你从 git 或本地源码安装时执行，需要 pnpm 与完整开发工具链。uninstall 会拉起一个脱离进程发送卸载遥测事件。发布包不声明 postinstall。
我该用哪个 DSH 版本？
取决于你装的是哪个构建：npm 的 latest（0.2.14）声明的是 0.1.1-rc.2 || 0.1.2-rc.1，而 main 分支（版本号仍是 0.2.14）声明的是 ^0.1.5-rc.1。请以你要装的那个版本自身清单里的声明为准。