《DeepSeek Harness、忒修斯之船与 RSI 递归自进化》读记

来源：飞书文档（2026-08-16 更新），社区第三方深度分析，作者自述在开源当晚通宵使用 DSH 并贡献了插件。本页为提炼 + 与本 wiki 页面的交叉对照（对照为 wiki 整理，非原文内容）。

核心论点

作者用忒修斯之船的思想实验框定 DSH 要回答的问题：不是”换完所有零件还是不是原船”，而是延伸版——一艘不断替换自身零件的船，怎样平稳航行直至对岸？

未来 Agent 会长期运行，并在运行中持续改造自身 Harness（调整 Prompt、工具、记忆、沙箱、执行逻辑）；每次修改都发生在系统仍在工作时，失败必须能撤回恢复。
聚焦问题：当 Agent 的 Harness 在运行中不断迭代工具、记忆和执行模块时，系统怎样既不依赖整机重启，又不让迭代破坏其他组件的协作？
作者判断：DSH 的推出应理解为一次面向 RSI（Recursive Self-Improvement，递归自我改进） 的长期技术选择，而不是又一个 Coding Agent 或办公 Agent 产品。把它当成熟消费产品审视（UI 顺滑度、任务完成度）会”捡了芝麻丢了西瓜”。

官方定义与定位

Agent = Model + Harness（官方定义）。模型提供智能；Harness 负责准备上下文、暴露工具、保存状态、执行动作、管理权限、出错后组织恢复。
DSH 把模型适配器、System Prompt、上下文管理、工具、Session、持久化日志、Agent Loop、沙箱、审批策略、子 Agent、任务调度、交互界面全部拆成可重组的运行时组件（“插件”，类比乐高积木）。
“There is no privileged core to patch”——没有特权核心；产品形态在配置层自由组合。DSH 更像构造 Agent 的方法和平台，产品形态做了留白，留给社区组合。
大众产品把复杂性藏起来；DSH 主动把模型/工具/日志/沙箱/审批/循环/UI 之间的接缝暴露给开发者。

三大设计思路（原文结构）

一、一切皆插件

Cordis 是管理插件的运行时底座，不提供具体 Agent 能力，只提供运行时协议：能力注册到共享环境、依赖声明、加载撤销（见 cordis）。
配置树加载：dsh-base 基础层 → web/headless profile 叠加 → patch 替换任意配置行（见 architecture）。
同一套 Harness 可组合成 Claude Code 式编程助手、后台自动化执行器、pi 式四工具极简 agent、或接入 MCP/Skills/定时任务/多 Agent 工作流。
作者观点：模型与 Harness 是共同工作的系统——强模型可承载更多工具与更复杂循环，小模型适合”定位-修改-验证”短反馈链；DSH 让模型-Harness 适配成为显式可配置的工程问题。

二、每一次运行都有迹可循

Session 采用 append-only event log；模型下一步看到的上下文从事件流重新推导（见 session-model）。
凡是进入模型上下文的信息，都必须能够从日志中重建（即本 wiki 记录的 “model-visible means logged” 不变量）。
作者以此解释一个产品行为：DSH 不允许 Session 中途随意切换某些运行模式——因为工具历史必须可复现，否则 Session 失去可回溯性。

三、多种运行模式 Preset（本 wiki 此前未覆盖，值得注意）

Composer 顶部的模式选择器，每个模式是一份完整 Agent Preset（决定加载哪些插件、模型看到什么工具、用哪套 Prompt）——选模式 = 选这一轮 Agent 由什么组成。官方四种：

模式	内容	对应机制（wiki 对照）
标准模式	完整编程 Agent：文件编辑、Shell、检索、Skills、计划、目标、子 Agent、Workflow；同时是其他模式的基线	bundle/base 默认组合（见 monorepo、tool-system）
PTC 模式（Programmatic Tool Calling）	保留标准能力，改变工具组织方式：给模型一套 TypeScript SDK，把多步工具调用写进一段程序一次执行，只把有用结果送回上下文；理念类似 Claude 的 Dynamic Workflow	即 Code Mode：`run_code` + code-runtime，见 tool-system
极简模式	只留两个工具（持久终端 + 文本编辑器），System Prompt 一句话，不加载上下文压缩；用于 benchmark 减少 Harness 干扰、教学、极简工作流	对应 examples/jsonrpc-agent 式最小组合（bash + str_replace_editor）
创造模式	Agent 检查当前 Runtime、在内存试验 Cordis 插件、把插件+工具+Prompt 组合成新的 Agent Preset 并保存（如”只读代码不能修改的审查 Agent”）	即 dynamic plugin：`cordis_define/run` + `ctx.dynamicCordisRunner`，见 extension-development

作者评价：创造模式最暴露 DSH 的野心——它是”Agent 组装新 Agent”的入口。

解读框架：Lilian Weng 文章与 Cordis 论文

