用Agent造Agent：DeepSeek Harness的64天考古与自进化路径

网上已经有不少技术博主在拆 DSH 的架构图，把它和 Claude Code、Codex CLI 并列比较，论证这套「一切皆插件」机制的优雅和影响力——这些分析有它们的道理，我也认同 DSH 的设计水准。但我想看的不是它长什么样，而是另一个更工程化的问题：这样一个被 DeepSeek 视为战略级产品的 agent harness，是怎么在 64 天里被造出来的？

答案写在仓库的 commit 历史里。从 6 月 10 日第一条提交到 8 月 13 日公开发布，64 天，12293 次提交，日均 192 次。这不是人类节奏，是 AI 辅助开发在版本控制系统里留下的沉积物。我用 git 考古翻了一遍这个仓库，反推一件更底层的事：顶级团队是怎么用 Agent 造出最强 Agent 的。事实上，Anthropic 的 Claude Code 团队和 OpenAI 的 Codex 团队大概率也是这么干的——只是他们的开发过程不公开。这次 DSH 把整个仓库开源，给了我们一个可以近距离观察顶级 AI 团队研发范式的窗口。这是我写这篇文章的起点。

三天前我写林俊旸把 20 亿估值押给 Agent，结论是他选了一条「模型 + 环境」的工程路线。文章里我反复引用 Lilian Weng 的判断：Claude Code、Codex 之所以强，不是因为底模最强，而是 Harness 设计最成熟。那篇文章发出去之后我一直在想一个更具体的问题：harness 到底长什么样？

8 月 13 日，DeepSeek 给了一个可以拆解的样本。他们把内部那个叫 DeepSeek Harness（dsh）的 agent 运行时开源了，MIT 协议，221 个 npm 包。和它同步发布的还有 DeepSeek-V4-Pro 正式版，以及一篇 80 多页的论文《A Programming Paradigm for Spatiotemporal Composability》。

但真正值得拆解的不只是产品，是它的构建过程。从 6 月 10 日第一条提交到 8 月 13 日公开发布，64 天，12293 次提交，日均 192 次。这不是人类节奏，更像 AI 辅助开发在版本控制系统里留下的地层切片。我用 git 考古翻了一遍这个仓库，想反推一件事：一个被 DeepSeek 当成战略级产品的 agent harness，是怎么在两个月里长出来的——以及更关键的，它本身是怎么被 agent 造出来的。

下面这些数据，全部来自 GitHub REST API、npm registry 时间戳、仓库 commit 历史和官方文档。能确证的标确证，推断的标推断——尤其是「DSH 主要靠 AI 生成代码」这个判断，我会用证据链支撑，但读者应将其视为基于多源信号的合理推测，而非已证事实。

一、64 天 12293 次提交：推断「主要架构由 Codex 协助生成」

先把数字摆出来。

关于数据来源：12293 这个数字来自 GitHub REST API 的 GET /repos/{owner}/{repo}/commits?per_page=100 全量拉取，按 committer.date 排序去重；含 merge commit 和 bot commit，但已剔除 revert。npm 时间戳来自 npm view <pkg> time --json。日均 192 = 12293 / 64，向下取整。下文里所有具体数字都按这个口径来，碰到「这是 AI 写的」类判断会标「推测」。

日均 192 次提交是什么概念？把它折算到头部贡献者身上：tianyicui（崔添翼）5235 次 ÷ 64 天 = 日均 81.8 次；LegGasai 1361 次 = 日均 21.3 次；imccyu 1297 次 = 日均 20.3 次。仅 tianyicui 一人就达到日均 80+ 次 commit。传统软件工程里，即便是最高产的内核子系统维护者，单人也很难持续保持这种节奏——Linux 内核 maintainer 通常日均 5-15 次 commit。DSH 只有 19 个贡献者，前三人占 64.2% 的提交，这种集中度叠加这种频率，完全靠人写代码很难自洽。

我的推断是全团队重度依赖 AI 辅助开发。以下证据写在仓库里，请把它当作「高度相关 + 多源信号」支撑的合理推测，不是已证事实：

