自进化引擎 Across2005/harness-self-evolution-plugin

Harness 自进化插件

一个 MoonBit 原生插件，用于扫描、监控、提议并验证 DeepSeek Harness（DSH）插件生态系统的进化。版本 3.2.3。MIT。

此插件面向 DeepSeek Harness。部署取决于 DSH 如何启动二进制文件、数据读写的位置，以及哪些文件（补丁、清单、面板）与二进制文件放在一起。

你的数据存放位置

DSH 通过 $DSH_HOME 解析其主目录（默认为 ~/.dsh；受管理的启动器可能将其指向其他位置）。插件与此保持一致：用户作用域的子代理定义存放在 /skills/ 下。完整的安装、验证和恢复指南： docs/deploy/deepseek-harness.md。

自 v3.0.0 起，该插件仅支持 DSH：此前声称兼容 MiniMax Code 属于过度声明（DSH 自身的源码中并无此类宿主概念），已被移除。

如果你是在编写或调试 DSH 插件，而非部署此插件，请阅读 docs/dsh-plugin-integration.md：宿主半部 / 客户端半部契约、Lazy-CJS 客户端打包规则（一个多余的顶层 export 会破坏组合中所有插件）、DSH_HOME 路由，以及“Failed to load plugins”的诊断顺序。

它的功能

- 扫描活动宿主在配置的扫描根目录下已安装的插件
- 监控调用延迟、成功率、token 用量、重试次数和用户反馈
- 识别强信号（用户覆盖、连续三次失败、延迟回归 > 20%）和中等信号（重复的参数误用、循环检测、重复的偏好）
- 提议由基准驱动的进化，并绑定到 Matt Pocock 工程原则
- 批准始终是人工步骤。auto_approve 默认为 false 并保持为 false —— 这是防止“代码把自己改到死胡同”的唯一关卡
- 执行采用状态机 pending → approved → executing → completed；在存在事务性沙箱适配器之前，真实执行保持故障关闭（fail-closed），而验证失败会将提议退回 pending
- 子代理工厂持久化 Markdown + YAML frontmatter 定义；作用域 plugin 位于插件的数据根目录下，作用域 user 位于 /skills/ 下（参见部署指南）

一段话概括架构

编译后的二进制文件（bin/harness-evolution.exe）是一个 stdio MCP 服务器，暴露十六个工具。DSH
主目录在 src/store/paths.mbt::dsh_home 中解析：设置 $DSH_HOME 时使用它，否则*从插件自身的
安装路径推导（/profiles//node_modules/...），再否则使用 ~/.dsh。用户作用域目录为 /skills（HARNESS_EVOLUTION_USER_DIR 可覆盖它），默认扫描根目录遵循同一
解析后的主目录（src/scanner/scanner.mbt::default_scan_roots）。自 v3.0.0 起，多宿主抽象已
移除 —— DSH 是唯一目标。

路径解析的细节参见 docs/code-architecture.md。

构建

.\build.ps1 -Task all # check + test + build；一条命令重新构建二进制文件

构建前置条件：MoonBit >=0.1.20260904，Linux/macOS 上的 MSVC 或 Clang。bin/harness-evolution.exe 中的当前二进制文件是 Windows 原生；在目标平台上重新构建会生成该平台的原生二进制文件。

完整的工作区门禁还会运行面板/监视器构建，以及一个不打开浏览器的隔离桌面共存冒烟测试：

$env:DSH_CLI = 'C:\\path\\to\\dsh-0.1.5-rc.2\\lib\\bin.js'
$env:DSH_REGRESSION_CLI = 'C:\\path\\to\\dsh-0.1.6-alpha.1\\lib\\bin.js'
node scripts/verify-workspace.mjs

数据与配置

当设置了 $HARNESS_EVOLUTION_HOME 时，插件会将提案、指标、信号、缓存和执行日志存储在该目录下；否则它会使用当前 DSH 树中的 /.harness-evolution/v2/（仅当无法解析出任何 DSH 树时，才回退到与宿主兼容的 ~/.dsh）。覆盖该环境变量可将开发/测试数据分开保存。

配置按以下顺序读取，第一个存在的文件生效：

1. $HARNESS_EVOLUTION_CONFIG（显式覆盖）
2. /.dsh-plugin/plugin.json（自清单）
3. .dsh-plugin/plugin.json（相对于插件根目录）

如果都不存在，插件会以内置默认值启动——缺少配置不会导致启动失败。

破坏性变更（未发布的 v2.7.0）：不再读取旧版的 /.zcode-plugin/plugin.json 回退路径。仍带有该文件的已部署实例必须将其重命名为 .dsh-plugin/plugin.json——内容无需更改。

安装到正确的树（DSH_HOME）

安装是按 DSH 树进行的：dsh plugin add 会写入 $DSH_HOME/profiles/，而 $DSH_HOME 决定启动哪棵树（默认为 ~/.dsh——受管理的启动器可能会将其指向别处）。各树之间不共享任何内容：bundles、node_modules、会话和技能都是按树隔离的，因此在一棵树中验证过的安装对启动另一棵树的宿主仍然不可见。

自 v3.1 起，随附的挂载行是 disabled: true 且不携带任何机器路径——某台机器上的字面路径在其他所有地方都指向一个不存在的文件，因此插件将根本无法挂载（DSH 会报告一行 warning 并继续启动：mcp-harness-evolution 不在宿主的 requiredStartupEntryIds 中，因此其激活失败是可选的）。该行是在安装时按树写入的：

解析 $DSH_HOME（或 ~/.dsh），安装 bundle，并将挂载行注入到该树的 profile 补丁层；添加 -DryRun 可先进行检查 pwsh -File scripts/install-dsh.ps1 -Profile web

然后进行静态验证（无需启动）
dsh --profile web --dump-config | Select-String 'mcp-harness-evolution'

dsh.profile.bundles 和补丁层是在启动时读取的，因此必须重启宿主，之后十六个 mcp__harness-evolution__ 工具才会出现在会话中。该插件还会推导其从安装路径拥有自己的树，因此即使 env.DSH_HOME 未设置，create_sub_agent scope=user 也会落在 /skills/ 中。

什么是真正致命的，什么不是。 挂载行上的 failOnStartupError: true 不会中止配置文件启动：它只会拒绝那一个插件的激活，而应用启动会将其降级为 optional 条目警告（见上文段落）。真正致命的情况是 DSH 无法解析的补丁层 —— parsePatchList 抛出异常，配置文件永远无法启动。scripts/install-dsh.ps1 会写入该文件，因此其输出由一个回归测试套件固定，该套件使用宿主自带的 js-yaml 来解析它：

pwsh -File scripts/test-install-dsh.ps1 # 7 个场景；仅写入临时树

完整的安装、验证和恢复指南：docs/deploy/deepseek-harness.md；实际安装实践（多 home 现实、.dsh-module-fallback 陷阱）： docs/dsh-compatibility.md。

许可证

MIT。参见 LICENSE。