OpenWrite

它是什么

OpenWrite 把 dsh 变成一间长篇小说的创作室。它不是单个工具：安装后你会得到四样东西——一个把规划与正文写作合并到同一会话的 Agent 预设、一个注册了大批 novel_* 工具的桥接层、一套浏览器端原生创作工作台，以及一个由插件自己管理的本地 Python 后端。README 把分工说得很直接：dsh 提供 Agent 与界面，OpenWrite Core 提供小说领域能力，人物、设定、大纲、正文和评审都留在你选定的本地作品目录里。

仓库自己元数据里的三个说法值得去数，而不是照抄，而三者在来源里都站得住：90 个工具、统一创作 Agent、审稿 DAG。

90 个工具确实是 90 个独立工具

这一条经得起数。已发布的 dsh-openwrite@0.2.10 包里，packages/openwrite-bridge/lib/tools.js 恰好有 90 处 defineTool 注册，名称全部唯一、全部以 novel_ 开头——资产、章节、修订、任务、模型、研究、大纲、场景、导出。桥接层自己的策略测试独立断言了同一件事：「real dsh tool registry isolates 90 tools by preset and disposes them」，且在 0.2.10 的发布源码上通过。

比数字更重要的有两点限定。

第一，这些工具的作用域是预设，不是整个 harness。同一个测试断言：普通会话看到 0 个 novel_* 工具，只有挂上 OpenWrite 创作预设之后才出现，销毁 scope 后 90 个全部消失。所以装了这个插件并不会给你所有对话都加上 90 个工具，只有跑 openwrite 预设的会话才有。

第二，它们由预设内的行（dsh-openwrite/tools）注册，而不是宿主 bundle。预设组装文件对此有明确说明：把桥接层再挂一次会重复注册进程级的 novelDomain 服务，导致该预设无法加载。

「审稿 DAG」具体是什么

README 里的「标准审稿 DAG」在 docs/REVIEW_DAG_FRAMEWORK.md 里有完整定义，比宣传词组具体得多。章节审稿是一张由 OpenWrite 一次性定义的固定拓扑，dsh 侧只负责按章实例化：

• 47 个节点、46 条包含边、14 条执行依赖。
• 1 个负责整章完成条件的根节点、1 个校验正文版本与评审基线的上下文前置节点、6 个质量域、36 个质量检查叶节点、1 个硬门禁（检查 27，其结果刻意不并入质量分），以及 1 个聚合节点。
• 六个域共 20 条加法评分准则，走 openwrite.review-dag-framework.v1 契约，带语义版本与 SHA-256 修订号。
• 未请求的检查写成 inconclusive，因此不同章节的图在拓扑上始终可比。

每份 review.json 都记录 frameworkId、frameworkVersion 与 frameworkRevision，历史审稿可以准确追溯到当时的框架修订号。每章的图写入 data/novels/<novel_id>/data/dog/reviews/<chapter_id>/dog-graph.json，DoG verifier 只读取这些确定性记录，不再次调用模型，也不重算评分。框架只开放四个扩展点（context-evidence、domain-evaluator、gate-evaluator、post-review-policy）；增删节点必须升级框架版本，不能在单章实例里临时改图。

所以这里的「DAG」应当理解成一份落盘、可检查的审稿产物，而不是一个在审稿时实时扇出模型调用的编排引擎。

工作台是 dsh 原生 UI，不是内嵌网页

packages/studio-panel 声明自己是 dsh 客户端插件，dsh.client.platform: web，浏览器端注册进 harness 自己的扩展点：conversation.view（创作 / 资料 / 任务三个工作台）、conversation.session.header.*、conversation.input.left、conversation.chat.turnTail、tool.call.toolview，以及左侧栏的 sidebar.footer.action 启动入口。packages/studio-panel/src 里没有任何 iframe。

CHANGELOG 记录了这次迁移本身：2026-08-23 那条写明默认工作流「彻底移除 iframe 与重复导航」，并加了断言原生路由与无 iframe 的 smoke 门禁。正文编辑器把 Vditor 作为打包运行时随插件附带（packages/studio-panel/vendor/vditor），而不是加载远端页面。90 个工具里有 55 个被映射到八类原生工具卡片。

运行要求与安装足迹

