跳转到内容

DeepSeek Harness 作架构范本:从 DSH 学到的八条

8 月 28 日的扫描把 DeepSeek Harness 记为"只参照、第四壳候选";8 月 29 日你指定它为**架构范本**,升格的是"借它的架构模式"这一档,运行时结论没变。克老师当天浅克隆读了七份架构文档,写出了这一页的骨架:AIOS 0.2 是一个"组织级 Harness",脊柱只做六件事,其余一切是插件,载体本身是"单会话 harness",AIOS 站在它们之上做 40 席乘 6 机的组织层。我 8 月装过 DSH,那页讲的是它怎么用;这页讲的是它怎么被我们借。

来源是 46 号 v1.3 §一(克老师,2026-08-29)和克老师记忆里的 DSH 条目。仓库事实为当日 GitHub API 现核:20 万星、MIT、2026-08-13 建仓、两周 20 万星不是笔误。

先记三样
  • 位置:DSH 本身是商品级运行时,但只借它的架构模式;脊柱自建,与它同构。
  • 抄与不抄:抄:一切皆插件、seam 三角、事件五模式、profile 分层。不抄:它的 API 向模型层和运行时(订阅-only、单会话、开发者预览)。
  • 一个数:两周二十万星。一条令:"脊柱六件与 Cordis 同构,推翻条件写死:它能驱动订阅壳且 API 稳定一版。"

你的架构观(08-29,克老师记录)

Section titled “你的架构观(08-29,克老师记录)”

先架构(主脊柱加可拔插),再全局设计,再外部吸收;接入三档,适配、转写、内化;按功能组合打包,可对外卖。

#DSH 或 Cordis 的做法AIOS 怎么用
1一切皆插件,没有特权内核:插件向共享上下文贡献服务、类型化事件和可逆副作用;连 agent 循环都是可从配置替换的插件派工循环、放置函数、评审门、看板都是插件;脊柱不含任何业务判断。"换一个插件就换掉整个行为"是设计目标
2服务容器:按 key 取服务、不 import 实现;inject 声明依赖决定加载顺序固定 key 表,插件之间只认 key;加载顺序由依赖表达,不手排
3能力缝 seam 等于定义加提供方加消费方三角;扩展插件只依赖定义,绝不依赖具体提供方借用件只能当提供方:sandbox-runtime 是沙箱缝的一个 provider,tmux 派发是载体缝的 provider,站内信是通道缝的 provider。换 provider 不改消费者,"适配、转写、内化"能成立全靠这个
4类型化事件加五种分发模式(emit、waterfall、parallel、serial、bail);事件即扩展点;持久事件与实时事件分域事件日志里的持久事件(票、义务、会话、节点、账号)与实时策略点分开:派工前用 waterfall(放置与沙箱策略在这里改写或拒绝),评审用 bail(第一个拦住的说话),关单用 serial
5"模型可见即已记录"不变量:会话日志是真源,模型历史从日志投影,运行时断言"决策可见即已记录":进入派工、评审、验收、计分的任何输入都必须能从事件日志重建
6注册是可逆副作用:每个注册都有 disposer,重载或拆除时撤销插件卸载即撤销它的常驻、钩子、子命令,直接对应运行表的"能卸"
7profile 加组合包加 patch 分层配置,dump-config 能看见整棵树发行版等于 profile;每台机的运行表就是 host 级 patch;对外卖或适配新项目等于换一组插件,不改脊柱
8包按能力族分组、每包只属一族、README 是合同、模块图由脚本生成并 CI 门禁、防御性模式清单、不变量注册表仓库按能力族分目录;doctor 跑不变量;合同真源就是脚本生成的模块图加事件矩阵

DSH 里可直接转写(不装它、抄机制)的件:两个壳的钩子线协议库、沙箱的 Seatbelt 后端、skill 族、goal 加 workflow、实验性的 agent-team(roster、任务板、mailbox,与我们的编队、票、站内信同构)、webhook 到 workspace session、会话查询的 SQLite 全文检索、凭据引用不落明文的 credentials 缝。

脊柱清单:必须有,也只有这些

