DeepSeek Harness 接入

DT Verify 以 DSH 资源 Bundle 交付：同一份产品 Skill、JavaScript CLI、验证插件（含修复阶段）和 Python 运行资源，配一个挂载随包 Skill 的加载器。主流程由 DSH 当前会话读取 Skill 后执行，业务判定仍由原有 CLI 与领域插件负责。组件不另起模型循环，不需要新增 HTTP 服务。

此接法依据《DSH 组件化接入指南》v0.9 第 5.3、5.5、7.9 节和附录 C.3。DSH 兼容基线为 0.2.1-rc.2：包清单的 engines.dsh 与宿主 peer 写范围 ^0.2.1-rc.2（团队插件市场的要求），DSH 安装和启动时按 engines.dsh 检查兼容，不满足的运行时会跳过本 Bundle。实际验证只在 0.2.1-rc.2 上做过，范围内的其他版本需要重新验证。组件版本取源码仓库 package.json.version，随包版本和摘要见 package.json、manifest.json。

范围与前置

• 交付入口为 dt-verify Skill，包含输入整理、候选计划、统一审查、插件执行与汇总；修复须由调用者明确要求。
• DSH 提供模型、会话、Skill 注册表、Skill 调用工具、文件读取与 shell 执行能力。选择带有这些能力的标准 preset，并按本机策略授权访问目标工程、需求来源和输出目录。加载本 Bundle 不会自动授予权限或配置模型。
• Node.js 满足 ^22.22.0 || ^24.0.0 || >=26.0.0；DSH 原生安装命令还需要 PATH 上可用的 pnpm。
• Harmony UT/UI 的 SDK、JDK、Hvigor、ohpm、HDC 和设备按原插件要求准备。UI 执行直接启动 Python 进程（只在 macOS 验收），需要 Python ≥ 3.11，并按插件说明准备 Hypium 6.1.0.210 与 xdevice。将 DT_VERIFY_PYTHON 设为实际解释器绝对路径，并让 DSH 启动进程继承它。换成 DSH 不会消除这些依赖。
• 包内注册 4 个子 Agent 角色：dtv_ut_feature_writer（UT 按功能组编写测试）、dtv_ui_page_writer（UI 按页编写脚本）、dtv_ut_sub_fixer 与 dtv_ui_sub_fixer（修复工作项）。每个角色是一个 DSH preset，persona 即角色说明，只含 instructions、时间上下文、bash/pwsh、fs、fs-search 与上下文压缩，不含委派、web 与 skill；宿主根另挂委派工具 dtv_subagent，父 Agent 用 agent_preset 选这些角色。它们会出现在 Agent preset 列表末尾（名称以“DT 子任务”开头），只用于委派，不要选它们新建会话。DSH 的 subagent.maxDepth 默认为 1，子 Agent 不能再派子 Agent；若计划阶段本身在子 Agent 中运行，再派发会被拒绝，插件按 Skill 改为逐组、逐页顺序处理。
• SKILL_ROOT 位于 Profile 的 node_modules 下，不在工作区内。主会话与子 Agent 都要能读取该目录并用 Node 执行其中的 scripts/dt-verify.mjs；按本机权限策略授权，不把资源复制进工作区。
• 本地打包、配置加载与真实模型/设备调用是不同验证层级。不得用资源可见、离线测试或旧 Codex 结果声明 DSH 的业务验收已通过。

从源码构建

在 harmony-verify 仓库根执行：

npm ci
npm run build:deepseek
npm pack ./dist/deepseek --pack-destination ./dist --ignore-scripts

也可用 npm run pack:deepseek 连续完成构建和打包。npm run build 仍默认生成 Codex 包。DeepSeek 包位于：

dist/deepseek/
├── package.json
├── manifest.json
├── index.js
├── cordis.patch.yml
├── README.md
├── locale/
└── assets/skills/dt-verify/
    ├── SKILL.md
    ├── scripts/dt-verify.mjs
    ├── inputs/
    ├── references/
    ├── contracts/
    ├── providers/
    ├── plugins/
    └── component.json

npm pack 输出的 dt-verify-deepseek-<版本>.tgz 就是发布到 npm 的同一个包，也可直接内部分发。接收者不需要源码仓库或开发依赖；仍需兼容的 DSH 和实际执行环境。包以 UNLICENSED 发布到 npmjs（publishConfig 固定 registry 与 next 标签），并收录在团队插件市场。包内没有开发 Skill、仓库 AGENTS、测试、用例真值或评测器。