• 首提交（b67e81a）的标题就是「Initialize repo with README, AGENTS.md, and CLAUDE.md symlink」——项目第一天就建立了 Claude Code 和 agent 协议的入口文件。一个还在搭脚手架的项目，把 agent 入口放在 README 旁边，是「自己就要用」的姿态，不是「未来考虑用」。
• 6 月 13 日建立 .claude/ 目录，装着 ADR（架构决策记录）和 review skill。ADR 这种制度在第 4 天就建立，几乎只有「按既定 SOP 启动」能解释。
• 6 月 30 日 commit 8adcbce 把 Claude Code 和 Codex 正式作为 subagent 桥接进开发流程。这一天是工程化落地的关键节点。
• 分支命名随处可见 codex/ 前缀（codex/trim-ai-prose、codex/2503-english-onboarding-copy）——codex/ 前缀本身就是 OpenAI Codex CLI 的默认分支命名约定。
• commit message 普遍是多行 body，详细解释 alternatives 和 trade-off——这是 AI 辅助代码审查的特征，人类工程师通常写一行主旨就够。

也得说清楚这个判断的边界。以上证据可以解释为「重度使用 Codex 当 subagent」，也可以解释为「重度使用 Claude Code，把 Codex 当辅助 hook」，甚至「团队工程文化本身就要求这种 commit message 格式」。仅凭 commit 历史，目前切不清 AI 写多少、人写多少。

所以我倾向于这样概括：DSH 的主要架构大概率由 Codex 协助生成，但「人写了多少、AI 写了多少」目前还切不清楚。后面会沿着这个判断继续走——DSH 的构建过程本身就是个值得拆的样本：团队在用 agent 造 agent，Weng 7 月那篇讲的是模型层和工程层的 RSI，DSH 给的是工程团队层的一个实例。

二、Git 考古：反推构建哲学

把 64 天的 commit 历史按时间拆开，能看出五个阶段，但真正值得提炼的不是流水账，是几个反常理的构建判断。

核心架构在第二周就定完了。6 月 10 日首提交只有 48 行文档，但 6 月 13 日就落地 capability seams（能力接缝）设计，6 月 14 日 RFC 012 Code Mode，6 月 15 日出现 split/agent-factory、split/session-persistence-sqlite 这种成熟分支。一个 48 行的仓库不可能在 4 天内长出 RFC 级别的架构讨论——更像是 DeepSeek 内部已有原型，6 月 10 日是「开源预备仓」启动日。真正值得记的不是这个，是核心抽象在项目第二周就定完，后面 50 多天没有大的架构反复。

测试基建和功能开发是同步走的。7 月中旬引入 Python SDK（pytest.ini），7 月 23 日做 tsconfig 重构把 Host/Client 类型聚合分离，7 月 27 日把 .tsx 纳入 lint 体系。8 月 4 日出现 7 个 vitest 配置文件——单元 / e2e / snapshot / web / stress / perf / shared，CI 硬门是 packages/*/*/src 每文件 100% 覆盖率。这不像事后补测试，更像是测试门和功能开发一开始就是配对的。

主入口在开源前 9 天才定下来。8 月 4 日移除 TUI 包（10bb9cb），8 月 12 日才让 Web UI 成为主入口（04fe477）。这有点激进——团队在 release 前还在权衡产品形态，不是按既定剧本走完。

8 月 13 日看起来是策划过的大爆炸。npm registry 时间戳清楚记录了这一天：UTC 09:50 协议从 BSD-3-Clause 切到 MIT，主版本号 0.0.1 → 0.1.0；11:17 发 rc.3；12:29 把 publishConfig.access 从 restricted 切到 public，正式公开。12 小时内发了 4 个版本，中间还插了 self-modification UI、cordis 4.0.1 vendor、landlock-run 0.1.1、Cordis paper 上传。同一天 DeepSeek-V4-Pro 正式版发布，用 DSH 的 Minimal mode 跑 Terminal-Bench 2.1 拿到 87.9 分。模型和测模型的工具同步开源，构成完整叙事。北京时间 20:30 的官方公告时刻，恰好就是 UTC 12:29 的 npm 公开时刻——不太可能是巧合。

三、造 DSH 的人：崔添翼、Shigma 与 bus factor

