快速回答
DeepSeek Harness（dsh）的爆火（开源 1 个多小时破 2 万星、首日 2.8 万–3.1 万星）不是营销，而是几个反直觉的架构决策共同作用的结果。读完官方仓库（12,293 次提交、54 个 npm 包、约 59.1 万行 TypeScript），最值得关注的不是它有多少工具，而是四件事：
- 没有特权内核：连 agent loop 本身都是插件，任何能力都能从配置整体替换。
- 会话日志是唯一事实来源：fork / 恢复 / 上下文压缩 / 回放全是日志的免费派生品。
- Agent 能现场改装自己：自引用工具集让运行中的 agent 可以定义新插件并立刻让模型看到新工具。
- 沙箱是一张矩阵：Linux / macOS / Windows / 云端各配后端，强制级别如实上报。
这四件事里，前三件是可以抄走的架构决策，第四件是工程态度的体现。下面逐一拆开讲，并给出普通开发者视角：这些设计对你用 agent 意味着什么。
这篇「技术报告」到底是什么
先对齐一下：DeepSeek Harness 官方目前没有一份「论文」形式的正式技术报告，但它的设计依据、源码与文档本身就是一份可读的架构说明书。本文的解读基于对官方仓库与参考文档的拆解（版本 0.1.0-rc.5）：
- 仓库：https://github.com/deepseek-ai/deepseek-harness
- 参考文档：https://deepseek-harness.github.io/deepseek-harness/reference/
- 底层框架：Cordis（https://github.com/cordiverse/cordis），设计依据论文《A Programming Paradigm for Spatiotemporal Composability》
下面从「值得关注的原因」和「怎么抄」两个角度讲。
决策一：没有特权内核，一切皆插件
这是 dsh 与其他框架最本质的分水岭。绝大多数 agent 框架是「核心 + 插件」：一个带主循环（agent loop）的神圣不可侵犯的内核，扩展只能走官方预留的钩子。
dsh 反过来：
产品的每一部分都是插件，包括模型适配器、工具注册表、会话日志，甚至 agent loop 本身。
底层是 vendor 进来的 Cordis 插件框架。三条机制撑起这个承诺：
- 插件 = 可逆副作用。注册任何东西（提示词片段、工具 schema、适配器、事件监听器）都是副作用（effect），插件卸载时自动撤销，reload / HMR 时按声明顺序干净重来。没有「装上了就卸不掉」的遗留状态。
- 依赖用声明，不用编排。插件用
inject声明自己需要的服务（ctx.tools、ctx.llm、ctx.sessions…），框架按依赖自动决定加载顺序。你永远不 import 具体实现，只按 key 找服务——所以任何服务都可以从配置整体替换。 - 事件有四种分发模式：
emit（观察）、waterfall（环绕中间件，必须next()委托）、parallel（并行扇出）、serial（按序执行）。拦截、审批、改写全部是「挂一个 waterfall 监听器」，不需要改循环本身。
开发者视角：这意味着「给 agent 加一个工具」「只给终端 + 文件操作、不给网络」「把模型从官方 API 切到另一个端点」——这些在传统框架里要么要改核心、要么要等官方出钩子的需求，在 dsh 里都只是配置或一个插件。对想深度定制 agent 的团队，这是能力面的从「官方给什么用什么」到「我要什么拼什么」的转变。
决策二：会话日志是唯一事实来源
这是 dsh 最狠的一条，也是「省 Token」传言的真正来源。
它把一句话上升为运行时不变式（runtime invariant）：
抵达模型请求的一切，都必须能从日志重建。
具体说，会话日志（SessionEvent log）是唯一事实来源。模型看到的一切——用户消息、助手 chunk、工具调用与结果、注入的上下文——都是追加式日志里的事件；deriveMessages() 从日志投影出模型历史，原始 assistant/chunk 事件保证回放和 UI 保真。
这个决策的连锁收益是「白捡的」：
| 你要的功能 | 传统框架要付出的成本 | dsh 的做法 |
|---|---|---|
| fork 会话 | 单独序列化 / 复制状态 | 从某条边界事件派生，天然一致 |
| 恢复会话 | 额外「记忆序列化」 | 重放日志即可 |
| 上下文压缩 | 容易造成历史与 UI 分裂 | 在日志上做 surfaceOp: { op: 'replace' } 显式替换，压缩本身也只是个事件 |
| 回放 / UI 同步 | 另存一份副本 | 直接读原始日志，模型历史与 UI 永远同源 |
配套的 spill 存储：超大工具输出落盘，模型只拿定位符，上下文不再被巨量文本撑爆。
开发者视角：绝大多数框架把「会话日志」当调试功能；dsh 把它当唯一的真理来源。对使用者的直接好处是可解释、可恢复、可审计——一个 agent 会话为什么走到了这一步，回放日志就能看到；要分叉出一个「如果当时换个做法会怎样」的分支，fork 一下就行。这种「所有状态都是派生品」的设计，也大幅降低了长期跑 agent 的运维心智负担。
决策三：能力 seam 三件套（定义 / 提供方 / 消费方）
dsh 的可替换性不只是「插件系统」，而是落到一组具体的抽象上：Service Definition / Provider / Consumer 三件套。
最直观的例子是沙箱。进程沙箱是一个可替换的 seam（ctx.sandbox），后端按平台选：
| 平台 | 沙箱后端 |
|---|---|
| Linux | bwrap / Landlock（自带 native 的 landlock-run，含预编译产物与 CLI 契约文档） |
| macOS | Seatbelt |
| Windows | ACL 受限令牌（每个会话/工作区一对私有临时目录 + SID） |
| 云端 | E2B 远程 Linux 沙箱（文件系统、子进程、shell 适配器共享同一个远程工作树） |
关键是：文件系统与进程执行共享同一套 provider 抽象。于是把 fs / subprocess 指向 E2B，Bash、PTY、LSP 就整体搬进远程沙箱，不需要为每个能力写平台专用 fork。这就是「能力 seam」的威力——换一个 provider，整条执行链跟着换。
沙箱还有一层工程态度值得单独说：强制级别如实上报。它区分 full / partial（旧 Landlock ABI、Windows ACL 的 Everyone 与硬链接边界算 partial），并明确要求「要求绝对保证的消费方必须拒绝 partial」。不假装安全，这是一个成熟系统该有的样子。
开发者视角：对普通用户，seam 意味着「迁移成本低」。把 dsh 从本机沙箱切到云端 E2B、把模型后端从官方 API 切到别的 OpenAI 兼容端点，都只是一行配置的事。对自建 agent 平台的人，这个三件套是一个可以直接抄的设计范式：先定义清楚能力接口，再让 provider 可插拔，最后消费方只依赖接口不依赖实现。
最劲爆的一条：Agent 能改装自己
dsh 提供了一组自引用工具：cordis_define / cordis_run / cordis_stop / cordis_undefine / cordis_inspect_*。
含义是：运行中的 agent 可以现场定义一个新的 Cordis 插件，注入到真实运行时——而新插件注册的工具，立刻对模型可见。
这不是玩具。工具集背后是 dsh-cordis-host-runner 的 vm 沙箱和定义注册表，一个运行中的包甚至可以注册额外的模型可见工具，直到被 stop / undefine 或进程重启。它默认不进任何发行树（刻意 opt-in，因为「动态包代码会到达真实运行时」），但机制本身是闭环的：
用框架 → 在框架里定义框架 → 改自己的工具集 → 继续用
开发者视角：这是目前市面上几乎唯一把完整版「元编程闭环」做成工具暴露给模型的框架。想象一个场景：agent 在干活时发现需要某种能力，它自己写一个插件、注册进去、立刻用上——而不是停下来等开发者改代码。这种「自举」能力到底会在真实任务里被用到什么程度，还需要社区验证，但方向是真实的：agent 不只是「用工具」，还能「造工具」。
它的工程文化：为什么值得信任
除了架构，仓库本身透露出的工程文化也值得关注：
- Postmortem 文化：仓库里有 4 份正式事故复盘。最出名的一条：178 项无密钥测试全绿时，真实 ACP 客户端会话当场崩溃——于是他们建立了独立的、带 secret 的真实 API e2e CI（对线上 DeepSeek API 跑真实模型调用、真实 bash、多轮次、恢复），并把「无密钥测试证明的是管线，不是产品」写进测试文档。
- 运行时不变式注册表：
ctx.invariants，每个工作区包都必须自带./invariant配套插件，无检查项也得写注释解释为什么；verify-package-invariants机械拒绝空安装器。 - 生成式文档 + 机械校验：Cordis API 目录、工具 schema 目录全部由脚本从源码生成，CI 里逐字节校验，防止文档与代码漂移。
- 用 Agent 造 Agent：1,386 份 agent 笔记（
.agents/notes），git 分支名大量是codex/...、agent/...、worktree/...——这个框架很大程度是 AI 编码 agent 自己写出来的，而这套 agent 机制又反过来支撑了这些 agent 的日常工作。狗粮吃到闭环。
开发者视角：对开源项目来说，「态度」本身就是一种可靠性信号。4 份 postmortem、逐字节校验的生成式文档、机械拒绝空检查项的 invariant 注册表——这些都是「这个项目会长期维护」的实证。
泼冷水：架构方向真实，但版本是预览版
再强调几条必须知道的边界：
- 明确标注 Developer Preview，官方声明「未来将有破坏兼容性的变更」。现在抄它做生产依赖，要做好追版本的心理准备。
- 每次 release 都是 222 个文件同步改版本号——54 个包同步发版的代价就是这种机械 churn。
- 底层 Cordis 是 vendor 方式引入的，不是 dsh 自研——对 Cordis 的信任要并入技术评估。
- 沙箱矩阵很强，但
partial强制级别如实存在，生产环境必须逐个确认自己平台的强制完整性。 - 「对标 / 取代 Claude Code」是媒体叙事；一个 rc.5 的预览版谈「取代」为时过早，但架构方向是真实的。
常见疑问
Q：DeepSeek Harness 有正式的论文 / 技术报告吗？ 目前没有单篇「论文」形式的官方技术报告。它的设计依据是 Cordis 论文《A Programming Paradigm for Spatiotemporal Composability》，而 dsh 自身的架构说明书 = 源码 + 参考文档。本文解读的就是这份「隐形的技术报告」。
Q：这三个架构决策里，哪个最值得我抄？ 如果是自建 agent 平台：能力 seam 三件套最直接，先把能力接口定义清楚，再让 provider 可插拔。如果是想让自己的 agent 系统更可靠：日志即唯一事实来源收益最大，把会话状态做成可重放的派生品，fork / 恢复 / 审计全免费。
Q：这些设计对普通用户有什么实际好处？
可解释（回放日志就知道 agent 干了什么）、可恢复（会话随时 fork / 续跑）、成本可控（spill 落盘 + 便宜模型）、迁移成本低（换 provider 只需改配置）。想低成本体验，一个 key 把 DeepSeek V4 接进来即可。
Q：什么时候适合认真跟进 dsh？ 想深度定制 agent、想做 agent 架构研究、或想「便宜跑 agent 规模」的人，现在就可以跟进。前提是接受 Developer Preview 的不稳定。想清楚再动手，见《DeepSeek Harness 是什么》。
想低成本跑一个 DeepSeek V4 的 agent 来验证这套架构，到 TeamoRouter 注册拿一个 key，把 DEEPSEEK_BASE_URL 指过去即可。想看到这套框架在真实多智能体场景里怎么用，接着读《用 DeepSeek Harness 跑一个多智能体协作场景》。