DeepSeek V4 Pro 與 Harness 同日雙發：開源 Agent Stack 真的補齊了嗎？（2026）

2026 年 8 月 13 日，DeepSeek 在官方發布頁宣布 DeepSeek V4 Pro 正式 GA；同日的 V4 Pro 官方 X與 Harness 官方 X兩則公告相隔約 91 分鐘。官方公告層面確實是「同日雙發」：前者補上模型與 Responses API 格式，後者補上 Agent 執行框架。但 AlphaLab 查證後的結論是：這是一組已能互相接線、尚未預設緊密整合的三層拼圖，不是可直接替換 OpenAI API 的完整相容層，也還不是成熟的 production stack。下面依序拆開模型、API、Harness、分數與熱度，判斷真正補齊了什麼。

同一天，DeepSeek 補上了哪三層？

先用最簡單的方式看這次發布：模型決定「會不會做」，API 決定應用程式「怎麼叫它做」，Harness 則決定它「如何反覆用工具、保留狀態、隔離環境並完成工作」。如果不熟悉第三層，可以先把它理解為 Agent 的執行引擎。

第一層：MIT 授權的 DeepSeek V4 Pro 開放權重

Hugging Face 官方模型庫公開 66 個 safetensors 分片，合計約 893GB，模型權重明確採 MIT License；設定檔支援約 104 萬 token 的 context window。官方 vLLM 部署範例使用 4 張 NVIDIA GB300——這是官方示範配置，不是宣稱的最低需求，卻足以提醒讀者它不是一般工作站等級。這是真正寬鬆的開放權重發布，但不等於「完整開源模型」：模型庫沒有一起提供訓練語料與可完整重現的訓練流程，1M context 也代表支援上限，不等於長距離有效推理已被獨立證實。

“Native OpenAI Responses API support, optimized for Codex with one-click setup.”

中文：原生支援 OpenAI Responses API，並針對 Codex 提供一鍵設定。

DeepSeek V4 Pro 官方發布頁

第二層：原生 Responses API 格式，但只是核心子集

DeepSeek 把它稱為「Native OpenAI Responses API support」，現有 Responses client 因此比較容易接入。不過官方相容表寫得很清楚：目前 endpoint 是 stateless，不支援 previous_response_id、conversation、store、background 等狀態功能；圖片與檔案不是原生多模態輸入。工具方面支援 function calling 與 server-side web search，但 file search、code interpreter、computer use、MCP 等會被忽略。最值得警惕的是，不支援的參數可能被靜默忽略而不報錯。所以精確說法是「原生支援 Responses API 格式與核心子集」，不是「完整相容」或「零風險替換」。

第三層：Everything is a plugin 的 DeepSeek Harness

DeepSeek Harness 同樣採 MIT License。它用 Cordis 把模型、工具、skills、session、sandbox、filesystem、agent loop、排程與 UI 都做成可替換 plugin，並以 append-only event log 重建模型看到的每一步。這不是只有 README 的空殼：repo 已包含 Web UI、headless runner、ACP／JSON-RPC、Python SDK，以及 Standard、Code、Minimal、Creator 四種執行模式。

“Everything is a plugin. Models, tools, skills, sessions, sandboxes, filesystems, loops, orchestration, and UI are ALL implemented as plugins.”

中文：所有能力都是外掛；模型、工具、技能、工作階段、沙盒、檔案系統、迴圈、協調與 UI，全都以外掛實作。

DeepSeek Harness 官方 X

官方分數看的是模型，還是模型＋Harness？

官方表格很亮眼：DeepSeek V4 Pro 在 Terminal-Bench 2.1 報出 87.9，HLE 無工具／有工具為 42.7／60.0，另列出 NL2Repo、CyberGym、DeepSWE 等 Agent 任務。但表格腳註同時揭露一個關鍵條件：多個公開 coding-agent 任務使用 DeepSeek Harness 的 Minimal mode、max reasoning effort，並採特定 sampling 設定。這些是模型＋腳手架＋推理設定的系統結果，不是把模型單獨放進任何 Harness 都會重現的固定能力。

測試	DeepSeek 官方	Artificial Analysis 獨立測試	正確解讀
Terminal-Bench 2.1	87.9%	78.65%	兩邊 Harness、執行環境與重跑方法不同，不能直接當成同一實驗
HLE（無工具）	42.7%	41.01%	兩者接近；不能拿獨立無工具結果去對比官方有工具的 60.0%
Agentic Index	未提供同名指標	49.56	只適合描述 AA 自己的測試組合，不可外推成全球排名

87.9 與 78.65 的 9.25 點落差不證明任何一方「做錯」，也不能把差異單獨歸因於 Harness；它只提醒我們，Harness、執行環境、工具描述、停止條件、context 壓縮與重試方法都屬於整套評測配置。要量出 Harness 本身的影響，仍需固定其餘條件做對照實驗。這也是本次發布最值得研究的地方：DeepSeek 不只發布模型，還把一部分「怎麼讓模型拿高分並完成任務」的執行層公開了。

看似完整的 Agent Stack，接縫仍然很明顯

Harness 的預設 DeepSeek 路徑不是 Responses API