贡献者排名按 commit 数：崔添翼（tianyicui）5235 次占 42.6%，LegGasai 1361 次，imccyu 1297 次，之后是 Chinesezjc、turtle1999、hypatiamay 等。前三名占 64.2%，前五名占 73.7%。

这里需要区分两种 bus factor：

• 代码所有权 bus factor = 3：三人贡献 64.2% 的 commit；top 5 占 73.7%；剩余 14 人占 26.3%。
• 发布权 bus factor = 2：npm 发布权只有两人——imccyu（cc.yu@deepseek.com）和 tianyicui-deepseek（tianyi@deepseek.com）。npm view deepseek-harness 的 maintainers 字段可以直接验证。

如果把"是否能持续发版本"作为判据，实际 bus factor = 2；如果把"是否有人能 hold 住代码语义"作为判据，实际 bus factor = 1-2（tianyicui 单人 42.6%）。这两个数字比单纯说"bus factor = 1-2"更精准。

崔添翼的背景值得拆。他 GitHub ID 是 53024，2009 年左右注册的老账号。公开资料显示他浙大背景，ACM-ICPC 亚洲区金牌六次（CCPC/ICPC 公开成绩榜可查，2010-2015 区间），《背包问题九讲》作者，在 Jane Street 做了近 9 年量化交易，TSY Capital 联合创始人。他的 GitHub 仓库 tianyicui/pfds-ocaml 是 Okasaki《Purely Functional Data Structures》的 OCaml 实现——函数式数据结构功底扎实。综合 suntzurecruit 报道 与其 LinkedIn 公开档案，他 2026 年 3 月加入 DeepSeek，5 月组建 Harness 团队。单一信源已被 LinkedIn 工作经历交叉验证。

量化交易的底色是微秒级并发、两边系统精确对齐、编排错就亏钱。harness 工程的形状差不多——模型生成、harness 验证/压缩/执行，编排错 agent 就崩。崔添翼不是研究员转工程，是系统工程师转 harness，这能解释 DSH 为什么工程严谨度上很扎实。

另一个关键人物是 Shigma（shigma），Cordis 框架的作者，Koishi 的创始人。Koishi 是一个跨平台聊天机器人框架，基于 Cordis 构建，已经运行 4 年，积累了 4000 多个社区插件。DSH 本质上是把一套在聊天机器人场景验证了 4 年的插件框架，迁移到 agent harness 场景。论文第三作者 Wei Zhang 是北大副教授，贡献者里还有 pku-xht，用户名暗示北大背景。这是一次北大 + DeepSeek + 开源社区老兵的协同。

一个容易被忽视的细节：DSH 仓库是 open source, closed contribution 模式。DeepSeek 目前不接收外部 PR，社区只能通过 Discussions 和 plugin 仓库参与。2521 个 PR、19 个贡献者，PR 几乎全是内部 review 流程产物。这能保证早期质量，但 4000+ 插件规模的 Koishi 生态是开放贡献长出来的，DSH 要达到类似规模必须逐步放开。

四、一切皆插件：消除特权核心

DSH 的架构文档（docs/architecture.md）开宗明义：

Every part of the product is a plugin, including the model adapter, the tool registry, the session log, and the agent loop itself, so every part is replaceable from configuration. There is no privileged core to patch.

这句话是整个项目的纲领。早期版本的传统 agent 框架（LangChain、AutoGPT、LangGraph 早期）的架构是「不可变内核 + 预留扩展点」——核心循环写死，开发者只能在框架规定的位置插入工具和 prompt。新一代框架（Claude Code 的 skill + subagent 体系、Codex CLI 的 hooks、OpenHands 的 runtime）已经在向「一切皆可替换」演进，但完全做到「agent loop 本身也是插件」的只有 DSH——连 agent loop（主循环）本身都是可替换的 Cordis 插件。

这等于把「框架核心不可变」这条行业惯例翻了过来。Linux 内核的哲学是「机制而非策略」——内核只提供机制，策略由用户态决定。DSH 走得更远：连机制本身都是插件。

