AI

一切皆插件!DeepSeek Harness 的 Cordis 架構拆解:四種運行模式、可追蹤設計,為何被譽為 Agent 界的 VS Code

2026年8月18日
9 分鐘閱讀
一切皆插件!DeepSeek Harness 的 Cordis 架構拆解:四種運行模式、可追蹤設計,為何被譽為 Agent 界的 VS Code

目錄

46 個章節

DeepSeek Harness 是什麼?Agent = Model + Harness 的時代來了

2026 年 8 月 13 日,DeepSeek 無預警開源了自家代理框架 DeepSeek Harness(簡稱 dsh),以 MIT 授權推出 developer preview 版本。同一天,V4-Pro 正式版上線,API 也宣布自 8 月 17 日起調漲價格。三件事同時發生,讓這個開源發布不只是「又多了一個工具」,而是整個 AI Agent 產業的訊號。

cordiverse/paper 的 GitHub 專案首頁,可以看到星數、README 開頭與目錄結構,一眼判斷專案規模與文件完整度。
cordiverse/paper 的 GitHub 專案首頁,可以看到星數、README 開頭與目錄結構,一眼判斷專案規模與文件完整度。

Agent = Model + Harness:把模型變成會做事的人

過去我們談 AI Agent,總是把焦點放在模型本身。但 DeepSeek Harness 提出的公式很直接:Agent = Model + Harness。模型是靈魂,負責理解與推理;Harness 則是讓靈魂真正落地執行的身體,賦予代理理解環境、呼叫工具、持續工作的能力。換句話說,同樣一個模型,裝上不同的 Harness,表現可能天差地遠。

這個概念在獨立評測中獲得印證。海外開發者 sentdex 用同一個 V4 Flash 權重,自寫簡陋工具時僅答對 44 題,改接社群完整 Harness 後答對 64 題,整整多了 20 題。中國知名 YouTuber 魚皮在騰訊新聞轉載的實測中更直接:「DeepSeek 接不接自家 Harness 效果差距大到離譜,同一 V4 Pro 裸接 Codex 連線條都畫不對,換 Harness 後對標 Claude。」這說明模型能力固然重要,但 Harness 決定模型能否把能力完整發揮出來。

一切皆插件:Cordis 微內核的模組化哲學

DeepSeek Harness 的口號是「一切皆插件」。模型、工具、技能、會話、沙箱、儲存、迴圈、排程、UI,全部是可替換的插件。底層由北大與 DeepSeek 聯合發表的論文《A Programming Paradigm for Spatiotemporal Composability》所提出的 Cordis 微內核驅動。Cordis 只管插件的掛載、卸載與依賴關係,Agent 的具體能力全部由外掛擴充。這種設計讓 dsh 被 Reddit 社群譽為「Agent 界的 VS Code」,架構彈性與可組合性備受好評。

官方提供四種運行模式:標準模式包含完整工具集,涵蓋檔案編輯、shell、搜尋、技能、規劃、多代理協作等;PTC 模式(Code mode)讓模型撰寫一段程式來組合多輪工具呼叫,也就是 programmatic tool calling;極簡模式只保留 shell 與檔案編輯器,適合做模型基準測試;創造模式則允許開發者在執行時期實驗新插件、組合全新工作流。每次運行皆留下可追蹤的 append-only session log,支援 resume、fork、search、replay,這項軌跡功能也是 dsh 獨特賣點。

四天 超過 149,644 顆星:現象級開源發布

發布後的 GitHub 星數成長速度驚人。根據 GitHub API 在 2026 年 8 月 17 日的查詢數據,dsh 已累積 129,超過 149,644 顆星與 12,875 次 fork,距離創建僅四天。觀察者網報導指出,發布 24 小時內星數達 80.3K,超過 Grok-1 的累計 5.2 萬顆星;同一時間,dsh-plugin 主題的相關 repo 也超過 1300 個,社群創造力大爆發。

安裝方式非常簡單:執行 npx @deepseek-ai/dsh web 即可啟動 Web UI,另有 Python SDK(pip install deepseek-harness-sdk)供無 Node.js 環境的使用者呼叫。團隊負責人崔添翼在 Hacker News 親自回覆「early developer preview, expect breaking changes」,坦承目前版本不穩定,但開發者仍趨之若鶩。

漲價三連發:從賣模型走向賣工具鏈

發布當天,DeepSeek 同時宣布 API 調漲,自 8 月 17 日 00:00 生效。根據北京商報與華爾街見聞報導,V4-Pro 高峰輸出價格從每百萬 token 6 元漲至 27 元,漲幅 350%;空閒時段也從 6 元漲至 13.5 元,漲幅 225%。V4-Flash 漲價 50% 至 150%。高峰時段為北京時間 9:00 至 12:00、14:00 至 18:00。這波漲價讓不少開發者哀嚎「DeepSeek 低價優勢結束了」。

然而若把三件事放在一起看,戰略意圖相當明確。模型漲價,但自家 Harness 能透過更高的緩存命中率替開發者省下大量 token 成本。魚皮實測「寫一個前後端項目才花 1 塊錢」;V2EX 用戶也反應「用 Harness 比直接裸接 API 省太多」。這種「模型漲價、工具省錢」的組合拳,正是要把開發者推向自家工具鏈。誠如觀察者網引述業界說法:「中國公司第一次在模型與工程外殼層面,具備與 Anthropic 正面對抗的完整閉環能力。」

社群反應兩極:狂熱與理性並存

在中國社群,dsh 的熱度近乎狂熱。Bilibili 上魚皮的實測影片觀看數達 61.1 萬,阿江-Relakkes 的介紹影片也有 34.7 萬觀看,其中內測用戶透露兩天跑了 20 億 token,「很絲滑」;社群甚至出現 2005 門戶風格 UI、Claude Code 風格 TUI、多 Agent 協作插件。24 小時內 1300 多個插件 repo 的產出速度,證明中國開發者的參與熱情。

國際社群則相對理性。Hacker News 討論拿下 731 分,有人稱讚插件架構與軌跡追蹤,也有人批評 README 過於簡陋,讀完論文後「看起來就跟其他 harness 差不多」,甚至有人質疑「如果這不是 DeepSeek 出的,根本不會有 超過 149,644 顆星」。Reddit 上「是否與其他 Agent 框架收斂到同一哲學」的討論,也反映出同質化疑慮。

真實風險:400G 刪檔事故的警惕

最需要被記住的,是發布後已發生的真實安全事故。根據什麼值得買網站轉載阿江的 B 站影片,有 Windows 用戶在安裝插件時,因 dsh 處理符號連結的引號與路徑解析錯誤,加上當下授權為 Full access(完全訪問權限)、無二次確認、也未進回收站,導致 G 盤根目錄約 400GB 檔案被刪除。這起事故對企業導入而言是必須畫出的安全紅線,任何 Agent 框架在授權管理上若不夠嚴謹,都可能造成不可逆的資料損失。