• Node >=22.19.0（根 engines）。安装指南称 Node 24 为完整验收基线，Node 22.19 / 26 做兼容检查。
• harness profile：web。清单声明 dsh.compatibility.profiles = ["web"]，并把 @deepseek-ai/dsh 0.1.2-rc.1 固定为基线。它声明的版本表是 {"0.1.2-rc.1": "compatible", "0.1.3-alpha.1": "unknown", "0.1.3-alpha.2": "unknown", "0.1.5-alpha.1": "compatible"}；清单的 dsh.compatibility.dsh 写明 "0.1.2-rc.1 || 0.1.5-alpha.1"，本条目将其逐字记为 dshTarget。安装前请自行核对宿主版本。
• 后端是本地托管，不是云服务。首次运行会下载固定版本的 uv 0.11.19 与 Python 3.12.13（URL 与 SHA-256 见 release/runtime-manifest.json）到 $DSH_HOME/openwrite/，再按 release/requirements.lock 安装锁定依赖，并自带 openwrite-5.8.2-py3-none-any.whl 作为 Core。无需预装 Python，也不需要 OpenWrite 账号或云端服务；但 docs/DSH_STORE.md 记录了首次准备需要联网——下载来自清单里的固定来源（GitHub 与 Python 包索引）。
• 后端只监听回环地址。受管理运行时把 base URL 拼成 http://127.0.0.1:${port} 并带实例 token；安装指南称受管理 Core 只监听回环地址、端口自动分配，实例认证只在宿主与 Core 之间传递。高级配置 mode: external / baseUrl 可以指向你自己跑的外部 Core，插件不接管该进程。
• 模型凭据由你自己配置，出站模型流量发往你选的服务商。README 把 dsh 宿主的对话模型与「任务 → 模型」里的小说生成/评审/测试模型分开，并说明安装与健康检查不调用写作模型，而使用收费服务商会产生 API 费用。「模型测试」可能真的调用服务商，文档明确把它与不调用模型的环境健康检查区分开。
• 权限是披露的，不是沙箱兜底。docs/DSH_STORE.md 把已绑定作品目录的读写、网络访问、子进程（受管理 uv/Python）以及源码构建路径都列为真实能力，并明确「工具策略不是操作系统沙箱」。准备环境的子进程使用允许列表环境，不继承无关 API Key。
• 除上述之外，README 没有权限、遥测或隐私声明。仓库里没有遥测或分析客户端，docs/ 里的「telemetry」一词只出现在无关的功能讨论中。没写到的地方，请按「未说明」理解，而不是按「安全」理解。

安装期脚本披露

根 package.json 带一个 prepare 生命周期脚本：node scripts/prepare.mjs。prepare 属于安装期钩子，源码安装会执行仓库代码。

脚本实际做什么（scripts/prepare.mjs，在 npm 包里逐字节相同）：读取 release/runtime-manifest.json，断言固定版本的 Core wheel 存在；然后对 packages/openwrite-bridge、packages/studio-panel、vendor/dsh-dog 三个目录，检查 lib/index.js 及其第二个入口文件是否已存在。只要有构建产物缺失，就在该包目录内执行 npm ci --ignore-scripts --no-audit --no-fund，接着执行 npm run build；最后运行 scripts/release-provenance.mjs 重新生成发布来源信息。

在已发布的 0.2.10 包里，三个 lib/index.js 都已存在，因此脚本自己的文件头注释与 docs/DSH_STORE.md 都把 prepare 描述为仅源码安装才做的事（「仅源码安装构建插件；预编译包已有运行资源」）。harness CLI 从另一侧给出同样的约束：对 git+/github: 形式的 spec，pnpm 会阻止构建，直到你把它打印出的确切键加进该 profile 的 pnpm-workspace.yaml 的 allowBuilds。README 里交给 Agent 的那段安装话术也明确要求不要放宽 pnpm 构建授权。

已知限制

• 90 个工具的上下文开销没有以 token 计的测量。仓库自己做了测量，并且说得很清楚。离线成本文档（docs/COST_MEASUREMENT.md）指出：UTF-8 工具声明字节数不是 tokenizer token，也不是账单费用；仓库不内置任何 tokenizer，因此真实 token、缓存命中与花费都记为 not-run。在 0.2.10 上跑桥接层自己的策略测试，会打印它确实测了的那两个数：{"measurement":"native-tool-schema","tools":90,"utf8Bytes":63983,"tokenizer":"not-measured"}，以及 PTC 呈现方式下的 {"measurement":"ptc-presentation","schemaBytes":944,"sdkBytes":60560}。缓解手段是有文档的——工具行接受 presentation: native（默认）、ptc 或 both，自定义预设可以改——但两种模式都没有实测的 token 数或金额。如果你在意「每次请求都带 90 份 schema」这件事，那是一项真实但未被量化的成本。
• 没有实测的模型计费结果。安装指南最后一节说明验证使用模型替身、未做真实模型计费测试；docs/COST_MEASUREMENT.md 把服务商那一半标为 not-run。
• 平台覆盖比「跨平台」这个说法窄。目标平台是 macOS arm64/x64、Linux x64、Windows x64；指南写明 Apple Silicon 至少 macOS 14、Intel Mac 至少 macOS 13，其他系统小版本的覆盖范围以 Release 报告为准。
• npm 包与 GitHub Release 产物在本次核对中未验证完全一致。两者同名 dsh-openwrite-0.2.10.tgz，GitHub Release 附件登记的大小与 npm 包相同（10,021,338 字节），README 也称二者是同一份产物、SHA-256 一致；但本次没有完成第二次下载来亲自核对校验和。
• 包内许可证是混合的。仓库整体是 Apache-2.0，package.json 与之一致，因此不存在 README 与清单冲突。但随包的 Studio panel 是 MIT，vendored dsh-dog 是 BSD-3-Clause，Vditor 与 OpenWrite 预设技能各自保留原许可证，包内还带一个为 macOS x86_64 本地重建的 cryptography 50.0.1 wheel 及第三方许可证文本。再分发前先读 THIRD_PARTY_NOTICES.md。
• 卸载行为刻意保守。移除插件会停止它的服务、界面与进程，并保留作品、凭据、会话与缓存；缓存需要单独手动清理。受管理预设按版本命名（openwrite-<version>），就地修改后插件会拒绝覆盖。
• README 指向同仓库的 native-core 分支，那里是小说核心，与本插件分支分别维护。