作者认为看懂 DSH 需要两篇文献（本 wiki 已整理前者，见 harness-engineering）：

Lilian Weng《Harness Engineering for Self-Improvement》

优化对象演化路线：指令提示词 → 结构化上下文 → 工作流 → Harness 代码 → 优化器代码。
Self-Improving Harness 闭环：发现弱点 → 提出有限修改 → 回归验证 → 接受或拒绝；失败方案只进日志不改活跃系统。
Harness Updating ≠ Harness Benefit：小模型也能写出结构合理的 Harness 改动，但能否从中受益仍依赖更强的模型能力（长程任务中及时调用新能力、遵守约束）。
三层可观测性（组件/经验/决策）——作者以此解释 DSH 为什么重视事件日志、组件结构和运行状态：Agent 若不清楚自己怎样失败，就无法可靠改进自己。
非参数化改进（改 Harness）与参数化改进（改权重）最终走向联合优化，归因随之变难——越深入越需要可靠轨迹、清晰组件边界、独立评估。
边界：Evaluator、权限控制、只读日志必须放在自我改进循环之外（对照 DSH：approval/sandbox 独立于模型可控表面、fail-closed，见 security-sandbox）。

论文《A Programming Paradigm for Spatiotemporal Composability》

作者把摘要浓缩为三个问题：

装上去时也要准备好怎样拆下来（Temporal Composability，时间可组合性）：组件的改变叫 Effect，每次上下文变换带运行时追踪的逆操作（Revertible Effects）；卸载时按记录完整撤销。
一个组件变化后，系统要知道还影响了谁（Spatial Composability，空间可组合性）：组件声明所需外部能力（Coeffect），环境变化时运行时按声明重算依赖、只处理受影响部分（Reactive Coeffects）。
系统不能被自己的维修历史拖垮（Confluence，合流性）：无论经历怎样的加载/卸载/失败/恢复路径，只要最终配置相同，系统必须回到稳定、可解释的状态——失败安装不留幽灵监听器、退出的服务不被继续引用、安装顺序不污染最终行为。论文用形式化规则与数学证明论证（依赖无环前提下不死锁、不停滞）。

作者对 DSH 的定位总结：DSH 无法判断哪次修改更聪明，也无法保证新工具一定更好，但它守住更基础的 baseline——旧能力可完整撤销、新依赖能重新连接、失败的更新不会摧毁负责恢复的系统。“DSH 的意义不在于解决了 Agent 自我改进的全部问题，而在于把一套可以管理持续变化的运行时机制，真正放进了 Agent Harness 里。“

两个令作者印象深刻的工程细节

Observability

LangSmith 式 Trace 以一次调用树为轴，适合执行路径稳定的 Chain/Workflow 时代。
Harness 时代的 Agent 会经历上下文压缩、子 Agent 分叉、后台进程、插件热替换、审批、跨会话恢复——一棵调用树表达不了。
DSH 把 Session 建在 append-only event log 上，Trajectory 视图按来源展开。作者金句：“Trace 关心一次调用经过了哪些节点；Event Log 关心一个 Agent 怎样随时间成为现在的样子。”
作者认为 DSH 在可观测性上的价值（把观测对象从模型请求推到 Agent 的连续状态演化）目前还没有被充分讨论。

Prompt Caching

作者体感：DSH 是其体验过的最快的 Agent Harness，TTFT 极短，长 Session 推进无明显迟滞。
原因：append-only 日志带来稳定前缀 + 插件化的工具/Prompt 配置易于识别不变部分 → 缓存命中率高（作者未做严格测试，为使用体感）。
（wiki 对照：system-prompt/tool-schema 组装与 request/header 快照机制见 session-model、architecture。）

结论与保留意见

DSH 仍是 developer preview，产品体验有大量待补齐；按成熟 Coding Agent 标准对比的失望”不难预料”（作者比喻：请意大利人吃夏威夷披萨）。
对 Harness 开发者：插件为核心元素、Session 为可重放事件流、工具编排进 Code Mode、副作用与依赖被 Runtime 显式管理——即使不作主力工具，拆开看也很有启发。
对 RSI：DSH 补上了关键的运行时基础，但只是一部分——怎样评估修改真的带来进步、怎样避免 reward hacking、怎样衡量长期收益、人类监督留在哪些位置，都没有完整答案。“现在就判断它会成为下一代 Agent 的标准底座，还太早。”
作者提出的下一代 Agent 核心问题：“一个 Agent 应该怎样持续存在？“——如何改变能力、保留修改历史、在改变中维持一致性、确保一次错误的进化不会成为终点。

附：作者的插件

dsh-record-replay（github.com/humblebanana/dsh-record-replay）：把 Open Record/Replay 接入 DSH，录制用户 macOS 桌面操作示范 → 保存会话与事件证据 → 校验后整理成 Skill Creator 可消费的输入包，面向长程 CUA 工作流的稳定复现与调试。

Wiki AI

目录