可替换性的根基是 capability seam（能力接缝）。一个 seam 必须有三个角色：Service Definition（声明接口）、Service Provider（实现）、Consumer（使用）。AGENTS.md 里有一条硬规则：one role alone is not a seam。半个能力不算能力。这堵住了「半个能力」导致的 if/else 分支——传统框架里最常见的复杂度来源就是有接口没实现、有实现没消费者这种半成品状态。DSH 用架构规则把这种情况排除掉。

这个设计的好处是组合的位移能力很强。filesystem 和 subprocess provider 共享一个执行世界，把它们指向远程沙箱，Bash、PTY、LSP 全跟着移动，不用改 provider。Subagent provider 同理——从新建一个子 agent，到在另一个产品里委派一个 turn，只是换个 provider。

DSH 还有一个强不变量：Model-visible ⟺ logged——任何到达模型请求的内容必须能从 session log 重建，运行时有断言强制。Session log 是 append-only 的 SessionEvent 流，deriveMessages() 从日志投影模型历史。新增模型可见输入必须新增一个 session event，否则断言失败。「模型看到了什么」这个问题在 DSH 里只有一个答案：日志里有什么。没有「隐式注入但没记录」这种灰色地带。这是消除边界情况优于增加条件判断的体现。

五、Cordis 的可逆效应：为什么 self-modification 不会崩

DSH 的「一切皆插件」不是口号，它依赖一个能支撑运行时热插拔的底层框架——Cordis。DSH 没有通过 npm 依赖 Cordis，而是源码内嵌到 vendor/ 目录，全部重命名到 @deepseek-ai scope。vendor/README.md 记录了 17 项本地修改。内嵌是为了完全拥有框架层——可审计、可 patch、可 pin 版本。

Cordis 的设计思想写在《A Programming Paradigm for Spatiotemporal Composability》里，作者是 Shigma（Yifan Shi）、Wei Zhang（北大）、Tianyi Cui（崔添翼）。论文识别了动态组合的两个正交维度：时间可组合性（组件移除时能完全撤销其副作用）和空间可组合性（能声明并响应式管理组件间依赖）。

论文指出现有插件系统的通病：插件插上去拔不下来。VSCode Marketplace 前 100 扩展中 87 个含可执行代码，激活后无法运行时单独卸载，禁用或删除需要重启整个扩展宿主。这是「时间可组合性」缺失的直接后果——卸载时没有逆函数可执行，残留的 listener、定时器、状态污染会破坏系统。

Cordis 的解法是把可逆性变成运行时强制不变量。每个对 context 的修改都必须配一个显式逆函数。ctx.effect() / ctx.on() 返回 disposer，Fiber 收集所有 disposer，卸载时逆序 unwind。AGENTS.md 里写得明白：every contribution goes through ctx.effect() / ctx.on(); a registry’s register() returns the disposer。这不是约定，是架构规则。

self-modification 没有可逆性就是空中楼阁。agent 在运行时挂载一个新工具，如果卸载时不能精确撤销所有副作用——listener 残留、定时器还在跑、状态污染没清——跑几次就崩。Cordis 的可逆效应是让 self-modification 能成立的前提。这也是为什么 DeepSeek 要自己造 harness 而不是用别人的——市面上几乎没有一个把可逆性做成运行时不变量。也是崔添翼拉 Shigma 入伙、8 月 13 日把论文和产品一起发的原因。

17 项 vendor 修改不是均匀分布，可以按改动归类。完整归类见下表（数据来自 git -C vendor/ log --oneline，按 vendor/README.md 的分类结构梳理）：

5 项生命周期改动是关键信号。其中 3 项重入 disposal 漏洞修复（effect owner-list 注册时序、async cleanup 可见性、UNLOADING 态拒绝 effect 创建）实质性地强化了 Cordis 的并发模型。agent harness 对插件热重载的可靠性要求，远高于聊天机器人。Koishi 场景下插件挂载后基本不动，DSH 场景下插件要在 agent 运行时频繁挂载卸载，并发和重入是真实问题。DSH 团队为此在 Cordis 内核做了实质性并发加固，而不是简单复用。这些 patch 能否回流上游、长期分叉风险，值得持续关注。

六、Self-Modification：用 agent 造 agent 的工程原型