DeepSeek Harness 的開源,把「Agent = Model + Harness」從口號變成可實際操作的架構。它讓開發者第一次能自由組合模型、工具與介面,也讓中國市場在代理框架領域擁有官方級別的話語權。尤其在同一個模型下,Harness 帶來的效果差距已被實測證實,這代表工具的價值正在超越模型本身。然而 developer preview 的不穩定性、漲價後的成本壓力,以及安全權限的隱憂,都是導入前必須謹慎評估的變數。下一章,我們將深入拆解「一切皆插件」背後的 Cordis 架構,看看這個微內核如何徹底改變 Agent 的組合方式。

Cordis 微內核拆解:從「一切皆插件」到「Agent 界的 VS Code」

DeepSeek Harness(dsh)的官方文件開宗明義寫著「Agent = Model + Harness」。模型是靈魂,Harness 則賦予代理理解環境、操作工具、持續工作的身體。但真正讓開發者社群沸騰的,不是 Harness 表層那些花俏的功能,而是支撐這一切的底層骨架:Cordis 微內核。DeepSeek 與北京大學聯合發表的論文《A Programming Paradigm for Spatiotemporal Composability》(Cordis 論文)描述了這套哲學,而 GitHub 上的 deepseek-harness 專案(2026-08-17 查得 129,超過 149,644 顆星)將它變成可執行的程式碼。本文要拆解的,就是這個微內核如何用「什麼都不做」的方式,撐起一個生態。

osgi.org 的官方頁面,功能定義、文件入口與產品定位,以官方說明為準。
osgi.org 的官方頁面,功能定義、文件入口與產品定位,以官方說明為準。

Cordis 的設計哲學:內核無所事事,能力全靠插件

要理解 Cordis,得先拋棄「框架就要包山包海」的直覺。Cordis 微內核本身幾乎是空的,它只負責三件事:插件掛載(mount)、插件卸載(unmount)、插件之間的依賴解析。除此之外,它不提供任何業務能力。模型要怎麼接?工具要怎麼呼叫?對話要怎麼管理?這些全部由插件來定義。用 DeepSeek 團隊的說法,Agent 的每一項具體能力都是插件,內核只是一個永遠在背景待命的小小排程器。

這種設計的威力在於替換性。任何一層都能被抽換,而且抽換的邊界由依賴宣告決定,不是由程式碼耦合決定。插件 A 宣告自己需要插件 B 提供的介面,Cordis 就在啟動時自動解析、按順序載入,若缺少依賴則直接報錯。開發者不需要理解內核的實作細節,只需要知道插件的合約長什麼樣子。

社群對這套機制的反應相當直接。Hacker News 上有使用者將 Cordis 類比為 Eclipse OSGi 的插件系統,感嘆「每一代都在重新發現同樣的東西」(HN 討論串,2026-08-14)。而 Reddit r/DeepSeek 則出現「Cordis System… Its the VS Code of Agent Harnesses」的讚譽(r/DeepSeek 討論,2026-08-14)。同樣的架構,有人看到老哏,有人看到未來。

九大插件類型:Agent 的器官清單

DeepSeek Harness 的開發者預覽版將插件歸為九大類型。這份清單基本框定了 Agent 所需的全部能力邊界:

  • 模型插件:接 DeepSeek、Anthropic、OpenAI 或任何 OpenAI 相容端點,模型中立是 Cordis 的預設立場。
  • 工具插件:檔案編輯、shell 執行、網路搜尋、程式碼分析等實際操作能力。
  • 技能插件:特定領域的任務流程封裝,例如「寫一篇部落格文章」「重構一個模組」。
  • 會話插件:管理對話歷史、上下文視窗、訊息格式轉換。
  • 沙箱插件:隔離執行程式的環境,限制權限與資源。
  • 儲存插件:持久化記憶體、工作區狀態、向量資料庫。
  • 迴圈插件:控制 Agent 的主迴圈邏輯,決定何時呼叫工具、何時停止思考。
  • 排程插件:定時任務、事件觸發、背景執行。
  • UI 插件:Web UI、TUI、Headless 等不同的前端介面。

這九類插件彼此獨立,卻能透過 Cordis 的依賴系統結合成完整的 Agent。例如「技能」插件可能依賴「工具」插件提供 shell 能力,而「沙箱」插件則宣告自己需要「儲存」插件來隔離檔案系統。開發者可以只替換其中一層,其餘全部保留,這就是「一切皆插件」的實際意義。

獨立評測者 sentdex 的實驗提供了一個有趣的數據:同一組 V4 Flash 模型權重,用自寫的簡陋工具呼叫框架只能答對 44/89 題,換成社群完整的 Harness 後提升到 64/89 題,整整多了 20 題(2026-08 月獨立評測)。這說明插件的品質與組合方式,有時比模型本身更能影響實際表現。

插件的生命週期:掛載、卸載與依賴管理

Cordis 對插件生命週期的管理,是它被譽為工程傑作的核心原因。一個插件從「被發現」到「被載入」需要經過以下階段:

  1. 宣告:插件以 manifest 檔案描述自己的名稱、版本、依賴項與提供的介面。
  2. 解析:Cordis 讀取所有候選插件,建立依賴圖,找出環狀依賴與缺失依賴。
  3. 啟動:依賴圖排序完成後,依序掛載。每個插件有自己的啟動與停止鉤子。
  4. 執行:插件間透過事件匯流排與服務介面通訊,不直接引用彼此類別。
  5. 卸載:當插件被移除或系統關閉時,依序停止所有依賴它的插件,再停止自己。

這套機制讓「熱插拔」成為可能。開發者可以在創造模式(Create Mode)裡於記憶體中實驗新插件,不需要重啟整個 Harness。V2EX 上有開發者回報(V2EX 初體驗帖,2026-08-14),實際操作「很絲滑」,而且有人很快做出了自動審批插件與 Docker 部署版本。但要注意的是,官方在發布公告中明言「THERE WILL BE COMPATIBILITY-BREAKING CHANGES」,也就是說 plugin API 尚未穩定,0.1 版的依賴合約隨時可能更動。

不新潮的內核:Eclipse OSGi 的影子

老 Java 開發者看到 Cordis,大概會心一笑。Eclipse 自 2003 年起就用 OSGi(Open Services Gateway Initiative)管理它的插件系統,同樣是微內核、動態掛載、服務註冊、依賴宣告(OSGi 官方文件)。Hacker News 討論串中有人點出這層歷史,直言「things being rediscovered every generation」(HN 討論串,2026-08-14)。

這個類比很精準,但不是批評。OSGi 當年因為過度複雜而沒有真正走進主流開發者世界,Cordis 卻刻意做得極為精簡。它沒有服務工廠、沒有分散式能力、沒有版本化的 bundle 倉庫,只有最樸素的「掛載、卸載、依賴」三件事。這反而讓它比 OSGi 容易理解得多。另一個更貼近當代開發者經驗的類比是 VS Code 的擴充套件系統:編輯器本體只提供視窗與編輯器核心,語言支援、主題、快捷鍵、除錯器全部由 extension 提供,市場上有數萬個擴充套件互不干擾(VS Code API 文件)。Cordis 想複製的,正是這種「薄內核、厚生態」的勝利方程式。