Section titled “脊柱清单:必须有,也只有这些”
脊柱件职责明确不做
1 内核容器Cordis 五概念的 Python 转写:插件、服务容器、依赖排序、事件五模式、可逆副作用不做热重载,一轮 profile 只启动时组装
2 事件日志与对象索引每机按日 JSONL 只追加;SQLite 索引可重建;"决策可见即已记录"断言不做集团级索引(二轮)
3 合同与 schema 注册七个 schema、版本、迁移、影响分析不做运行时类型图(三轮)
4 组合与配置profile、组合包、patch 分层;dump-config不做插件市场
5 不变量与诊断包归属的不变量注册表;doctor 跑契约测试、版本一致、未登记常驻无
6 正门与子命令注册一个入口;各包在自己目录注册子命令无

其余全是插件:票、义务、会话、节点、账号、放置、派工、评审、合并、沙箱、载体、通道、技能、看板、计分、租户、备份、搜索。每个插件只依赖容器的 key,不 import 别的插件。

插件合同:每个插件必须声明的字段

Section titled “插件合同:每个插件必须声明的字段”

名字、版本、所属能力族(只属一个);提供哪些服务、需要哪些服务(决定加载顺序);发出与监听哪些事件、各自分发模式;注册哪些子命令;是否常驻(默认否,只有运行时族且在运行表登记才允许);副作用必须可逆;配置 schema;至少一条不变量与一条契约测试;provenance(借用或转写来源:上游、版本、许可、替身、退出日、从它学什么);档位(适配、转写、内化)。

生命周期:发现,解析依赖,应用,副作用登记(每个都带 disposer),拆除。

profile装什么谁用
control-plane脊柱加票、义务、放置、评审、合并、看板真源LG01(你的工作机加真源;常驻只减不增)
builder-node脊柱加载体、沙箱、会话、派工消费方LX01 主池、LM01、LT01
runtime-only脊柱最小加站内信加节点OC2(我)
founder-controlTelegram 通道加看板只读加决定卡你的手机
spike-lab任何插件可装可卸M3Max(附录)

对外形态:同一脊柱加不同插件组合即可打包;开源站内信等于通道缝的一个 provider 包独立发布;将来若卖,卖的是 profile 与插件,不是脊柱分叉。

为什么不直接建在 DSH 上(高代价决定的反证)

Section titled “为什么不直接建在 DSH 上(高代价决定的反证)”
  • 最强反证:20 万星、插件生态齐全、桌面与 Web 客户端齐全,直接当基座能省一年。
  • 仍自建脊柱的三条理由:订阅-only,DSH 的模型层是 API 向适配器,Claude 的 OAuth 只给原生应用,DSH 驱动不了我们的订阅载体;DSH 是单会话 harness,AIOS 是 40 席乘 6 机的组织层,义务、票、放置、运行表都不在它的问题域;开发者预览明示会有破坏性变更,三律第二条不允许把真源建在上面。
  • 推翻条件:DSH 提供订阅壳驱动(或我们的载体迁到 DSH)且 API 稳定一个版本以上,那时把 AIOS 组织层做成 DSH 组合包。所以脊柱必须与 Cordis 同构,迁移成本才低。
  • 最小实验:一轮尾在 M3Max 装 dsh 加 dsh-agent-teams 跑一个三票任务,对照我们的派工循环。
  • 第 1 课那张“操作系统对照表”的内核层,今天的具体设计就是这六件脊柱。
  • 第 3 课讲的“载体可换、身份不换”,在这里是 seam 三角:载体是提供方,席位是消费方,换提供方不改消费方。
  • 我 9 月的DSH 装机实录讲的是 DSH 自己怎么跑,一个被代理剥掉端口的 403,和 profile 包的思路,是这一页的实操脚注。

为高代价决定写反证。 46 号这一节的写法是先写“最强反证”,再写“仍然这么做的理由”,最后写“什么证据会推翻”。任何要花一年的决定都该这么写。

  • 集团内部:46 号《AIOS 0.2 一轮:架构脊柱、编队对席、校验 DAG、机制融入、借用修订、准入状态 v1.3》§一 AIOS Harness(克老师,2026-08-29);克老师记忆 dsh-deepseek-harness 条目;Ling 架构观(2026-08-29)。
  • 上游:deepseek-ai/deepseek-harness 的 architecture、capability-seams、cordis-primer、event-producer-consumer、agent-lifecycle、defensive-patterns 六份中文文档与 packages/README。