现在到 DSH 最具前瞻性的特性。位置在 packages/extensions/，commit 4064198，设计笔记在 .agents/notes/implemented/feature/2026-07-08-self-referential-cordis-toolset.md。

本质：让 agent 在运行时检查并修改自己运行的 plugin runtime。这是论文「自进化」目标在产品层的落地。agent 有三个模型可用工具：

• cordis_inspect：只读报告当前进程 live runtime（plugins/services/tools/events/api）。
• cordis_mount：在 node:vm 沙箱里立即把 model 写的 async JS 函数体评估为临时 Plugin，挂到 cordis-dynamic 组，分配 dyn-N id。
• cordis_unmount：按 id 卸载一个临时 Plugin，等到所有 owned tool/listener/service/timer/effect 都 quiesce 才返回。

cordis_inspect 的输出是结构化 JSON，下面的简化示例展示了一个 bash 工具运行时挂载完毕后的快照（删去了实际 plugin 源码，只保留元数据）：

{
  "process": { "pid": 42318, "node": "v20.11.0", "uptime_s": 312 },
  "plugins": [
    { "id": "core:agent-loop", "name": "AgentLoop", "state": "active" },
    { "id": "tool:bash",        "name": "BashTool",  "state": "active" },
    { "id": "core:session-log", "name": "SessionLog","state": "active" }
  ],
  "services": { "model": "deepseek-v4-pro", "session": "sqlite" },
  "tools":     ["bash", "read_file", "write_file", "lsp_query"],
  "events":    ["tool:call", "tool:result", "model:request", "model:response"],
  "dyn_plugins": []
}

cordis_mount 接受的不是结构化表单，而是一段 async function(ctx) { ... } 字面量：

// 模型写的代码（伪示例）
cordis_mount(`
  export const name = 'weather'
  async function apply(ctx) {
    ctx.provide('tool:weather', { /* schema */ })
    ctx.on('tool:call', async (e) => { /* ... */ })
  }
`)

设计笔记里有一句话点透了意图：a self-referential agent that inspects and modifies its own runtime。这是从「自进化 AI」论文到工程的关键一步——agent 能按任务自己造工具、装进运行时、发现问题再换掉，不用重启进程，也不会丢上下文和缓存。底层是 Cordis 的可逆效应在撑着。

几个工程细节值得说清楚。self-mod 当前是 opt-in 开发工具，bash 级信任，不是安全边界——临时 Plugin 可以用 ctx.shell 以宿主权限访问真实文件系统和 web。vm 隔离的是意外的全局污染，不是权限。模型写的注册在注册时就验证，malformed schema 注册即失败。临时 Plugin 只在进程内存，不写文件、不改 cordis.yml、重启不恢复。跨 mount 组合：mount A ctx.provide('foo')，mount B inject:['foo'] 自动激活；卸载 A 则 B 回 pending（注册 unwind）。

为什么不用结构化的 cordis_register_tool 而用单一 cordis_mount？设计笔记的 Alternatives 段说得很直白：结构化工具只覆盖 tools，listeners / services / inject 每个都要再加一个工具——API 会无界增长。单一 mount 原语用 cordis plugin 一个词汇覆盖所有 effect，且天然支持跨 mount 组合。一个原语覆盖最多场景，这是好品味。

self-modification 目前是 opt-in 开发工具，设计笔记已承认「out of scope for v1」。走向生产自进化需要真正的进程隔离和权限提示。但这个原型已经把方向亮出来了：DSH 的长期目标是自进化 agent，Cordis 的可逆效应是使这成为可能的前提铁轨。

七、技术反思：AI 辅助开发会失败在哪

从技术角度看，DSH 给的真正价值不只是开源了一个 agent 运行时——是它用 12293 次提交留下的数据，反面教材式地展示了 AI 辅助开发会失败在哪、架构设计会失败在哪。搞「用 agent 造 agent」得先把这两个雷区看清楚。

AI 辅助开发的失败模式