為何是「Agent 界的 VS Code」

Reddit 上出現「VS Code of Agent Harnesses」這個稱號後,迅速被中國與國際社群引用。但要說清楚,這不是一個關於「程式碼編輯器」的類比,而是關於「生態可組合性」的類比。VS Code 的成功證明了兩件事:第一,內核夠薄,第三方才有創作的空間;第二,擴充套件的合約夠穩定,第三方才敢投入時間。Cordis 目前做到了第一點,第二點還要等 API 穩定之後才能驗證。

DeepSeek Harness 發布 24 小時內,社群就長出了超過 1,300 個 dsh-plugin 主題倉庫(來源:觀察者網,2026-08-14)。有人做出 2005 年門戶風格的 UI 插件,有人做出 Claude Code 風格的 TUI 插件,還有人做出多 Agent 協作的外掛。B 站創作者阿江(MediaCrawler 作者)在實測影片中透露,內測用戶短短兩天就跑掉 20 億 token,社區插件生態的爆發力由此可見(阿江 B 站影片,2026-08-14)。

這種「平台式思維」的戰略意義,比任何單一功能都重要。DeepSeek 等於在告訴市場:模型你們可以換,但 Harness 是 Agent 的工作環境,就像開發者可以換任何語言,但 VS Code 變成習慣之後就很難離開。官方選在 V4-Pro 正式版發布、API 漲價的同一天宣布開源,意圖相當明確(VentureBeat,2026-08-13)。漲價後用自家 Harness 能靠緩存命中節省 token,等於把開發者往自己的工具鏈拉攏。

當然,封號的背後也有冷靜的聲音。V2EX 上有開發者直言「這產品如果不是 DeepSeek 出的,連 超過 149,644 顆星也不會有人下載」(V2EX 星數討論帖,2026-08-14)。也有 Reddit 使用者認為它跟 Pi Agent 收斂到同一哲學,缺乏真正的獨特性(r/PiCodingAgent,2026-08-14)。「VS Code 封號」目前更像一個願景,而不是已成事實的頌詞。

小結:薄內核的賭注

Cordis 微內核的本質,是把 Agent 框架的複雜度從「內核內部」轉移到「插件邊界」。這是一場賭博:賭的是插件合約的設計夠不夠好、社群夠不夠活躍、生態能不能自己長出來。至少從前四天的星數與插件數量來看,賭盤正在往樂觀的方向移動。但 0.1 版的穩定度、以及前文提到的 400G 刪檔事故(來源:什麼值得買,2026-08-15),都提醒我們:薄內核讓組合變容易,也讓錯誤的邊界更容易失控。下一章,我們將探討開發者實際安裝與使用 Harness 的體驗,包含四種啟動模式與極簡模式的「邪修」話題。

四種運行模式實測:標準、PTC、極簡、創造怎麼選?

DeepSeek Harness 在 2026 年 8 月 13 日發布後,憑藉「一切皆插件」的架構設計迅速成為開發者社群的焦點(來源:GitHub 官方專案)。多數人第一次啟動 dsh 時,會面對四種運行模式的選擇,分別是標準、PTC、極簡與創造。這四種模式不是同一套功能的不同外觀,而是從「完整代理」到「最小實驗場」的光譜排列。選錯模式,輕則用不到關鍵功能,重則在錯誤的環境裡跑自動化任務,平白增加風險。這一章逐一拆解四種模式的功能邊界與適用場景,並搭配社群實測數據,幫你判斷哪一種最適合自己的工作流程。

sina.cn 的文章頁面,可見「一切皆插件!DeepSeek Harness 的 Cordis 架構拆解」的實作說明或評測觀點,可當作正文之外的補充資料。
sina.cn 的文章頁面,可見「一切皆插件!DeepSeek Harness 的 Cordis 架構拆解」的實作說明或評測觀點,可當作正文之外的補充資料。

標準模式:功能最完整的日常主力

標準模式是 DeepSeek Harness 預設的運行方式,內建完整的工具集,包含檔案編輯、shell 指令執行、網路搜尋、技能呼叫、任務規劃、目標管理、子代理派發與工作流編排(來源:官方快速入門文件)。換句話說,模型在標準模式下可以自主完成「理解需求、拆解任務、操作檔案、執行指令、驗證結果」的完整迴圈,不需要外部工具輔助。

實際使用上,標準模式最適合一般開發任務與企業內部流程自動化。像是修改多個程式檔案、跑測試、搜尋文件、再根據結果調整程式碼,這些動作都能在同一個 session 裡連續完成。V2EX 上有開發者分享,用標準模式寫一個前後端專案只花了新台幣約四塊錢的 token 費用(來源:V2EX 初體驗討論,2026-08-14)。這反映了標準模式在「功能齊全」與「成本可控」之間取得平衡。

標準模式的另一個優勢是完整的可追蹤性。每一次工具呼叫都會寫入 append-only 的 session log,使用者可以透過 Trajectory 檢視畫面回放、暫停、分支甚至重新執行某一段流程。對於需要在事後稽核的企業場景,這項設計比多數商業 coding agent 更具透明度。

PTC 模式:把工具呼叫寫成程式

PTC 模式的全名是 Programmatic Tool Calling,中文可以理解為「程式化工具呼叫」。在這種模式下,模型不直接逐次呼叫工具,而是先撰寫一段程式,由這段程式依序組合多輪工具操作。這個設計類似 Code mode,但更進一步把控制權交給程式碼邏輯,像是條件判斷、迴圈與錯誤處理都能寫進呼叫流程裡。

PTC 的優勢在於精確與可重複。當任務需要依序處理大量檔案,或需要依照中間結果決定下一步時,寫成程式會比讓模型自由決定更穩定。例如批次處理一百個檔案,標準模式可能每一輪都要重新理解狀態,PTC 則可以用一段 for 迴圈跑完。對於具備程式基礎的開發者,PTC 模式能顯著減少 token 浪費,因為不需要反覆把相同上下文餵給模型。

需要注意的是,PTC 模式要求使用者具備一定的程式能力,至少看得懂模型生成的程式碼,也必須能在出錯時手動修正。社群回饋顯示,PTC 在處理「重複性高、規則明確」的任務時表現突出,但面對模糊需求,例如「幫我改善這個專案的架構」,還是回到標準模式比較合適。

極簡模式:性能暴增的「邪修」之路

極簡模式只保留 shell 與檔案編輯器兩個工具,其他全部拔除。乍看之下像是一台拔掉所有配備的跑車,但實際測試結果出乎意料。知名 B 站創作者魚皮(98.6 萬粉絲)在實測影片中指出,極簡模式下的模型性能「暴增」,但「幾乎沒人用」(來源:騰訊新聞轉載魚皮實測,2026-08-15)。他把這種狀態形容為「邪修」,意思是透過極度簡化工具集,反而讓模型專注在核心任務上。