安装到 DeepSeek Harness

以下命令适用于 macOS/Linux shell。先使用团队已经安装的匹配运行时，确认 dsh --version 为 0.2.1-rc.2，并确认 pnpm --version 成功。也可使用固定版本 npx --yes @deepseek-ai/[email protected] 替代下面每次出现的 dsh；整套操作保持相同的运行时和 DSH_HOME。

最简单的方式是在 DSH「插件 → 发现」中添加团队索引源 https://fuxi-ailabs.github.io/dsh-plugin-market/index.json，找到“DT 验证组件”后安装。也可以直接用 npm 包名安装（版本写实际发布的版本）：

dsh plugin --profile web add --save-exact dt-verify-deepseek@<版本>

本机 npm 默认 registry 是不同步或延迟同步的镜像时，在 Profile 目录的 .npmrc 或用户 ~/.npmrc 中把 registry 指向 https://registry.npmjs.org/。

验证本地构建的 tarball 时，建议使用独立目录和新的 Profile，避免影响已有会话。将 tarball 路径改为实际生成的文件：

export DSH_HOME="/absolute/dt-verify-dsh/home"
export DSH_AGENTS_HOME="/absolute/dt-verify-dsh/agents"
export DSH_TOOLS_MODE=native
mkdir -p "$DSH_HOME" "$DSH_AGENTS_HOME" "/absolute/dt-verify-dsh/workspace"

# 仅在首次创建这个 Profile 时执行；已有 Profile 不重复使用此参数。
dsh --profile dt-verify-check --from-default-profile web --dump-config

dsh plugin --profile dt-verify-check add "/absolute/dt-verify-deepseek-<版本>.tgz"
dsh --profile dt-verify-check --dump-config
dsh --profile dt-verify-check --no-open

--profile 必须放在 add 之前。已有业务 Profile 可以直接安装，但安装、检查和启动要使用同一个 Profile 名称；不要重新执行创建命令。Desktop 使用其内置插件入口或对应安装提供的命令，普通 npm CLI 不能管理 Desktop 保留的 Profile。

安装会把包加入 Profile 的依赖和 dsh.profile.bundles。Bundle patch 插入 dt-verify.skills 实例；加载器以自己的 import.meta.url 解析 assets/skills，注册 dt-verify-bundled-skills provider，关闭该实例的默认目录扫描。无需复制资源到 .dsh/skills，也不要再扫描同一资源副本。若其他 provider 也提供名为 dt-verify 的 Skill，先消除重复或确认选择的来源。

首次安装可能需要从 registry 下载 DSH peer；仅有 tarball 不代表完全离线可安装。没有全局 DSH 时，固定版本 npx 也需要能获取运行时。不要以 latest 替代固定版本后沿用本兼容结论。

维护者可在仓库内用一条命令在新的独立目录复验安装与加载（不调用模型）：

npm run verify:deepseek -- \
  --tarball "$PWD/dist/dt-verify-deepseek-<版本>.tgz" \
  --dsh-root /absolute/deepseek-harness-runtime

--dsh-root 指向含 node_modules/@deepseek-ai/dsh 的运行时目录。它创建新 Profile，执行原生安装与 --dump-config，再用 DSH 官方加载链（loadProfile、createRuntimeResolution、PluginPackages、SkillRegistry）发现并读取 Skill 与相对资源，运行包内 CLI 的成功和失败调用，检查释放后 Skill 注销；再以 --patch 插入只读探针、--port 0 启动真实宿主，核对每个子 Agent 角色 preset 激活无诊断、dtv_subagent 已注册且可选角色正确，以及 Web 启停；结果写到 artifacts/tests/deepseek/validation.json，不记录凭据或启动 URL。它不代替会话内的模型调用与业务验收。

打开终端输出的完整 Web URL，在界面中明确选择工作区。确认模型 provider、模型与凭据可用，选择带文件/shell/Skill 工具的标准 preset，再新建会话。凭据按 DSH 的模型设置管理，不写入组件包或日志；启动 URL 可能携带认证信息，不用于共享验收记录。

在会话中调用