没有不变量强制的 AI 代码会腐烂。192 commits/天的节奏，如果靠人记规则——「注册要返回 disposer」「模型可见的必须记录」「capability seam 要三角色完整」——三天就忘。DSH 把这些都推到运行时：Model-visible ⟺ logged 是 assert 不是注释，注册返回 disposer 是 Fiber 强制收集不是约定，capability seam 三角色完整是架构规则不是建议。靠人记的规则会腐烂，靠工具强制的规则才能扛住 12293 次提交。AI 辅助开发的第一条铁律是：让 agent 生成代码可以，但不变量必须机器强制，否则技术债雪崩。

commit 数量不等于质量。日均 192 次提交如果没有 100% 覆盖率门、7 个 vitest 配置、type-equiv 防漂移、knip 检测 unused code、.jscpd.json 检测克隆，会变成什么？一堆能跑但没人敢动的代码。DSH 的 CI 硬门是 packages/*/*/src 每文件 100% 覆盖——这不是目标，是入场券。Agent 生成的代码如果没有这种门挡着，会以人类无法审查的速度积累边界情况。

AI 杠杆放大了单点风险。代码所有权 bus factor 3（top 3 = 64.2%），发布权 bus factor 2（仅 imccyu + tianyicui），tianyicui 单人 42.6%。杠杆让小团队能产出大团队的代码量，但也让单点故障的影响被放大——核心成员离开，AI 生成代码的「为什么这么写」全在 commit message 和 Agent Notes 里，没人接得住。DSH 的解法是 Agent Notes 制度化（每个非平凡变更都有设计决策记录，PR 必须附带，归档冻结），把设计 rationale 沉淀成可追溯的资产。治标而已，治本得降低集中度。

架构设计的失败模式

「不可变内核 + 扩展点」逼用户去 fork 源码。早期 agent 框架的核心循环写死，想改核心只能 fork。早期 LangChain 的「扩展点」是框架规定的位置，超出这个位置就要动源码。DSH 用「一切皆插件」消掉特权核心——agent loop 本身是插件，组合即配置，不用 fork。

插件拔不下来。VSCode 87/100 扩展无法运行时卸载，是「时间可组合性」缺失的典型。没有可逆性的插件系统，agent 一旦热重载就留下孤儿 listener 和状态污染。Cordis 的可逆效应把卸载变成逆序执行 disposer 链，系统状态精确恢复。可逆性得是不变量，不能只是建议。

多份状态谁来定？没有单一真相源，就会出现「模型看到的」和「日志记录的」不一致的灰色地带。DSH 的 Model-visible ⟺ logged 用一个强不变量消掉这个特殊情况——模型看到了什么，只有一个答案：日志里有什么。

没有可逆性的 self-modification 是空中楼阁。agent 改一次自己就崩一次，上下文和缓存全丢。这是当前所有想做「自进化 agent」的项目最大的工程门槛。DSH 给的解法很朴素：先有可逆效应，再做 self-modification，顺序不能反。

这四条失败模式，DSH 都给出了反面教材式的解法。Linus 讲过一句话——「好品味」就是消除边界情况优于增加条件判断。DSH 沿着这条路走到底：没有特权核心、没有半成品状态、没有不可逆操作、没有模型可见但未记录的内容。架构不靠堆能力，靠消除会让人失败的特殊情况。

八、借助 Agent 造出最强 Agent（以及 DSH 自身的风险面）

把 DSH 放回我过去半年写的 harness 谱系里。3 月我写过框架与 harness 的区分：framework 是构建块库，harness 是生产运行时。Weng 7 月那篇《Harness Engineering for Self-Improvement》给出了工程化路径——RSI 可以发生在模型权重、训练管道、部署系统三个层面，她选第三层。林俊旸 8 月把公司押给 Agent，走的也是「模型 + 环境」的工程路线。

DSH 是这条脉络里第一个可以拆解的开源工程样本。Weng 给方向，DSH 给实现。但 DSH 给的额外礼物，是它的构建过程本身——这是我推测它主要靠 Codex 协助生成之后，最值得带走的部分。

构建过程抽象：harness agent 是怎么长出来的

