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) |
| 一句话改运行时 | 手动改配置 | 自动消化并执行 |
| 跨会话成长 | 无 | 技能/偏好/台账落盘,下次继续 |

一句话:极简模式能加装手脚,但内核没有可插拔的治理回路;dsh-loom 把内核也当成可替换插件——什么时候换、换对了没有、换坏了怎么还原,都由治理回路决定。
一个完整的例子(读者视角)
你把一个本地 27B 模型接进 dsh,想让它帮你改代码。第一天它连"把内容写进文件"都做不到——不是模型笨,是它根本没有写文件的工具。
插件做了这些事,而你只做了一件事(继续用):
- 任务失败 → 监督员发现"连续失败" → 唤醒改进模型;
- 改进模型看完失败记录和配置,设计了一个"写文件"工具,还预测了它应该产生的运行轨迹;
- 核验器在隔离环境里真实验证:工具能加载、任务能完成、其他能力没被弄坏;
- 执行器在回合边界安装这个工具;
- 你的 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——连"回复一句话"都失败。没有任何人提示它换模型,监督员唤醒改进模型后,它:
- 把默认模型改成
deepseek-v4-flash(第一次安装); - 安装后监督员再次被唤醒,它继续迭代,把模型改成
deepseek-chat(第二次安装); - 用最终配置重跑,正常回复。
两次修改的 before/after 都完整留档。模型太慢、太贵、想节约成本时同理——它会自己评估并重新调度。
npm run supervisor-swap-demo
案例 3:用户一句话,不需要 agent 自觉
你直接说:"bash 命令 sleep 1 总是 500ms 就被杀掉,把超时调大。"——没让 agent 调用任何特殊指令。插件自动消化这条消息,监督员唤醒改进模型,它把超时从 500ms 调到 10000ms,核验通过、安装生效。
这条路线的意义:即使你的 agent 完全不知道自己该求助,宿主也能兜底。
npm run runtime-request-demo
案例 4:一句话,它给自己装上 refine 能力
你对 agent 说:"遇到连续失败时,你要能自己发起一次复核和改进,别硬撑。"——它会把这句话变成自己的能力:
- 改进模型理解需求后,生成一个"失败时主动请求改进"的行为技能(类似 prime-agent 的 refine 入口,但由 agent 自己长出来);
- 核验器在真实环境验证这个技能能被加载、指令有效;
- 执行器把它装进技能库;
- 之后 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 能力不足:工具错误率高、反复重试、输出合规率低 → 自动补工具或调配置;
更多案例:同一条回路的不同切面
- 免疫记忆:每次修好的失败都会自动沉淀成回归集——同一个坑,你的 agent 不会掉进去第二次;
- 新项目 onboarding:第一天它不熟悉你的仓库约定,几天后它自动掌握测试习惯、提交规范、目录结构,像来了很久的老成员;
- 技能包可导出、可分享:你的专属技能库是一个普通目录,能打包带走;另一个 agent 或同事导入后,直接获得同一套行为习惯;
- 多 agent 团队:每个 agent 有自己的教练团队,但共享同一个垂直技能库——一个人学会的教训,全队都会;
- 危机恢复:改坏了自动回滚,回滚之后还会复盘:这次为什么错、下次怎么避免;
- 资源自适应:内存紧张、磁盘不足、时延超标时,自动调整超时、并发和缓存策略,而不是硬扛到崩;
- 安全自适应:发现权限过宽会自动收紧(比如把写权限降级为只读);被拒绝的操作过多时会重新评估策略是否合理;
- 团队规范沉淀:多个人的纠正("输出别带 markdown"、"先跑测试再说完成")会沉淀成团队的公共技能;
- 插件自举:连 meta-validate 自己的治理规则,最终也由这套回路治理(v1 锁定,验证链路成熟后放开);
- 可审计进化史:每次改动都有 before/after、理由、验证证据和回放命令——适合需要合规追溯的场景。
与 dsh 理念的契合

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

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

| 方案 | 它做什么 | 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/101 | L1-L5 全过 | off 0/3 → on 3/3 | pass=true | qwen3.6-27b → v4-flash → deepseek-chat | 自动改 runtime 配置 |

其他可查记录:
- 真实模型回炉:改进模型(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:all、npm run supervisor-swap-demo、npm run scheduled-notify-demo(都是真实模型跑通并留档)。
设计边界(诚实声明)
- v1 只允许改
config | tool | skill,loop 层锁定(设计项,不是缺陷); - 核验器是准入门槛,上线后真实运行 + 观察才是最终裁判;
- 验证成本 = 一轮完整任务 token,用最小回归集控制;
- 行为类技能(如"编辑后必须验证")是"显著提高概率"而非确定性保证,验收用 2 次尝试兜底;
- dsh v0.1 是 developer preview,接口会变;所有注入点收敛在
src/index.ts。