DeepSeek Harness 实战与架构解析：让 Agent 从“会聊”到“能交付”

DSH（命令行叫 dsh）是 DeepSeek 推出的 Agent 运行环境。它给模型提供工具、沙箱、记忆和可组装的插件系统，让模型在一个受约束的执行环境里把任务从开始做到交付。本文从一次"整理周报"的任务出发，拆解 DSH 的六层结构，讨论 Super-agent 原型中的 Router/Worker、链式召回、事件驱动和端云协同，最后给出上手路径与局限。

一、从一个周报任务说起

周三下午，同事在群里丢来一句："把上周的测试报告整理成一页周报，下班前给我。"

用聊天窗口里的 AI，流程通常是这样：打开对话框，描述需求，把散在三个目录里的 log 逐个打开、复制、粘贴进去；它回一段排版不错的文字；你复制出来改两个数字，再贴到群里。

模型负责"想"，人负责"做"------搬运、核对、保存、重跑，大部分体力活还在人这边。

问题不是模型不够聪明，而是它没有手。

一个人通常只能同时跟进三到五个活跃会话。单任务上限取决于模型能力，多任务上限取决于人的注意力。多数人把这理解成产品体验问题：界面不好用、切换太麻烦，做个统一看板就好了。但再往下一层看，记忆、调度、审批、恢复都困在"一个会话"里，于是本该由系统承担的事，被交给了人。

DSH 想回答的就是这个问题：能不能把记忆、调度、审批、恢复从人身上挪进系统，让人只负责设定目标和验收结果？

二、DSH 是什么：模型之外的那一层

"Harness"原意是挽具------套在马身上的皮带和嚼子。马有力量，但力量要变成牵引力，需要挽具。模型是马力，Harness 是把马力接到犁上的那套东西。

具体来说，它补三样：

• 手：读写文件、执行命令、搜代码、查网页、生成 Office 文档。模型只能输出文字，工具把文字变成动作。
• 边界：沙箱决定它能碰到哪里，审批决定哪些动作要先问你。默认最安全，放宽需要主动操作。
• 记忆：每一步写进只追加的会话日志。进程崩了能接着干，关掉窗口明天再来还记得，觉得哪一步不对可以回看原始输入输出。

核心机制可以概括为一句话：模型说"我要调用某个工具"，Harness 执行它，把结果作为新事实追加进会话，再拿更新后的历史去请求模型。

