vlln/evo-engineering

evo-engineering

让 agent 把任意产物——文档、代码、skill、提示词——一轮轮改得更好：先定「怎样算更好」，
再自动跑「改进 → 独立评审 → 按冠军线选优」，而人随时能看、能喊停、能回滚。
（DeepSeek Harness 插件；同时含一份跨 harness 的 evo skill）

这是什么

把「自进化 / 递归自我改进（RSI）」当成一个动词用：对某个产物说「进化它」，剩下的交给一个固定回合协议——

元层（你 + 当前会话）：定标准 → 看结果 → 随时介入
任务层（子代理）：propose → act（隔离实现）→ critique（独立评审）→ select（冠军线）→ regress → commit

三层一起交付，协议不绑死在某一个 harness 上：

| 层 | 形态 | 谁能用 |
|---|---|---|
| 便携手册 | skills/evo/（SKILL.md + references） | 任何 agent harness——复制进你的 skill 目录，agent 按手册用你自己的子代理/文件/git 跑协议 |
| 确定性引擎 | workflow/evo-round.mjs | 任何带官方 workflow 引擎的 dsh 会话（把脚本喂给 workflow 工具） |
| 插件 | /evo 命令 + evo_init / evo_round / evo_status / evo_rollback | dsh 用户（自动记账、每圈 git 打点、可回滚） |

为什么需要它

你现在的做法大概是这样：让 agent 改一版，读一遍，觉得"好像好点了"，再让它改一版……
到第 5 轮时你已经说不清哪版最好、为什么好，也退不回第 3 版；换个会话重来，结论还会变。
如果有两个人（或两个模型）各改一版，你只能凭印象挑。

这个插件把这几件事交给流程：标准写成文件（evals/criteria.md）、候选各自隔离实现
（actor 互不可见，避免抄答案）、独立评审打分（critic 互不可见、必须给证据）、按冠军线选优
（新版本必须严格超过上一任冠军才被采纳）、每圈一个 git 检查点（随时回滚）。

它不解决什么：

- 标准模糊到语言也判不了时，仍然要人裁定——critic 分歧时会主动停下来问你（这是设计，不是故障）。
- 分数只是代理指标：所以还有"回归账本"（每圈重跑上一任冠军必须保持的行为），挡住"分涨了但把旧东西弄坏"。
- 它不替你决定"什么值得进化"，也不保证一定变得更好——变化不够大时它会选择不改。

与相邻方案的区别：

| 方案 | 谁发起 | 你要做什么 |
|---|---|---|
| 手工反复让 agent 改 | 你，每一轮 | 每轮自己判断好坏、自己记着哪版最好 |
| dsh-loop（定时循环） | 你设定间隔，模型自调节 | 决定"多久跑一次"；循环本身不评估产物好坏 |
| dsh-inspect（检查→修复→复查） | 你要求检查/修复 | 一次闭环：找问题、修、复查；不做多轮选优与历史冠军线 |
| evo-engineering | 你说「进化它」 | 定一次标准，然后每圈看结果、必要时介入 |

安装

1) dsh 插件：

dsh plugin --profile web add "github:vlln/evo-engineering#main"   # 装
dsh plugin --profile web remove @vlln/evo-engineering              # 卸载

装完重启 web（bundle 在启动时组层栈）。仓库是零构建的（入口直接是 src/index.mjs），
git 源安装不触发构建。

（改源码要立刻试的本地开发安装见 docs/engineering-notes.md——
它需要先把官方 SDK 链进 clone 的 node_modules，否则 profile 起不来。）

插件跑在官方 workflow 引擎上（服务名 workflowEngine，官方基础组合自带）。本插件不静态
依赖它：缺该服务的组合里插件照常启动，只有调用工具时才报一条可操作的错误，而不是拖垮整个
profile 启动。

2) evo skill（可选，跨 harness 都能用）：SKILL.md 是通用规范，落位方式是放进 skill 发现路径。

让当前 DSH_HOME 认得它（用户级）
mkdir -p "$DSH_HOME/skills"
ln -s "$DSH_HOME/profiles/web/node_modules/@vlln/evo-engineering/skills/evo" "$DSH_HOME/skills/evo"

或只在某个项目里生效（项目级，二选一）
ln -s "$PWD/skills/evo" /.agents/skills/evo

（发现路径：项目 /.dsh/skills、/.agents/skills；用户 $DSH_HOME/skills、
~/.agents/skills。其他 harness 用自己的等价目录即可。）

用起来是什么样

