DeepSeek Harness 是什麼？拆解「模型＋Harness＝Agent」背後的開放式代理執行環境

DeepSeek Harness 不是 DeepSeek 推出的另一個大型語言模型，而是一個用來建構與運行 AI Agent 的開放原始碼執行環境。它在 2026 年 8 月 13 日以 MIT 授權開放，當時仍屬開發者預覽版。

DeepSeek 對它的定位可以濃縮成一句話：Agent = Model + Harness。

模型負責理解語言、推理與產生回應；Harness 則負責把這些能力接到現實環境，讓模型能呼叫工具、讀寫檔案、執行指令、維持工作階段狀態，並在多個步驟之間持續完成任務。

Harness 補上了模型缺少的「手腳」

單獨的語言模型可以產生文字，但它不會自動知道如何檢查程式碼儲存庫、執行 Shell 指令、修改檔案、保存工作進度，或在中斷後繼續工作。要把「會回答問題」變成「能完成工作」，中間需要一層負責協調模型與外部環境的執行系統。

DeepSeek Harness 將這一層放在設計核心。官方文件列出的能力包括模型、工具、Skills、工作階段、沙箱、儲存、Agent loop、排程，以及使用者介面；這些元件都能以插件形式掛載、移除或重新組合。

因此，Harness 更接近一個 Agent 基礎層，而不是功能固定的程式設計助手。開發者不只可以調整提示詞或工具，也能改變模型周邊的狀態管理、執行流程與協調邏輯。

但彈性越大，工程責任也越重。插件相容性、權限控管、依賴管理、錯誤處理、升級測試與安全隔離，都會成為導入時不能忽略的工作。

Cordis：把整個 Agent 拆成可替換插件

Harness 建立在 Cordis 之上。Cordis 可視為一個負責掛載插件與解析插件依賴關係的核心框架，讓 Agent 的主要行為不必被鎖在單一、不可拆解的執行迴圈中。

目前可替換的範圍包括：

• 模型介面卡；
• 工具與 Skills；
• 工作階段與儲存系統；
• 沙箱與檔案系統存取；
• Agent loop 與排程；
• 子 Agent 行為；
• Web 介面及其他 runtime 元件。

這正是 Harness 與一般 AI 應用程式最主要的差異。傳統產品通常允許使用者設定提示詞、工具或第三方整合，但底層的任務編排方式仍由供應商控制。Harness 則試圖讓「模型如何思考、呼叫工具、保存狀態並結束任務」這一整套執行模型也能被重新配置。

換句話說，它不是把 Agent 當成一個已經完成的產品，而是把 Agent 當成一組可以自行組裝的系統元件。

四種執行模式，代表四種組合方式

開發者預覽版提供四種預設模式。它們與其說是四個獨立產品，不如說是同一個 runtime 的四套起始配置。

Standard：完整的編碼 Agent

Standard 模式提供較完整的能力組合，包括檔案編輯、Shell、搜尋、Skills、規劃、目標、子 Agent 與工作流程，適合一般軟體開發任務。

Code：以程式組合多次工具操作

Code 模式透過程式導向介面提供工具，讓模型能以 TypeScript 程式串接多個操作。對於原本需要連續呼叫多個工具的任務，這種方式可能減少反覆往返，讓模型以一段程式完成相關步驟。

Minimal：刻意縮小能力範圍

Minimal 模式只保留持久化 Shell 與檔案編輯工具，將環境限制在較窄的範圍內。這有利於進行相對受控的模型評估，也能觀察 Agent 在缺少大量內建能力時的行為。

Creator：用來創作新的 preset

Creator 模式面向希望建立自訂配置的開發者，加入 runtime 檢查與記憶體內插件實驗功能，讓使用者探索如何重新組合不同元件。

僅追加式工作階段日誌：讓 Agent 行為可追蹤

Harness 的另一項關鍵設計，是以僅追加式事件流記錄模型看見與執行的內容。系統提示詞、推理內容、工具呼叫與結果、子 Agent 排程，以及上下文注入，都會寫入工作階段日誌；同一份事件歷史也支援搜尋、回放、恢復與分支。

這種設計有助於除錯與重現。當一次執行失敗時，開發者可以回頭檢查當時的上下文與動作，而不是只看最後一段錯誤訊息。分支功能則類似從較早的版本另開一條路線，無須每次都從頭重新執行實驗。

不過，完整紀錄也帶來資料治理問題。日誌可能包含敏感提示詞、原始碼、工具輸出，甚至是意外暴露給模型的憑證或其他私人資料。若要在正式環境使用，團隊應先訂定保存期限、存取權限、資料遮罩與沙箱政策，不能把 trajectory log 直接視為普通的執行紀錄。

與 Claude Code、OpenAI Codex 有何不同？

DeepSeek Harness 經常與 Anthropic 的 Claude Code 及 OpenAI Codex 一起討論，但三者的產品定位並不相同。

