DeepSeek 測試工具回顧：所有三次運行皆回報完成。但實際上只有一個頁面正常運作。

154,302 個星。我讀過的每一篇評論都告訴我同樣三件事：一切都是外掛、會話記錄是僅附加的，以及這是開發者預覽版。

但沒有一篇告訴我它會吃掉多少磁碟空間，或是閒置會話會佔用多少 RAM，或是當你指向一個非 DeepSeek 自家的端點時會發生什麼事。

所以我安裝了它，並給了它一個任務，重複三次：建立一個單一自包含 HTML 檔案的即時 ISS 追蹤器。三個不同的提供者設定，相同的提示詞，相同的模型。三個都完成。三個都印出了自信的「完成」，並附上一個他們聲稱已驗證的所有項目的清單。

然後我在瀏覽器中打開了這三個頁面。其中兩個是壞的。

關鍵收穫

• npm install @deepseek-ai/dsh 在 macOS 上拉取了 531 個套件和 306 MB。不是 1.5 GB，但也不算小，而 dsh 套件本身只佔 172 KB。
• dsh 網頁伺服器在開啟即時會話後，閒置時約 35 到 40 MB RSS，啟動時峰值約 212 MB。人們常說的 500 MB 數字並非指伺服器行程。
• 軌跡視圖是這個版本中真正的亮點。它是一個磁碟上純僅附加的 JSONL 事件串流，讓我在幾分鐘內診斷出設定問題，而不是花費數小時。
• 兩行 YAML（compat.thinkingFormat 和一個真正的 maxTokens）將同一個任務從 36 步、422 秒的運行，變成了 15 步、152 秒的運行。這兩行都不在文件網站上。
• 每次運行都報告成功。只有一個產生的頁面完全沒有主控台錯誤。請閱讀輸出，而不是摘要。
• 這是開發者預覽版，README 以大寫字母標明。可以進行受控試行，還不能當作生產控制平台。

這裡是整篇文章的一張圖。兩個 ISS 追蹤器頁面，相同的提示詞，相同的模型，一個設定差異。左邊是我調整過的運行，右邊是我沒調整的運行。

由 DeepSeek Harness 建立的兩個 ISS 追蹤器頁面並排比較，左邊是地圖錯亂且標籤卡住，右邊是正確渲染並顯示即時標記

左：調整過的運行，152 秒，十五個畸形的 SVG 路徑和一個卡在「過時」的標籤。右：未調整的運行，422 秒，零個主控台錯誤。兩者都報告完成。

為什麼每篇 DeepSeek Harness 評論都說同樣三件事

這個儲存庫在 8 月 13 日上線，到我開始寫這篇文章時，它已經在 MIT 授權下擁有 154,302 個星和 15,960 個分支（GitHub，2026 年 8 月）。以這種速度，大多數報導只是閱讀 README，因為沒有時間做其他事情。

所以現有的 DeepSeek Harness 評論格局分為三類，而這三類都有相同的漏洞。原始碼審查文章挑選插件接縫，卻從未執行基準測試。數據文章比較 Token 數量，並明確跳過安裝大小和記憶體。企業採購文章幾乎沒有測量數字就得出結論。

沒有人安裝它、端到端執行一個任務，然後打開結果。

與此同時，最尖銳的批評不在任何評論中，而是在發布討論串的兩個留言，它們在四天內獲得了 737 分和 309 則回覆。

兩個關於 DeepSeek Harness 安裝大小和閒置記憶體使用量的 Hacker News 原文留言

這篇評論實際嘗試驗證的兩個抱怨，直接引用自發布討論串。

使用者 Kuyawa：「下載 47 MB，建置後 1.5 GB，搞什麼？」以及編輯後：「35 個依賴項佔了 1.4 GB，它們是做什麼用的？」使用者 eglintondust，在一個關於 CPU 負載的子討論串中：「記憶體使用量肯定失控了，現在有一個閒置會話吃掉 500 MB」（Hacker News，2026 年 8 月）。

這是我首先想驗證的兩個數字，因為它們決定了這個東西能否留在你的筆電上。結果兩者都比留言所暗示的更複雜，而且其中一個衡量的是人們假設的不同東西。如果你需要架構基礎知識才能理解這些，那是另一篇文章：DeepSeek Harness 到底是什麼。

我如何設定這次 DeepSeek Harness 評論：一個任務，一個端點

設定故意很無聊，這樣變數就是設定，而不是任務。

任務。 建立一個即時 ISS 追蹤器，放在一個自包含的 index.html 中。它需要一個外部 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, not 23.x
2npx @deepseek-ai/dsh web       # Web UI on http://127.0.0.1:3080

為了得到一個可以與 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      # where the weight lives

這是我機器上產生的結果：

textCopy
1added 531 packages in 2m
2306M    node_modules
3255     top-level entries in node_modules
4172K    node_modules/@deepseek-ai/dsh          <- the package itself
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

