RPG 制作猿 baihestudio/dsh-rpgmaker-mv

RPG Maker Agent

面向 RPG Maker MV 和 MZ 的 AI 生产智能体

用户想了解如何使用制作猿及其内置技能，请看 用户指南。安装、更新和卸载则看 Windows 安装与维护指南。

Windows Release ZIP（第 7 阶段）

用户下载 Windows Release ZIP，解压后双击 Install.cmd 即可。这个零参数安装程序会为八个阶段输出稳定的、只追加的纯文本，自动修复并校验受支持的 Windows 前置条件（包括精确的 Bun 1.3.14），安装固定版本的 DSH/MV/MZ 运行时和托管配置档，校验组合与实时 MCP 契约，并创建 RPG Maker Agent 开始菜单快捷方式。首次安装时选择目标位置；重新运行 Install.cmd 会在单独确认关闭正在运行的智能体之后，修复或升级已记录的根目录。捆绑依赖的声明见 THIRD-PARTY-NOTICES.md。

完整的首次运行、修复、端口冲突、工作区选择与卸载指南见 docs/windows-release.md。卸载会校验归属元数据，删除安装位置回执，这样重装时就能选择不同的根目录，同时保留回滚/恢复状态、可变状态、凭据、日志和项目；uninstall.ps1 -Purge 是显式清除。

贡献者仍可在 PowerShell 中运行底层的 bootstrap 和 doctor 脚本：

./bootstrap.ps1
./doctor.ps1

harness 把官方 DeepSeek Harness 运行时放在应用自有的目录树中，绝不 fork 或修改 DSH。安装会落地一个精确的、由应用托管的 web 配置档，包含四个直接托管的包依赖和六个有序的 DSH bundle 层：内置的 @deepseek-ai/dsh-base 和 @deepseek-ai/dsh-web-app 模板层，随后是固定版本的 Web 与图像生成包，再加上发布方自有的品牌与工作区 MCP bundle。安装/修复负责配置档的落地；正常启动只校验已提交的配置档，而 Doctor 只报告只读健康状态，不改变配置档状态。Windows 是唯一受支持的产品平台。

真实工作区验收只使用一次性状态：bun run phase2:real 从中立的落地目录准备项目无关的 Host，检查 CJK/空格工作区、单个池化 Host 服务器、同步收集到的稳定 rpgmaker_ 工具、直接以智能体为作用域的调用，以及观察到的引擎/工作区子进程身份。它的机器可读 JSON 报告实际的子进程/进程证据和 shell 进程观察结果；它不会凭一个常量就声称存在选择器或权限重试。一次性的原生 Windows 全新安装门禁接受显式的源根目录和桌面宿主根目录：

bun run phase7:windows-installed -- --source-root (Get-Location).Path --desktop-host-root C:\temp\built-desktop-host

它会构建全新归档，用一次性的前置条件/运行时根目录运行编译后的安装程序，执行由回执驱动的修复，校验 host、精确的 Node/Bun 运行时、应用自有的 pnpm/配置档、快捷方式、计时记录、MCP 契约、脱敏日志，并且只清理自己的可丢弃根目录。真正在干净机器上做 WinGet 预配的验收门，仍然是一项明确的高成本检查。

安装与修复

bootstrap.ps1 会构建一棵全新的暂存树，其中包含 src/config.ts 里声明的精确 DSH 包与 npm 完整性信息，复制由发布版本维护的 runtime-manifests/dsh/package.json 和 package-lock.json，运行 npm ci，用 Node 校验包与锁文件的精确事实以及 koffi，然后把它换到正式位置。发布版本还带有 MCPorter、RPG Maker MCP 和应用自有 pnpm 的等价锁定清单；目标环境搭建时绝不会从注册表生成锁文件。上一个运行时会被保留在带时间戳的回滚目录里。安装或校验失败时，只删除自己的暂存目录，不动当前活跃的运行时；更旧的 DSH 发布版本不会被接受。如果无法确认进程终止或回滚，锁会报告降级状态，并保留可恢复的暂存/回滚路径，供手动恢复。对有效运行时重复执行是无操作；bootstrap、doctor 和 launch 会通过操作锁把短暂的运行时操作串行化。活跃的 DSH 子进程还会持有会话租约，阻止 bootstrap 或第二次 launch 替换运行时，而 doctor 仍然可用。

在 Windows 上，选定的安装根目录拥有程序文件、运行时和可丢弃缓存。固定的本地状态根目录仍然是 %LOCALAPPDATA%\\BaiheStudio\\DSH-RPGMaker-MV，用于存放设置、凭据、日志、锁和安装位置回执。打包的 sidecar 从自身安装位置推导程序根目录，并显式提供这个本地状态根目录，因此过期的 DSH_ 路径变量无法让开始菜单启动改换位置。测试接缝可以注入根目录。doctor 检查启动器实际可见的可执行文件路径和版本，而不是信任包管理器元数据。缺失的前置依赖会自动修复，包括精确的 Bun 1.3.14；WinGet 返回无更新结果后，会接着刷新并校验。

