Back to home

ZTCNO0NE

dsh-loom

Loom (织机) — external coach / second verifier for DeepSeek Harness: silently evolves your agent's tools, skills, config and model, with deterministic verification and cold-apply.

Stars
0
Language
TypeScript
Created
Aug 16, 2026
Updated
Aug 16, 2026

Introduction

dsh-loom(Loom · 织机)

让正在运行的 agent 自己变强:工具、技能、配置、甚至模型,都由一个更上层的改进模型自动设计和安装,独立的核验器把关,执行器冷替换——全程不需要你写代码。

ZTCNO0NE/dsh-loom(对外品牌 Loom · 织机:把你的使用、纠正与失败"织"进 agent 的能力里)是 DeepSeek Harness 的插件。你可以把它理解为给你的 agent 配了一个"外部教练团队"

  • 监督员:一直看着你的 agent 怎么干活(快不快、错不错、卡没卡),判断"该不该改进";
  • 改进模型:当需要改进时,它看全量信息,设计出具体修改方案(加工具、改技能、调配置、换模型);
  • 核验器:把方案放进隔离环境真实跑一遍,和预期结果逐项核对,不通过就退回重做,绝不让模型自己给自己当裁判
  • 执行器:只负责安装和回滚,改错了自动还原;
  • 你的 agent:什么都不用改,只需要继续干活,然后发现自己越来越能干。

架构总览:外部教练团队

它能帮你的 agent 做到什么(30 秒看懂)

你遇到的情况插件会做什么
agent 连写文件都不会从零给它长出工具和技能,直到任务全过(0/3 → 5/5)
agent 缺某个能力自动补工具(文件读写、执行命令、搜索……)
agent 行为习惯不对(改完文件不验证)自动给它加"行为技能",下次主动验证
某个配置不合理(命令总被 500ms 超时杀掉)自动诊断并调整配置(改进模型自己选值)
模型不匹配 / 太慢 / 太贵自动换模型或重新调度;你说"节约成本"它就按省钱的方式调度
agent 空转/死循环监督员主动暂停它,再唤起改进
你说一句话要改运行时不需要 agent 自觉,监督员自动理解并唤起改进
改进过程会不会卡住对话可预约:后台静默跑完,完成时通知你"reload 后生效"
你说"给它加个 refine 能力"它自己设计并装上这个能力
你什么都不说,一直用越用越懂你,越用越贴合你的垂直方向
同一个错反复犯 / 旧能力退化自动修复并沉淀成免疫记忆,不再犯第二次
复杂任务某环节卡进度检测到"超预算 + 进度小"就主动唤起迭代进化
新领域不会 / 工具老报错自动补领域技能或补工具,错误率降下来
时延 / token / 成本超预算自动调度:换模型、限输出、减重试
要改 agent 自己的循环(loop)v1 锁定,后续版本放开(runtime/loop 层是进化方向之一)

它不是 dsh 极简模式

dsh 自带的"极简模式"(minimal agent preset)是出厂配置:预设只给两个工具、固定提示词、无压缩。极简模式(以及 dsh 任何预设)借助 dsh 的插件工具也能自己加装工具/技能——但那是"自己动手、自己判断":没有独立验证、没有外部回滚、没有跨会话沉淀。

dsh-loom 是运行中的治理回路:它把 dsh 的一切——工具、技能、配置、模型,甚至 Agent Loop / 运行时内核——都当作可替换的插件对象。谁观察、谁决定该改、谁验证、谁安装、改错谁兜底,都由治理回路决定。v1 出于安全先锁 loop 层,但这是策略开关,不是架构限制;把内核也当插件来换,正是后续要做深的方向。

维度极简模式dsh-loom
本质静态预设(配置态)动态进化回路(治理态)
加工具/技能能自己动手,但无独立验证/无外部兜底自动长出 + 隔离验证 + 失败回滚
内核 / Agent Loop架构上是插件,但没有"改它"的回路当作可替换插件(治理回路决定换不换;v1 先锁)
自己换模型能改配置,但无评估、无验证自动评估并安装(qwen3.6-27b → v4-flash → deepseek-chat)
一句话改运行时手动改配置自动消化并执行
跨会话成长技能/偏好/台账落盘,下次继续

