我認為這次發布提供了兩樣東西：一個開箱即用的編碼代理，以及一個底層的元 Harness 框架，就像 Pi 與 OpenClaw 的關係一樣。
這或許也能解釋圍繞這個專案的一些爭議。人們並不總是在討論同一件事。許多批評者是在評價前者，而我更感興趣的是後者的設計。
DeepSeek Harness 讓編碼代理本身成為可插拔的。企業與開發者可以替換個別元件，並組裝出符合自身需求的 Harness。它還提供了一種建立模式，用於執行時期的自我擴充與迭代改進。
從高層次來看，模型看起來是這樣的：
- 核心提供執行時期與擴充機制。
- 外掛提供可替換且可組合的原子能力。
- 企業從社群中挑選外掛或自行建構，然後將核心與外掛打包成符合自身需求的內部 Harness。
要理解這件事為何重要，我們首先需要釐清我們所說的 Harness 是什麼意思。
什麼是 Harness？
幾天前，InfoQ 的一位同仁問了我一個問題：
從上下文管理與任務規劃，到 MCP 工具呼叫與多代理協作，Harness 的能力正變得越來越相似。還有哪裡留有有意義的創新空間？
目前仍然沒有普遍公認的 Harness 定義。
我的觀點是，模型提供了代理的基礎推理與認知能力。Harness 則決定了這些能力如何被組織、呼叫，並應用於真實任務。模型與 Harness 共同定義了代理的實際能力與效能。
我將 Harness 分為兩層。
狹義的 Harness 是幫助編碼代理完成任務的執行時期框架。它包含上下文管理、記憶、工具呼叫、規劃、測試、驗證與多代理協作。它決定了代理能否可靠地完成任務。
廣義的 Harness 是讓代理能在真實商業環境中接收驗證、回饋與修正的閉環系統。它將代理與組織的系統和流程連結起來，幫助它隨著時間持續做正確的事。
Harness 問題的前半部分，是關於代理如何完成任務。這個領域的能力確實正在趨同。
但相似的功能清單並不會產生相同的結果。速度、準確度、穩定性、成本與失敗復原方面的差異，往往隱藏在表面之下。
後半部分則是關於代理如何進入真實的工程與商業系統、接收回饋，並持續朝目標推進。
這正是差異化將日益來自的地方：情境特定的驗證、回饋歸因與閉環執行。
開發平台、生產日誌、追蹤系統、內部自動化平台、專有知識與組織規則，全都需要被連結起來。代理必須看到真實的回饋、判斷結果是否正確、定位失敗的來源，並持續進行修正。
這一層高度依賴特定的環境。一個通用的編碼代理無法直接解決它。
同一個編碼代理在一個團隊裡可能感覺近乎神奇，在另一個團隊裡卻完全無用。差異往往在於團隊圍繞它所建構的 Harness。
這就是為什麼有這麼多專案在打包外掛。這些外掛的核心，是將過去散落的技能、MCP 整合、文件與連接器，帶入可安裝、可組合且可散布的單元。
從這個角度來看，DeepSeek Harness 的方向就清楚多了。
再次審視 DeepSeek Harness
DeepSeek Harness 的核心訊息是「一切皆為外掛」。
更重要的是，它讓編碼代理本身成為可插拔的。模型、工具、技能、工作階段、沙箱、儲存、迴路、排程與 UI，全都由可替換且可重新組合的外掛組裝而成。
這意味著企業可以使用社群外掛、開發自身情境特定的外掛，或替換 DeepSeek Harness 內附的預設 Harness 元件。
原則上，這增加了二次開發的彈性，同時降低了對整個專案進行 Fork 的需求，使其更容易持續跟隨上游的開發。
這個設計讓我想到我們多年前用 Egg 所做的事。
Egg 提供了執行時期的核心、外掛系統，以及用於建構更高層框架的擴充機制。
同樣的模型可以用來理解 DeepSeek Harness：
- 核心提供執行時期與擴充機制。
- 外掛提供可替換且可組合的原子能力。
- 企業將核心與社群或內部開發的外掛結合，建構出屬於自己的 Harness。
其理念是維持一個穩定的核心，並讓生態系去探索其餘的部分。
如果這個方向成功，我們最終可能得到的不只是一個 oh-my-dsh。我們可能會看到為不同情境打造的無數變體。
它可能如何影響現有的編碼代理
社群裡有些人開玩笑說，MiniMax、Kimi 與 ZCode 等團隊一定在偷笑。
我不那麼確定。
DeepSeek Harness 或許不會對現有的編碼代理造成立即的產品壓力。然而，它在生態系層面的影響，可能會顯著得多。
梁文鋒的 AGI 願景與 DeepSeek 的開源模型，已經提供了兩個強而有力的號召點。DeepSeek Harness 現在又增添了一個有趣的架構主張。
如果這個架構在真實世界的檢驗下站得住腳，它可能會吸引來自世界各地的開源開發者。如此一來，現有的編碼代理團隊未必能笑到最後。
Pi 歷史上曾在 OpenClaw 之下扮演重要角色，至今仍被廣泛討論。OpenCode 也持續吸引著忠實的開發者社群。但這些專案擁有 Harness，卻沒有自己的基礎模型。
DeepSeek 同時擁有 LLM 與 Harness。這種組合創造了可觀的生態系潛力。
社群最近一直在討論同一個模型在不同 Harness 之下，表現可能會有很大的差異。
如果 DeepSeek Harness 最終成為比較模型的共享基礎設施的一部分，會怎麼樣？
如果它成為開源社群中首選的 Harness 基礎，而開發者逐漸圍繞它建立起豐富的外掛生態系，DSH 就可能發展成事實上的標準。其他編碼代理屆時可能會轉向與其介面與慣例相容。
這些可能性仍屬推測。它們是基於今日可見的想法與架構，而非已證實的生態系成果。
這個概念很吸引人，潛力也是真實的。接下來會如何，取決於開發者用放大鏡檢視程式碼之後，這個架構是否仍能贏得社群的支持。