如果你的网络需要代理，请在安装前设置 HTTP_PROXY、HTTPS_PROXY、npm_config_proxy 和/或 npm_config_https_proxy。本地预检可以用 http://127.0.0.1:17890 作为示例端点；代理设置的作用域是进程，绝不会持久化。在 PowerShell 支持命令中，如果执行策略阻止 npm.ps1，请改用 npm.cmd。

启动 DSH Web

./launch.ps1

Windows 启动器与项目无关：它从不打开文件夹选择器，不读取最近项目，不写入应用自有的项目选择状态，也不接受 launch --project。发布 ZIP 带有预构建的 bundle/dsh-workspace-mcp 包，以及生成的 MV/MZ 清单。安装或修复会准备并校验源固定的 DSH、pnpm、MCPorter 和 Xerolo MV/Redseb MZ MCP 运行时、应用托管的 web 配置档、默认预设、生效组合，以及实时 MCP 契约。正常启动会消费这些已提交的产物，只做开销很小的归属、必需文件、固定端口和进程就绪检查；它不会运行 npm、pnpm、WinGet、注册表下载、配置档修复、预设生成，也不会实时枚举 tools/list。DSH 启动在应用自有的中立落地目录；在 DSH Web 里选择和切换 RPG Maker 文件夹。rpgmaker 是默认预设。新智能体默认使用 deepseek-v4-flash-vision-exp；DSH Web 常规的模型选择仍然是用户覆盖项，已有会话保留其记录的模型选择。用户附加的 PNG、JPEG、WebP 和 GIF 图片可作为图像输入读取；这不会增加图像生成、远程 URL 摄取或自动游戏画面捕获。

工作区包会校验 DSH Web 工作区正下方的 Game.rpgproject（MV）或 game.rmmzproject（MZ），以及 data 和 js。每个智能体获得稳定的名称，例如 rpgmaker_validate_project；会话标识符和 MCP 传输名称绝不会出现在提示词或历史记录中。同一工作区内的智能体共享所选引擎的一条热连接，而不同的引擎/工作区组合保持隔离。工作区服务器是 Host 生命周期：最后一个智能体离开后它仍保持热状态，只在 Host 关闭时关闭。没有并发写入锁或串行化，也没有空闲驱逐。如果池化的引擎子进程崩溃，受影响的工作区智能体会失败，直到 Host 重启；不提供子进程自动重启。

启动器始终显示这份编辑契约：

- 会话运行期间，智能体及其 rpgmaker_ 工具是唯一的写入方。
- 不要让多个智能体同时写入同一个项目。
- 如果 RPG Maker MV 或 MZ 编辑器处于打开状态，它是只读的；不要从它保存。
- 在检查智能体的改动之前，先在编辑器中重新打开项目。

如果 DEEPSEEK_API_KEY 和 DSH 的本地凭据元数据都不存在，启动前会提示 DSH 仅限回环的本地引导流程。启动器绝不会读回、存储或打印凭据值，也不会把它放进生成的设置、项目文件或日志中。

仓库检查

bun test
bun run check
Optional real project-neutral DSH + dual-engine workspace acceptance
bun run phase2:real

测试使用一次性的运行时、DSH home、凭据和 MV/MZ 项目目录。它们不会触碰用户已安装的 DSH 状态、RPG Maker 项目、应用或凭据。常规测试套件使用伪造的前置条件/运行时可执行文件；可选的真实门禁只把固定版本的 DSH/MCPorter/Xerolo/Redseb 包安装到一次性的临时运行时中，并验证所选引擎的工具契约。真实的 PowerShell/Coreutils 身份、Windows .cmd 启动，以及已安装项目的检查，仍由互补的 Windows runner 门禁负责。

阶段 2：RPG Maker 智能体与 MCP 编辑闭环

Install.cmd 会准备好精确锁定版本、由应用自有的 MCPorter 与双引擎 RPG Maker 运行时，完整的受管 web 配置档（包括本地 dsh-workspace-mcp Host bundle）、默认的 rpgmaker 预设、与项目无关的 web --dump-config 组合，以及两份实时 MCP 契约。随后 launch.ps1 直接使用这些已提交的产物，不再依赖包管理器、配置档、预设、组合或实时 schema 修复。选择器显示 🐒 制作猿。访问层同步提供稳定的 rpgmaker_<raw engine tool name> 工具，并在首次请求前校验实时工作区连接。工作区无效或含义不明确时，服务器在启动前就会失败。