所以：306 MB，不是 1.5 GB。 那個 Hacker News 留言中的 1.5 GB 數字是完整的原始碼建置，它會拉入整個單一儲存庫的開發依賴項和建置輸出。執行時期安裝只有那個的五分之一。

話雖如此，對於一個編碼代理來說，306 MB 仍然很大，而分解說明了為什麼人們會感到惱火。你安裝了三個你可能永遠不會呼叫的供應商 SDK（openai、@google/genai、@mistralai/mistralai 合計 51 MB）、一個完整的 OpenTelemetry 樹、一個原生的 sharp 二進位檔，以及一個語法高亮器。「一切都是外掛」有運輸成本，而現在無論你是否使用那些路由，你都要預先支付所有費用。

對於閒置記憶體，啟動網頁設定檔，打開一個會話，讓它閒置，然後讀取 RSS：

bashCopy
1npx @deepseek-ai/dsh web --port 3099
2# then, in another shell:
3ps -o pid,rss,command -p $(pgrep -f "dsh web")

在開啟即時會話且沒有任務運行的情況下，每分鐘取樣一次，持續五分鐘：

textCopy
1t+0s     101.8 MB     (right after the session opened)
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

啟動時觸及約 212 MB，UI 連接後穩定在約 102 MB，然後垃圾回收器將其降至 35 到 40 MB 的區間，並保持在那裡。這不是「失控」。

但 eglintondust 不一定錯，而這是值得理解的部分：dsh 網頁設定檔是一個本機伺服器加上一個瀏覽器分頁。那 35 MB 是伺服器。UI 是瀏覽器中一個完整的網頁應用程式，該記憶體會計入 Chrome，而不是 dsh。如果你在活動監視器中看到一個 500 MB 的閒置會話，請在回報錯誤之前檢查它歸屬於哪個行程。完整的安裝細節在10 分鐘安裝指南中。

實際的終端機輸出，顯示 DeepSeek Harness 安裝佔用空間和閒置記憶體測量值

實際測量值，附帶可見的命令。安裝後 306 MB，閒置時 35 MB。

步驟 2：將 DeepSeek Harness 指向你自己的端點

在 UI 中，這是「設定」>「模型」>「新增自訂提供者」：提供者 ID、基礎 URL、協定、金鑰、模型列表。你也可以直接將其寫入 $DSH_HOME/settings.yaml（預設為 ~/.dsh/settings.yaml），我就是這樣做的，因為檔案版本可以在運行之間進行差異比較。

該檔案中的區段以外掛 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

那就是未調整的設定，也是我開始使用的。它有效。從 Atlas 主控台 取得金鑰，export ATLAS_API_KEY=...，然後運行就通過了。請注意，apiKeyEnv 是一個參考，而不是秘密，因此金鑰永遠不會出現在這個檔案中。

UI 中有一個容易忽略且真正不錯的細節：當金鑰來自環境時，API 金鑰欄位會顯示為「由啟動環境提供（唯讀）」。提供者旁邊的綠點表示路由已解析。內建 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=<your key>
3dsh --profile headless "<the prompt above>"

三個設定：

• 運行 A，調整過的：compat.thinkingFormat: deepseek，contextWindow: 1048576，maxTokens: 131072。
• 運行 B，來自步驟 2 的未調整設定：模型條目只有 id。
• 運行 C，常見的錯誤：與 A 相同，但 maxTokens: 4096，這個數字是我直接從轉接器自己的 README 範例中抄來的。

三個都退出碼 0。三個都寫了 index.html。三個都印出了聲稱驗證的摘要。運行 C 的摘要甚至吹噓了自我修復：「在建置過程中我發現並修復了一些錯誤：軌跡淡入中的未定義變數、不正確的 N/S/E/W 後綴邏輯……」

然後我在真正的瀏覽器中打開了所有三個檔案，並打開主控台，讓它們輪詢兩個週期。

再讀一遍那張表格。最快的運行和我精心調整的運行都產生了壞掉的頁面。緩慢、未調整、最昂貴的運行是唯一一個正常運作的。

運行 A 的失敗頗具啟發性。遙測面板是完美的：431 公里高度、27,547 公里/小時、正確的經緯度，即時更新。它下面的地圖是一個綠色團塊，因為所有十五個大陸路徑都以一個沒有座標的懸空 L 結尾（"... L48.0 624.0 L Z"）。而標籤顯示「過時，保留最後位置」，附帶「最後更新：-」，而網路分頁中有三個成功的擷取。它正確處理了困難的部分，卻搞錯了可見的部分。

原因就在它自己的推理記錄中，在第 12 步，用它自己的話說：它刪除了地圖建構器仍在使用的變數，注意到了，然後繼續進行。這種在運行後期自我造成的回歸，正是僅附加軌跡的用武之地，也就是下一步。

