dsh-loom（Loom · 织机）

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

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

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

它能帮你的 agent 做到什么（30 秒看懂）

它不是 dsh 极简模式

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

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

一句话：极简模式能加装手脚，但内核没有可插拔的治理回路；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

案例 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 能力不足：工具错误率高、反复重试、输出合规率低 → 自动补工具或调配置；

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

• 免疫记忆：每次修好的失败都会自动沉淀成回归集——同一个坑，你的 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 层（循环更换与升级，验证链路成熟后放开）、回归保护（每次进化旧能力不许退化）。

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

它和别人不一样

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

与行业自进化方案的对照

工作原理（一分钟）

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

名词对照

数据证据链

其他可查记录：

• 真实模型回炉：改进模型（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。

相关参考

• DeepSeek Harness
• Tycho（ARC-AGI-3）
• SAGE：多智能体自进化（arXiv 2603.15255）
• CoEvoSkills：技能自进化与共进化验证（arXiv 2604.01687）
• Red Queen Gödel Machine（arXiv 2606.26294）
• prime-agent
• 项目总览与验收细节