极简模式 vs dsh-loom 对比

一句话:极简模式能加装手脚,但内核没有可插拔的治理回路;dsh-loom 把内核也当成可替换插件——什么时候换、换对了没有、换坏了怎么还原,都由治理回路决定。

一个完整的例子(读者视角)

你把一个本地 27B 模型接进 dsh,想让它帮你改代码。第一天它连"把内容写进文件"都做不到——不是模型笨,是它根本没有写文件的工具。

插件做了这些事,而你只做了一件事(继续用):

  1. 任务失败 → 监督员发现"连续失败" → 唤醒改进模型;
  2. 改进模型看完失败记录和配置,设计了一个"写文件"工具,还预测了它应该产生的运行轨迹;
  3. 核验器在隔离环境里真实验证:工具能加载、任务能完成、其他能力没被弄坏;
  4. 执行器在回合边界安装这个工具;
  5. 你的 agent 重试任务——成功了。

然后是第二个任务、第三个任务…… 工具一个个长出来,行为习惯(改完必须验证)也长出来。到最后,你甚至可以告诉它"模型太慢了,换一个"——它会自己去换,而不是等你手动改配置

案例库

案例 1:从零养大一个 agent

裸 agent(所有工具禁用)单独跑三个任务:写文件、列目录、编辑验证——0/3 全失败。插件介入后,改进模型逐级生成并安装:

  • fs-write / ls-dir / bash-run / file-read 四个工具;
  • edit-verify(编辑后必须验证)、json-verify(JSON 结构校验)两个行为技能;
  • 每一级都经过隔离真实执行 + 完整核验 + 安装,且旧能力回归不降。

结果:off 0/3 → on 5/5,同任务集严格对照 Δsuccess +3

npm run fromzero:all

案例 2:它自己决定换模型

你的 agent 被配置成 qwen/qwen3.6-27b,但路由到了根本不提供这个模型的官方 API——连"回复一句话"都失败。没有任何人提示它换模型,监督员唤醒改进模型后,它:

  1. 把默认模型改成 deepseek-v4-flash(第一次安装);
  2. 安装后监督员再次被唤醒,它继续迭代,把模型改成 deepseek-chat(第二次安装);
  3. 用最终配置重跑,正常回复。

两次修改的 before/after 都完整留档。模型太慢、太贵、想节约成本时同理——它会自己评估并重新调度。

npm run supervisor-swap-demo

案例 2:它自己决定换模型

案例 3:用户一句话,不需要 agent 自觉

你直接说:"bash 命令 sleep 1 总是 500ms 就被杀掉,把超时调大。"——没让 agent 调用任何特殊指令。插件自动消化这条消息,监督员唤醒改进模型,它把超时从 500ms 调到 10000ms,核验通过、安装生效。

这条路线的意义:即使你的 agent 完全不知道自己该求助,宿主也能兜底。

npm run runtime-request-demo

案例 4:一句话,它给自己装上 refine 能力

你对 agent 说:"遇到连续失败时,你要能自己发起一次复核和改进,别硬撑。"——它会把这句话变成自己的能力

  1. 改进模型理解需求后,生成一个"失败时主动请求改进"的行为技能(类似 prime-agent 的 refine 入口,但由 agent 自己长出来);
  2. 核验器在真实环境验证这个技能能被加载、指令有效;
  3. 执行器把它装进技能库;
  4. 之后 agent 在陌生任务上失败时,会主动发起改进请求,而不是硬撑或放弃。

为什么值得单独说:prime-agent 是当前自进化方向最具代表性的开源工程之一,核心就是 refine——任务失败时,actor 提出对自身 harness_state 的修改,宿主负责 apply 与回滚,第一次把"agent 改自己的运行状态"做成了可审计的工程协议。dsh-loom 的证明更小:这个入口不需要预置。两次独立复现产物一致:/tmp/refine-skill-demo.txt = refine-skill-ok

这是模拟,不是等价。初版技能的完善程度取决于底层模型能力与需求复杂度:模型强、需求清晰,一次安装就能接近 prime-agent 的体验;模型弱、需求模糊,则需要多轮回炉补齐。prime-agent 的优势在工程化协议——actor/validator 分工、宿主状态管理、长期迭代打磨;dsh-loom 目前只是在行为技能层复刻其入口语义。

