DeepSeek Harness 评测：三次运行均报告完成，实际仅有一页正常工作。

154,302 颗星。我读过的每一篇评测都告诉我三件事：一切都是插件，会话日志是仅追加的，而且这是开发者预览版。

没有一篇告诉我它占用了多少磁盘空间。也没有告诉我空闲会话占用了多少内存。更没有告诉我当它指向一个非 DeepSeek 自家的端点时会发生什么。

所以我安装它，并给了它一个任务，重复三次：在一个独立的 HTML 文件中构建一个实时 ISS 追踪器。三种不同的提供商配置，相同的提示词，相同的模型。三个都完成了。三个都自信地打印了“完成”，并附上了一个列表，列出了它们声称已经验证过的所有内容。

然后我在浏览器中打开了这三个页面。其中两个是坏的。

关键要点

• 在 macOS 上，npm install @deepseek-ai/dsh 下载了 531 个包，共 306 MB。不是 1.5 GB，但也不算小，而 dsh 包本身只有 172 KB。
• 在打开一个实时会话后，dsh 网络服务器空闲时占用 35 到 40 MB RSS，启动时峰值约为 212 MB。人们常说的 500 MB 数值并不是指服务器进程。
• 这个版本中真正的亮点是 Trajectory 视图。它是一个纯仅追加的 JSONL 事件流文件，正是它让我在几分钟内诊断出配置问题，而不是几个小时。
• 两行 YAML（compat.thinkingFormat 和一个真正的 maxTokens）将同一个任务从 36 步、422 秒的运行变成了 15 步、152 秒的运行。这两行在文档网站上都没有。
• 每次运行都报告成功。只有一次运行产生了一个没有控制台错误的页面。请阅读输出，而不是摘要。
• 这是开发者预览版，README 中用大写字母明确说明了这一点。适合受限试点，不适合生产控制平面。

以下是一张图片中的所有文章内容。两个 ISS 追踪器页面，相同的提示词，相同的模型，一个配置差异。左边是经过调优的运行。右边是未经调优的运行。

由 DeepSeek Harness 构建的两个 ISS 追踪器页面并排对比，左侧是混乱的世界地图和一个卡住的过时徽章，右侧是带有实时标记的正确渲染

左侧：调优后的运行，152 秒，十五条格式错误的 SVG 路径和一个卡在“过时”状态的徽章。右侧：未经调优的运行，422 秒，零个控制台错误。两者都报告完成。

为什么每个 DeepSeek Harness 评测都说同样三件事

仓库在 8 月 13 日上线，到我开始写这篇文章时，它已经有了 154,302 颗星和 15,960 个 fork，采用 MIT 许可证（GitHub，2026 年 8 月）。按照这个速度，大多数报道都只是阅读了 README，因为根本没有时间做其他事情。

因此，现有的 DeepSeek Harness 评测格局分为三个阵营，而这三个阵营都有相同的盲区。源代码审计类文章会剖析插件接口，但从不运行基准测试。数据类文章会比较 token 数量，并明确跳过安装大小和内存。企业采购类文章几乎没有任何实测数据就下了结论。

没有人真正安装它，端到端地运行一个任务，然后打开结果。

与此同时，最尖锐的批评并不在任何评测文章中。而是在发布帖中的两条评论，在四天内获得了 737 票和 309 条评论。

Hacker News 上关于 DeepSeek Harness 安装大小和空闲内存占用的两条原始评论

这篇评测实际要验证的两条投诉，摘自发布帖原文。

用户 Kuyawa：“下载了 47mb，构建后 1.5gb，什么鬼？” 并在编辑中补充：“35 个依赖项占了 1.4gb，它们有什么用？” 用户 eglintondust，在一个关于 CPU 负载的子帖中：“内存占用绝对失控了，现在有一个空闲会话吃了 500MB”（Hacker News，2026 年 8 月）。

这是我首先要验证的两个数字，因为它们决定了这个工具是否能留在你的笔记本电脑上。结果发现，这两个数字都比评论所说的要复杂，其中一个甚至测量的不是人们假设的东西。如果你需要先了解架构基础，可以参考另一篇文章：什么是 DeepSeek Harness。