每个随附预设都会为上游 Forgejo MCP 服务器挂载官方 DSH @deepseek-ai/dsh-mcp-client，因此其完整工具面会以 mcp__forgejo__list_repo_issues、mcp__forgejo__create_issue 之类的名称发布。每个 Release ZIP 都包含应用自有的 tools/forgejo-mcp/forgejo-mcp.exe；无论是全新运行 Install.cmd，还是走事务式本地更新路径，都会校验其锁定的 SHA-256 与 --version。用户无需安装 Go，也无需自备 MCP 可执行文件。DSH_FORGEJO_MCP_COMMAND 仅作为显式覆盖项保留。

打包的 wrapper 会清除其他 Git 凭据助手，选用 Git Credential Manager，并对 http://forgejo.localhost:17480/baihestudio/dsh-rpgmaker-mv.git 执行非交互式查询。它只使用 Git Credential Manager 中已存储的密码（即 Forgejo PAT），不会提示输入、创建或持久化 PAT。该密码只会以 FORGEJO_ACCESS_TOKEN 的形式传给 Forgejo MCP 子进程；绝不会写入生成的预设或 Release ZIP。原生 MCP 访问刻意保持通用，而两个共享技能把自动上报限制在 baihestudio/dsh-rpgmaker-mv：forgejo-agent-issue-report 提交经核实的、智能体观察到的缺陷、阻塞项以及工具/MCP 故障；forgejo-user-feedback-report 会先澄清用户反馈的体验或能力问题，再提交。两者使用同一套不含机密、完整的去重协议。

RPG Maker 预设把 MCP/智能体视为唯一写入方。其挂载的 mv-reference.md 是一份紧凑的本地编写地图，涵盖 MV 核心/运行时分层、DataManager、包括 $dataSkills 在内的 $data 记录、Game_Interpreter、管理器/游戏对象/UI 分层，以及官方 MV Help、Plugin Specifications、Output Formats 链接。插件工作会先核实实际项目的 js/rpg_.js API 与数据，使用 ES5 和 MV 支持的 fs，而不是 node:fs，并且只做必要的最小改动，不添加猜测性的兼容层、大规模重构、额外接口或审查者/第二模型工作流。

RPG Maker 预设把 MCP/智能体视为唯一写入方。数据库、事件/对话、地图元数据、插件以及恢复类改动都使用稳定的 rpgmaker_ 名称，先做定向重读，再执行 rpgmaker_validate_project，并在返回成功前给出可见警告。.mcp-backups/ 相关指引是只读的：harness 会报告建议的 .gitignore 条目，但未经用户同意，绝不修改项目现有的 ignore 文件。

生成的 preset 和 patch 位于 DSH_HOME 下；它们包含应用自有的运行时路径，不含任何凭据。固定的 DSH Code preset 从已安装的运行时读取，不会被修改。两个应用自有的 Host patch 都不插入 timeout policy：固定的 DSH web profile 在 Host 作用域拥有官方 id: timeout-policy / @deepseek-ai/dsh-tool-call-timeout-policy 行。Install 和 Doctor 会校验 web --dump-config，并要求自定义 Agent preset 中恰好有一行生效的官方行；preset 组合中从不包含它。重新运行 Install.cmd 可重写应用自有的 patch，并修复过时的已提交组合。

MZ 工作空间使用 Redseb 固定的 119 工具编辑面，包括定向的 database/map/event/tile 写入、dry-run 预览，以及 project/reference 校验。MZ Playtest 的 launch/status/log/stop、截图、运行时输入和 build/release 自动化有意不支持；Playtest Debug preset 会报告这一边界，而不是启动 MV 运行时。

Phase 3: 游戏设计与文档

🐒 制作猿 在机制、叙事、节奏、数值、玩家目标或设计文档任务中按需读取 game-design 与 game-design-bootstrap Skills。它在同一工作空间维护设计资料，可检查文档明确指向的项目路径并按需使用 Web 研究；保留自适应索引、决策、待确认问题和参考资料，不强加固定档案结构，也不会自动删除既有文档。

Phase 4: Playtest 调试

🐒 制作猿 在 MV 工作空间直接完成真实 Playtest 与日志诊断。发起调试时，它先通过 Skill 工具读取并遵循 presets/rpgmaker/skills/playtest-debug/ Skill，按有界序列编排稳定的 rpgmaker_ 工具：静态验证、空闲预检、有界 Steam App ID 363890 发现、存在 nwjs-win\Game.exe 时 NW.js 启动、否则浏览器模式回退、有界状态/日志观察、MCP stop 与停止后状态确认。MZ 工作空间不提供 Playtest、截图、运行时输入或构建发布，相关请求会如实报告不支持。它绝不递归扫描磁盘，拒绝已运行的 Playtest，不认领 PID 也不调用 OS 进程控制，MCP 状态无法确认清理时如实报告 unverified。浏览器回退返回可玩 URL，但 rpgmaker_playtest_log 无法捕获浏览器 DevTools 控制台输出。

