DeepSeek Harness 实测：为什么现在 AI Agent 不只是靠模型？Harness、Skill、Sandbox 到底解决什么问题

最后更新于 2026 年 9 月 11 日。本文按官方仓库与子系统文档做实测核对，依据是 DeepSeek Harness 官方仓库、Skills 子系统说明 与 Process Sandbox 文档。

团队把 DeepSeek、Claude 或 Gemini 换了一轮，聊天质量上去了，真正落地时还是会在同一处摔倒：模型连续调用工具、改文件、跑脚本，却没有人能说清「这一步为什么发生、能不能回放、写到了哪、失败后该不该重试」。2026 年再谈 AI Agent，瓶颈已经不是「谁更会答」，而是谁能把一次任务安全地跑完。

结论先说：模型负责判断「下一步该做什么」；Harness 负责循环、会话和插件组合；Skill 负责把可复用的操作说明按需装进上下文，而不是一次性塞进系统提示；Sandbox 负责限制这次子进程能写哪些文件，并且在无法强制隔离时直接失败，而不是悄悄裸跑。三者缺一，演示能过、生产会漏。

8 月我们写过 DeepSeek Harness 架构解析，那篇看模块边界和工具管线。这篇只回答一个更日常的问题：你已经会调模型了，为什么还要这三层。

只换模型，解决不了哪三类翻车

把「更强的模型」当成 Agent 方案，通常会在三处同时失守，而且换一家供应商也救不回来。

第一类是循环失忆。一次任务要经过多次工具调用：列目录、读文件、改代码、跑测试。如果历史靠内存变量拼接，进程一重启、界面一切页，模型就不知道自己做过什么。更糟的是，排障的人看不到同一条事件日志，只能凭聊天截图猜。

第二类是说明书过载。团队把部署规范、代码风格、发单流程全写进系统提示。上下文被占满后，模型开始漏步骤；你再加一段「务必遵守」，它只会更吵，不会更稳。真正该发生的是：平时只让模型看见技能目录，真正动手时再加载那一份正文。

第三类是副作用裸奔。模型一旦能调 shell，就可能写到仓库外、改掉密钥文件，或在失败时把半成品留在磁盘上。没有按次决议的文件系统策略，你只能靠「别乱来」这种提示词纪律——这对生产没有意义。

这三类问题，换更大的上下文窗口也解决不了。窗口更大，只是让错误说明书住得更久；循环和隔离仍然要靠执行层。如果你已经在别的模型上踩过工具循环，可以把同一套纪律对照过来，例如我们写过 Claude 2026 的 Tool Use 与 Agent 治理：字段名不同，失败模式几乎一样。

Harness 解决什么：循环、会话、插件组合

DeepSeek Harness（dsh）把自己定位成开源 Agent Harness，而不是又一个聊天客户端。官方口号是 Everything is a Plugin：模型适配、系统提示、工具注册、会话日志、Agent 接口和默认循环，都被拆成可替换的包，再用 Cordis 组合起来。仓库仍标注开发者预览，兼容性破坏变更可能发生——这不影响你用它理解「执行层到底该干什么」。

实测里，Harness 真正替你扛住的是三件事。

• 循环归属。默认 agent-loop 只是 Agent 合约的一种实现。插件应依赖 Agent 接口，而不是把业务焊死在默认驱动上。目标不确定时走开放循环；有审批节点的业务，应把确定性工作流放在外层。
• 会话可重建。模型下一轮能看见的内容，应当能从 Session Log 推出来，而不是某个函数里的临时数组。原始分块事件留下来，是为了回放、界面和排障，不是为了好看。
• 组合可覆盖。Profile、Bundle 和 Patch 叠成运行时插件树。你要换模型提供者、沙箱后端或界面，优先打 Patch，而不是复制核心包。官方提供 dsh --profile web --dump-config 查看机器实际启动的配置树。

所以 Harness 解决的不是「模型聪不聪明」，而是谁驱动下一步、历史存在哪、哪一层允许被替换。没有这一层，Skill 没有稳定的加载时机，Sandbox 也没有稳定的调用方。

Skill 解决什么：按需加载的操作手册

官方把 Skill 写成可选指令，不是会话事件。模型平时只看到一份目录：排序后的 name 和经过截断、转义的 description，默认描述上限 500 字；正文、路径、来源和路由提示都不会提前灌进上下文。真正要用时，模型调用 skill({ name })，框架按当前会话的工作目录解析出获胜技能，再返回规范结果。

本地技能是 kebab-case 名称，接受目录包（SKILL.md）或扁平 Markdown。官方本地提供者按优先级扫根目录：项目 .dsh/skills 最高，其次 .agents/skills，再往后才是自定义目录、用户目录和打包技能。项目根是最近的 Git 根；没有仓库时退回当前工作目录。嵌套的 **/SKILL.md 递归发现不受支持——你不能把技能随便塞进深层文件夹指望被找到。

