导读：
传统的 Agent 框架把 Loop 锁死在内核里，DeepSeek Harness 反其道而行——把内核做空，“一切皆插件”。但内核这么薄，凭什么保证状态可信、执行安全、能力可换、形态可重组？
答案是四把设计钥匙：事件溯源 SSOT（状态可信）、waterfall 统一把关位（执行安全）、seam 三位一体（能力可换）、分层叠加配置 + fiber 级热更新（形态可重组）。
合起来就是一句话：能换的都是能力，不能换的只有机制。
先从“Harness”这个词讲起。
“Harness” 的英文原意是马具。一个模型，就像一匹野马：有蛮力、没方向、还爱乱跑。你没法直接让它去拉货，你得先给它套上马具：缰绳（工具 + 上下文，告诉它该干嘛）、护具（安全 + 审批，让它跑不出边界）、挽具（插件 + 可替换，拆装自如）。套好之后，这匹“野马”才变成能安全干活的一辆“马车”。
模型是“引擎”，Harness 是“整车”：一个让 AI 会想，一个让 AI 能干活。
但真正值得关注的，是 Harness 背后的架构变化。回看 Agent 基础设施的演进，行业已经走过五种不同形态：
前四代都在回答“怎么把 Loop 管好”，而 DeepSeek Harness 又往前追问了一步：为什么 Loop 非得长在系统里？
于是，DeepSeek Harness 选择把内核尽可能做薄。在 DeepSeek Harness 里，Agent Loop、日志、UI、审批 全部是可替换插件；只有三个内核原语（Service / Typed Events / Reversible Side Effects）是不可替换的机制。这就像把马车的车架、轮子、缰绳全做成可拆装的零件，只留一截最薄的底盘。
但问题也随之而来：内核这么薄，凭什么让人放心？如果一切都是插件，谁来保证？
状态是可信的：模型看到的、系统记录的，会不会各说各话？
执行是安全的：审批、拦截这些横切逻辑，塞进哪一行代码？
能力是可以换的：今天跑本地，明天上远程沙箱，要不要重写？
形态是可以重组的：换产品形态，要不要改一行内核代码？
这四个问题，正好对应下文的四大设计精华。它们并不是简单的功能堆叠，而是 DeepSeek Harness 面对具体工程问题时做出的四种架构取舍。
先从状态开始：如果状态不可信，后面的执行、恢复和追踪都无从谈起。
想象一个团队在维护一个 Agent 应用：模型已经回了消息，但日志里没有；系统崩溃后恢复，历史对不上；出了事故要追责，谁也不知道模型当时到底“看见”了什么。问题的根源只有一个——状态有多个副本，副本之间会漂移：一份在内存、一份在数据库、一份在模型上下文里，各说各话。
DeepSeek Harness 的处理方式很直接：状态不存副本，一切从日志派生。它把“会话日志”从一条普通记录，升级为整个系统唯一的单一事实来源（SSOT）：
只追加，不修改：日志是一个 append-only 的事件数组，seq == 下标，append() 写完即 deepFreeze，有任何“改”的入口——账本上的每一笔，都盖了章。
模型历史是投影，不是备份：模型能看到的全部历史，由 deriveMessages() 从日志增量投影而来，只投影 user/message、assistant/message、tool/result 三类 surface 消息——状态不存副本，只存“投影规则”。
零额外状态定义（单一事实来源）：fork、恢复、transcript、遥测、持久化，全部从同一条事件流派生，没有第二份状态可以漂移。
这是不变量，不是约定：“模型所见 = 日志所录”由编译期强制 + 运行期校验双重保证（surfaceOp 双重校验），而非文档里的一句承诺。
图1: 事件溯源——写入、追加、投影、派生的闭环
从图中可以看到，那条陶土橙色的焦点箭头 deriveMessages()：模型历史不是“另一份记录”，而是从 SSOT 日志算出来的视图。右侧的派生视图、持久化、重启恢复，全都是同一条事件流的“投影”，源头只有一条。
这里真正关键的是：Event Sourcing 在 Agent 领域的正确用法 不是做报表，而是让恢复成本趋近于零——当崩溃恢复变成日常事务，Agent 的容错就从“灾难恢复”降级为“重启即重放”。
状态可信之后，下一个问题是执行安全。
现在系统能“记得”一切了，但模型要调用工具了——rm -rf、发消息、写数据库。审批、危险操作拦截、超大结果截断、埋点观测……这些横切关注点，塞进哪一行代码？
传统做法是在每个工具函数里写 if (需要审批) ...——策略和业务耦合在一起，每加一个工具就要改一遍代码，大概率会有遗漏。
DeepSeek Harness 的第二项设计，是把统一把关位放进事件机制里：工具执行的每一步，都触发类型化事件，而 tools/* 三个事件（pre-execute / execute / post-execute）就是统一把关位。审批、Guard、Spill、遥测——全部挂在这三个事件上，不需要改任何插件代码。
tools/pre-execute：执行前把关——可拒绝、可改写，挂审批（人工确认）与 Guard（危险操作拦截）。tools/execute：实际执行——注入点，超时/重试/遥测环绕。tools/post-execute：执行后处理——结果拦截，Spill（超大结果替换为 locator，防止上下文被大对象撑爆）。
图2: 三道把关位与旁挂的策略车道
从图中可以重点看两个细节：
策略在“车道”里，不在流水线里：审批/Guard（陶土红）、Spill/遥测（灰蓝）是两条挂在把关位上的虚线——它们不进入主链路，而是“旁挂”在 pre-execute 和 post-execute 上。这就是零侵入的含义：加一个策略，不需要碰任何工具插件的代码。
把关位是“洋葱”：waterfall 派发模式要求监听器通过 next() 逐层委托——调用 next() 才继续内层，不调用即否决后续（含内置行为），外层因而可以拦截、改写、拒绝内层的执行。它与 emit（同步广播，不等待、异常不隔离）、parallel（并发等待，失败聚合为 AggregateError）、serial（顺序等待，可提前中断）、bail（同步顺序调用，遇首个终止值即停）一起，构成统一事件类型系统的五种派发模式。
这一设计的关键在于：把关位长在内核事件上，才保证了 fail-closed 的成立：拿不到安全保证，就失败（无沙箱后端抛 SANDBOX_UNAVAILABLE 绝不裸跑）。如果把关逻辑散落在各插件里，“安全保证”就是可绕过的装饰；当它长在事件里，绕过把关位就等于绕过内核，这在架构上是不可能的。
执行安全解决之后，还要回答另一个工程问题：能力怎么换？
把本地文件系统换成远程沙箱、把 A 模型换成 B 模型、把 CLI 界面换成 Web 界面。在传统框架里，这通常意味着大动干戈：实现方式变了，调用方也要跟着改，牵一发动全身。
DeepSeek Harness 的第三项设计，是把每个能力拆成一组三位一体的 seam：
Definition（声明）：能力“长什么样”——接口契约，如 schema: sandbox.exec。这是不变的部分。
Provider（实现）：能力“怎么实现”——本地进程、远程沙箱，都是同一 schema 的不同 Provider，可热替换。
Consumer（使用）：“谁在用能力”——ctx.tools.call('sandbox.exec', ...) 只依赖接口，不感知实现。
图3: seam 三位一体——换 Provider 零迁移
从图中可以看到，那条陶土橙色的虚线就是热替换路径：本地 Provider → 远程沙箱 Provider，实现换了，但中间的两个 IMPLEMENTS（声明-实现）和右侧的 INJECTS（注入使用）完全不动——因为 Consumer 绑定的不是实现，而是接口。替换一个 Provider，Bash、PTY、LSP 一并迁移，零迁移。
与 seam 配套的，还有一个很关键的设计——注册即副作用，卸载即撤销：ctx.effect() 管理外部资源并返回 disposer，ctx.tools.register() 返回 disposer；手动 dispose、Provider 热替换、HMR 配置变更、应用关闭——四个触发点自动清理。没有“卸载 API”，dispose 即清理。
这一设计的关键在于：“能力靠接口绑定，不靠实现绑定”，是把可替换性从工程技巧上升为抽象正确性：换后端像换电池，插上就能用。当你想换掉一个能力，改动面收敛到“换一个 Provider”，而不是“重写所有调用方”。
能力可以替换之后，接下来是整个产品形态怎么拼。
一个 Agent 应用长什么样，是 Web 版、Headless 版，还是别的 profile？装了哪些 bundle？这些“组装信息”如果硬编码在代码里，改产品形态就等于改代码、重启服务。
DeepSeek Harness 的第四项设计，是把整个产品的组装方式声明为一份分层配置：
关键规则只有一条：后层整体替换配置（覆盖即整体替换），非深度合并——同 id 后写覆盖，产品可从配置层面完全重组，无需改代码。
但配置能叠加还不够，还要能够热生效。这就是配套的 fiber 级热更新（HMR）：
图4: 四层配置叠加与 fiber 热更新闭环
从图中可以看到，上半部分是“说明书”：L1 打底、L2/L3 逐层覆盖、L4 --patch 临时叠，每层之间一个“后写覆盖”的箭头；下半部分是“热更新闭环”：配置变更（watch 到文件）→ 旧 fiber 卸载（副作用自动清理，这正是第三把钥匙的“注册即副作用”在配置层的复用）→ 新 fiber 创建 → apply，进程全程不重启。
这一设计的关键在于：“配置热生效”不是附加功能，而是由 profile 的 patchReload 与 hmr 配置项控制的可选能力：dsh --dump-config能看到最终配置树（打印出的任意条目都能被上层覆盖），dsh --patch foo.yml本次覆盖——配置不再是“设定”，而是“可编程的声明”。
讲到这里，再回到开篇那个“野马与马具”的比喻。
传统框架更像是“造一辆整车”——Loop 焊死在车架里，想换轮子就得拆车；DeepSeek Harness 更像是在“造一个底盘”。前面的四项设计，可以归纳为：
四项设计合起来，正好印证开篇那句话——“能换的都是能力，不能换的只有机制”：
事件可以派生、策略可以挂载、Provider 可以替换、产品可以重组——能力全部可换； 但三原语（Service / Typed Events / Side Effects）是机制的底线，替换事件通道即绕过把关位——机制不可换。
这也构成了 DeepSeek Harness 的“微内核宣言”：把 Agent 基础设施的竞争，从“功能堆叠”拉到了“架构哲学”层面。模型负责“聪明”，Harness 负责“靠谱”——五步演进，一个内核，一切皆插件。
DeepSeek Harness 官方仓库：github.com/deepseek-ai/deepseek-harness（MIT，2026-08 开源）
前往腾讯云 Lighthouse 镜像市场，搜索 DeepSeek，选择对应镜像，跟着页面提示完成购买与部署，就能快速拥有自己的云端 AI 协作工作台。
图5: 腾讯轻量云镜像一键部署