為什麼少兩個工具會讓性能變好?Reasoning 模型在每個步驟都要決定「下一步做什麼」,當候選工具從八個縮減到兩個,決策空間大幅縮小,模型可以把更多注意力放在任務本身,而不是反覆評估該用哪個工具。這點跟獨立評測者 sentdex 的結果一致:同樣使用 V4 Flash 權重,自寫簡陋工具的答題數是 44/89,換成功能完整的社群 Harness 後提升到 64/89,增加整整二十題(來源:Hacker News 討論串,2026-08-15)。工具集的完整度直接影響模型表現,但極簡模式證明「少而專」在某些情境下反而更強。

既然性能更好,為什麼沒人用?魚皮的分析點出關鍵:極簡模式缺少搜尋、技能、規劃與子代理,等於把 agent 降級成「能跑指令的對話框」。日常開發任務需要頻繁查文件、管理多個子任務,少了這些工具,使用者必須手動把外部資訊貼進對話,效率反而下降。極簡模式真正的價值在模型基準測試,用固定的最小工具集去比較不同模型的真實能力,排除 harness 功能差異帶來的干擾。另外,它也適合跑一些「只需要改檔案或執行指令」的封閉式任務,例如批次修改設定檔、跑固定腳本。

創造模式:插件開發者的實驗溫床

創造模式是四種模式裡最特別的一個,它允許使用者在運行時檢查系統狀態、在記憶體中載入實驗性插件,並即時組合出全新的運行模式。換句話說,標準、PTC、極簡都是官方預設的「成品」,而創造模式是讓你把 Cordis 微內核當成樂高積木,自己拼出第四種、第五種模式。

這個模式主要服務兩類人。第一類是插件開發者,他們需要一個低摩擦的環境來測試新寫的工具或技能,不用每次修改都重啟整個 harness。第二類是進階使用者,想探索「如果同時啟用某些插件,會發生什麼事」。社群已經出現不少有趣的實驗,例如有人做出 2005 年入口網站風格的 UI、有人把 Claude Code 的 TUI 介面移植過來,也有人寫了多 agent 協作插件(來源:阿江 B 站實測影片,2026-08-14)。這些創作幾乎都是在創造模式裡孵化的。

不過創造模式對一般使用者並不友善。它缺乏標準模式那種「裝好就能用」的體驗,需要理解 Cordis 的插件合約與依賴管理,踩到雷的機率也比較高。比較合理的定位是:把它當成開發者預覽版的「開發者預覽」,一般任務請回標準模式,想要玩實驗再切進來。

四種模式怎麼選:一張表看懂

模式 核心工具 適合情境 不適合情境
標準 檔案編輯、shell、搜尋、技能、規劃、子代理、工作流 一般開發、企業流程、多步驟任務 追求極致性能的基準測試
PTC 程式化工具呼叫 批次處理、明確規則的重複任務 模糊需求、探索性任務
極簡 shell、檔案編輯器 模型基準測試、封閉式腳本任務 需要搜尋或外部資訊的任務
創造 運行時檢視、實驗插件 插件開發、架構實驗 日常開發、生產環境

以現階段的生態成熟度來看,標準模式最適合作為大多數使用者的起點。它的完整工具集讓你能體驗 DeepSeek Harness 號稱「對標 Claude Code」的完整能力,也最容易銜接社群教學與既有工作流程。PTC 與極簡模式則留給有明確需求的進階使用者,前者節省 token、後者用於評測,值得在 side project 裡先練熟,再決定是否導入日常工作。創造模式暫時不建議一般企業採用,畢竟 0.1 版還在 developer preview 階段,官方明言會有相容性破壞變更,拿生產環境測試實驗插件,風險完全不划算(來源:團隊負責人崔添翼於 HN 親自回應)。

四種模式不是彼此競爭,而是覆蓋同一套核心架構的不同使用場景。標準模式是日常,PTC 是效率,極簡是量測,創造是未來。先從標準模式站穩腳步,再依照自己的需求往其他模式探索,會是風險最低的路徑。

可追蹤設計深入談:append-only Session Log 與 Trajectory 檢視

上一章談完四種運行模式,這章要把焦點放在 dsh 最常被忽略、卻可能是長期價值最高的設計,也就是可追蹤性(traceability)。Hacker News 上有人特別點名「traceability 獨特」是 dsh 與其他 harness 最大的差異點(來源:HN 討論串)。V2EX 的開發者對軌跡功能也普遍抱持好感,甚至有人直言「軌跡功能受歡迎」是 dsh 初體驗中最亮眼的部分(來源:V2EX 初體驗帖)。這些第一線回應透露一個訊號,市場對 agent 的「過程可視化」已經有非常具體的期待。

deepseek-ai/deepseek-harness GitHub 專案首頁:149.7K stars、README 開頭 Everything is a Plugin 與 dsh 0.1.0-rc.7 目錄結構
deepseek-ai/deepseek-harness 的 GitHub 專案首頁:149.7K stars、README 開頭「Everything is a Plugin」與 dsh 0.1.0-rc.7 目錄結構,一眼看出專案規模與文件完整度。

append-only 的意義:每個動作都是不可抹滅的證據

dsh 的每次運行都會產生一份 append-only session log,意思是這份日誌只能不斷附加新紀錄,不能修改或刪除舊紀錄。這個設計乍看簡單,實際上隱含了非常深刻的工程決策。一般 agent 框架的日誌大多是「覆蓋式」或「截斷式」,跑完一輪任務就清空,只留下最終結果,過程中的決策、失敗嘗試、工具回傳的原始資料,全部隨風而逝。

append-only 的好處在於它把 agent 的運行過程變成一份完整且不可篡改的歷史。每一條工具呼叫、每一次模型回覆、每個檔案編輯指令,都依照時間順序被永久記錄。這在除錯時特別重要,當 agent 做出意料之外的舉動,你不需要靠猜測還原現場,只需要把 session log 打開,就能看到它是在哪個步驟開始偏離軌道。對企業而言,這種「行為證據」也等於一層基本的稽核能力,特別是當 agent 具備檔案編輯與 shell 執行權限時,事後追查的價值遠高於當下的便利。

另一個務實的好處是 token 成本。append-only 讓整個 session 可以被反覆讀取與重播,replay 時不需要重新向模型請求同一段脈絡,直接從既有日誌重建狀態即可。這對照 dsh 官方強調「自家 harness 能省 token,緩存命中率高」的說法,軌跡設計正是支撐這個優勢的底層機制之一。

Trajectory 檢視:四種操作,把「歷史」變成「資產」

光有日誌還不夠,dsh 更進一步在 UI 上提供 Trajectory 檢視,讓使用者可以針對一份 session log 執行四種操作,分別是 resume、fork、search、replay。這四個動作各自解決不同痛點,值得逐一拆解。

resume 是從中斷點繼續,適合情境是 agent 跑到一半因網路斷線、token 額度耗盡或使用者手動中止而停止。傳統做法是整個任務重跑,浪費時間也浪費 token;resume 則直接從一個完整步驟接續,像是把看一半的書從上次的頁碼重新翻開。

fork 是從某個歷史節點分岔出去,這對探索性任務特別有價值。假設 agent 跑了十個步驟,第十一步的決策方向你不滿意,不需要全部重來,只要回到第九步的節點,fork 出另一條路徑讓 agent 用不同方式繼續。這像是 Git 的分支概念,把 agent 的決策樹變成可以自由操作的版本控制,而不是一條走到底的單行道。