你: 把 report/ 下的 csv 汇总成一份月报
  → read  report/*.csv
  → pwsh  统计行数、求和、去重
  → write report/2026-11.md
  → present report/2026-11.md
你: 收到一个可以打开的文件

这个循环叫 agent loop。听起来平平无奇，但它带来一个质变：任务长度可以超过一次回答的长度。一次回答最多几千字，一件真事往往要几十步。有了循环，几十步可以自己走完。

需要说明定位边界：DSH 不是模型，不是 IDE，也不是云端 SaaS。模型只是它调用的一个部件。读者如果熟悉工作流工具，可以把它理解成"模型驱动的、可组装的执行环境"，而不是固定流程编排。

Agent Loop 核心循环

【用户目标 / 验收标准】
          ↓
【模型请求调用工具】
          ↓
【Harness 执行：沙箱 + 审批】
          ↓
【结果追加进会话日志】
          ↓
【更新上下文】
          ↓
      任务完成？
       ├─ 否 → 回到【模型请求调用工具】
       └─ 是 → 【交付物呈现：文件卡片 / 结果】

三、围绕会话长出来的六层

DSH 的架构围绕会话长出来，拆开看是六层。理解这六层，后面的功能大多是变体。

层	管什么	一句话
会话	记忆	只追加的 JSONL 日志，默认 zstd 压缩；崩了能续，满了能压
循环	推进	模型请求 → 工具调用 → 观察结果 → 再请求
工具	执行	文件、命令、搜索、抓网页、Office、交付物呈现
沙箱与审批	安全	三档模式 + 审批策略，每会话独立、重启后还在
上下文	成本	先剪超大工具输出，再摘要旧历史，/compact 手动触发
交付	落地	文件以卡片挂在对话下，点开就能用

有一点值得单独说：它真的可以拆开重装。DSH 本体只提供骨架，能力几乎全由插件拼出来。一个 profile 就是一组插件按顺序叠起来的结果。结构主要是两个文件，放在 $DSH_HOME/profiles/「名字」/ 下：package.json 声明装了哪几组插件，cordis.patch.yml 写自己的覆盖。

# 关掉用不上的插件，或者改它的配置
- id: ui-theme
  config:
    preference: dark
- id: dsh-market
  disabled: true

加载时从一个空配置开始，依次叠上每个 bundle 的补丁、你自己的补丁、home 级补丁、临时补丁。想知道最终叠成了什么，不用猜：

dsh --dump-config

这意味着加功能不必等官方，删功能也不必忍着。想要飞书接入，装插件；想要逐处采纳的 diff 审阅，装插件；嫌某个界面元素烦，几行 YAML 关掉它。

它有三种外壳，内核是同一套：桌面 App、浏览器界面、命令行的 headless 模式。同一套 dsh-base，在桌面版里调好的行为，搬进 CI 时不容易变形。

四、Super-agent 原型：让"会话"成为实现细节

上一节的 DSH 仍然要求用户自己管会话。DeepSeek 在设计文档里给出的判断是：Session 应当是系统的实现细节，而不应是用户的认知负担。

这句话反过来说更有意思：如果多任务的上限取决于人的注意力，那说明系统没把该干的活干完。于是有了 Super-agent 这套架构探索，团队把它开源成了 dsh-superagent-prototype。据公开报道，原型把一批任务的 p95 完成时间从 29.5 分钟压到了 15.7 分钟。【发布前补：该数据来源链接】

注意，这一节讲的是原型和设计方向，不是当前下载即用的功能。几个主张值得逐条看。

1. 调度与执行分离：Router 与 Worker

引入两层：Router 判断一件事值不值得做、该交给谁、做到什么程度算完成，它不执行，只决策；Worker 拿到任务就执行，专注交付。

更本质地说，这是控制面与数据面的分工------分布式系统里的老概念，被搬到了 Agent 上。

2. 计算与状态分离：Agent as a Service

Worker 不是常驻的 Agent 实例，而是可调度、可替换的执行服务。

常驻实例听起来自然，也不用异步，但有个死结：实例不可替代。它挂了任务跟着挂，它慢了任务跟着慢，它的 Harness 过时了，任务只能跟着过时。把执行 Loop 做成无状态、状态放进数据库，今天用这个 Harness、明天换那个，对上层透明。并行度的上限，就从"你有几个实例"变成"你有多少算力"。

3. Router 凭什么知道派给谁

这是整套设计里最容易糊弄过去、也最关键的一环。

如果 Router 真能很轻量，小模型能不能担这个责任？在一个会话里用旗舰模型聊久了都会出幻觉，何况它要理解、调度、裁决全局上下文。更麻烦的是误判代价：一句"帮我把那个临时文件删掉"，历史里恰好有个同名文件，删错的可能就是重要工作。这不是"答得不好"，是不可逆。

所以 Router 可行的前提不是它多聪明，而是它看到的上下文有边界。

工作场景天然自带边界：A 专项群和 B 专项群讨论的事不一样，一个群本身就是一个自带边界的工作区；一个仓库、一个 PR、一张工单，同理。边界一旦可控，很多判断就不必交给模型猜：谁能访问、在哪个项目里访问，几条代码规则写死就行，回归到 workflow 的思路。

4. 链式召回：把上下文窗口当缓存

长任务必然沉淀出远超窗口的上下文。只压缩会丢早期信息，全塞进去又挤占窗口、稀释注意力。DSH 文档里有句话说得挺直接：浪费上下文窗口，就是浪费模型的智能。

它的解法是链式召回：系统里每个对象都有 ID，构成一张引用关系图；每次送给模型时只内联摘要和 ID，需要细节再现时顺着 ID 逐跳去取。上下文窗口从仓库变成了缓存。

5. 事件驱动与订阅直通

单会话时代，输入是你敲的那句话。长程时代，主要输入变成环境里发生的事：群里有人说话、CI 跑完了、有人提了 PR、监控报警了。

人只是其中一个来源，不再是唯一来源。于是要做三件事：把海量事件接进来（文档里叫 Trigger），筛出值得处理的，再决定往模型窗口里塞什么。

这里有个聪明的取舍：如果每条消息都让 Router 重新判断一次，Router 自己就成了瓶颈。所以同一个 IM 话题、同一个工作区、同一个 PR 下的消息构成一条 Thread，Router 与订阅过的 Thread 建立直接关系，后续消息由程序直送 Worker，不再经过 Router------只有没被订阅过的新消息才需要它判断。这套多对多订阅关系，思路和消息系统的发布订阅是一回事：先确定归属、建立订阅，之后按已有关系投递。

6. 独立巡检：故障不是崩了，是没进展

长期在线系统很难只靠内部逻辑保证可靠，通常要在外面放一个独立控制回路，像 k8s 的控制器。

Agent 场景的难点在于：很多故障不是进程挂了，而是任务原地打转。存活探测发现不了"模型在绕圈"，也发现不了"方向已经偏了"。所以这套设计里有一个独立的 Watchdog Session，用定时消息驱动它巡检：系统层面查报错和恢复失败，业务层面让模型判断每个任务有没有实质进展、方向有没有偏。发现异常就介入，偶发故障就持续复查。

7. 全双工与多信道：前台不该被后台堵住

经典 ReAct 循环里，模型发起一次同步的工具调用后，整个循环就阻塞了，直到工具返回，期间会话听不进任何新输入。

解法是把耗时的命令和子任务改成异步的 start() 与 stop()：start() 立刻返回"已启动"，循环不再等它；后台跑完，结果作为一条新事件投递回会话；跑太久，模型可以主动 stop()。前台响应和后台执行从此解耦。

配套的还有信道差异：面向单人终端的输出直接搬进群聊，很容易变成信息过载。文档里有一条很实在的硬性规定------IM 场景单次回复不超过 100 词。【发布前补：官方文档出处】这类规则看着琐碎，却决定了它在群里是"同事"还是"噪音"。

8. 端云协同：Sandbox 是 Agent 的工具，不是容器

模型干活需要的上下文，很大一部分要靠工具调用从仓库、本地文件、依赖服务里取。也就是说，执行环境本身也是一种上下文。

常见做法是把代码拉进云端沙箱、重建环境再跑。但真实环境往往复制不了：未提交的本地修改、私有凭据、本地配置、只在特定网络里可达的服务。

既然环境难以同步，那就不让环境跟着计算上云：云端 Agent 通过端侧一个轻量 daemon 按需接入真实环境，daemon 不存会话状态，只执行命令、返回结果。Sandbox 于是从"Agent 的容器"变成"Agent 的工具"------不是 Agent in the Box，而是 Sandbox as the Agent Tool。个人设备也就成了它的一只手，天然支持 BYOM（带上你自己的机器）。

Super-agent 总览

【事件源：IM / CI / PR / 监控】
            ↓
【Trigger：接入与筛选】
            ↓
【Router：值不值得做 / 交给谁 / 完成标准】
            ↓
【Thread 订阅关系】
   ├─ 已有订阅 → 【程序直送 Worker】
   └─ 新消息   → 【建立订阅】→【交给 Worker】
            ↓
【Worker 池：无状态、可替换执行】
            ↓
【状态库 + 链式召回：摘要 + ID】
            ↓
【Watchdog：巡检进展与方向】
            ↓
【异常介入 / 继续执行】

五、五个特点，一句话一个

• 可组装：加功能不用等官方，删功能不用忍------几行 YAML 就是全部。
• 安全是默认值：三档沙箱、两档审批，捆成"权限预设"；故障安全的默认值是最严格的 read-only；策略每会话独立，A 会话放宽不会连累 B。
• 扛得住长活：goal 默认最多自动续 256 轮，定时任务支持 cron 且重启后仍在，再加后台任务与上下文压缩，架构层面还有 Watchdog。【发布前补：256 轮出处】
• 会分工：一两个独立子任务用 subagent（默认只许一层），几十个用 workflow 脚本扇出；再往上是 Router/Worker 那一层。
• 能被嵌进去：headless 进 CI（不监听任何端口）、SDK 起 JSON-RPC、ACP 接编辑器、MCP 接外部工具。

六、上手：半小时到第一个真任务

安装

桌面版最省事，自带终端里就有 dsh，不用另配 Node。

Deepseek Harness 桌面端安装地址 ： https://www.deepseek.com/harness/

选工作区

工作区就是权限边界------你在哪个目录下启动，可写范围就是哪里。第一件事不是写提示词，是 cd 到该干的活那儿。

第一句话

别问"你能做什么"，那只会换来一段自我介绍。给它一件能验收的小事，同时给三样东西：路径、验收标准、边界。

读 reports/ 下这三个 csv，按月份汇总成一张表，写成 monthly.md。
金额保留两位小数，缺数据的行单独列在最后，别改原始文件。

你写得越像验收标准，它交付得越像成品。

选权限

读代码、做调研用 read-only + never；日常改代码用 workspace-write + ask；装依赖、动系统配置，用一次批准；容器或 CI 才用 danger-full-access。一个实用技巧：让它先在只读模式下出方案，你看完再放宽------很多返工，来自"它理解错了但已经把文件改了"。

三个立刻能用的场景

1. 整理混乱目录："先给我一份移动清单，我确认后再动手。"这句话把不可逆操作拆成了"可审阅的提案 + 执行"。

2. 塞进 CI：

dsh --profile headless "跑一遍测试，失败就定位到具体用例并给出建议，别改代码"

3. 每天替你盯一件事："每天早上九点，看一遍 release/ 的变更，版本号有更新就汇总成三条要点。"

教它规矩：技能

反复交代的流程别每次粘贴，写成技能：

---
name: weekly-report
description: 把本周变更整理成团队周报，按固定四段式结构
---
1. 读 `changes/` 下本周的 md
2. 按「进展 / 问题 / 风险 / 下周计划」归类，每条不超过 40 字
3. 输出到 `reports/weekly-<日期>.md`

放在 「项目」/.dsh/skills/（跟着仓库走）、「项目」/.agents/skills/（兼容别的 agent）或 ~/.dsh/skills/（自己的通用技能）。目录里只暴露名字和描述，正文用到才加载，放二十个也不容易撑爆上下文。

扩展它

界面侧边栏有"插件"页，命令行等价物是：

dsh plugin --profile web add <包名>

第三方插件有索引站 dshopen.org：把飞书、钉钉、企微、Telegram 接进来派活和审批的；给对话加 Monaco 编辑器、逐处采纳或回滚的；把 MCP 配置粘进去先给风险提示再写入的。装完不满意，改 cordis.patch.yml 关掉就行，不用卸载。【发布前核实：dshopen.org 的性质与安全性说明】

七、局限与风险

好话说完了，该说问题。

Router 那一层还在原型里。 上下文边界回答了"为什么可能可行"，但没有证明"一定可行"------边界之内仍然要判断，判断仍然会错，而错的代价不可逆。这是读到"Router 可以很轻量"时最值得追问的一句。

沙箱会先带来摩擦。 你可能会遇到"明明这个文件我能改，它却说没权限"。多数情况不是 bug，而是它在工作区之外。解法不是关沙箱，是把工作区设对，或者对那一次操作单独批准。

上下文是真花钱的。 让它"把这个文件读完再回答"，五千行的文件一次读完，账单会提醒你。更好的问法是"先 grep 出相关函数，再读那三处"。

它会过度自信。 模型的通病，Harness 治不好。有用的办法是在提示里明确要求"改之前先读""结论要指出依据在哪个文件第几行"。

别在陌生仓库里关审批。 网上克隆来的项目，postinstall 能干任何事。danger-full-access 该留给容器，不该留给主力机。

最后一条比前面五条都重要：它的上限不在功能多少，在它能进哪些系统、以什么身份进、被谁信任。 模型会趋同，算力会变便宜，Harness 会开源，这些都可能贬值；而"这个 agent 能进哪些系统"不会自己变便宜。所以各家都在抢入口、抢协议、抢身份体系。

八、回到那句话

"帮我把上周的测试报告整理成一页周报。"

现在我大概会这么回：把报告目录指给它，说清楚周报长什么样、哪些数据不能动、什么时候要，然后把窗口最小化，去干别的。二十分钟后回来，文件挂在对话下面。

这件事的意义不在于省了二十分钟，而在于：过去只有"人能做"的那一类工作，现在有一部分可以交出去了------不是交给一个更聪明的聊天机器人，而是交给一个能被约束、能被审查、能被复盘的执行环境。

至于它接下来要变成什么样，DeepSeek 给的方向是：会话退成实现细节，记忆、调度、审批、恢复都归系统，人只管设定目标和验收结果。这条路走不走得通，还得看 Router 那一层怎么落地。

但有个判断标准现在就能用：当你开始把"描述需求"变成"描述验收标准"，它就从玩具变成了工具。