这一层解决的是「说明书何时出现」。把发版清单、代码审查口径、排障脚本用法做成 Skill，模型只在相关任务里加载；改正文不会重写旧的工具结果，下一次调用会读到新内容。目录变更会热更新，但不完整的发现结果不会覆盖上一份可用目录。

Skill 不是权限系统。它告诉模型怎么做，不决定模型能不能写到仓库外。没有 Sandbox，一份写得很清楚的「部署 Skill」反而更危险，因为它会把危险步骤写得更可执行。

Sandbox 解决什么：文件副作用隔离

官方 Process Sandbox 管的是同机子进程的文件副作用，不是网络、也不是进程可见性。容器、微虚机和远程执行被写成并列的能力缝，而不是 ctx.sandbox 的一种实现。本地提供者在 Linux 上走 bwrap / Landlock，在 macOS 上走 Seatbelt，在 Windows 上走受限令牌与 ACL。

模式只有三档，而且只有前两档会进入隔离提供者：

• read-only：拒绝写入；POSIX 运行器额外放行 shell 需要的 /dev/null。
• workspace-write：允许写会话工作区根目录，以及后端承诺的临时区。工作区根来自会话不可变的 cwd。
• danger-full-access：绕过隔离，调用方直接拉起原始 argv，不再走 ctx.sandbox。

实测里最有价值的纪律是失败即关闭：请求了隔离却找不到可用后端，必须抛 SANDBOX_UNAVAILABLE，禁止静默裸跑。执行策略按次决议，所以同一个提供者可以同时给 bash 只读、给子 Agent 可写状态目录，而不改全局状态。消费者还要分清两类失败：运行器自己没起来，和隔离生效后挡住了写操作——前者是基础设施故障，后者说明 Sandbox 在工作。

执行完整度还会报 full 或 partial。旧 Landlock ABI 和 Windows ACL 的部分边界会被标成 partial。你若需要绝对承诺，就不能把 partial 当成已经锁死。

三者怎么串成一次任务

把一次「修测试并提交补丁」摊开，三层的分工就不再抽象。

1. Harness 从 Session Log 重建上下文，注入当前可见的技能目录（只有名字和描述）。
2. 模型决定先加载 repo-test-patch 这类 Skill，而不是凭记忆编步骤。
3. skill 工具按 cwd 读出正文，返回指令和相对资源提示。
4. 模型再请求读文件或跑测试；Harness 走工具管线，Sandbox 按这次策略包住 argv。
5. 工具结果写回 Session Log。下一步仍从日志推导，而不是从某个全局变量里「记得差不多」。

缺 Harness，你没有稳定的目录注入和结果落盘；缺 Skill，系统提示会被说明书撑爆；缺 Sandbox，Skill 写得越清楚，越像一份越权操作手册。三层是互补，不是三套重复功能。

实测怎么跑、怎么写一个 Skill

官方推荐的最快启动是 npx @deepseek-ai/dsh web，默认在 http://127.0.0.1:3080 打开 Web UI。从源码构建则是克隆仓库后 pnpm install && pnpm run build && pnpm dsh web。SSH 远程拉起时，它通常只打印主机 URL，本地转发地址交给你的 SSH 客户端。

写第一个项目技能，按官方发现顺序放在仓库根下：

---
name: repo-test-patch
description: 只在需要改测试并提交补丁时使用。先跑失败用例，再改最小范围。
---

# repo-test-patch
1. 在工作区根目录确认当前分支。
2. 先跑失败测试，不要先改生产代码。
3. 补丁只覆盖失败用例相关文件。
4. 不要触碰工作区以外的路径。

名称必须是 kebab-case。目录包用 SKILL.md，不要指望深层嵌套会被扫到。frontmatter 里的 disable-model-invocation 和 user-invocable 控制模型和人能不能从目录里看见它；两者都关掉时，只有受信任的 ctx.skills.get() 调用方还能加载。

跑起来后先看三件事：会话里是否出现过技能目录消息；调用 skill 后返回的是正文而不是把整份手册提前贴进系统提示；在 read-only 下往工作区外写文件，应被后端挡住，而不是「提示词说了不要写」却仍然写成功。若隔离后端不可用，进程应报错退出，而不是继续裸跑。

仓库仍是开发者预览。把 DeepSeek Harness 当架构样板做验证可以，把它当已经完成生产认证的平台还太早。你要验收的是循环、目录和隔离这三条路径，不是某一个演示视频。

什么时候该上完整栈，什么时候别上

和自研一个「while 循环 + 几个工具」相比，DeepSeek Harness 的收益是模块边界、会话重建和按次隔离已经分开；成本是 Cordis 组合模型、预览阶段的破坏性变更，以及团队必须分清 Skill 与 Sandbox 不是一回事。每年如果你真的会换模型后端、换沙箱实现或把技能目录交给多个仓库，这套拆分才值。

最后一句话：2026 年把 Agent 做稳，靠的不是再换一家更会聊天的模型，而是把判断、循环、说明书和文件边界拆开。Harness 管跑完，Skill 管按需说明，Sandbox 管这次能写到哪。三者齐，演示才能变成可审计的任务。

常见问题