yu-xin-c/dsh-evolution-console

README 摘要

DSH Evolution Console 面向 DeepSeek Harness Creator 模式的自进化闭环插件：把一次运行时修改固化为不可变候选，在隔离的 Headless DSH 中做基线/候选对照评测，通过代码门禁后自动晋升，并保留可回滚的版本谱系。 Creator 负责提出和实现新的 Cordis Package；Evolution Console 负责版本化、评测、判定、部署和记忆。它不是一张“自进化”仪表盘，而是把修改前后真正接起来的执行闭环。 为什么需要它 DSH 的 Creator 模式已经可以在会话中创建、运行和热更新 Cordis Package，也就是修改当前 Agent 的 Runtime。但原始流程还缺少四件关键事情： 1. 修改前的能力没有被冻结成可重放基线。 2. 修改后通常靠一次人工体验判断好坏。 3. 失败版本、成功版本和评测证据没有形成长期谱系。 4. “新代码运行成功”与“新代码确实更好”没有被分开。 Evolution Console 在 Creator 与 Runtime 之间加入一个确定性的发布门禁： 闭环包含什么 一次完整循环包括： - 观察 ：直接读取当前会话的 dynamicCordisRunner ，列出 Creator 已定义的 Package。 - 固化 ：保存 Package 的 Host/Client 源码、父版本和 SHA-256 内容身份；同样内容得到同样候选 ID。 - 对照 ：Champion 与 Candidate 使用同一份冻结评测集、同一 Profile、相同运行次数。 - 隔离 ：每次尝试启动一个新的 Headless DSH 子进程、临时工作区和未压缩 JSONL Session Log。 - 测量 ：从真实轨迹中读取最终输出、工具调用、工具错误、步数、Token 和耗时。 - 判定 ：由 TypeScript 门禁判定，不让模型给自己打分。 - 行动 ：通过后自动热晋升，未开启自动晋升时标记为 eligible ，失败则拒绝。 - 记忆 ：候选、评测报告、事件和 Champion 历史保存在项目自己的 .dsh/evolution-console/ 。 - 恢复 ：上一代 Champion 可重新挂载，当前版本转为 rolled-back 。 它仍然保留一个有意的边界： 目标与候选可以由 Creator/Agent 产生，但验收规则必须由人预先写进 Benchmark 。否则 Agent 同时改实现和改考卷，并不构成可信进化。 晋升门禁 Candidate 只有同时满足以下条件才会通过： 条件 行为 总分严格大于 baseline + minImprovement 平分也拒绝 每个任务的通过率不低于基线 任一任务退化即拒绝 Candidate 尝试没有 Runtime/基…

分类