但「长出来」与「预置好」有一个本质差别:预置方案的能力边界由设计者定义,长出来的能力由需求本身驱动。随着需求不断攀升——更多失败模式、更复杂的治理协议、loop 层契约——这套一句话长出来的 refine 会一步步逼近,最终有望与预置方案并驾齐驱。

npm run refine-skill-demo

留档说明:refine 演示当前为产物证据留档;脚本退出问题已修复,正式快照可随时低成本补跑。

案例 5:什么都不说,越用越懂你

你不需要发任何指令,只要正常用:写代码、改配置、跑命令。系统一直在记录你的使用模式和失败模式:

  • 连续失败 → 自动改进;
  • 你纠正过一次输出格式 → 之后同类任务自动按你的格式来;
  • 你的垂直领域用得越多(嵌入式 / 数据 / 前端……),技能库就越往那个方向长。

这是用出来的个性化:改进不是你说出来的,是它观察出来的。

偏好沉淀已实测闭环:你纠正"输出用纯文本、不要 markdown 代码块"后,监督员唤起 → 改进模型更新 system-prompt 并声明偏好 → 核验通过 → 应用落盘(preferences.json 2 条、ledger 2 条)→ headless 下 meta_growth 可见。留档 eval/run-records/preferences-demo.json

npm run preferences-demo

案例 6:你的垂直方向,长成你的专属技能库

用一段时间后,agent 的技能库会变成你的专属配置:编辑 JSON 必校验、发布前必跑回归、文件改完必报行数、遇到某类错误先查日志……这些不是手动装的,是改进模型从你的使用史里沉淀出来的。

每次进化都落盘(技能文件 + harness-state),下次启动继续生效——跨会话的成长

案例 7:复杂任务卡进度,它主动接手

一个多阶段任务,你的 agent 卡在某个环节:按预期这一步只需要一两次工具调用,它却来回试了十几步,耗时远超这个环节应有的预算,进度却几乎没动。继续硬跑只是在浪费你的时间。

插件不会等它自己认输:监督员按阶段预算和进度增量做判定(耗时超预算 × 系数、进度增量低于阈值、一段时间无实质进展),主动暂停当前回合,把"阶段预算、实际消耗、最近帧、停滞快照"打包交给改进模型;改进模型判断是补能力、换方案还是改参数,核验通过后安装。

这期间你可以继续做别的事——改进在后台完成,完成后通知你 reload 即可。

案例 8:同一个坑不会掉第二次

你的 agent 反复栽在同一个错误上:同样的工具、同样的错误码,连续几次都失败。监督员识别出重复失败模式后唤起改进模型;修好后,这个失败用例自动沉淀进回归集——之后每次进化都会先跑它。

这是"免疫记忆":能力只涨不跌,修过的坑不会再踩。

案例 9:换个领域也能上手

你的 agent 在熟悉的领域已经养成习惯(比如改完文件必验证)。遇到新领域任务(比如编辑 JSON),它沿用旧习惯只做了行数验证、没做结构校验——验证证据不足,任务判定失败。

监督员识别出泛化缺口:旧方法论覆盖不了新领域。改进模型补一个领域专用技能(JSON 结构校验),核验器验证真实可用后安装。之后新领域任务通过,旧领域行为也不退化。

npm run fromzero:all   # 含 L5 泛化:json-verify 技能

触发场景浓缩(S1–S8)

  • S1 反复失败、S2 进度不足、S8 泛化缺口已展开为案例 7–9;
  • S3 用户纠正:你纠正过一次 → 监督员理解意图,改进模型把纠正沉淀成偏好或技能;
  • S4 回归失败:旧能力退化 → 强制修复,能力只涨不跌;
  • S5 回合异常:回合超时 / 步骤超限 / 输出重复 / 无心跳 → 主动暂停,把现场打包交付给改进模型;
  • S6 资源异常:P95 时延 / token / 成本超预算 → 自动调度(换模型、限输出、减重试);
  • S7 能力不足:工具错误率高、反复重试、输出合规率低 → 自动补工具或调配置;

监督员触发场景 S1-S8 与免疫记忆