/evo init README.md        # 建工作区：目标快照进 baseline/，生成标准与回归探针占位
然后和用户对标准（这是唯一必须由人做的事）：编辑 /evals/criteria.md
/evo round                 # 跑一回合：提 2 案 → 隔离实现 → 每案 2 个独立评审 → 选优 → 回归 → 记账+打点
/evo status                # 回合数 / 当前 champion / 最近一轮
/evo round "把开头换成个人经历"   # 由你（元层）指定提议，跳过 brainstorm
/evo rollback              # 不满意？回滚到最近检查点

一回合结束后你会拿到这样的报告（真实运行输出，节选）：

outcomes (sorted by mean score)
- runs/1/candidate-1  score 8.8  [1 verdicts, 1 accept / 0 reject]
- runs/1/candidate-2  score 6.3  [2 verdicts, 0 accept / 0 reject]

selection
- selected: runs/1/candidate-1  score 8.8 (> champion 0)
- needsHuman: true (4 regression concern(s) from critics)

regression probes
- [PASS] fact-check — 逐条核对 baseline 的事实主张，无相反陈述
- [PASS] smoke — 候选目录内 README.md 与 CHANGELOG.md 存在且非空

下一回合如果挑战者只拿到 8.5（高于阈值、无 reject，但没超过冠军 8.8），它会拒绝采纳、
champion 不变——这就是"宁可不动"的那一帧。评审的判分与理由落在
runs//candidate-/verdict-.json，每圈记在 ledger.md，git tag 可回滚。

能力面

命令

| 命令 | 说明 |
|---|---|
| /evo init  [workspace] | 建工作区：快照目标到 baseline/、生成 evals/ 与 ledger.md、git init |
| /evo round [数量 \| "提议文本"] | 跑一回合；带引号的文本 = 由你指定的提议 |
| /evo status | 回合数 / 当前 champion / 最近一轮 |
| /evo rollback [round] | 回滚到检查点（缺省最近一圈） |
| /evo help | 用法 |

工具

| 工具 | 说明 |
|---|---|
| evo_init | 建工作区（可指定 workspace、overwrite、标准起草提示） |
| evo_round | 跑一回合，参数见下；跑完自动写 ledger + 打 git 检查点 |
| evo_status | 读 ledger，报告冠军与回合历史 |
| evo_rollback | 恢复工作区到某圈（只恢复工作区子树，不动宿主仓库其余部分） |

Skills

| Skill | 作用 |
|---|---|
| evo | 跨 harness 的进化协议手册：工作区布局、六阶段回合协议、critic 判分与模糊标准、防退化三件套、递归阶梯（L1 产物 → L2 标准 → L3 协议 → L4 能力）与各层人类门禁 |

参数

evo_round 的常用参数（完整表见 workflow/evo-round.mjs 的 ROUND_ARGS_DOC）：

| 参数 | 默认 | 作用 |
|---|---|---|
| proposals | 无 | 由你指定改进提议（给了就不自动 brainstorm） |
| own_proposals | 2 | 自动提议的子代理数（每个独立上下文） |
| actors | 2 | 并行实现的子代理数（actor 之间互相隔离） |
| critics | 2 | 每个候选的独立评审数（判分与证据落盘） |
| threshold | 7 | 入选所需的最低均分（0–10） |
| note | 无 | 本回合备注，写进 ledger |

工作区里由你维护的两个文件：evals/criteria.md（怎样算更好——每条尽量写成可观察的表现）、
evals/regression.md（上一任冠军必须保持的行为——每圈重跑，任一失败即不采纳）。

已知限制

- 需要 profile 提供 workflow 引擎（官方基础组合自带）；没有它时工具会明确报错。
- actor 的工作目录未受限：子代理按自身 cwd 解析路径，当前靠"回合后把产物吸收进 runs/N/"
补救——根治需要 DSH 侧支持 per-agent cwd。
- 分数差小的时候别当真：引擎不知道评估噪声有多大，几十分之一的差可能只是抖动；
噪声与真实差异同量级时，演化会退化成随机游走且看起来完全正常（见
docs/known-issues.md §3）。
- 模糊标准下 needsHuman 会经常出现：critic 分歧即升级给人，这是刻意的代价交换。
- 成本 = 每圈 P×C 个子代理：默认 2×2；预算参数有上限，但请按目标规模调整。
- 只作用于指定工作区内的产物：不扫描、不修改工作区之外的文件。

插件管理

已装插件用 plugin-registry 的薄控制台管理（浏览器面板）：管理 profile 插件安装态
（bundle 层栈 + insert 行 + 启停），无需手改配置。安装：
dsh plugin --profile web add /packages/plugin/console

许可

MIT

工程备忘（真实运行验证证据、六个下线 bug 的复盘与最小复现、架构取舍、测试与门禁）：
docs/engineering-notes.md ·
docs/design.md ·
docs/known-issues.md ·
CHANGELOG.md