search 是在冗長的 session log 中搜尋特定關鍵字或工具呼叫。別小看這功能,當一次運行橫跨數小時、產生上千條記錄時,沒有搜尋等於在大海撈針。搜尋讓除錯從「肉眼掃描」升級為「精準定位」,直接跳到出問題的那一步。

replay 是重播整個過程,介面會依照時間順序逐步重現 agent 的決策與動作。replay 的價值在兩方面,是教學與協作,新人可以透過 replay 理解資深工程師如何設計 prompt、如何拆分任務;是審計,管理者可以完整檢視 agent 在敏感操作前後的上下文,確認沒有越權行為。

競品對照:為什麼多數 agent 框架沒有完整軌跡回放

把視角拉到競品,就能看出 dsh 在可追蹤性上的差異化。Claude Code 雖然是垂直整合的成熟產品,提供 session 管理與恢復功能,但它偏重於「繼續任務」,沒有像 dsh 這樣把整個運行過程視覺化呈現,更缺少以節點為單位的 fork 操作。OpenAI Codex 主打雲端任務與 GitHub 原生 PR 工作流,使用者在介面上看到的是任務結果,過程對使用者來說就像一個黑箱。Prime Agent 的 /refine 自我改進機制固然強大,但它的 traceability 著重在模型層級的改善,而非運行過程的完整回放。

Reddit r/PiCodingAgent 上有使用者討論 dsh 跟 pi 是否收斂到同一哲學(來源:Reddit 討論),這顯示市場對 agent 框架功能同質化的擔憂確實存在。但就軌跡回放這個面向而言,dsh 的 append-only log 加上四種 Trajectory 操作,在開源 harness 中確實走出自己的路。Hacker News 上有人類比 Eclipse OSGi 的插件系統,說「每個世代都在重新發明同樣的東西」(來源:HN 討論串),但可追蹤性這塊,dsh 不是重新發明,而是補上了多數框架長期忽略的缺口。

除錯與協作的具體優勢

把這四種操作組合起來看,真正受惠的是兩類情境。第一類是除錯。過去 agent 出錯,開發者只能看到錯誤訊息,然後祈禱重跑會成功。現在有了 append-only log 與 replay,你可以完整重現 agent 的思考軌跡,看到它是在哪個環節誤解了指令、哪個工具回傳內容導致決策失誤。結合 search 快速定位,除錯效率的提升不是線性,而是倍數級。

第二類是協作。橙皮書(deepseek-harness-orange-book)的實測中特別提到,官方文件缺乏一手資料,他們於是將「三份原始會話日誌」直接公開,讓不寫程式的人也能看懂 agent 的運作過程(來源:橙皮書 repository)。這個動作本身就示範了軌跡的協作價值。在團隊中,資深成員可以導出 session log 交給新人研究,或是用 fork 示範「如果這裡換個做法會怎樣」,這些都是白板討論難以達到的精確度。

台灣企業導入 agent 時,可追蹤性更應該被視為必要條件而非加分項。原因很務實,當 agent 具備 shell 與檔案編輯權限,一旦發生異常,沒有軌跡就等於沒有調查方向。dsh 的 append-only 設計加上四種查閱操作,至少提供了事後還原現場的能力,讓團隊可以在可控的風險範圍內逐步摸索 agent 的極限。

獨立實測對決:Harness 與 Codex、Claude Code 的真實差距

DeepSeek Harness 發布之後,各方評價相當兩極。支持者宣稱「換上 Harness 之後對標 Claude」,懷疑者則認為「跟其他 harness 差不多」。官方示範與社群吹捧都不足以當作採購依據,這時候獨立測試者的對照實驗反而最有參考價值。這一章整理四組具體的實測結果,用數字與方法呈現 Harness 對模型能力的加成效果。

sentdex:同一模型權重,工具從簡陋到完整,分數從四十四題進步到六十四題

海外獨立評測者 sentdex 做了一組控制得相當乾淨的實驗。他使用同一個 V4 Flash 模型權重,先以自己撰寫的簡陋工具迴圈跑一份八十九題的基準測試,結果只解出四十四題。接著換上社群開發的完整 Harness 配置,同一份權重直接解出六十四題,整整多了二十題(來源:sentdex 獨立評測,2026 年 8 月)。

這組對照最可貴的地方在於模型根本沒有換,變數只有外圍工具。四十四題與六十四題的差距,可以百分之百歸因於 harness 的設計。換句話說,模型再強,缺少合適的框架去承接工具呼叫、檔案編輯與執行流程,能力就會被白白浪費。sentdex 自己也坦言,他原先預期差異不會這麼大,實際跑完之後才理解為什麼 DeepSeek 要把 harness 定位成與模型同等重要的一層。

魚皮:同一 V4 Pro 裸接 Codex,連線條都畫不對

中國社群最具話題性的實測來自 B 站創作者魚皮。他的頻道有九十八點六萬粉絲,實測影片累計六十一點一萬觀看、兩千餘則回覆(資料截至 2026-08-17,來源:魚皮 B 站影片)。魚皮讓同一個 V4 Pro 模型裸接 OpenAI Codex 的 CLI 環境,結果連一條簡單的線條都畫不對,圖形輸出完全走樣。

接著他把同一模型接到 DeepSeek Harness,輸出水準直接對標 Claude。他用「角色專武」來形容這個現象,意思是模型能力需要搭配專屬武器才能完整發揮。他的影片還提到極簡模式,在只保留 shell 與檔案編輯器的設定下,模型性能反而暴增,但幾乎沒有人使用這個模式。這個細節很有意思,它說明工具數量不是重點,工具與模型的適配程度才是關鍵。

九天Hector:效率翻倍,效果追平

九天Hector 的《VS Codex 全面對比評測》走的是另一條路線,他沒有鎖定單一模型,而是直接比較 Harness 與 Codex 在多輪實務任務上的表現(來源:B 站搜尋「DeepSeek Harness VS Codex」,2026 年 8 月)。結論是「效率翻倍、效果追平」。他所謂的效率翻倍,來自 Harness 的軌跡系統讓每次執行階段都可以檢視、繼續與重播,程式寫到一半卡住時,不必整個對話重來,節省大量時間。

九天Hector 的測試涵蓋檔案編輯、工具呼叫與多步驟工作流,Harness 在這些項目上都比 Codex CLI 更順手。他也提到,Codex 的優勢在於雲端任務與 GitHub 原生整合,但就單機開發的日常操作而言,Harness 的即時回應與執行軌跡確實更有感。這份評測的價值在於把比較維度拉開,不是只看模型輸出,而是看整個工作流程的摩擦成本。

AI超元域:同一組提示詞重做遊戲,操控性勝出

AI超元域的實測採用更直觀的方式:他用同一組提示詞,把 Claude Code 測試過的遊戲任務在 Harness 上重做一遍,結果 Harness 版本的操控性在主觀體驗上勝出(來源:AI超元域 B 站影片)。雖然這種測試缺乏量化分數,但同提示詞在不同框架下產出不同結果,已經足以說明框架對最終成果的影響。