更多案例:同一条回路的不同切面

  • 免疫记忆:每次修好的失败都会自动沉淀成回归集——同一个坑,你的 agent 不会掉进去第二次;
  • 新项目 onboarding:第一天它不熟悉你的仓库约定,几天后它自动掌握测试习惯、提交规范、目录结构,像来了很久的老成员;
  • 技能包可导出、可分享:你的专属技能库是一个普通目录,能打包带走;另一个 agent 或同事导入后,直接获得同一套行为习惯;
  • 多 agent 团队:每个 agent 有自己的教练团队,但共享同一个垂直技能库——一个人学会的教训,全队都会;
  • 危机恢复:改坏了自动回滚,回滚之后还会复盘:这次为什么错、下次怎么避免;
  • 资源自适应:内存紧张、磁盘不足、时延超标时,自动调整超时、并发和缓存策略,而不是硬扛到崩;
  • 安全自适应:发现权限过宽会自动收紧(比如把写权限降级为只读);被拒绝的操作过多时会重新评估策略是否合理;
  • 团队规范沉淀:多个人的纠正("输出别带 markdown"、"先跑测试再说完成")会沉淀成团队的公共技能;
  • 插件自举:连 meta-validate 自己的治理规则,最终也由这套回路治理(v1 锁定,验证链路成熟后放开);
  • 可审计进化史:每次改动都有 before/after、理由、验证证据和回放命令——适合需要合规追溯的场景。

与 dsh 理念的契合

dsh 生态分层

dsh 的理念是"一切皆插件、结构层开放"。在这条链路上:

  • 工具 = 插件行,技能 = SKILL.md 文件,配置 = 插件配置——它们都是可进化的对象
  • 别人写插件,它自己长插件:未来新的工具模块、插件包、甚至 dsh 运行时配置,都可以由改进模型设计并安装(v1 从 config | tool | skill 开始);
  • 官方插件机制(bundle / insert)解决"怎么装";dsh-loom 解决"装什么、什么时候装、装错了怎么办";
  • plugin-registry 控制台是人工管理安装态;dsh-loom 是自动治理进化;
  • 静态 skills 目录靠手动维护;dsh-loom 让技能自动长出并带回归保护;
  • 同一条链路的下一站:运行时层(权限/超时/工具参数/会话配置)、loop 层(循环更换与升级,验证链路成熟后放开)、回归保护(每次进化旧能力不许退化)。

模型调度(太慢、太贵、节约成本时自动换或重新调度)只是这条链路上最早跑通的一个示例。

它和别人不一样

自指困境 vs 外部教练团队

  1. 判断权整体上移。多数自进化是"模型提议、模型评审、模型决定",终审还是模型自己;这里改进模型只负责提议,核验器独立判定,执行器负责安装——你的 agent 不参与对自己修改的最终判断
  2. 核验是确定性的。把方案放进隔离环境真实执行,预期轨迹和真实帧逐字段/哈希对齐(参考 Tycho),第一次分歧就退回重做;不用模型自评,不给模型当自己的裁判。
  3. 改错了能还原,验证链碰不到。所有修改都留 before/after 快照,安装失败自动回滚;核验器、回归集对 agent 只读;所有关键状态落盘文件(不信任上下文,因为压缩会丢、注意力会稀疏)。
  4. 越用越懂你。同样的回路既做"能力补齐"(工具/技能/配置/模型),也做"个性化沉淀"(纠正过的格式、你的领域习惯、你的垂直技能库)——改进不是一次性事件,是持续发生的。

与行业自进化方案的对照

行业方案对照

方案它做什么dsh-loom 的不同点
Tycho(ARC-AGI-3 满分)离线求解:世界模型仿真 vs 真实帧确定性验证借了帧对齐;但我们做的是运行中的 agent 治理
prime-agent预置 refine 协议:actor 提 harness_state 修改,宿主 apply/回滚不预置入口:一句话长出 refine 行为技能(模拟非等价)+ 独立 verifier 硬校验 + 回炉/台账
SAGE多 agent 协作,外部 verifier角色与 TCB 的物理隔离更彻底
CoEvoSkills技能共进化 + 确定性验证不止技能:工具/配置/模型 + 跨会话偏好沉淀
RQGM评估者本身也被进化安全分界:v1 verifier/loop 锁死,评估不可被进化
self-refine / LLM-judge 类同一模型内部自评判断权整体上移,不给模型当自己的裁判