什么时候用它、什么时候不要用

如果你确实在 dsh 里写长篇小说，希望同一个会话连着规划、写章、审稿、修订，手稿在自己磁盘上、写作链路里没有托管服务，那它合适。最没有替代品的部分是落盘的审稿产物（框架版本、六域、门禁、覆盖率、证据）以及修订门控：大纲、资产、创作重点、伏笔和写作目标的每一处独立改动都先出服务端保存的预览、应用时重验源 revision，并返回只对已确认结果有效的撤销 token。

不要因为「工具听起来很多」而装它。这是一个垂直套件：带一个受管理的 Python 运行时、一次首次运行的网络下载，以及大量只服务单一领域的提示词投入。如果你的工作不是长篇虚构，那 90 个工具就是纯成本；而预设的人格是一份很长的中文写作契约，你会是在跟它对抗，而不是在用它。如果你不愿意让插件替你管理一个本地 Python 环境和一个回环服务，或者你需要「你所在 harness 版本受支持」的证据，那这个包声明的兼容版本只有 0.1.2-rc.1 与 0.1.5-alpha.1，落在这两个版本之外时这份证据它给不了。

FAQ

「90 个小说工具」是真的还是宣传口径？

是真的，而且数得出来。已发布的 0.2.10 包里 packages/openwrite-bridge/lib/tools.js 有 90 处 defineTool 注册、90 个唯一 novel_* 名称；桥接层的 tool-policy 测试也对着真实的 dsh 工具注册表断言了同一个数字。这个数字的作用域是 OpenWrite 预设：普通会话看到的是 0 个。

审稿 DAG 到底做什么？

它实例化一张固定且带版本号的章节审稿蓝图：47 个节点、46 条包含边、14 条执行依赖、1 个上下文节点、6 个质量域与 20 条加法准则、36 个质量检查叶节点、1 个与质量分分离的硬门禁，以及 1 个聚合节点。结果按章写成 dog-graph.json，由 verifier 读回，verifier 不再次调用模型、也不重算评分。

工作台是 dsh 原生界面还是内嵌网页？

原生。packages/studio-panel 是 platform: web 的 dsh 客户端插件，把 React 视图注册进 conversation.view、会话头、输入区与工具调用等扩展槽，源码里没有 iframe。CHANGELOG 记录了 2026-08-23 移除旧 iframe 与重复导航，并加了断言此事的 smoke 门禁。

需要外部的 OpenWrite 服务或账号吗？

不需要。领域后端是本地 Python 服务，由插件在首次使用时自行下载管理（固定 uv 0.11.19、Python 3.12.13、依赖取自 release/requirements.lock，并自带 Core wheel），监听 127.0.0.1。文档记录的外部调用只有：环境准备阶段按清单固定来源下载运行时、向 Python 包索引取依赖，以及访问你自己配置的模型服务商。其余数据留在本机与你选定的作品目录。

安装会执行代码吗？光安装就会消耗 token 吗？

package.json 声明了 prepare 生命周期脚本，源码安装会执行 scripts/prepare.mjs：校验固定 wheel，仅在 lib 产物缺失时构建三个内部包，并重新生成发布来源信息。已发布包里预编译产物齐全，脚本自己的注释与 docs/DSH_STORE.md 都说明它只在源码安装时起作用。安装与环境健康检查不调用写作模型，README 对此有明确表述。领域工具带来的持续 token 开销是另一个问题，而来源里没有任何地方测量过它。

该用哪个 dsh 版本？

清单只声明了两个兼容版本：0.1.2-rc.1 与 0.1.5-alpha.1，并把 0.1.3-alpha.1、0.1.3-alpha.2 标为 unknown；0.1.2-rc.1 是固定基线，Node 24 是完整验收基线。清单的 dsh.compatibility.dsh 写作 "0.1.2-rc.1 || 0.1.5-alpha.1"，本条目逐字记为 dshTarget。安装前请把 dsh --version 与该声明及 Release 说明对照；另外注意 alpha 兼容结论依赖该仓库报告中固定到 2026-09-09 的依赖解析。