特別,AI超元域強調 Harness 在多步驟遊戲邏輯的拆解上更穩定,模型不容易在長流程中迷失方向。搭配 append-only 的 session log,每次執行都能回頭檢視是哪一個環節出了錯,這在遊戲開發這種需要反覆調整參數的情境特別實用。

這些實測說明了什麼

把四組測試放在一起看,會得到一致的結論。sentdex 控制模型權重,魚皮控制模型版本,兩者的對照都把變數縮到最小,差距完全來自工具與框架。九天Hector 從工作流程切入,看到效率層面的差異。AI超元域 則以成品品質佐證框架的影響力。與其繼續爭論哪一家模型最強,不如先確認自己選定的模型與框架組合是否經過實測驗證。

從替代方案的角度來看,台灣團隊導入 agent 時,不能只看模型評分或星數。獨立實測的對照方法值得借鏡,建議先用自家專案的最小範例,固定模型版本,分別以裸 CLI 與 Harness 各跑一輪,記錄完成率、花費時間與 token 成本。魚皮與 sentdex 的測試都證明同一模型在不同框架下的表現差距極大,內部驗證的結果遠比網路上任何單方面宣傳來得可靠。

另外也要提醒,這些獨立實測大多在中國社群發酵,國際社群仍有保留意見,引進企業環境之前務必自行複測。實測之餘,安全議題更不能忽略,下一章會深入討論 400G 刪檔事故與權限管理的紅線。

安全紅線巡禮:400G 刪檔事故與企業導入前必做的三道防線

DeepSeek Harness 發布四天內衝上 超過 149,644 顆星,社群一片火熱,但真正值得企業注意的,不是那顆閃亮的星星數,而是一起真實發生的刪檔事故。2026 年 8 月,一名 Windows 用戶在安裝社群外掛時,DSH 因為符號連結的引號與路徑解析錯誤,誤刪了 G 槽根目錄約 400G 的檔案。這起事件最初由阿江在 B 站影片中揭露,後續被《什麼值得買》報導整理(來源),成為目前 DeepSeek Harness 最嚴重的真實安全事故之一,也是企業導入前必須清楚認知的紅線。

事故還原:符號連結的一場誤判

這起事件的技術脈絡並不複雜。Windows 的符號連結與目錄路徑在解析時,會遇到空格、引號跳脫等細節,DSH 在開發者預覽階段對這些邊界條件的處理還不夠成熟。當使用者觸發某個外掛的安裝流程時,DSH 把符號連結誤判為一般目錄,接著執行清理或搬移指令,指向了 G 槽根目錄。整段過程沒有任何攔截,400G 的檔案就這麼消失。更關鍵的是,這個操作發生在 Full access 權限下,agent 擁有對檔案系統的完整控制力,系統沒有針對高風險指令做任何隔離。

三個致命設計

把這起事故拆開來看,可以歸納出三個在設計上就埋下的致命點。第一個是 Full access 權限。開發者預覽階段的設計哲學是「讓 agent 自由探索」,因此官方預設給予完整存取權,沒有採用最小權限原則。對個人實驗來說這很方便,但對企業環境,這等於把整台機器的人身安全交給一個仍在快速變動的程式。

第二個致命點是沒有二次確認機制。當 DSH 準備執行刪除目錄這類不可逆的高風險操作時,系統沒有停下來問使用者「你確定嗎」。設計者假設 agent 的判斷值得信賴,但這起事故證明,路徑解析錯誤時,agent 根本不知道自己在刪什麼。任何一個資深工程師都會承認,刪除是最該被攔截的操作,而這道防線在當下版本完全缺席。

第三個致命點是沒進回收站。刪除指令直接繞過資源回收筒,等於斷絕了的救援機會。沒有二次確認,又沒有回收站緩衝,一旦誤刪就是永久損失。這三個設計加在一起,構成了完整的事故鏈:過大的權限讓錯誤得以執行,缺少確認讓錯誤不被阻止,沒有回收站讓錯誤無法挽回。任何一個環節有防護,400G 的悲劇都不會發生。

版本穩定性與插件品質的雙重風險

這起事故並非孤例,背後反映的是版本穩定性的根本問題。DeepSeek 官方在 Hacker News 上由團隊負責人崔添翼親自回應,直言這是「early developer preview, expect breaking changes」(來源)。這句警告非常誠實,但也意味著任何企業若貿然把 0.1 版推進生產環境,就必須承擔介面變動、行為改變、甚至安全邊界重劃的風險。V2EX 上已有開發者明確表示,上生產線起碼要等 1.0,保守一點甚至該等 0.5 之後的穩定版(來源)。

另一方面,社群的插件品質參差也放大了風險。發布 24 小時內,宣稱的 dsh-plugin 主題 repo 已超過 1300 個(來源)。這數字很驚人,但多數出自熱情滿滿的開發者之手,沒有經過資安審查,沒有測試覆蓋,甚至沒有文件。企業若貪圖方便直接安裝第三方外掛,等於把生產環境的鑰匙交給陌生人。更別提 8 月 17 日起 API 大幅漲價,V4-Pro 高峰輸出從每百萬 token 6 元漲到 27 元,漲幅高達 350%(來源),成本敘事快速鬆動,企業的導入決策更需要理性評估,而不是被社群熱度牽著走。

企業導入前必做的三道防線

站在企業顧問的角度,我們建議任何團隊把 DeepSeek Harness 引進工作流程之前,先築起三道防線。

第一道防線是權限最小化。絕對不要用管理員帳號或 Full access 權限運行 DSH。替 agent 建立獨立的低權限系統帳號,只開放特定工作目錄的讀寫權,並把系統根目錄、使用者設定檔、重要資料夾全部設為唯讀。有能力的團隊進一步用容器或虛擬機器隔離,讓 agent 就算暴走,也碰不到真正的生產資料。權限越小,事故的爆炸半徑就越小。

第二道防線是刪除保護機制。在 agent 執行環境的外層設定即時備份與同步,至少對高價值目錄啟用版本控制,讓每次刪除或覆寫都可回溯。若使用 Windows,可考慮把資源回收筒容量調大,並確認 agent 的刪除指令是否強制繞過回收筒。若無法繞過,這就為誤刪多留一道緩衝。同時建立明確的稽核日誌,任何刪除行為都要留下紀錄,事後才能追查。

第三道防線是導入前驗證與員工教育。企業不該讓第一波使用者直接在正式環境「嘗鮮」。應先用代表性專案在隔離環境跑完整的驗證腳本,涵蓋檔案操作、目錄搬移、路徑含空格與中文資料夾名稱的案例,確認不會觸發類似符號連結的解析錯誤。同時間,所有使用 agent 的同仁都必須接受資安教育,理解 Full access 的風險、高風險操作的辨識方法,以及遇到異常時如何緊急切斷 agent 的執行權。