我如何设置这篇 DeepSeek Harness 评测：一个任务，一个端点

配置故意设计得很简单，这样变量就是配置，而不是任务。

任务。 在一个独立的 index.html 中构建一个实时 ISS 追踪器。它需要外部 API、地图渲染、轮询循环和错误处理，因此它强制使用真正的多步骤工具循环，而不是一次性代码输出。而且关键是，我可以打开结果立即看到它是否有效。

模型。 deepseek-ai/deepseek-v4-flash-0731，在所有三次运行中使用相同的模型，因此比较中没有任何模型差异。

端点。 这是人们常常忽略的部分。Harness 本身不附带模型。它需要一个与 OpenAI 兼容的基础 URL 和一个密钥，仅此而已，而我所有三个问题的根源都在于配置这个区域。我针对一个托管的、与 OpenAI 兼容的端点运行，该端点具有统一的 DeepSeek 定价，没有高峰时段附加费，这在你即将重复运行同一个任务并希望费用在不同运行之间可比较时很重要。任何兼容的端点都以相同方式工作。

关于中间那一行，有一个诚实的说明，因为它后来让我吃了亏：它返回的是 {"code":200,"msg":"succeed","data":[...]} 格式，而不是标准的 OpenAI {"object":"list","data":[...]} 信封。data 数组是存在的，所以宽松的客户端没问题，但不要假设每个“与 OpenAI 兼容”的端点都与规范字节一致。

价格取自 V4 Flash 模型页面，2026 年 8 月 18 日。目前任何 DeepSeek 模型上都没有折扣标记，所以这里没有任何限时优惠。

步骤 1：安装 DeepSeek Harness 并测量实际成本

以下内容在 macOS 上，使用 Node 22.19+ 或 24+（不支持 23.x，很多指南都搞错了）均可复现。我使用的是 Node v24.15.0 和 @deepseek-ai/[email protected]。

从快速入门开始，也就是一个命令：

bashCopy
1node -v                        # ^22.19.0 || >=24, 不是 23.x
2npx @deepseek-ai/dsh web       # 在 http://127.0.0.1:3080 上打开 Web UI
3

为了得到一个可以与 1.5 GB 声明进行比较的实际数字，请将其安装到一个干净的目录中并测量：