這是最容易被「同日雙發」敘事掩蓋的細節。Harness 的通用 llm-pi-ai adapter 的確能使用 openai-responses protocol；但隨附的 DeepSeek 官方 adapter明確走 Chat Completions，原始碼呼叫 /chat/completions，base bundle 預設模型也是 V4 Flash，而不是 DeepSeek V4 Pro。V4 Pro 可選、三層也能接線，但目前不是「Harness 預設以 V4 Pro 的 Responses endpoint 驅動」。

MIT 開源不等於 production-ready 或開放治理

README 用全大寫警告「THERE WILL BE COMPATIBILITY-BREAKING CHANGES」。截至 2026 年 8 月 14 日 19:29（台北時間），GitHub 尚無 release 或 tag，repo 根目錄的 package version 為 0.1.0-rc.5；CONTRIBUTING 也寫明暫不接受外部 pull request。程式碼與授權是開放的，治理流程仍未完全對社群開放。

Sandbox 的名稱不能取代真正的權限邊界

官方 credential 文件明言，0600 檔案權限只能阻止其他 OS 使用者，無法阻止同一 UID 下的工具程序讀取；workspace-write 主要限制檔案變更，不會自動封鎖讀取、網路或 process visibility。也就是說，若 Agent 可以執行不受信任的程式，就不能把 API key 與工作區隔離責任全部交給 Harness。正式測試前，仍應使用一次性 container／checkout、最小權限憑證與獨立網路政策；需要實作流程可延伸閱讀 Docker Sandboxes 的四道安全邊界。

8.59 萬 GitHub stars：最亮眼，也最不該誤讀

截至 2026 年 8 月 14 日 19:29（台北時間），DeepSeek V4 Pro 官方 X約 180 萬觀看、1.4 萬讚，Harness 官方 X約 300 萬觀看、1.7 萬讚；Hacker News 的 V4 討論為 1,022 points／443 comments，Harness 討論為 676／276。依照 X 官方說明，view 不是不重複人數，重複觀看也可能計數；這些都只能衡量注意力。

同一時間，GitHub API顯示 Harness repo 在建立約 23.5 小時後累積 85,881 stars 與 7,609 forks。這個速度異常強烈；但單看公開 star count 無法判定每顆 star 的來源，更不能由此證實 bot 或操弄。更重要的是，repo 內有可追溯到 6 月的上萬筆 commit，不能說整個專案「一天內從零做出來」。最穩健的寫法只有一個：8.59 萬是帳面星標與爭議性熱度，不是 8.59 萬名開發者已使用，更不是品質、成熟度或採用率證明。

AlphaLab 判讀：可部署層更完整，production stack 還沒有

我同意市場興奮的核心：DeepSeek V4 Pro 的 MIT 開放權重、Hosted API 的 Responses 格式橋接，以及 MIT Harness，把模型、協議與執行層放進同一個可部署版圖。對不想把 Agent 命運綁在單一閉源供應商的團隊，這比單純多一個 benchmark 第一名更重要。

但我不同意把它直接稱為「完整開源 Agent stack」。權重缺少完整訓練可重現性；Responses endpoint 是刻意縮窄的相容子集；Harness 的預設 DeepSeek adapter 又走另一條 API 路徑。官方分數是在指定 Harness 與設定下測得，跨 Harness 的可攜性仍待同條件實驗驗證。這套組合已形成一個罕見而寬鬆的可部署層，卻還沒有證明跨 client 相容、安全邊界、版本穩定與社群治理都足以支撐正式 production。

換句話說，這次發布真正改變的不是「DeepSeek 已經贏了所有 Agent」，而是競爭單位正在從單一模型，變成模型＋API 行為＋Harness。未來只比較模型分數會愈來愈不夠，因為執行框架本身就是能力的一部分。

現在怎麼測，才不會被發布熱度帶著走？

1. 模型評估者：固定同一套 Harness、工具、任務、重試與 token 預算，再比較 DeepSeek V4 Pro 與其他模型；另做一次「換 Harness」實驗，量出 scaffold sensitivity（腳手架敏感度）。
2. API 開發者：把 Responses endpoint 當 compatibility bridge（相容橋接層），逐項測試實際使用的欄位與 SSE event；對被忽略的參數採 fail closed（未驗證就視為失敗），不要因為 HTTP 200 就假設功能生效。
3. Harness 探索者：鎖定 commit 或 rc 版本，只在 disposable checkout／container（用完即丟的程式副本或容器）執行，使用最小權限短效憑證，不把 developer preview 直接接上正式秘密資料。
4. 技術決策者：接下來 30 天觀察是否出現穩定 release／tag、更多第三方可重現的 Agent benchmark、公開的安全修補與回應紀錄，以及外部 contribution 是否真正開放。這四項比 star 曲線更能回答成熟度。

最值得立刻做的不是全面遷移，而是拿一個可回滾的真實工作流，同時記錄成功率、工具錯誤、token、延遲與人工接管次數。若結果只在 DeepSeek 自家 Minimal mode 特別好，你找到的是一組優秀的 model–harness 配對；若換框架仍穩定，才更接近可攜的模型能力。