DeepSeek Harness 技术入门与架构原理电子书

内容提要

前言

资源与支持

导读 为什么现在需要Harness

0.1 Model只会生成Token，但Agent要完成任务

0.2 为什么DSH值得单独写一本书

0.3 本书的学习路径

第1章 Harness不只是另一个Coding Agent

1.1 先把“产品”和“Runtime”区分开

1.2 “一切皆插件”

1.3 为什么这不只是“多加几个Tool”

1.4 这是否意味着DSH会成为行业标准？

1.5 Developer Preview

第2章 从零开始运行DSH

2.1 环境准备

2.2 Workspace是Agent的“现实世界”

2.3 配置模型

2.4 预置4套Agent Preset

2.4.1 对照4套Preset

2.4.2 观察composition的“差分”

2.4.3 比较同一任务的执行轨迹

2.5 为什么官方Benchmark会选Minimal

2.6 本章小结

第3章 “一切皆插件”意味着什么

3.1 DSH的4套Preset不是4个独立Agent

3.2 Host Plane与Agent Plane

3.2.1 Scope Context：会话级能力从哪里来

3.2.2 作用域的意义：动态组合必须有边界

3.3 Standard：能力基线

3.4 PTC：同一批能力，不同的呈现方式

3.5 Minimal：把Harness压到非常薄

3.6 Creative：让Runtime本身也成为可操作对象

3.7 4套Preset如何体现“一切皆插件”

3.8 “一切皆插件”不等于没有内核

3.9 本章小结

第4章 从Skill、Tool到Hook——亲手改变Harness

4.1 Skill：最轻量的扩展

4.1.1 Skill路径与默认启用方式

4.1.2 动手实验：删除Skill，观察能力是否还在

4.2 第二层：写一个真正的工具

4.2.1 注册也有生命周期

4.2.2 不要把Tool看成一个函数

4.3 第三层：用Hook改变执行规则

4.4 Tool Execution Pipeline：一次工具调用究竟要经历哪些阶段

4.5 Guard、Approval与Sandbox：规则判断、单次授权与执行隔离

4.5.1 为什么Guard要“单调”

4.5.2 Approval与Sandbox为什么必须放在不同层

4.6 PTC与Pipeline：为什么不能绕开这条管线

4.7 动手实验：同一Tool，不同执行规则

4.8 本章小结

第5章 Cordis让插件能够动态组合

5.1 Temporal Composability：生命周期结束时，变化也必须被撤下

5.2 Effect的边界

5.3 Spatial Composability：当能力环境变化时，插件还能不能运行

5.4 插件被发现，不等于已经具备运行条件

5.5 Fiber：记录插件实例的一段生命周期

5.5.1 Fiber还记录“谁和谁一起结束”

5.5.2 逆序清理不等于逆序完成

5.6 Cordis的HMR建立在生命周期之上

5.7 Effect与Coeffect：插件增加什么，又需要什么

5.8 动手实验：让依赖出现，消失，再回来

5.9 为什么Cordis特别适合Agent Runtime

5.10 本章小结

第6章 Agent一轮工作的全过程

6.1 Agent Loop不是黑盒

6.2 Turn与Step：一轮工作可以包含多次模型推进

6.3 Tool Call要经过统一执行管线

6.4 Session不是简单的消息数组

6.5 模型看见的内容应当可追溯

6.6 为什么“可重建”对调试特别重要

6.6.1 持久会话事件与实时Agent/能力事件：记录事实和支持干预

6.6.2 为什么还要保留assistant/chunk

6.6.3 Projection：同一组事实可以生成不同视图

6.6.4 上下文压缩也必须保持可解释

6.7 稳定的请求前缀与KV Cache

6.8 从“保存事件”到“重建模型请求”

6.8.1 重建一次模型请求，至少需要哪些材料

6.8.2 能回放，不等于结果一定能复现

6.8.3 用Session调试Agent：先找证据，再判断是不是模型问题

6.9 本章小结

第7章 从Tool Call到Agent Runtime

7.1 PTC：让模型用程序编排已有工具

7.2 PTC不能绕过安全治理

7.3 PTC的分层设计与适用边界

7.3.1 代码执行能力与具体实现分离

7.3.2 PTC压缩的是确定性控制流，不是依赖语义理解的决策

7.3.3 PTC中的工具调用为什么还要经过统一执行管线

7.3.4 动手实验：用同一任务比较Native Tool Calling与PTC的执行效果

7.3.5 PTC什么时候反而不划算

7.4 Subagent：子任务的委派也可以是可替换的能力

7.4.1 同一种Subagent能力，可以有不同实现

7.4.2 委派子任务的3个问题

7.4.3 委派还要明确任务和返回结果

7.5 Sandbox：决定能力在哪个受控环境中执行

7.6 持续任务机制：让工作跨越多个Turn

7.7 Extensions：让Agent可以观察和修改当前Runtime

7.8 Creative为什么属于高信任能力

7.9 Runtime到底多做了什么

7.10 本章小结

第8章 设计自己的Harness

8.1 从需求出发，而不是从插件列表出发

8.2 能力定义、Provider与使用方

8.2.1 设计一种新能力时，需要先确定什么

8.2.2 把可替换点放在正确的层

8.3 动手实验：写出自己的第五套Preset

8.3.1 最终项目：设计一套Preset

8.3.2 第一步：先列任务与权限清单，再写YAML

8.3.3 第二步：把Host的共享能力与Reviewer的会话级组合分开

8.3.4 第三步：只向模型暴露审查真正需要的工具

8.3.5 第四步：规定审查结果的输出格式

8.3.6 第五步：用失败路径验证Preset，而不只测试正常情况

8.4 不要把Preset当成权限系统

8.5 插件生态越强，边界越重要

8.6 模型表现与Agent整体表现必须分开

用Preset做可重复的对照实验

8.7 DSH最值得学习的不是某个API

8.8 Harness Lab的最终架构

8.9 本章小结

附录A 核心术语

附录B 快速演进中的DSH ——版本更新、视觉模型与插件生态

B.1 先固定一个版本快照

为什么这一点对插件尤其重要

B.2 0.1.1-rc.x值得关注的变化：视觉能力进入Harness

read_image是一个很好的例子

版本提示

B.3 配置DeepSeek-V4-Flash-Vision-Exp

B.4 为本地模型添加视觉支持

B.5 一些插件推荐

B.6 插件一：dsh-archived-chats——把Session Log变成可管理资产

B.7 插件二：dsh-better-sidebar——从UI插件变成插件平台

B.8 插件三：dsh-product-subagent-console——给Multi-Agent增加Control Plane

B.9 插件四：dsh-remote-access——把Plugin扩展到网络访问边界

B.10 如何持续跟踪DSH的更新

B.11 版本补充：0.1.5的Session V3和in-history System Prompt

B.12 总结：不要追版本，要追能力边界