报告区分静态验证、进程启动、崩溃/日志证据、清理确认与行为/视觉验证。进程启动和干净日志不是行为验证。Harness 拥有的进程树清理属于独立的 automated-playtest 能力；截图/输入/gameplay 自动化不在本仓库范围。

Phase 5: 图片素材

Install.cmd 用 WinGet 安装 ImageMagick.ImageMagick，提供 Windows 全局的 magick 命令；它不是应用自有的二进制，也不是 DSH 插件。制作猿在图片素材任务中按需读取 image-assets Skill：Kepos 生成或编辑视觉候选，magick 进行像素缩放、绿幕清理和精灵表准备，并直接接入 RPG Maker 工作流。

Phase 6: DSH runtime foundation

所有 launcher、preset、Windows shell、MCP 和 Playtest 契约都挂载到 src/config.ts 中声明的官方 DSH 运行时，并据此校验。暂存运行时在原子替换前会校验精确的 npm package-lock、包版本与完整性、基于 Node 的 DSH 可执行文件，以及 koffi。替换后校验失败时会恢复先前的运行时，并保留未验证的目录树以供检查；不会就地修改任何运行中的运行时。
MV 和 MZ 的 MCP 锁检查刻意只覆盖稳定发布事实：顶层版本号精确匹配、dist/index.js bin、以及固定的 npm 完整性。锁数据缺失或被篡改时一律失败关闭；传递依赖的元数据不做固定。生产环境的编辑契约是挂载的 RPG Maker 技能加上稳定的 rpgmaker_ 工具，另有一轮可丢弃的真实验收，覆盖变更后重读、校验、备份/恢复和 schema 拒绝。

编辑模型

首个版本中，RPG Maker MV 或 MZ 工作区处于智能体控制之下时，智能体是唯一的写入者；不要让多个智能体同时写入。编辑器可以保持打开，但仅用于只读参考：用户不得从编辑器中保存，检查智能体的改动前必须先重新打开项目。

阶段 7：Windows 发布门禁

构建并检查真实的 Release ZIP，不要覆盖已有归档：

bun run release:zip -- C:\temp\DSH-RPGMaker-MV-Windows.zip --desktop-host-root C:\temp\built-desktop-host

公开的 release:zip 命令要求显式传入预构建的 --desktop-host-root 载荷，即使它在 WSL 或 macOS 上运行也是如此，并且会在报告成功前严格检查该载荷。发布门禁在自动化测试中使用测试自有的假用户/安装根目录。完整的基础验收是：

bun test
bun run check
bun run phase2:real

基础部分到此为止，不包含自动化 gameplay/CDP 监督，后者仍留在单独的 draft/hold 标记上。

Electrobun Windows 桌面适配器

可复用的 Electrobun/Cottontail/WebView2 宿主位于单独的 dsh-electronbun 仓库。本产品仓库只提供轻量的 RPG Maker sidecar 适配器和生成的宿主清单；不复制宿主的 supervisor、启动状态机或运行时恢复逻辑。发布打包器消费产出的预构建宿主载荷，校验其固定契约，并把它安装到产品树旁边的 desktop-host 下。参见 docs/windows-electrobun.md，并用以下命令搭建测试自有的宿主工作区：

bun run desktop:stage -- --host-root /path/to/dsh-electronbun --output-root /tmp/dsh-rpgmaker-electrobun

适配器目前固定使用已验证的 Windows Bun 1.3.14，动态加载已安装的产品启动器，并让原生 WebView2 宿主在 127.0.0.1:3081 上加载现有的项目无关 DSH Web 会话。产品 sidecar 传入 DSH 的显式 --no-open 标志；内嵌 WebView 是唯一的 UI 打开者。维护者在构建发布版时可以显式提供已构建好的载荷：

bun run release:zip -- /tmp/DSH-RPGMaker-MV-Windows.zip \
--desktop-host-root /path/to/built-desktop-host

公开命令始终要求并严格检查显式载荷。载荷必须包含规范的 desktop-host.json 描述符、固定的宿主 commit/Bun 版本、其原生 .exe 启动目标，以及必需的 sidecarEntrypoint/supervisorExecutable 字段指向暂存后的确切文件。描述符还必须带上规范的 sidecarProvenance 对象，该对象由单次 desktop:stage 交接生成，其中恰好包含带 schema 版本号的当前 adapter-source 与 bundled-sidecar SHA-256 摘要。发布门禁在接受载荷前会重新计算这两个值；它绝不会在用户机器上构建或下载 host。