工作原理(一分钟)

五步回路:观察 → 判断 → 设计 → 核验 → 安装

五步回路:观察 → 判断 → 设计 → 核验 → 安装。安装完成后监督员会再看一次,直到没有值得改的证据(多轮收敛)。

名词对照

文档术语读者视角职责
actor你的 agent干活的那个,只体验,不参与对自己的判断
监督员 / 唤起器教练团的"监工"只看关键摘要(模型/时延/错误率/停滞),决定是否唤醒改进
builder改进模型看全量信息,设计方案(加工具/改技能/调配置/换模型)
verifier核验器隔离真实执行 + 预期轨迹对齐,LLM 不进判定
gate执行器安装/回滚,agent 不可写

数据证据链

单元测试从零成长严格对照宿主闭环自主换模型用户消息自动唤起
101/101L1-L5 全过off 0/3 → on 3/3pass=trueqwen3.6-27b → v4-flash → deepseek-chat自动改 runtime 配置

严格同任务集对照 从零成长 L1-L5

其他可查记录:

  • 真实模型回炉:改进模型(V4 Flash)2 轮迭代后通过并安装;
  • 改进模型提交前会主动申请隔离试运行(probes[]),失败回传修改;
  • Terminal-Bench 2.1 官方 API 切片:fix-git PASS(1.0)(overfull 超时,基准阶段复测);
  • 成本记账:cost-log.jsonl,L1 样例改进模型 ~974 in / 4681 out;
  • 一句话 refine 复刻 prime-agent 核心语义:产物证据两次独立复现(/tmp/refine-skill-demo.txt = refine-skill-ok),留档 eval/run-records/refine-skill-demo.json
  • 偏好沉淀闭环:pass=true,偏好 2 条落盘、ledger 2 条、headless 下 meta_growth 可见,留档 eval/run-records/preferences-demo.json

快速开始

三步上手,不需要懂任何内部概念:

1. 安装

# 方式一:npm 包
dsh plugin --profile headless add dsh-loom@1.0.2

# 方式二:GitHub 仓库
dsh plugin --profile headless add "github:ZTCNO0NE/dsh-loom#main"

dsh --profile headless --dump-config   # 确认组合树

想从源码构建?npm install && npm run build,然后 dsh plugin add ./dsh-loom(或 tarball:dsh plugin add ./dsh-loom-1.0.2.tgz)。

2. 开一个开关(后台优化,不卡对话)

config:
  mode: apply
  scheduled: true
  notify:
    start: true
    progress: true
    completion: true

3. 正常用,然后问它

  • 什么都不用做:它失败多了、卡住了、或你纠正过它,它自己会变强;
  • 想知道进度:直接问它"优化进度怎么样?";
  • 优化完成:它告诉你"reload 后生效",重启/刷新会话即可用上。

改进模型 / 监督员默认走 DeepSeek V4 Flash(DEEPSEEK_API_KEY);你的 agent 可以接本地模型(示例 qwen3.6-27b)。换模型类案例需要目标模型在 agent 的路由上可用。

如果你也想亲眼看看「agent 自己长能力」是什么感觉,装一条命令就够了。从 0 开始的 agent,会像打一场自己的军备竞赛:从一无所有开始,先长出第一件工具,然后是技能、配置、模型,一步步武装自己,直到有一天换掉自己的内核、装上更聪明的 loop。

npm run try

已装 npm 包的用户(任何机器):

dsh-loom try

详细手册与常见问题见 docs/USAGE.md;更多案例:npm run fromzero:allnpm run supervisor-swap-demonpm run scheduled-notify-demo(都是真实模型跑通并留档)。

设计边界(诚实声明)

  • v1 只允许改 config | tool | skill,loop 层锁定(设计项,不是缺陷);
  • 核验器是准入门槛,上线后真实运行 + 观察才是最终裁判;
  • 验证成本 = 一轮完整任务 token,用最小回归集控制;
  • 行为类技能(如"编辑后必须验证")是"显著提高概率"而非确定性保证,验收用 2 次尝试兜底;
  • dsh v0.1 是 developer preview,接口会变;所有注入点收敛在 src/index.ts

相关参考