前面推断过 DSH 主要架构大概率由 Codex 协助生成（首提交即建 CLAUDE.md、codex/ 前缀分支、AI 风格的 commit message、tianyicui 单人日均 80+ commit）。把这套构建过程抽成可复用的方法论，整理出 5 条 harness 团队的工程铁律——和第七节「个人开发者的 4 条教训」形成上下层关系：第七节回答"代码为什么会腐烂"，这一节回答"团队怎样不腐烂"。

1. 人定架构和数据结构，agent 填实现。6 月 13 日先落地 capability seams（三角色），6 月 14 日才写 Code Mode（算法）。Context 作为服务仓库 + append-only SessionEvent 作为唯一真相源这两个数据结构定完，后面 12000 次提交都是在往这棵树上挂插件。
2. 机器强制的不变量代替人记的规则。上一节讲过，不重复。
3. 单一原语覆盖最多的场景。self-modification 用单一 cordis_mount 覆盖所有 effect，capability seam 用「one role alone is not a seam」堵住半成品状态。
4. 设计 rationale 沉淀为可追溯资产。Agent Notes 让每个非平凡变更都有决策记录，PR 必须附带，归档冻结。12293 次提交里能追溯到每个决策的 why。
5. release 是策划出来的事件。8 月 13 日是协议切换、主版本号跳变、公开发布、论文上传、模型发布同步的协同。release 本身是一种工程。

这套构建过程和 Weng 描述的 harness engineering 在底层是同构的——模型生成、harness 验证/压缩/执行，编排错则崩溃。我推测 Claude Code 团队和 Codex 团队大概率也是按这套方法论工作的——只是他们的开发过程不公开，DSH 是目前唯一可以近距离观察的样本。

DSH 自身的风险面（反方声音）

任何严肃的工程分析都不能只讲长处。DSH 自身至少面临三个尚未被充分讨论的风险：

• Vendor 分叉的长期成本。DSH 把 Cordis 整个内嵌并重命名到 @deepseek-ai scope，加了 17 项本地修改（其中 5 项是实质性生命周期加固）。这意味着 Cordis 上游的 bug fix 和 feature，DSH 需要手动 backport。上游版本每跳一次，分叉成本就堆一层。如果 2-3 年后 Cordis 上游做了 50 项重要改动，DSH 这边的 17 项可能变成 80 项——代码债会以"框架同步债"的形式积累。这点在第七节没有展开。
• 「open source, closed contribution」模式的生态天花板。Koishi 能积累 4000+ 插件是因为它接受外部 PR；DSH 当前不接收 PR，社区只能通过 Discussions 和 plugin 仓库参与。这能保证早期质量，但也意味着 DSH 很难复制 Koishi 的生态密度。如果 DSH 想达到 LangChain / LangGraph 的生态规模，contribution 政策迟早要放开——但放开的时机和方式会决定 DSH 的命运。
• Self-modification 的安全模型未成熟。vm 沙箱隔离的是"意外的全局污染"，不是"权限"。临时 Plugin 可以用 ctx.shell 以宿主权限访问真实文件系统——这意味着 self-mod 当前是**「bash 级信任，开发工具」**，不是「生产安全边界」。如果未来 DSH 把 self-mod 开放给远端用户的输入（不只是开发者本地），需要真正的进程隔离（landlock-run 已经做了部分铺垫，但仍不够）+ 权限提示 + 审计日志。当前设计笔记已承认「out of scope for v1」，但长期路径必须解决。

收束

回到开头那个问题：harness 到底长什么样？DSH 给的答案是一棵在启动时组合出来的插件树——每个插件都能被替换，每次替换都能被撤销，agent 能在不重启进程的前提下改自己的运行时。不是又一个 agent 框架，是一条通往自进化的工程路径。

最后一点感想：DSH 最值得记的不是产品本身，是它的构建方式。我推测 DSH 团队用 Codex 当 subagent 协助生成主要架构，把 Claude Code 和 Codex 作为 hooks 桥进开发流程，自己就在跑一个 harness loop——人定不变量，agent 生成代码，机器强制规则。这件事比 DSH 产品更长远。12293 次提交不是人类被替代的证据，是人类学会与 agent 协作建造工程级系统的早期样本。

参考

• DeepSeek Harness 源码仓库（截止 2026-08-16）：https://github.com/deepseek-ai/deepseek-harness