Claude Code 與 Codex 是偏向完整工作流程的整合式編碼 Agent 產品，重點在於讓使用者以較少設定開始工作。Harness 則是開放式 runtime，主打組合能力與執行控制。模型、工具、儲存、沙箱、工作階段行為與 Agent loop，都被設計成可以透過插件替換，而非固定在單一供應商的產品內部。

可以用以下方式理解兩者差異：

面向	DeepSeek Harness	Claude Code／OpenAI Codex
主要定位	開放式 Agent framework／runtime	整合式編碼 Agent 產品
模型選擇	透過介面卡與插件追求模型可替換	主要圍繞各自供應商的模型與服務
擴充方式	連 Agent loop 等核心子系統也能替換	可擴充工具與整合，但核心編排較由產品控制
運作方式	可自架、可檢查，開發者負責組合	較即用，設定與營運負擔較低
可觀測性	以僅追加式軌跡日誌作為核心設計	也提供工作階段與工具紀錄，但不是同一種可替換 runtime 架構

因此，Harness 的競爭點不在於宣稱自己一定擁有更好的程式設計模型，而在於提供一個更開放的 Agent 基礎層。

如果團隊重視成熟的使用體驗、較低的設定成本與受管理的營運模式，Claude Code 或 Codex 可能是更直接的選擇；如果更在意模型可攜性、自架、可重現性、研究用途或自訂執行政策，Harness 才更值得評估。

GitHub 爆發式成長代表什麼？

DeepSeek Harness 上線後吸引了異常大量的早期關注。有報導指它在公開後約一至一個半小時內突破 20,000 個 GitHub stars，之後的報導則稱截至 2026 年 8 月 17 日已超過 141,000 個 stars。

這些數字很醒目，但不應直接解讀為生產環境採用率。GitHub star 比較接近注意力、好奇心與收藏行為，無法單獨證明框架的安全性、可靠性、成功任務數量，或維護團隊能否長期支撐生態系。至於「成長速度超越 Grok-1」的說法，也取決於不同專案與時間區間如何計算，因此較適合視為報導中的比較，而不是已經確立的產業紀錄。

較穩妥的結論是：開發者對更開放的 Agent stack 顯示出強烈興趣。至於 Harness 是否已經準備好投入生產環境，單靠星數仍無法得出答案。

MIT 授權不代表使用模型零成本

MIT 授權適用於框架程式碼，不代表模型推理免費。Agent runtime 在多輪執行期間，可能反覆傳送系統指令、工具結果、政策與累積的對話歷史。若每次互動約有 47,600 個未快取輸入 token 的報導數字屬實，上下文規模便可能成為成本與延遲的重要因素；不過，這個數字目前未由最強的一手來源獨立證實。

使用哪一家模型供應商，同樣會直接影響帳單。DeepSeek 的 V4-Pro 發布也伴隨 API 從單一價格轉向尖峰與離峰定價的調整。報導列出的 V4-Pro 尖峰輸出價格為每百萬 token 3.96 美元，相較早前的 0.87 美元有所上升。

實際的 Harness 工作流程成本，仍會受到以下因素影響：

• 使用的模型；
• 快取命中率；
• 上下文裁剪方式；
• 工具輸出的詳細程度；
• Agent loop 反覆執行的次數。

也就是說，開放框架降低的是軟體層的綁定，不會自動消除推理、儲存與營運成本。

開發者預覽版的穩定性風險

DeepSeek 明確將 Harness 標示為 developer preview，並提醒核心插件與 API 仍會持續演進。 對有意測試的團隊而言，較務實的做法包括鎖定版本、固定插件依賴、在隔離環境中測試升級，以及保留可回復的部署路徑。

早期第三方插件若出現相容性或執行失敗，並不令人意外。Harness v0.1 的價值正是暴露大量可擴充介面，但每一個介面也同時增加了相容性、安全審查與維護工作。至於部分報導提到的插件失敗數量與早期插件提案數，目前缺乏足夠可靠的證據，不宜當成可直接用於採購或部署決策的精確指標。

結論：它更像開放式底座，而非現成替代品

DeepSeek Harness 值得注意的地方，在於它把 Agent runtime 本身提升為一個開放、可檢查、可重新組合的工程層。透過 Cordis 插件系統與僅追加式工作階段歷史，開發者能更細緻地控制 Agent 如何推理、採取行動、保存狀態，以及如何在事後檢查執行軌跡。

這使它對研究人員、基礎設施團隊，以及需要組合式 Agent 系統的開發者相當有吸引力；但對只想快速取得可靠程式設計助手、又不希望承擔大量整合工作的團隊而言，吸引力就沒有那麼直接。

短期內，Harness 更可能成為 Claude Code 與 Codex 之外的開放式選項，而不是立即取代它們。它用即用型便利性換取模型可攜性、可觀測性與控制權。最終能否成為長期平台，將取決於插件 API 是否穩定、生態品質是否足夠、安全邊界是否清晰、文件是否完善，以及開發者在初次展示之後，能否承受這套架構帶來的營運複雜度。