前言¶

在 DeepSeek Harness（DSH）这类“一切皆插件”的智能体环境中，单个插件能安装，只说明它进入了运行时；多个插件能否围绕同一目标协同修改、验证、生效和恢复，是另一个问题。

dsh-loom（Loom / 织机）是面向 DeepSeek Harness 的 second-validator 插件。它提供一条可验证的演进控制面：Actor 专注当前任务，Builder 在隔离环境中实现和测试，Verifier/Gate 负责裁决候选是否能整体生效。

这是什么¶

dsh-loom 由 ZTCNO0NE 维护，许可证为 MIT。它被描述为一个静默的外部教练，可以从使用历史中编织 agent 的 tools、skills、config，甚至 model，并提供 deterministic verification 与 cold-apply。

已核实的能力包括：

• Actor 自然语言 Plan/Execute 与持久任务卡（Verified）
• Config/新 Skill 隔离实现与独立裁决（Verified）
• Builder 只读方向诊断（Verified）
• 自然语言插件委托（v1.3.0 Preview）
• 最多三个插件联合源码演进（v1.3.0 Preview）
• 确定性插件生命周期（v1.3.0 Preview）
• package-aware 原子激活/恢复（v1.3.0 Preview）
• 通用插件安装、更新、移除与恢复（v1.3 Preview · Verified E2E）
• 多插件源码协同与原子 Profile 激活（v1.3 Preview · Verified E2E）

版本边界需要注意：v1.3.0 Preview 已发布自然语言插件委托、最多三个插件联合源码演进、确定性插件生命周期与 package-aware 原子激活/恢复。首发插件事务只在可识别的 DSH 源码 checkout 中启用真实 cold Loader；普通全局 CLI 安装继续提供 v1.2 Config/Skill 能力，但不会假装插件事务 ready。复杂 Loop 更换仍是 Research。

核心机制¶

dsh-loom 把演进过程拆成几类职责，避免 Builder 自己实现、自己验收、自己放行。

1、Actor 负责当前任务上下文：解析目标、提出候选、解释风险，并保留可查询的任务卡状态。

2、Builder 负责隔离实现与测试。它可以探索和实现，但不能选择 live 目标、扩展事务范围或放行自己。

3、Verifier 读取冻结候选，不接受 Builder 临时改写的验收规则。

4、Gate 是唯一安装与恢复权限持有者。

在这些边界内，dsh-loom、DSH、凭据、Verifier/Gate 始终不属于普通演进目标。它明确不做：

• 自动 npm publish
• 无来源修改
• Builder 自批
• 自改 Loom/Verifier/Gate
• 用单 patch Gate 假装组合原子

安装与启用¶

前提：DeepSeek Harness 已能运行；Node ^22.19 或 >=24；Python >=3.10。

1、先配置凭据。可以在 DSH Settings/Models 或 $DSH_HOME/.credentials.yaml 配置 DEEPSEEK_API_KEY。Builder 默认复用这份凭据，不需要把 key 发进对话。

2、安装 dsh-loom 1.3.0：

pnpm dsh plugin --profile web add dsh-loom@1.3.0

3、检查 DSH 配置中是否出现 Loom 相关校验入口：

pnpm dsh web --dump-config

输出中应包含 meta-validate。

4、安装隔离实现 runtime。

Windows PowerShell：

$env:DSH_META_VALIDATE_ROOT = "$env:USERPROFILE\.dsh\meta-validate"
$runtimeRoot = Join-Path $env:USERPROFILE ".dsh\meta-validate\runtime\mini-swe-agent-2.4.6"

powershell -ExecutionPolicy Bypass `
  -File "$env:USERPROFILE\.dsh\profiles\web\node_modules\dsh-loom\bin\setup-windows.ps1" `
  --runtime-root $runtimeRoot

node "$env:USERPROFILE\.dsh\profiles\web\node_modules\dsh-loom\bin\dsh-loom.mjs" start --profile web --runtime-root $runtimeRoot

macOS / Linux：

export DSH_META_VALIDATE_ROOT="$HOME/.dsh/meta-validate"
runtime_root="$HOME/.dsh/meta-validate/runtime/mini-swe-agent-2.4.6"

sh "$HOME/.dsh/profiles/web/node_modules/dsh-loom/bin/setup-unix.sh" \
  --runtime-root "$runtime_root"

node "$HOME/.dsh/profiles/web/node_modules/dsh-loom/bin/dsh-loom.mjs" \
  start --profile web --runtime-root "$runtime_root"

5、保持 Web 进程运行，打开：

http://localhost:3080

典型用法¶

下面是一些来自已核实示例的自然语言请求，可用于观察 Plan、隔离实现、裁决和恢复链路。

单插件或 Config/Skill 类请求：

给我加一个发布前检查配置的技能，先展示计划，不要直接安装。

确认执行后，流程为：后台隔离实现 → Verifier/Gate 裁决 → 返回已生效或未生效。

查询演进状态：

演进进度怎么样？

查看当前插件：

列出当前插件

多插件协同演进示例：

把 dsh-cost 的统计增加模型维度，先给计划

让 cost 与 notify 联动，组合验收后再整体生效

恢复上一插件组合

多插件任务还需要宿主预先配置独立 integrationCommand。Actor 不会让 Builder 自己发明验收。

适用场景与注意¶

适合：

• 需要让 DSH 中的 Config、新 Skill 变更保持可计划、可验证、可查询的开发者；
• 需要让多个插件围绕同一目标进行联合源码演进、组合验收、原子激活和恢复的团队；
• 希望把 Builder、Verifier、Gate 的职责分开，避免实现者自行放行的 DSH 插件开发者。

注意：

• dsh-loom 以当前 dsh 进程权限运行，安装前应检查源码、依赖与 MIT 许可证；
• DEEPSEEK_API_KEY 应放在 DSH 凭据配置或 $DSH_HOME/.credentials.yaml 中，不要写进对话；
• v1.3.0 Preview 的插件事务能力依赖 DSH 源码 checkout 与 dsh-loom start 路径；
• 普通全局 CLI 安装只提供 v1.2 Config/Skill 能力，不意味着完整插件事务 ready；
• 多插件任务需要宿主配置 integrationCommand；
• 复杂 Loop 更换仍是 Research，不能把 Preview 能力外推到任意复杂重构必然成功；
• 不要依赖它自动执行 npm publish，也不应允许 Builder 自批或自改 Loom/Verifier/Gate。

链接¶

仓库：https://github.com/ZTCNO0NE/dsh-loom

许可证：MIT