DeepSeek Harness 的架構理念確實令人興奮,插件化、可追蹤、可組合的設計也獲得不少實測肯定。但 400G 刪檔事故提醒我們,越強大的工具,越需要嚴謹的邊界。企業導入 AI agent 從來不只是把模型接上 API,而是把權限、備份、驗證、教育整套機制一起建立起來。紅線畫清楚,工具才能真正為你所用,而不是某天醒來發現整個 G 槽只剩一封道歉信。

替代方案有限公司觀點:台灣企業導入 DeepSeek Harness 的務實評估

我們是替代方案有限公司,長年代理台灣企業導入 AI Agent 與自動化流程,自家生產環境跑的是 Hermes Agent。這半年來,客戶最常問我們的一句話是:「DeepSeek 那麼便宜,是不是換過去就對了?」這次 DeepSeek Harness(以下簡稱 dsh)發布,加上 8 月 17 日 API 價格調漲,我們認為是一個很好的時機點,把話說清楚。dsh 的架構理念確實亮眼,插件化、可追蹤、可組合的設計在開源社群獲得大量實測肯定,但台灣企業要導入,不能只看 GitHub 星數,更要看成本結構、安全紅線與生態成熟度。

漲價後的峰谷定價,才是真正的決策關鍵

8 月 17 日凌晨零點起,DeepSeek API 調整價格。V4-Pro 的高峰時段輸出價格從原本每百萬 token 新台幣約 27 元(人民幣 6 元)一口氣調漲到 270 元(人民幣 27 元),漲幅高達 350%;離峰時段則為 135 元(人民幣 13.5 元),漲幅也有 225%。高峰時段為北京時間上午 9 點到 12 點、下午 2 點到 6 點,恰好就是台灣企業上班的黃金時段。V4-Flash 也有 50% 到 150% 的漲幅(來源:北京商報 2026 年 8 月 13 日報導)。這些是官方定價,實際帳單還要看你是否啟用了 上下文快取(context caching)功能,快取命中率高的請求能省下不少錢。

我們的觀察是,多數台灣客戶對「漲價」的第一反應是「那不要用了」,但這是誤會。DeepSeek 這次是從「無腦便宜」切換到「聰明的便宜」,用峰谷定價把離峰時段的算力閒置成本釋放出來。對照我們的實務經驗,以下兩種情境最值得算一算:

  • 批次型任務適合離峰執行。例如報表生成、資料清洗、知識庫索引建立,這些工作不需要即時回覆,排程到晚上 8 點後跑,成本直接砍半。我們用 Hermes 的 cron 功能排定夜間批次任務已經非常成熟,dsh 的 Headless 模式也能做到類似效果。
  • 即時互動型任務要精算快取效益。開發者互動、客服對話這類即時場景,落在高峰時段是躲不掉的。但 dsh 官方強調自家工具鏈的快取命中率高,同一模型裸接其他 harness 與接上 dsh,魚皮的實測影片(2026 年 8 月)顯示差距大到「對標 Claude Code」,這意味著 token 消耗總量下降,帳單不見得變貴。不過,快取對企業導入的真正意義在於一致性與追蹤,這點後面會談。

權限盤點,是導入前不能跳過的步驟

我們在前一章已經詳細討論過 400G 刪檔事故的技術細節,這裡要從顧問實務的角度補充。事故發生在 Windows 環境,用戶授予 dsh Full access 權限後,因符號連結路徑解析錯誤,刪除了 G 槽約 400GB 的檔案,且未進回收站(來源:什麼值得買 2026 年 8 月報導)。對我們來說,這不是「個案」,而是任何 agent 工具在企業落地前必經的試煉。

我們導入 Hermes 時,第一件事不是寫技能(skills),而是跑權限盤點。做法很簡單,分三步:

  1. 列出現有服務帳號的存取範圍。包含檔案系統路徑、資料庫連線字串、雲端服務金鑰,全部寫成一份清單。
  2. 為 agent 開立最小權限帳號。只給它需要的目錄與 API 存取權,不允許使用管理員身分執行。
  3. 建立高風險操作攔截清單。凡是會刪除、覆寫、搬移檔案的指令,一律需要人工二次確認。

dsh 的設計哲學「一切皆插件」某種程度上讓這件事變更容易,因為你可以針對特定插件設定專屬權限。但 developer preview 階段的破壞性變更風險仍在,官方在 Hacker News 討論串(2026 年 8 月)中親口承認「THERE WILL BE COMPATIBILITY-BREAKING CHANGES」,這意味著企業內部的測試環境與自動化測試必須更嚴謹。我們建議,任何要導入 dsh 的團隊,先把權限盤點當成「儀式」來做,就像第一次約會要交換身分證字號一樣,看清楚再談感情。

哪些場景適合導入,哪些場景建議等待穩定版

綜合我們的實測與社群回饋,以下分兩類說明。台灣企業可以拿這份清單對照自己的情境:

適合現在導入的場景:

  • 內部工具開發與原型驗證。dsh 的插件架構非常適合快速打造內部 AI 工具,24 小時內社群貢獻超過 1300 個插件 repo(來源:觀察者網 2026 年 8 月報導),意味著找現成功能比從零開發容易得多。
  • 批次資料處理與夜間排程。離峰定價加上 Headless 模式、Python SDK,讓資料團隊可以用熟悉的語言撰寫自動化流程,不必綁定特定 UI。
  • 開發者體驗優先的團隊。如果你的工程師喜歡 DIY、追蹤軌跡、實驗新架構,dsh 的 Trajectory 檢視與 append-only session log 提供了極佳的除錯體驗。

建議等待穩定版的場景:

  • 直接面對客戶的生產環境。客服機器人、對外 API 服務這類一旦出錯就會造成商業損失的場景,我們不建議在 0.1 版本就上線。V2EX 開發者說得直接:「上生產起碼要 1.0」(來源:V2EX 初體驗討論串 2026 年 8 月)。
  • 需要多模態圖片理解的任務。目前的體驗仍不理想,這是社群公認的弱項。
  • 超長上下文密集的應用。超過 200k 上下文後 UI 會卡頓,這是 JavaScript runtime 的瓶頸,短期內難有解。
  • 替換既有的成熟 agent 工具鏈。如果你已經用 Claude Code 或 Codex 跑得很順,沒有必要為了嚐鮮而替換。Reddit 上也有討論質疑 dsh 與 pi、OpenCode 是否「收斂到同一哲學」(來源:r/PiCodingAgent 討論串 2026 年 8 月),獨特價值還有待時間證明。

我們的務實建議:把 dsh 當作「第二工具」,而不是全面取代

回到台灣市場的落地情境。我們認為台灣企業對 dsh 的正確態度,是把它放進工具箱,但不要急著全面擁抱。我們的具體建議如下:

第一,用離峰時段做小規模概念驗證。挑一個不影響營運的內部專案,用 dsh 的 Python SDK 寫一個自動化流程,實際記錄快取命中率與帳單金額。這樣做風險低、成本可控,又能驗證官方宣傳的省錢效益是否真實發生在你家的工作負載上。我們自己的經驗是,Hermes 搭配 DeepSeek V4 Flash 的批次任務,在離峰時段執行確實划算,但這個結論必須由每個團隊用自己的資料驗證。

