延續 DeepSeek V4 Flash 0731 正式版的熱潮後，最近很熱門的 DeepSeek 又有新產品推出，是許多人期待的 DeepSeek Harness v0.1 開發者預覽版。這款工具採 MIT 開源授權，基於 Cordis 元框架打造，核心設計哲學在於一切都可以是外掛程式，以至於不論模型、工具、技能、沙箱、檔案系統、編排機制或 UI 介面，均可自由組合與替換，專為建構客製化 AI Agent 框架而設計。
為了驗證其在實際開發場景中的可用度，CyberQ 在128 GB 記憶體的 GB10 硬體環境上，將 DeepSeek Harness 0.1 接上本機執行的 ds4-server，進行了兩輪真實的 agentic 程式碼重構與執行任務實戰測試。
評測環境與測試總覽
| 評測項目 | 實測組態與數據 |
| Harness 版本 | 0.1.0-rc.6 |
| 推論模型 | DeepSeek V4-Flash IQ2XXS (量化版) |
| 推論後端 | ds4-server (:8000) |
| 執行硬體 | NVIDIA GB10 · 128 GB 記憶體 |
| 評測結果 | 全數測試項目一次通過 |
整體而言，DeepSeek Harness 在本機模型上的整合成本比預期低得多。僅需設定兩個環境變數，即可完成全套 Harness 與 ds4-server 的串接，過程中未修改任何一行外掛程式碼。兩輪任務均達成零工具錯誤，且經由獨立驗證確認多檔案重構產出完全正確。
零程式碼修改的整合機制與隱藏地雷
Harness 在 LLM 抽象層僅設計了兩個轉接器（adapter）。內建的 dsh-llm-deepseek 端點呢，可以直接讀取 DEEPSEEK_BASE_URL，其預設的模型目錄名稱正好為 deepseek-v4-flash 與 deepseek-v4-pro，這與 ds4-server 宣告的模型別名完全一致，所以對已經習慣使用 DS4 跑 deepseek-v4-flash的我們來算是比較好部署的環境。
在 ds4-server 端，API 功能支援相當完整。其 /v1/models 回報的 supported_parameters 包含 tools、tool_choice 與 reasoning_effort，底層二進位檔也完整支援 tool_calls 與 reasoning_content，並同時提供 OpenAI、Responses 與 Anthropic 三種協定端點。
CyberQ 這次使用的完整啟動設定相當簡潔，只要這樣：
DEEPSEEK_API_KEY=local-no-auth \
DEEPSEEK_BASE_URL=http://127.0.0.1:8000/v1 \
npx @deepseek-ai/dsh web
CyberQ 提醒維運的時候，
DEEPSEEK_BASE_URL後方的/v1切勿省略，因為轉接器內部是採用${baseURL}/chat/completions進行字串拼接的。
沉默失效的地雷設定與最佳化
轉接器預設的 defaultContextWindow 設定為 1,000,000，然而本機 ds4-up.sh 啟動時帶入的參數為 --ctx 100000。若未手動覆寫此設定，系統的壓縮（compaction）觸發門檻（0.8）將永遠無法達到，長對話會直接撞上 ds4 的上下文上限而中斷，且不會顯示任何警告訊息。
CyberQ 在這次的測試中，解決方式是將限制寫入 $DSH_HOME/settings.yaml。該設定支援熱重載（Hot Reload），修改後無需重啟服務，以下是我們的YAML：
llm-deepseek:
baseURL: http://127.0.0.1:8000/v1
defaultContextWindow: 100000
thinking: enabled
reasoningEffort: high
models:
- id: deepseek-v4-flash
contextWindow: 100000
maxTokens: 32768
AI Agentic 核心能力實測
測試一：基礎工具呼叫閉環
第一個測試要求 Agent 建立 fizzbuzz.py 檔案、使用 Python3 執行並回報結果，目的在於確認 tool-call 迴圈是否能順利閉合。
任務在 3 個步驟與 2 次工具呼叫內完成，達到 0 錯誤且輸出結果完全正確，JSON 格式保持完整無破損，證明即便在 DeepSeek V4 Flash IQ2XXS 這種極度壓縮的量化模型下，格式控制依然穩定。
測試二：多檔案邏輯重構
第二個測試建立了一個 115 行的 loganalyzer 套件，內含三個解析器模組，其中存在重複的時間戳解析與 IP 驗證邏輯。任務要求將重複程式碼抽離至新的 common.py、更新三個呼叫端、確保錯誤訊息不變、補齊新測試，最後執行 ./run_tests.sh 確保 5 個基準測試全數通過。
整個重構過程耗時 244 秒，歷經 7 個步驟與 13 次工具呼叫，達到 0 工具錯誤，最終 9/9 測試全數通過。
執行歷程
15s：執行 bash (pwd && ls -R) 確認目錄結構。
51s：執行 read 讀取三個解析器、測試與說明文件。
96s：執行 write 建立 loganalyzer/common.py。
199s：執行 edit 修改三個解析器模組。
223s：執行 write 建立 tests/test_common.py。
229s：執行 bash (./run_tests.sh) 驗證測試 pass。
244s：完成任務並結束回合。
獨立驗證結果
為確保評測客觀，我們也對產出進行了獨立檢查：
測試覆蓋確實提升，手動重新執行測試指令確實回報 9 個測試通過。
重複程式碼完全消失，使用搜尋過濾後僅剩 common.py 保留相關語法。
模組執行順序與原始 ValueError 錯誤訊息字串一字未改，行為完全一致。
無殘留未使用的引用（import），例如 access.py 中不再需要的 datetime 被精準移除。
單元測試具備實質邊界值覆蓋（包含 255.255.255.255、0.0.0.0 等案例）。
Token 消耗與傳輸效率
整體任務累計消耗計算，輸入為 6,125 tokens、輸出 3,338 tokens、快取讀取（cacheRead）69,244 tokens。
快取讀取量達到實際輸入的 11 倍，顯示快取機制在多步驟 Agent 迴圈中發揮了顯著效益，每一步皆有效重用系統提示與歷史紀錄，這是總耗時能控制在 244 秒的主因。換算有效產出速度，這台跑 DS4 + DeepSeek Harness 約為 13.7 tok/s（包含每一步 prefill 耗時），反映了本機執行 AI Agentic 任務的真實速度。這是不加入 DSpark 投機模型 / MTP 投機模型下的數字，有加入的話，理論上會更快。
這是 CyberQ 實際測試 DeepSeek Harness 網頁介面的 token 消耗與快取命中率的數字參考截圖。
不過呢，投機解碼確實在運作上是呈現零回退、零失效、零錯，但效果完全取決於接受率。CyberQ 這次測試的時間分解顯示驗證階段佔掉 816–888 ms，在這個硬體上驗證成本很重，接受率低於約四成時，開銷就吃掉全部收益，變成負的。平均約 +7.6%，變異大且會回退。
所以結論是不要開投機解碼，在這種思考模式下它一次都不會提案，而思考正是這個 checkpoint 在 agentic 上暴衝的原因（Terminal-Bench 61.8 → 82.7)，為了條件式的 7% 放棄它並不划算。所以把那 5.58 GB 記憶體拿來當批次併發的記憶體餘裕，價值更高。
併發、資源占用與安全治理
批次與併發效能
ds4-server 預設一次僅處理單一請求。為了因應排程與互動式 Agent 同時存取的場景，我們啟動了 --batched-session 2 參數並進行併發測試：
單一請求耗時：14.65 秒
雙請求併發耗時：19.57 秒
序列化執行推估：29.30 秒
整體吞吐量提升：1.5 倍
單一請求的延遲雖從 14.65 秒上升至 19.57 秒，但換取到了 1.5 倍的整體吞吐提升，這對於多任務並行的架構是合理的折衷。需要留意的是，每個常駐 session 會佔用約 1.64 GB 的 KV 快取與 2.46 GB 的上下文緩衝區。在 128 GB 的設備扣除 80.76 GB 的模型權重後，設定 2 個 session 會消耗 4.81 GB 記憶體，不建議將 session 數量調得更高。
信任框架與安全沙箱
DeepSeek Harness 內建了以 bwrap 與 landlock 為基礎的沙箱機制。當模型嘗試寫入工作區以外的目錄時，沙箱會自動阻擋；若模型帶入理由請求提權，系統會觸發審核機制。
政策控制僅需透過一個事件監聽器（Listener）搭配 cordis.patch.yml 即可掛載，具備幾項優異的安全特性，預設拒絕（Fail-closed，無回應者即預設阻擋）、授權一次性生效（僅限當次呼叫），以及稽核日誌寫入失敗時自動拒絕執行。
Web Profile 與 Headless Profile 的選擇陷阱
實測發現，在 Web Profile 下，系統的 apiproxy 會為所有 Agent 註冊預設的審核監聽者，將請求轉為等待前端 UI 點擊授權。當無人值守的自動化任務執行時，會因為長達 40 秒以上無人處置而導致任務永久卡死。
因此，若要建立自動化排程任務，必須使用 --profile headless 啟動。Headless Profile 不會掛載 Web 執行環境，可確保自訂政策為唯一的裁決來源，任務能順利審核並回傳 exit code 0。
綜合評估與優缺點解析
系統優勢
CyberQ 認為，DeepSeek Harness 的框架設計採用真正的模組化，替換模型後端僅需修改 YAML 設定檔，它的llm-pi-ai 模組可原生相容 OpenAI 與 Anthropic 等多種協定。
它的設定檔支援熱重載，調整參數無需重新載入數十 GB 的模型權重，大幅提升除錯效率，同時呢，又完整整合 Agent 所需元件，包含 subagent、workflow、compaction、skills、MCP、LSP 與沙箱機制都有。
整體來看，它的原始碼品質與註解算是不錯的，架構邏輯明確，便於開發團隊進行二次開發。同時在安全與權限設計上嚴謹，例如原生拒絕 --host 0.0.0.0 綁定，避免將遠端執行權限暴露於網路環境中。CyberQ 建議，如果你要在區域網路其他地方連線到這個 DeepSeek Harness ，就需要用 Tunnel 的方式連線才行。
CyberQ 在我們測試環境中使用的指令是這樣 ssh -N -L 3080:127.0.0.1:3080 [email protected]
在終端機貼上那段指令透過 Tunnel 連線後，瀏覽器網址只要貼上 http://localhost:3080/ 就可以讀取 DeepSeek Harness 網頁版界面來互動使用，它也可以是 headless 調用。
現階段的侷限
目前仍處於 RC 預覽階段，版本升級可能存在不相容變更，配置檔結構尚不宜寫得過於複雜。框架抽象層較厚，單次套件安裝會拉入超過 500 個套件，問題排查時需理解 Cordis Loader 機制。
另外，它預設的 defaultContextWindow 預設值（1M）容易與實際模型上下文產生落差，需要手動撰寫設定檔修正。且本機執行速度（13.7 tok/s）仍是主要瓶頸，較適合背景執行的批次任務，不適合極度要求即時回應的互動場景。
落地導入建議
CyberQ 認為，在實務上，DeepSeek Harness 適合定位為建構客製化 Agent 產品的底層骨架，而非單純的終端使用者 CLI 工具。所以我們在使用上是讓它和我們在 NAS 跑的 Hermes Agents 是並存的，二者的用途和訴求不同。
DeepSeek Harness 在結合本機推論後端（如 GB10 上的 ds4-server）時，它能降低團隊對外部雲端 API 的依賴與費用開銷。許多金融、科技研發或具備敏感機密的單位，內部資料與原始碼絕對不能離開內網環境。透過 Harness 搭配本機執行的模型，可以在完全斷網（Air-gapped）的架構下執行大型專案重構、技術債清除與安全弱點掃描，既無資料外洩風險，也完全不需要支付昂貴的 Token 費用。
對於希望建構資料不出境、無 Token 訂閱費用且具備嚴格安全稽核機制的團隊，Harness 提供了可行的架構基礎。在部署策略上，CyberQ 建議將互動式任務與背景自動化任務進行分流，互動需求使用 Web Profile，而背景檢核、自動化重構與補齊測試等排程工作，則一律強制採用 --profile headless 執行，以確保系統穩定運作。