運行 C 則更有趣也更糟。它聲稱修復了軌跡淡入錯誤和 N/S 後綴邏輯。軌跡正是壞掉的（十二個 NaN 圓圈，完全沒有軌跡渲染），而緯度標籤顯示 -34.76° S，這是雙重符號。它聲稱修復的兩件事都沒修好，並且它用 node --check 驗證了工作，這只會解析 JavaScript 語法，對於 SVG 路徑是否合法一無所知。

第三次運行的 ISS 追蹤器頁面，帶有 NaN 位置軌跡、卡在左上角的標記，以及雙重符號的緯度標籤

運行 C，50 秒的運行：漂亮、即時，但在它聲稱已修復的兩個地方悄悄地壞掉。

這些都不是真正的 Harness 錯誤。這是一個編碼代理的錯誤，Harness 忠實地執行它，然後忠實地報告為成功。這就引出了這個版本中真正讓我印象深刻的一個部分。

步驟 4：兩行修正，以及發現它的 DeepSeek Harness 軌跡視圖

運行 B 花費的時間是運行 A 的 2.8 倍，這對我來說毫無意義。相同的模型，相同的任務，唯一的差別是幾行 YAML。所以我去了軌跡。

官方描述是準確的，這比應有的更罕見：「模型看到的一切都記錄在一個僅附加的會話記錄中：系統提示詞、推理、工具呼叫和結果、子代理排程，以及每次上下文注入……在軌跡視圖中，你可以按來源檢查這些記錄。恢復、分支、搜尋和重播都在同一個事件串流上運作」（DeepSeek Harness，2026 年 8 月）。

這不是行銷。串流是一個真實的檔案：

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

一行一個 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// Run A
2{"config":{"provider":"atlas","model":"deepseek-ai/deepseek-v4-flash-0731","maxTokens":131072},
3 "adapterDefaults":{"maxTokens":true}}
4
5// Run B
6{"config":{"provider":"atlas","model":"deepseek-ai/deepseek-v4-flash-0731"}}

運行 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 評論花費了多少，以及它是否已準備好投入生產

三次非平凡任務的完整代理運行，直接來自軌跡，以統一的 $0.14 輸入 / $0.28 輸出每 1M 費率計算：

有兩件事值得從中提取出來。首先，快取數字是真實的，端點會報告它們：三次運行中 93.8% 的提示詞 Token 以快取讀取的形式返回，這正是讓代理迴圈變得負擔得起的原因。其次，設定錯誤的運行成本是調整後運行的 3.5 倍，用於相同大小的任務。這就是那兩行 YAML 的實際價格。

請注意每次運行中第一次呼叫的形狀：在代理做任何事之前，大約有 11,000 個輸入 Token。那是系統提示詞、工具架構和「一切都是外掛」所暗示的技能目錄，你每次新會話都要支付它。這就是為什麼快取命中率在這個 Harness 上比在較薄的 Harness 上更重要，以及為什麼如果你的任務不需要完整的工具集，值得嘗試最小模式（僅 bash 和檔案編輯器）。

那麼你能把它投入生產嗎？ 不能，而且專案同意你的看法。README 自己的話：「DeepSeek Harness 目前處於開發者預覽階段，正在快速迭代。將會有不兼容的變更。」網頁 UI 打開時會顯示一個模態視窗，上面寫著「DeepSeek Harness 0.1 仍在為 Harness 開發者進行測試。」MIT 授權意味著你可以隨意使用它；這並不意味著你針對建立的 API 下個月還會存在。

其餘的風險清單簡短而真實。有一個匿名遙測 UUID。外掛和 MCP 伺服器在 bash 沙箱外執行，因此外掛是你選擇信任的程式碼。而且正如這篇評論所發現的，控制成本和正確性的設定記錄在套件 README 中，而不是指南中，這意味著你的第一張帳單可能是應有的數倍，原因沒有錯誤訊息會告訴你。

DeepSeek Harness 評論：常見問題

DeepSeek Harness 是否已準備好投入生產？

否。README 清楚地說明：「DeepSeek Harness 目前處於開發者預覽階段，正在快速迭代。將會有不兼容的變更。」網頁 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 個，以及相同任務的 3.5 倍 Token 成本。請設定 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 與 Claude Code 或 OpenCode 相比，我應該每天使用哪一個？

如果你想要一個今天就能可靠編寫程式碼的工具，不是這個，還不是。當你想要改變的是代理執行時期本身時，選擇 Harness，因為在這裡交換迴圈、工具或 UI 是設定，而不是分支。有關 Token 使用量的數字優先比較，請參閱 DeepSeek Harness 與 OpenCode，至於擴展層，請參閱哪些外掛值得安裝。

---

運行於 2026 年 8 月 18 日在 macOS 上執行，使用 Node v24.15.0、@deepseek-ai/[email protected]、模型 deepseek-ai/deepseek-v4-flash-0731，透過 Atlas Cloud 上的 OpenAI 相容端點提供服務。本文中的每個 Token 計數、實際時間和主控台錯誤都來自這些運行的會話記錄和瀏覽器主控台。