第二,把安全機制建在 agent 外面。dsh 的安全設計還在進化,但企業導入時不需要等它成熟。我們的做法,是在 agent 前方加一層閘道,統一管理 API 金鑰、身分驗證與操作稽核。這樣一來,底層工具換成 dsh、Hermes 或任何新框架,都不會影響企業的安全邊界。有人已經把 dsh 整合進 Hermes 當作 delegated coding engine,這正是我們樂見的方向。

第三,繁體中文的導入文件是一個缺口,也是機會。目前 dsh 的中文內容以簡體為主,繁體中文的實測與導入指南極少。我們計畫在接下來的系列文章中補上這個缺口,從權限盤點、成本計算到實際部署,提供台灣團隊可以直接參考的範本。

,我們想說的是,dsh 的發布可以說是 2026 年最現象級的開源事件之一,GitHub 星數 4 天從 27.5K 暴漲到 129K(來源:GitHub 官方 repo 2026 年 8 月 17 日查詢),這背後有中國市場的品牌紅利,也有真實的技術創新。但我們對台灣企業的建議始終一致:好工具值得關注,但導入前先算清楚成本、畫清楚權限、寫清楚測試,這樣才能在 AI 浪潮中穩穩站在浪頭上,而不是被浪打暈。下一篇文章,我們會深入探討 dsh 與 Hermes 在實際專案中的對照測試,敬請期待。

結論與下一步:從今天開始用 dsh 打造你的第一個 Agent

DeepSeek Harness(dsh)在 2026 年 8 月 13 日發布,短短四天內於 GitHub 累積超過 超過 149,644 顆星(來源:GitHub 官方 repo 2026 年 8 月 17 日查詢),發布 24 小時內更突破 8 萬星(來源:觀察者網 2026 年 8 月)。這不是又一次開源熱潮,而是 DeepSeek 從「賣模型」跨入「賣工具鏈」的關鍵轉折。模型是靈魂,Harness 是讓靈魂得以行動的軀體。對台灣企業而言,dsh 的意義不在於它有多紅,而在於它把過去只有大型團隊才負擔得起的 Agent 基礎建設,變成一行指令就能啟動的開源工具。

這篇文章是這個系列的收尾。我們不會重複前面章節的細節,而是把最務實的下一步整理給你,讓你在今天就能動手。

第一步:一行指令,啟動你的第一個 Agent

你只需要一個安裝 Node.js 的環境,在終端機輸入:

npx @deepseek-ai/dsh web

這個指令會自動下載並啟動 dsh 的 Web 介面,打開瀏覽器之後,你就可以開始跟 Agent 對話,指派它讀取檔案、修改程式碼、執行 shell 指令(來源:DeepSeek 官方頁面)。如果你不想安裝 Node.js,也可以改用 Python SDK:pip install deepseek-harness-sdk,兩者都能完整使用 dsh 的核心功能。

啟動之後,dsh 提供四種使用方式。你不必一次全部學會,先挑一種順手的開始:

  • Web UI:圖形化介面,最適合第一次接觸的使用者,所有工具和對話紀錄一目了然,也是官方示範的主要介面。
  • TUI:終端機介面,操作速度更快,適合已經習慣命令列的開發者,也方便在 SSH 環境中遠端使用。
  • Headless:不開啟介面,直接以 API 方式呼叫,適合把 Agent 整合進自動化流程或 CI/CD 管線。
  • Python SDK:用 Python 程式碼直接控制 dsh,適合原本就使用 Python 技術棧的團隊(來源:SegmentFault 部署指南 2026 年 8 月)。

四種方式共用同一套核心,你在 Web UI 裡建立的會話,之後也可以用 TUI 繼續追蹤。這是 dsh 的 append-only session log 與 Trajectory 檢視功能帶來的彈性,也讓每次實驗都能回頭檢視、分支或重播。

第二步:把官方文件與社群資源變成你的學習地圖

動手之後,下一步就是有方向地深入。以下是我們在系列文章中實際使用過,也推薦你優先參考的資源:

另外,Hacker News 上作者親自回應的討論串也值得一讀(HN 討論串 2026 年 8 月)。崔添翼直接表明這是 early developer preview,未來會有破壞性變更。這句話請先記在心裡,因為它決定了你要用什麼心態導入。

第三步:導入前,先想清楚三件事

dsh 的實測成績相當亮眼,中國開發者魚皮在騰訊新聞轉載的評測中指出,同一個 V4 Pro 模型裸接其他工具連簡單圖形都畫不對,換上 Harness 之後表現直接對標 Claude Code(來源:騰訊新聞 2026 年 8 月)。但我們在整理這個系列的過程中,也看到三條必須正視的紅線。

其一,安全永遠排在功能前面。 2026 年 8 月傳出 Windows 用戶因為符號連結路徑解析錯誤,加上 Full access 權限,導致約 400G 的檔案被刪除,且沒有進回收站(來源:什麼值得買 2026 年 8 月)。這起事件提醒我們,無論採用哪一套 Agent 工具,導入前先做權限盤點,限制 Agent 只碰得到它該碰的資料。

其二,成本不是靜止的數字。 從 2026 年 8 月 17 日起,DeepSeek API 調整定價,V4-Pro 的高峰輸出價格從每百萬 token 6 元調整為 27 元,漲幅約 3.5 倍(來源:北京商報 2026 年 8 月)。dsh 的緩存命中率確實能省下不少 token,但你還是要把自己的使用情境拿出來做成本試算,而不是只看別人的省錢心得。

其三,把這個工具當作夥伴,不是神主牌。 中國市場一片火熱,國際社群則有「跟其他 harness 差不多」的質疑(來源:Hacker News 2026 年 8 月)。我們認為這不是壞事,反而代表你更應該自己動手實測,用你自己的專案、你自己的資料,確認 dsh 到底適不適合你。

替代方案有限公司的看法

作為長期協助台灣企業導入 AI Agent 的顧問團隊,我們把 dsh 定位為「值得認真評估的選項」,而不是「非用不可的答案」。台灣企業普遍重視穩定與可維護性,因此我們的建議是:先從一個低風險的內部專案開始,用 dsh 跑兩週,記錄它在 200K 以上上下文的 UI 表現、多模態處理能力,以及團隊成員的操作回饋。同時,把權限控管的檢查清單列為第一優先,不要讓 Agent 擁有超出任務範圍的存取權。成本方面,由於 API 已經漲價,我們建議把自家問題的 token 消耗量實測出來,再決定是否長期依賴 DeepSeek 的模型與工具鏈,或者混用其他模型來分散風險。如果你需要一套完整的導入前評估表,或者想看 dsh 跟我們日常使用的 Hermes 在相同任務上的對照結果,我們很樂意提供第一手資料。

這趟從「認識 dsh」到「上手 dsh」的旅程,到這裡告一段落。模型會一直換,工具鏈會一直演進,但不變的是你的判斷力。先動手做一個小專案,再決定要不要升級成正式工作流程,這永遠是學習新技術最划算的路徑。

📩 有任何問題或需要協助,歡迎聯絡我們:[email protected]

Related

延伸閱讀