先验证 Skill 正文、相对引用和 CLI，而非只看列表：

请加载 dt-verify Skill，报告实际加载路径。
按它的路径约定读取 references/plan-review.md，概括审查要求。
用 shell 执行同一 Skill 内 scripts/dt-verify.mjs 的 prepare --help，报告真实退出码和输出。
如果 Skill、文件或命令不可用，直接说明，不推断成功。

插件会派子 Agent 时，再在同一会话确认角色可选、子 Agent 能读到 Skill 资源：

用 dtv_subagent 工具、agent_preset 为 dtv_ut_feature_writer 派一个子 Agent，
把 dt-verify 的 SKILL_ROOT 绝对路径交给它，让它读取 SKILL_ROOT/plugins/harmony-unit/plan.md
并原样返回第一行，同时说明自己的角色说明开头一句。
等待完成通知后报告子 Agent 的原始返回；工具不可用、被拒绝或读取失败时直接说明。

正常使用只需提供目标工程和需求来源：

使用 dt-verify 验证工程 /absolute/harmony-project。
Spec 在 /absolute/spec；Android 行为基线在 /absolute/android-project。
按 Skill 完成计划、审查、执行和汇总，返回结果文件与证据位置。
缺少环境或依据的要求保留未验证，不缩小验收范围。

非迁移场景省略 Android。只做计划时明确指定“截至正式计划接受，后续由宿主接管”；需要修复时明确授权修复范围。调用者不需要预先编写内部 request.json 或分配验收 ID。

CLI 最小调用约定：

# SKILL_ROOT 取 DSH 实际加载的 SKILL.md 所在目录，不能假设等于当前工作目录。
node "$SKILL_ROOT/scripts/dt-verify.mjs" prepare \
  --target /absolute/harmony-project \
  --spec /absolute/spec

迁移增加 --android。成功阶段将结构化 JSON 写到 stdout，并返回下一阶段入口和产物位置；输入错误返回非零退出码，stderr 包含 error.code 与 error.message。命令返回 0 只表示该阶段完成，不等于全部验收通过。执行状态 PASS/FAIL/BLOCKED 与验收结论 SATISFIED/VIOLATED/UNVERIFIED 分开，最终以汇总文件及原始证据为准。

常见失败验收：在新运行中提供不存在的 Spec 路径，确认真实 CLI 返回非零退出码及错误消息，DSH 如实报告失败且不产生验收通过结论。随后使用有效路径创建新的运行，验证正常调用可以继续。完整宿主验收还需从认可的需求来源跑通一个成功业务场景和一个失败场景；UT/UI 声明须有对应真实 SDK/设备证据。

写入、长任务与恢复

读取来源并冻结快照；workflow、测试和证据按 Skill/插件规定写入，生产修改必须符合请求授权。每轮与每次 attempt 保持独立身份，失败记录不覆盖。重复 prepare 默认分配新运行目录；不要用安装器或重新打包覆盖业务工作区。

编译、设备执行和多步规划可能耗时。终止应通过 DSH 会话停止能力与实际 shell 进程控制完成，并检查构建/设备/Python 子进程、资源锁和写入是否已结束。组件不提供新增的后台任务服务，也不承诺 DSH 停止会话即完成全部进程清理；这需要在目标宿主单独验收。中断后保留已有证据，根据最后成功阶段核对状态，不把部分输出当成通过。

升级使用新版本 tarball，安装后重启 DSH 并核对实际加载版本。回退时用保留的上一版 tarball 重新安装并重启；这只回退组件包，不回退业务代码、设备状态或已有 workflow。仓库的 npm run release -- --install/--rollback 当前管理 Codex 项目安装，DeepSeek Bundle 使用 DSH 原生插件管理器。

验收边界

按指南保留 L01 共用实现、L02 调用约定、L03 薄适配、L04 安装使用、L05 实际验证五项。本组件的写入、多步执行、长调用、插件/子进程和子 Agent 委派涉及 E02、E03、E05、E06；Harmony UI 依赖 hdc 与设备，E01 按实际选择的验证插件确认。离线打包、替身加载和 verify:deepseek 只证明安装与加载层级。会话内的模型调用、子 Agent 委派、成功/失败业务场景、取消与设备行为未执行时必须写“未验证”，不能声明组件化完成。