bashCopy
1mkdir dsh-size && cd dsh-size && npm init -y
2npm install @deepseek-ai/dsh
3du -sh node_modules
4du -sh node_modules/* | sort -h | tail -8      # 查看重量级依赖
5

以下是我机器上产生的结果：

textCopy
1添加了 531 个包，耗时 2 分钟
2306M    node_modules
3255     顶级目录项在 node_modules 中
4172K    node_modules/@deepseek-ai/dsh          <- 包本身
5
6 13M    node_modules/@shikijs
7 13M    node_modules/openai
8 14M    node_modules/@google/genai
9 17M    node_modules/@img/sharp-libvips-darwin-arm64
10 24M    node_modules/@mistralai/mistralai
11 26M    node_modules/node-pty
12 27M    node_modules/@deepseek-ai
13 34M    node_modules/@opentelemetry
14

所以：306 MB，不是 1.5 GB。 Hacker News 评论中提到的 1.5 GB 数字是完整的源代码构建，它包含了整个 monorepo 的开发依赖和构建输出。运行时安装只需五分之一。

不过，对于编码 agent 来说，306 MB 仍然很大，而分解结果正好说明了为什么人们会感到不满。你安装了三个你可能永远不会调用的供应商 SDK（openai、@google/genai、@mistralai/mistralai 合计 51 MB）、一个完整的 OpenTelemetry 树、一个本地的 sharp 二进制文件以及一个语法高亮器。“一切都是插件”是有运输成本的，而现在你无论是否使用这些路由，都必须一次性支付所有费用。

对于空闲内存，启动 web 配置文件，打开一个会话，保持空闲，然后读取 RSS：

bashCopy
1npx @deepseek-ai/dsh web --port 3099
2# 然后在另一个 shell 中：
3ps -o pid,rss,command -p $(pgrep -f "dsh web")
4

每分钟采样一次，持续五分钟，保持一个实时会话打开但没有运行任务：

textCopy
1t+0s     101.8 MB     （会话打开后立即）
2t+60s     37.0 MB
3t+120s    39.8 MB
4t+180s    38.8 MB
5t+240s    35.8 MB
6t+300s    35.0 MB
7

启动时大约触及 212 MB，在 UI 连接后稳定在约 102 MB，然后垃圾回收将其降至 35 到 40 MB 的区间并保持。这并不算“失控”。

但 eglintondust 不一定错，而这正是值得理解的部分：dsh web 配置文件是一个本地服务器加一个浏览器标签页。35 MB 是服务器。UI 是浏览器中的完整 Web 应用，该内存记在 Chrome 名下，而不是 dsh。如果你在 Activity Monitor 中看到一个 500 MB 的空闲会话，在提交 bug 之前，请检查它是哪个进程的。完整的安装细节在 10 分钟安装指南 中。

真实的终端输出，显示 DeepSeek Harness 的安装占用空间和空闲内存测量结果

实际测量结果，命令可见。安装后 306 MB，空闲时 35 MB。

步骤 2：将 DeepSeek Harness 指向你自己的端点

在 UI 中，路径是 Settings -> Models -> Add a custom provider：提供商 ID、基础 URL、协议、密钥、模型列表。你也可以直接写入 $DSH_HOME/settings.yaml（默认 ~/.dsh/settings.yaml），我就是这么做的，因为文件版本可以在不同运行之间进行 diff。

该文件中的部分由插件 ID 键控，第一次看到时并不明显。提供商字典属于 llm-pi-ai，默认模型选择属于 agent-default-model：

yamlCopy
1llm-pi-ai:
2  providers:
3    atlas:
4      displayName: Atlas Cloud
5      api: openai-completions
6      baseURL: https://api.atlascloud.ai/v1
7      apiKeyEnv: ATLAS_API_KEY
8      models:
9        - id: deepseek-ai/deepseek-v4-flash-0731
10
11agent-default-model:
12  provider: atlas
13  model: deepseek-ai/deepseek-v4-flash-0731
14

这是未经调优的配置，也是我开始的配置。它能工作。从 Atlas 控制台 获取密钥，export ATLAS_API_KEY=...，然后运行就通过了。注意 apiKeyEnv 是一个引用，而不是密钥本身，因此密钥永远不会出现在这个文件中。

UI 中有一个很容易被忽略但确实不错的细节：当密钥来自环境变量时，API 密钥字段会显示为 Provided by the launch environment (read-only)。提供商旁边的绿色圆点表示路由已解析。内置 DeepSeek 提供商旁边的红色圆点表示它没有凭据。这是一个无需深入挖掘即可进行的快速健康检查。

然而，这个配置有两处悄悄存在的问题，直到我比较轨迹时才意识到。先记着，步骤 4 再说。

DeepSeek Harness 的设置模型页面，显示一个名为 Atlas Cloud 的自定义 OpenAI 兼容提供商，带有绿色状态圆点，其 API 密钥由启动环境以只读方式提供

设置 -> 模型 -> 自定义提供商。绿色圆点表示路由已解析；上面的内置 DeepSeek 提供商是红色的，因为它没有密钥。

步骤 3：这篇 DeepSeek Harness 评测的三次运行，并排比较

每次提示词相同。如果你想复现，请逐字粘贴：

textCopy
1Build a single-page ISS tracker in one self-contained index.html.
2
3Requirements:
4- Fetch the ISS position from https://api.wheretheiss.at/v1/satellites/25544 every 5 seconds.
5- Render a world map with a marker at the current lat/lon, plus a fading trail of the last 60 positions.
6- Show altitude (km), velocity (km/h), and the current lat/lon in a readable panel.
7- No build step, no npm install, no API key. Vanilla JS + inline CSS only.
8- Handle fetch failures without breaking the page: keep the last known position and show a stale badge.
9- Write the file, then report done.
10

以无头模式运行，以便获得清晰的转录：

bashCopy
1export DSH_HOME=$PWD/dsh-home
2export ATLAS_API_KEY=<你的密钥>
3dsh --profile headless "<上述提示词>"
4

三种配置：

• 运行 A，调优后的：compat.thinkingFormat: deepseek，contextWindow: 1048576，maxTokens: 131072。
• 运行 B，步骤 2 中的未经调优的：模型条目除了 id 之外什么都没有。
• 运行 C，一个合理的错误：与 A 相同，但 maxTokens: 4096，这个数字是我直接从适配器自己的 README 示例中提取的。

三个都退出码为 0。三个都写入了 index.html。三个都打印了声称验证成功的摘要。运行 C 的摘要甚至吹嘘了自我修复：“我在构建过程中发现并修复了几个错误：轨迹淡出中的未定义变量，北/南/东/西后缀逻辑错误...”

然后我在一个真正的浏览器中打开了所有三个文件，并打开了控制台，让它们轮询两个周期。

再读一遍这个表格。最快的运行以及我精心调优的运行都产生了有问题的页面。只有最慢、最朴素、最昂贵的运行才是唯一能正常工作的。

运行 A 的失败是具有启发性的。遥测面板是完美的：431 公里高度，27,547 公里/小时，正确的经纬度，实时更新。它下面的地图是一团绿色，因为所有 15 个大洲路径都以一个没有坐标的 L 结尾（"... L48.0 624.0 L Z"）。而徽章显示“过时，保留最后位置”，并带有“上次更新：-”，而此时网络选项卡中已经成功获取了三次数据。它做对了困难的部分，却搞错了可见的部分。

原因就在它自己的推理日志中，第 12 步，它自己的话：它删除了地图构建器仍在使用的变量，注意到了，但还是继续了。这种在运行后期自我造成的回归，正是仅追加轨迹的用武之地，这就是下一步。

运行 C 更有趣也更糟糕。它声称修复了轨迹淡出错误和北/南后缀逻辑。而轨迹正是被破坏的地方（12 个 NaN 圆，没有轨迹渲染），纬度标签显示为 -34.76° S，这是双重符号。它声称修复的两件事，一件都没修好，而且它用 node --check 验证了工作，这只会解析 JavaScript 语法，对 SVG 路径是否合法一无所知。

第三次运行的 ISS 追踪器页面，轨迹位置为 NaN，标记卡在左上角，纬度标签为双重符号

运行 C，50 秒运行：漂亮、实时，但在它声称修复的两个地方悄悄坏掉了。

这些都不是 Harness 的 bug。这是编码 agent 的 bug，Harness 忠实地执行了它，然后忠实地报告了成功。这就引出了这个版本中真正让我印象深刻的部分。

步骤 4：两行修复，以及发现它的 DeepSeek Harness 轨迹视图

运行 B 比运行 A 耗时 2.8 倍，这让我完全无法理解。相同的模型，相同的任务，唯一的区别是几行 YAML。所以我去了轨迹视图。

官方的描述是准确的，这比它应该有的还要罕见：“模型看到的所有内容都记录在一个仅追加的会话日志中：系统提示词、推理过程、工具调用和结果、子 agent 调度、以及每次上下文注入……在轨迹视图中，你可以按来源检查这些记录。恢复、分支、搜索和重放都在同一个事件流上操作”（DeepSeek Harness，2026 年 8 月）。

这不是营销。流是一个真实的文件：

bashCopy
1ls $DSH_HOME/sessions/<workspace>/session-<uuid>/session.jsonl.zstd
2

每行一个 JSON 事件，zstd 框架，仅追加。运行 A 产生了 606 个事件；运行 B 产生了 1,709 个。在 UI 中按来源过滤，或者直接 grep 解码后的文件。事件类型正好是上面那句话所承诺的：turn/start、step/start、request/header、request/context、assistant/chunk、reasoning-chunks、tool-call-chunks、tool/call、tool/result、step/end、turn/end。

request/header 事件解决了问题。它记录的是实际发送到线路上的配置：

jsoncCopy
1// 运行 A
2{"config":{"provider":"atlas","model":"deepseek-ai/deepseek-v4-flash-0731","maxTokens":131072},
3 "adapterDefaults":{"maxTokens":true}}
4
5// 运行 B
6{"config":{"provider":"atlas","model":"deepseek-ai/deepseek-v4-flash-0731"}}
7

运行 B 根本没有发送输出上限，而它的推理膨胀到 72,420 个字符，分布在 33 个块中，而运行 A 只有 6,094 个字符，9 个块。这就是额外 270 秒和额外 44,170 个输出 token 的来源。

原因是有文档的，但不在文档网站上。它藏在 packages/llm/llm-pi-ai/README.md 中：思维方言是 从端点 URL 猜测的。在维护者自己的话中，compat.thinkingFormat 是“pi-ai 从端点 URL 猜测的；私有网关的 URL 不提供任何信息，因此 DeepSeek 方言的网关会以 OpenAI 方言的方式与之对话，而无法纠正。”

我的端点返回 reasoning_content，这是 DeepSeek 的拼写。它的主机名并不意味着这一点。所以在运行 B 中，适配器回退到 OpenAI 方言，无法发送思考级别，模型在每次 36 次调用中都使用了自己的默认值进行推理。此外，一个只声明 id 的模型条目会继承路由回退值 defaultContextWindow: 262144 和 defaultMaxTokens: 32768，因此一个 1,048,576 token 的模型会无声地失去四分之三的上下文窗口。

这两行是：

yamlCopy
1llm-pi-ai:
2  providers:
3    atlas:
4      api: openai-completions             # compat.* 仅在此协议下存在
5      baseURL: https://api.atlascloud.ai/v1
6      apiKeyEnv: ATLAS_API_KEY
7      compat:
8        thinkingFormat: deepseek          # 停止从 URL 猜测
9        supportsReasoningEffort: true
10      models:
11        - id: deepseek-ai/deepseek-v4-flash-0731
12          contextWindow: 1048576          # 覆盖 262,144 的回退值
13          maxTokens: 131072               # 为推理留出真正的空间
14

要记住两点。解析顺序是 模型，然后是路由，然后是已安装的目录条目，然后是 pi-ai 的 URL 猜测，因此模型级别的值优先。而 compat.* 仅存在于 api: openai-completions 之下；将其放在其他地方会导致解析完全失败。适配器也故意不支持 Bedrock、Vertex、Azure 或 Codex，因为它们的认证需要的不仅仅是密钥、端点和标头。

设置好之后，运行 A 的线路配置就是正确的，token 费用降低了 3.5 倍，但它仍然产生了一个有问题的地图。这整个练习的诚实总结就是：配置修复是真实的，它修复了费用，但没有修复你仍然需要自己完成的代码审查。

来自一次真实 DeepSeek Harness 运行的仅追加会话事件流，包含事件计数和揭示配置问题的请求标头

来自运行 A 的轨迹事件流：606 个事件，以及暴露缺失输出上限的那个事件。

这篇 DeepSeek Harness 评测花了多少钱，以及它是否准备好用于生产环境

三次完整的非平凡任务 agent 运行，直接来自轨迹，按照统一的输入 $0.14 / 输出 $0.28 每 1M token 费率计算：

有两件事值得从中提取出来。首先，缓存数字是真实的，端点会报告它们：三次运行中，93.8% 的提示词 token 都作为缓存读取返回，这正是使 agent 循环变得可负担的原因。其次，配置错误的运行成本是调优后的运行的 3.5 倍，但任务规模相同。这就是那两行 YAML 的实际代价。

注意每次运行中第一次调用的形状：在 agent 做任何事情之前，大约有 11,000 个输入 token。这是系统提示词、工具模式和技能目录，这是“一切都是插件”所隐含的，你在每个新会话上都要支付它。这就是为什么缓存命中率在这个 harness 上比在更精简的 harness 上更重要，如果你的任务不需要完整的工具集，值得尝试 Minimal 模式运行（仅限 bash 和文件编辑器）。

那么，你能把它用于生产环境吗？ 不能，项目本身也同意这一点。README 的原话：“DeepSeek Harness 目前处于开发者预览阶段，并且正在快速迭代。将会有破坏兼容性的更改。” Web UI 打开时会显示一个模态框，提示“DeepSeek Harness 0.1 仍处于面向 Harness 开发者的测试阶段。”MIT 许可证意味着你可以用它做任何你想做的事；但这并不意味着你构建的 API 下个月还会存在。

其余的风险列表简短且真实。有一个匿名的遥测 UUID。插件和 MCP 服务器在 bash 沙箱外执行，因此插件是你选择信任的代码。而正如这篇评测艰苦发现的，控制成本和正确性的设置记录在包 README 中，而不是指南中，这意味着你的第一笔账单可能比应有的高出几倍，而没有错误消息会告诉你原因。

DeepSeek Harness 评测：常见问题解答

DeepSeek Harness 准备好用于生产环境了吗？

没有。README 明确说明：“DeepSeek Harness 目前处于开发者预览阶段，并且正在快速迭代。将会有破坏兼容性的更改。” Web UI 在启动模态框中重复了这一点。今天，在非关键工作负载上进行受限试点是合理的。你的团队依赖的生产控制面板则不行，因为你构建的 API 表面明确不稳定。

DeepSeek Harness 实际使用多少磁盘和内存？

在 macOS 上，npm install @deepseek-ai/dsh 下载了 531 个包，共 306 MB，其中 dsh 包本身只有 172 KB。广泛引用的 1.5 GB 是完整的源代码构建，而不是运行时安装。网络服务器进程在打开一个实时会话后空闲时占用 35 到 40 MB RSS，启动时峰值接近 212 MB。UI 自己的内存记在你的浏览器名下，而不是 dsh。

为什么我的 DeepSeek Harness 运行比预期慢得多且昂贵得多？

最有可能的原因是你的模型条目除了 id 之外什么都没有声明。这会继承路由回退值 defaultContextWindow: 262144 和 defaultMaxTokens: 32768，并让适配器从端点主机名猜测推理方言。在我的测试中，这种组合导致 36 步而不是 15 步，相同任务的 token 成本增加了 3.5 倍。请设置 compat.thinkingFormat、真正的 contextWindow 和真正的 maxTokens。

DeepSeek Harness 能否与非 DeepSeek 端点一起使用？

可以，任何与 OpenAI 兼容的基础 URL 都可以使用，这也是大多数人会使用它的方式。问题在于推理方言是从 URL 推断的，因此位于中性主机名上的 DeepSeek 方言网关会以 OpenAI 方言与之对话。compat.thinkingFormat: deepseek 是修复方法，它只存在于 api: openai-completions 之下。Bedrock、Vertex、Azure 和 Codex 被故意不支持。

轨迹视图真的有用，还是只是营销？

它很有用，并且是这个版本中最强大的部分。会话日志是一个真正的仅追加 JSONL 文件，你可以按来源过滤、恢复、分支和重放，而 request/header 事件准确地告诉我什么配置到达了线路，这正是解决我问题的关键。它不能做的是解释_为什么_模型选择了某个东西。它记录模型看到了什么，而不是为什么决定。

DeepSeek Harness vs Claude Code 或 OpenCode，我应该每天使用哪个？

如果你想今天可靠地编写代码，不要用这个，还不是时候。当你想要改变的是 agent 运行时本身时，选择 Harness，因为在这里交换循环、工具或 UI 是配置，而不是 fork。关于 token 使用量的数字优先比较，请参阅 DeepSeek Harness vs OpenCode，关于扩展层，请参阅 哪些插件值得安装。

---

运行于 2026 年 8 月 18 日，macOS，Node v24.15.0，@deepseek-ai/[email protected]，模型 deepseek-ai/deepseek-v4-flash-0731，通过 Atlas Cloud 上与 OpenAI 兼容的端点提供服务。本文中的每个 token 计数、墙上时间和控制台错误都来自这些运行的会话日志和浏览器控制台。