tt-a1i/archify-dsh 适配器实战指南在 DeepSeek Harness 中安装、调用与发布 Archify 架构图 Skill【免费下载链接】archifyAgent skill for beautiful, verifiable architecture, workflow, sequence,>项目地址: https://gitcode.com/GitHub_Trending/arch/archify导读tt-a1i/archify-dsh是 Archify 官方仓库中为 DeepSeek HarnessDSH提供的社区集成适配器它以Skill-only 包的形式把 Archify 的架构图渲染能力打包进 DSH 的插件体系让你在 DSH 中直接以archify之名调用它绘制架构、工作流、时序、数据流与生命周期图。本文基于 integrations/deepseek-harness/README.md结合仓库内打包脚本、发布元数据与自动化测试完整讲解该适配器的版本矩阵、安装升级、调用卸载、安全边界与发布维护流程读完即可在自己的 DSH 环境中落地使用并理解其底层的打包与验收机制。适配器定位社区集成非官方产品tt-a1i/archify-dsh是一个社区维护的 DeepSeek Harness 集成适配器不是 DeepSeek 的官方产品也不暗示任何 DeepSeek 背书。这一点在 README 开头即被明确声明因此在引入时应当把它当作可选社区插件而非官方能力来看待。从源码结构看该适配器是一个典型的Skill-only bundle它不注册任何原生的 render / validate / deliver 工具不提供自定义 Web 客户端也不带 Produced Files chips、遥测、凭据处理、后台服务或安装钩子。它只做一件事——向 DSH 的 Profile 插入一个名为archify-plugin的文件系统 Skill Provider让 DSH 能够从已安装的 npm 包内发现并加载 Archify Skill见 cordis.patch.yml 与 lib/index.js。适配器自身不发起任何网络请求。这种克制设计带来的直接好处体现在 adapter-security.test.mjs 的测试断言中lib目录下的宿主代码不得出现child_process、fetch、node:http/https/net/dgram、遥测/OTLP、凭据与环境变量密钥读取、定时器/Worker/cluster也不得调用tools.register把适配器攻击面压缩到最小。版本矩阵v0.1.0 与待发布的 v0.2.0该适配器遵循实验性兼容、非跨版本稳定保证的发布哲学。README 明确给出当前与待发布两个版本的对照维度已发布 v0.1.0待发布 v0.2.0仓库package.json已就绪DSH 兼容deepseek-ai/dsh0.1.0-rc.6开发者预览deepseek-ai/dsh0.1.2-rc.1开发者预览Node.js^22.19.0 \|\| 24.0.0^22.19.0 \|\| 24.0.0捆绑 SkillArchify Skill 2.14.0Archify 2.17.0-dev.1 开发快照Skill 源码—固定提交920543baa1c6137803c5b45a69d8977152773d35类型—Skill-only bundle单 Provider 注入其中 v0.2.0 相比 v0.1.0 新增了作者品牌标记authored brand marks、Workflow schema v2、Viewer 本地化i18n、更新感知update awareness以及后续的打包与 CLI receipt 修复。需要注意v0.2.0 目前并未发布尚不能通过npm install获取因此文末的安装示例在 v0.2.0 正式发布并公开验证前仍指向0.1.02.17.0-dev.1 是开发快照而非 2.17 稳定版其 Skill 源码被固定pin在一个不可变提交上这正是 release.json 中sourceCommit字段的用途——它同时记录 Skill 源码提交、Skill 版本与 DSH 版本作为验收acceptance时的唯一事实来源。仓库中的 package.json 已把version提升为0.2.0dsh.bundle.patch指向./cordis.patch.ymlengines与 README 声明一致并声明了keywords: dsh-plugin / deepseek-harness / agent-skill / architecture-diagram。安装只装预构建的精确版本官方安装方式只有一个使用预构建的 npm 包并指定精确版本不要从 Git 源码安装。dsh plugin --profile web add tt-a1i/archify-dsh0.1.0要点--profile web指定安装目标 Profile如果你在多个 Profile 中使用 Archify需要对每个 Profile 分别执行安装命令必须使用精确版本号0.1.0这与 README 强调的非跨版本稳定保证一致——DSH 本身处于开发者预览阶段锁版本是唯一可控的复现方式当前仓库package.json声明的 Node 兼容范围为^22.19.0 || 24.0.0安装前请确认运行环境满足该前提。常见误用不要dsh plugin add tt-a1i/archifyREADME 特别警告不要执行dsh plugin add tt-a1i/archify。原因有二仓库根目录并不是一个 DSH 包也没有 bundle 元数据适配器所需的dsh.bundle.patch等信息只存在于 integrations/deepseek-harness/package.json且该路径被标记为pack input而非仓库根。这也正是 pack.mjs 在打包时要求 tarball 必须同时包含package.json、release.json、cordis.patch.yml、README.md、LICENSE、lib/index.js、skills/archify/SKILL.md的原因——缺少任意一项都会直接打包失败。如果遇到 npm 下载问题可以改用本地下载并校验完整性后的.tgz文件将其绝对路径直接传给安装命令dsh plugin --profile web add /absolute/path/to/package.tgz从 distribution-acceptance.mjs 的profile-identity检查可以反推其内部原理验收会确认 Profile 的package.json中dsh.profile.bundles确实包含tt-a1i/archify-dsh且dependencies中对应项不是link:或源码检出路径——也就是说安装链路必须是真实 tarball → Profile本地源目录不能混入。升级逐 Profile 重跑同一条精确版本命令升级方式与安装相同——在每个使用 Archify 的 Profile 中重跑同一条精确版本安装命令dsh plugin --profile web add tt-a1i/archify-dsh0.1.0 # 升级时换成目标精确版本README 明确两点预期升级 DSH 本身不会升级已安装的插件——插件是独立的 bundle 层宿主版本更新与插件内容无关升级 Archify 仓库也不会更新已安装的插件——插件打包的是 Skill 源码的不可变提交快照见下文发布维护。这正是锁版本 固定提交设计的一致性体现想获得新版本能力唯一路径是显式安装新版本号。调用用自然语言按名加载 archify安装完成后直接在 DSH 中按名字请求 Archify 即可。README 给出的参考提示词如下Use the archify skill to map this repositorys runtime architecture. Show 8–12 core components, one primary path, external dependencies, and trust boundaries. Put supporting detail in cards instead of adding more edges. After delivery, return the exact workspace paths of the specification JSON and the HTML artifact.执行流程上Archify 会经由 DSH 普通的 Skill、shell 与 filesystem 路径运行没有特殊通道生成的规范 JSON 与 HTML 工件都是普通的 workspace 文件。这也带出下一个必须知道的限制。Produced Files 限制让 Agent 回传精确工作区路径由 shell 命令创建的文件不会自动出现在 Web 的 Produced Files 栏中适配器不提供自定义 Web 客户端或 Produced Files chips。因此 README 给出的实践是要求 Agent 在交付后回传规范 JSON 与 HTML 工件的精确 workspace 路径再从工作区打开这些文件——上面提示词的最后一行就是为这件事准备的。从测试实现 probe-skills.mjs 可以看到Skill 以标准skills.list/skills.get接口被发现与加载其返回的resourceBase指向已安装包内的skills/archify目录验收脚本还会校验该资源根必须位于已安装 tarball 包内部resource-base阶段确保 Skill 内容只来自包体而非工作区任意路径。卸载标准插件命令基座 Profile 不受影响dsh plugin --profile web remove tt-a1i/archify-dsh标准插件命令会移除适配器依赖与 bundle 层卸载后基础 Profile 依然可用。这一点同样被验收脚本覆盖uninstall与base-profile阶段卸载后 Profile 的bundles与dependencies中不再存在包名且重新--dump-config后不再出现archify-skill-filesystem行或archify-pluginProvider证明没有残留层。安全姿态无遥测、无网络、无生命周期脚本README 给出适配器完整的安全承诺清单适配器无遥测、无网络客户端、无凭据处理、无后台服务没有prepare、install、postinstall脚本宿主加载的适配器代码不派生进程也不打开第二条权限路径包解析、Provider 加载与组合compose错误会在 DSH 正常启动过程中直接失败fail loud而不是静默降级。仓库中的测试把上述承诺变成了可执行的机器检查见 adapter-security.test.mjsassert.doesNotMatch(source, /child_process/); assert.doesNotMatch(source, /fetch\s*\(/); assert.doesNotMatch(source, /node:http|node:https|node:net|node:dgram/); assert.doesNotMatch(source, /telemetry|opentelemetry|otlp/i); assert.doesNotMatch(source, /credentials|DEEPSEEK_API_KEY|process\.env\.\w*TOKEN/); assert.doesNotMatch(source, /setInterval|setTimeout|Worker|cluster/); assert.doesNotMatch(source, /archify_render|archify_deliver|tools\.register/);同时resolveArchifySkillRootlib/index.js对缺失的 ProfilebaseUrl或无法解析的包路径一律抛错而不是猜一个 Skill 根目录——fail loud是安全边界的一部分。需要补充的边界说明来自 READMEv0.2.0 的 Skill 内含一个可选、仅通知性质的稳定版 Archify 更新检查器对应 archify/scripts/check-update.mjs、archify/scripts/update-contract.mjs 与 archify/skill-release.json它永远不会自动升级插件而 Skill 的作者远程品牌资源可能用到有限的网络路径bounded network path但适配器本身不做任何网络请求。发布维护从分支准备到三平台验收发布流程在 integrations/deepseek-harness/scripts/pack.mjs 与 integrations/deepseek-harness/scripts/distribution-acceptance.mjs 中实现为两条可执行命令另配一套单元测试integrations/deepseek-harness/test/ 下的adapter-staging、package-contract、tarball-contract、zero-regression、docs-contract等。发布分支上的准备动作在发布分支上需要依次完成提升package.json版本号当前仓库已就绪为0.2.0更新release.json写入完整的 Skill 源码提交哈希40 位十六进制、匹配的 Skill 版本与 DSH 版本——release-source.mjs 会校验sourceCommit必须是完整的不可变 Git 提交并校验archify/package.json中的版本与release.skillVersion严格一致不一致直接抛错准备包内 README。然后依次运行三条命令node --test integrations/deepseek-harness/test/*.test.mjs node integrations/deepseek-harness/scripts/distribution-acceptance.mjs node integrations/deepseek-harness/scripts/pack.mjs --out /tmp/archify-dsh.tgz --json打包机制只认 Git HEAD 的 blob不认工作区这是该适配器打包设计中最关键的一点pack.mjs与release-source.mjs从当前适配器 Git HEAD 的 blob 读取打包输入而不是从工作区路径读取。release-source.mjs通过git ls-tree/git cat-file blob取文件内容并且只接受100644/100755普通文件拒绝符号链接与非常规 Git 文件对路径做跨文件系统可移植性检查NFC 规范化、大小写碰撞、Windows 保留名、非法字符防止同一打包结果在不同平台上解析不一致因此 README 的提醒顺理成章先 commit 再打包工作区未提交的改动不会进入包体。打包流程本身pack.mjs分四步stageAdapter把适配器文件从 HEAD blob 还原到临时目录→releaseSnapshotgit clone --shared --no-checkout后再checkout --detach sourceCommit得到不可变 Skill 快照→stageCleanSkill用规范的 clean-Skill 流程对快照做清理→npm pack产出.tgz并校验包内必须包含package.json、release.json、cordis.patch.yml、README.md、LICENSE、lib/index.js、skills/archify/SKILL.md。其中stageCleanSkill来自仓库根目录的 scripts/stage-clean-skill.mjs它的职责是只打包干净、可分发的最小 Skill输入来自git ls-files跟踪的文件排除package-lock.json、generate-brand-marks.mjs、generate-validators.mjs、test/目录、.hive、.workbuddy、node_modules及.validator-check-*片段打包前做读取前/读取后双快照校验含O_NOFOLLOW打开、inode/大小/mtime/ctime 比对防止打包期间文件被并发修改要求THIRD_PARTY_NOTICES.md与仓库根版本逐字节一致清理package.json中的scripts与devDependencies保证包内无生命周期脚本——这正是 README 安全清单中无 install/postinstall 脚本的落地手段。组合注入cordis patch 做了什么DSH 通过 Cordis patch 机制组合配置cordis.patch.yml 是 v0.2.0 包的核心- insert: - id: archify-skill-filesystem name: deepseek-ai/dsh-skill-filesystem config: providerName: archify-plugin includeDefaultRoots: false bundledSkillDir: !!js process.getBuiltinModule(node:path).join(...)它向 Profile 组合配置插入恰好一个archify-pluginProvider并刻意设置includeDefaultRoots: false——Skill 根目录只从已安装 npm 身份解析createRequire(baseUrl).resolve(tt-a1i/archify-dsh/package.json)绝不把路径拼接在baseUrl上也不混入 DSH 的默认 Skill 根目录。验收脚本compose阶段会严格断言原始skill-filesystem行未被替换、archify-pluginProvider 恰好一个、includeDefaultRoots false。验收流程在临时 Profile 里装真的 DSHdistribution-acceptance.mjs不是单元测试而是一次端到端真实验收README 明确了其环境要求Node 22用于规范化 ZIP 回归检查与 pnpm 10。流程概览pack运行pack.mjs并校验 receipt 的包名、版本、适配器提交、Skill 提交与 tarball 存在性tarball-inspect解包检查文件清单禁止出现test/、node_modules/、package-lock.json、.hive、.workbuddy、probe-skills、generate-brand-marks.mjs、generate-validators.mjs等并确认包含skills/archify/SKILL.mddsh-runtime-install用 pnpm 安装固定的真实 DSH 运行时deepseek-ai/dsh0.1.2-rc.1并通过--allow-build...显式白名单放行生命周期构建fail-closed网络瞬时故障由 transient-retry.mjs 针对ETIMEDOUT/ECONNRESET/EAI_AGAIN重试一次跨平台 CLI 兼容Windows 上的 pnpm、tar、npm shim由 resolve-cli.mjs 处理plugin-install / profile-identity / compose以 tarball 路径真实安装进临时 Profile校验包身份、组合配置skill-discovery / skill-load / resource-base通过 probe Skilltest/probe-skills.mjs轮询公开 Skill 注册表确认archify只能从archify-plugin被发现、完整定义可加载、资源根位于安装包内部package-smoke对安装好的 Skill 根运行 scripts/package-smoke.mjs 冒烟测试uninstall / base-profile执行dsh plugin remove并确认无残留zero-regression重新构建 ZIP与仓库根 archify.zip 做解包内容比对Linux 上还做规范化 ZIP 字节级比对并运行npx skills add --list --full-depth验证 Skill 清单。发布 CI 会在Linux、macOS、Windows三个平台各跑一遍上述流程。README 还规定只发布验收通过的 tarball 作为新版本并给对应适配器提交打archify-dsh-vversion标签tt-a1i/archify-dsh0.1.0及其archify-dsh-v0.1.0标签保持不变旧版本复现方式是先检出该标签重建已发布适配器时使用其标签与记录的 Skill 提交而非移动分支。待 v0.2.0 正式发布并公开验证后再把公开安装示例切换到0.2.0。小结tt-a1i/archify-dsh的价值在于把复杂架构图渲染压缩为一个可审计、可复现、无副作用的 DSH 插件交付物安装用精确版本、调用走普通 Skill 路径、升级靠逐 Profile 重装、卸载干净无残留而安全姿态通过无生命周期脚本 无网络 fail loud的代码与测试双重锁定。如果你需要在自己的 DSH 环境中稳定复现 Archify 的绘图能力建议按 README 的三条命令流程走一遍pack → acceptance → pack --json并始终以release.json记录的 Skill 提交作为发布事实来源。延伸阅读适配器本体 lib/index.js、组合补丁 cordis.patch.yml、打包脚本 scripts/pack.mjs、发布源 scripts/release-source.mjs、验收脚本 scripts/distribution-acceptance.mjs以及 clean-Skill 打包器 scripts/stage-clean-skill.mjs 与冒烟测试 scripts/package-smoke.mjs。【免费下载链接】archifyAgent skill for beautiful, verifiable architecture, workflow, sequence,>项目地址: https://gitcode.com/GitHub_Trending/arch/archify创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考