翁荔的这篇文章 从一个老问题切入：递归自我改进（RSI，Recursive Self-Improvement） ——系统用现有能力去改进「产生能力的机制」。在当下的工程语境里，这往往 不是 模型当场改写权重，而是改 训练管线、改 部署系统，让后继运行更强。翁荔把 部署系统 叫作 harness：从基座模型到真实任务之间的那一层，决定模型如何规划、如何调工具、如何读写上下文、如何把产物落盘、如何用 verifier（验收器） 判过不过。Claude Code、Codex 一类产品的价值，大量在这层，而不只在 base model 的 benchmark 分数上。
《DeepSeek Harness 架构解读》 已把 dsh 读成 Profile 叠 Bundle 的插件树、Session 日志作事实源、扩展旁挂 Cordis Service。《Cordis 论文导读》 则从 §1.2.2 说明：若 Agent 要 高频改自己的 harness 组件，装卸插件与依赖响应就不只是体验问题，而是服务能否连续、失败能否收回。《DeepSeek Harness 记忆解读：场域分层、参考架构与实现思路》 还提到社区里的 continual-evolve、memory-evolve：continual-evolve 主要做带版本号的 harness 资产（prompt、skill 等）；memory-evolve 主要做跨 session 的文件记忆。二者都不是 DGM 那种改整库源码的自我进化。
本文想要分享的是：按翁荔文中的 RSI 框架看 DeepSeek Harness——官方开放了哪些可改的配置与运行时能力，社区插件怎么在 dsh 上验改动、决定留还是撤，以及和 Self-Harness、AHE 论文里的完整流程相比还缺哪些环节。
RSI 在 harness 语境里指什么
翁荔文中的 harness 指包裹 base model 的部署系统：agent loop、tool 注册、Session 持久化、沙箱与审批、Skill 加载、子 agent 委派等。写一段 system prompt 只是其中一小块可编辑面（editable surface）；外面还有 workflow 怎么编排、插件怎么组合、验收脚本怎么写。
RSI 说的是一种闭环：用系统现有的能力，去改进「让系统变强」的那部分机制。近几年研究里，被改进的对象一直在往上挪——最早是人手改 prompt，后来是 playbook、skill 文件这类结构化 context，再往后是 workflow 图、harness 源码，甚至专门负责「怎么改 harness」的 optimizer 程序[1]。Self-Harness、AHE、Meta-Harness、DGM 都属于同一方向：让 harness 本身进入搜索或进化循环。它们之间的差别，在于改动的范围不同——有的只动 system prompt 里的一小段，有的改 skill 或 tool 描述，有的动整份 agent 实现；验收方式也不同——有单元测试、benchmark 通过率这类可自动判分的任务，也有只能靠人眼看结论是否站得住的设置，后者很难做成稳定的外环。
Anthropic 的长程 agent harness 讲的是另一件事：任务跨多个 context window 时，用 git、进度文件把状态写在磁盘上，新开窗口仍能读到这些记录，从上次停下的地方继续。翁荔这篇问的是 harness 怎么参与自我改进。dsh 的 Session 日志、工作区文件、subagent 与 jobs 在两种场景里都会用到，但解决的问题不一样。
会改 harness，不等于长程任务变强
Lin 等人[1] 用 updating 和 benefit 两个指标分开量：前者看模型或外层程序能不能提出像样的 harness 修改；后者看换上修改之后，长程任务的通过率或分数会不会真的上去。
| 维度 | 问的是什么 | 在 dsh 里大致对应 |
|---|---|---|
| updating（会不会改） | 能否提出有用的 harness 编辑——改 system 片段、写 skill、调 tool 描述、补 subagent 规格 | Creator 模式在内存里试 Cordis 插件；/evolve、evolve_* 工具改 prompt notes / skill；Profile patch 改组合 |
| benefit（改完有没有用） | 换上新 harness 后，长程任务的通过率/分数是否变好 | 取决于 base model 的 tool 跟随与长程稳定性；社区插件用 benchmark 做非退化验收，但没有官方统一 SLA |
Lin 等人[1] 在实验里看到：不同规模模型在 updating 上的差距可能不大，小模型也能写出结构像样的 skill 补丁；benefit 却不跟着涨，有时中间档模型反而提升最大。模型会改 harness 文案，不等于换上新 harness 后任务表现就会上去——进化过程里既要检查 patch 写得是否合理，也要在你要部署的那档模型上实测长程任务，后面这一步通常更费功夫。
哪些 harness 配置能改，Cordis 如何支撑
DeepSeek Harness 没有开箱的 Self-Harness 三步流程[1]：先在任务集上找出反复出现的失败模式，再在限定的文件范围内提案修改，最后在原失败集和其它题目上回归，两边都不退步才合并。官方提供的是一套方便做有界改动的运行时——组件可组合、可替换，改动在 Context 内尽量可撤销。这依托 Cordis 的可撤销注册（revertible effect，对应 ctx.effect() 与 dispose）和依赖声明后的重建（reactive coeffect，对应 inject）。论文 §1.2.2 谈的是这类 self-evolving harness 的共同需求；dsh 是 Cordis 上的应用之一，但论文里的规模案例是 Koishi，并没有把 dsh 写进实验章节。
在 dsh 里，常见能改动的层如下：
| 层级 | dsh 落点 | 改动的生效方式 | 边界 |
|---|---|---|---|
| Prompt / 指令片段 | system 模板、Creator 对话、continual-evolve 的 prompt notes | 注入或 patch；部分需重启 Profile | 社区插件常 冻结 不可变 base system，只改增量段 |
| Skill / 工作区规范 | ctx.skills、skill 工具、工作区 markdown | 文件落盘 + catalog inject | 应像发版，不要静默覆盖 |
| Tool / 插件 | ctx.tools、Cordis 插件行 | insert 插件可热更新；bundle 多层 patch 常需重启 host | tool-cordis 动态包仍主要在 进程内存 |
| 组合 / Profile | dsh.profile.bundles、cordis.patch.yml | 换 Bundle 顺序 = 换整套默认能力 | --dump-config 可观测实际加载树 |
| Agent loop 本身 | core/agent-loop 也是插件 | 可替换，但是 框架级变更 | 一般二次开发旁挂，不指望 Agent 自动改 loop 源码 |
Creator 模式（官方产品页与文档里的创造模式）主要解决 updating 的前半段：先看当前运行时里 loaded 了哪些插件，再在内存里试验新的 Cordis 插件、拼出新组合。这和 DGM 那种改整份 harness 源码不是同一粒度；内存里的 trial 要通过之后，若要长期保留，仍要落到工作区文件、npm 包或 Profile patch。
Session 不变量仍然成立：模型能看见的内容须写进 Session 日志。进化证据因此可以审计、可以 replay；反过来说，如果插件只在内存里改状态、不写日志，fork 和 compaction 会对不上。社区进化插件若承诺可回滚，需要说明回滚的是文件里的 harness 资产，还是进程里那次插件 trial。
社区插件：continual-evolve 与 evolver
DeepSeek 没有统一的 Evolution API。各家社区插件自己串起改 harness、在任务集上验收、决定留还是撤这几个步骤；改 prompt 还是改 tool、分数怎么算，实现各不相同。共同点是：哪些字段能改、怎么写盘、冲突和失败怎么处理，尽量写进代码，而不是写进 prompt 请模型自觉。
continual-evolve（[dsh-continual-evolve][4]，记忆篇 也提过）维护一份带版本的 harness 状态：prompt 备注、memory 条目、skill 文案、subagent 规格等按 kind 分开存。每次 refinement 会在 audit 里记下触发原因、改了什么、引用了哪段 session 轨迹、最后是采纳还是回滚。模型通过 evolve_* 工具或 /evolve 命令提案；插件侧做 schema 校验、原子写文件、乐观锁。回滚时按已经生效的编辑生成逆操作，不让模型再猜一遍该怎么改回去。benchmark 分数由插件代码自己聚合，模型不能自报；新旧 harness 对比时，任务集上不能退步才合并进全局状态——全局改动通常还要人点批准。一轮 turn 结束或 compaction 之后，还可以走自动 review gate。
和 Self-Harness 论文比，continual-evolve 已有 session 轨迹提炼、有界编辑（base system 不可动、rubric 做隔离）和回归验收；缺的是 Harness core 自带的失败 trace 聚类——哪类失败该优先修，多半靠插件自己的 planner 和 benchmark 集，而不是统一的 weakness mining 服务。
deepseek-harness-evolver（[deepseek-harness-evolver][5]）补的是 Creator 模式里内存 trial 怎么落盘。Creator 可以在进程里试 Cordis 插件；evolver 提供 evolve_stage、evolve_validate、evolve_score、evolve_solidify 等工具，把 trial 从内存写到工作区，必要时用 evolve_mount 经 ctx.plugin 挂进当前进程。它主要从最近 tool 调用的 signal 里判断该改哪个 tool 插件，不碰 continual-evolve 那套跨 session 的 prompt/skill 状态机。两条线可以同时装：continual-evolve 负责长期 harness 资产和 benchmark gate；evolver 负责「这次内存试验能不能固化成持久插件」。都不替换 ctx.subagents 或官方 workflow tool。
memory-evolve（[dsh-memory-evolve][6]）又是另一回事：跨 session 的文件记忆、待办、确认后再注入，记忆篇里归在 L5 文件轨。它改善 Write/Read 治理，不覆盖 prompt notes、benchmark 验收或插件 mount。谈 harness RSI 时不要和 continual-evolve 混成一个产品名。
相对 Self-Harness 与 AHE，还缺什么
翁荔文里 Self-Harness[1] 的三步，在 Harness 官方和典型社区插件上是这样对齐的。
第一步 weakness mining（挖弱点）：用当前 harness 在任务集上做 eval，把失败 trace（执行轨迹）聚类成带 verifier 依据的失败模式。第二步 bounded proposal（有界提案）：只在人事先划定的可编辑面里改，上下文里写清能改哪些文件、哪些已通过的行为必须保留、以前改过什么。第三步 proposal validation（验收合并）：每个候选 patch 在原失败集（held-in）和其它题目（held-out）上都不能退步，才 merge 进线上 harness。Harness core 里没有这套统一 orchestrator；continual-evolve 用自有的 benchmark store 和 gate 接近第三步，第一步仍依赖外部任务集和插件自己的逻辑。
AHE[1] 强调另一块：rollout 失败时，要能指出是 prompt、tool 描述还是 middleware 出了问题。在 dsh 里，Session JSONL、tool 结果、插件注入段可以对齐一部分信息，但没有官方的三维 harness 观测模型，也没有自动归因 API。排障仍靠 dsh --profile web --dump-config、读日志、读社区插件写的 audit 文件。
DGM 那种整库进化——让 coding agent 改自己依赖的 harness 源码——通常要 fork 主仓或在外部 monorepo 做 eval，dsh plugin add 覆盖不到。翁荔也写到：验收如果又快又清楚（单元测试、通过率），外环才转得动；验收如果很慢，或只能靠人眼判「像不像科学」，候选 patch 很难自动筛出优劣。
权限设计仍在 loop 之外：若允许 Agent 改 verifier、换模型、改 reasoning budget，抽象边界就被破坏了[1]。dsh 的沙箱与审批链在 tool 执行层；benchmark 和 verifier 多半还在插件或 CI 里，不在 Turn 状态机内。
Harness 算不算「支持 RSI」
更准确的说法是：DeepSeek Harness 在 Cordis 上提供了可组合的运行时、Creator 试验面、Profile/Bundle 组合层，以及 Session 审计约束；社区插件（尤其 continual-evolve）在此基础上做了有版本、可回滚、带 benchmark 的改动验收。安装 dsh 并不等于自带 Self-Harness 或 AHE 的论文复现，也不等于改模型权重意义上的 RSI。
做二次开发前，最好先弄清几件事：改的是 prompt、skill、tool 还是 Profile 哪一层；改动是靠 insert 插件热更新，还是要重启 bundle 才生效；验收靠插件内置 benchmark，还是人工读 trajectory；回滚针对的是磁盘上的 harness 状态，还是某次进程内 trial。这几件事清楚，再选社区插件或自研 gate，比先贴「自我进化」标签省事。
可组合和可审计也有成本：同一 dsh web，换 home 或 patch 可能是另一套工具集；进化插件叠得多了，要防止 L5/L4 重复 inject 占满窗口。好处是同一 CLI 可以叠不同 Profile，在不改 agent-loop 源码的前提下试验 harness 补丁；坏处是 benefit 那一侧仍要自己在目标模型和任务集上测，社区 benchmark 的数字不能当成对外 SLA。
DeepSeek Harness 仍在 developer preview，接口可能 breaking；社区插件 compatibility 以各仓库为准。
收尾
系列前几篇分别讲过 Turn/Session 主干、Cordis 时空可组合、多 Agent 原语、记忆参考架构。本篇补 RSI 与 harness 进化这一维：翁荔文的主线是改部署层而不只追权重；dsh 官方侧是可替换插件树、Session 日志作事实源、Creator 供内存试验；社区 continual-evolve 则把 prompt/skill 等 harness 资产版本化，并用代码里的 benchmark 做验收。和 Self-Harness、AHE 相比，core 里还没有统一的 weakness mining、官方 Evolution API，以及生产环境级的 eval 契约。
若你从架构篇刚读完，建议顺序仍是架构、Cordis、多 Agent、记忆，再到本篇。动手前可 dsh --profile web --dump-config 看清本机插件树，再读目标进化插件的 design doc 与 benchmark 说明。
参考资料
[1] 翁荔. Harness Engineering for Self-Improvement（Lil'Log, 2026-07）。lilianweng.github.io/posts/2026-07-04-harness/
[2] Yifan Shi, Wei Zhang, Tianyi Cui. A Programming Paradigm for Spatiotemporal Composability（Cordis 论文，2026）。github.com/cordiverse/paper
[3] DeepSeek Harness（github.com/deepseek-ai/deepseek-harness）。
[4] dsh-continual-evolve（github.com/ZK-Andy/dsh-continual-evolve）。
[5] deepseek-harness-evolver（github.com/shinjiyu/deepseek-harness-evolver）。
[6] dsh-memory-evolve（github.com/csyangwen/dsh-memory-evolve）。
