寫在前面2026 年 8 月兩個都叫「Harness」的東西前后腳出現在視野里。8 月 13 日 DeepSeek 放出了 dshDeepSeek Harness的開發者預覽幾天后的 8 月 19 日OpenAI 發了一篇《Codex as a platform》把已經在驅動 Codex App、CLI、IDE 的那套執行系統正式講成一套可復用、可嵌入的開源 Agent Harness。我這邊把兩邊的官方文檔和源碼都翻了一遍——Codex 那份是 clone 下來的openai/codex倉庫dsh 是之前就在本地跑過的deepseek-ai/dsh。翻完最直接的感受是兩者都自稱 harness都在解決「模型之外那層執行系統」的問題但設計取向幾乎是相反的。一個像整車一個像底盤。這篇文章不想給兩者排優劣也不預測誰會贏。只想講清楚一件事同樣是「模型周圍的執行系統」為什么會長成兩個方向以及這兩個方向分別適合什么場景。先對齊一個概念Harness 到底指什么如果你還沒接觸過這個詞可以先記住一個等式Agent Model Harness。模型負責的事其實很窄——給它上下文它決定下一步做什么產出一段文字或者一次工具調用。但一個真實的任務遠不止「決定下一步」。假設你讓 AI 改一個倉庫它要先讀文件、再改代碼、然后跑測試中途可能要申請網絡權限進程斷了還得能接著來。這里就冒出一串模型自己答不了的問題誰記住改到哪一步了誰真正去執行那條 shell 命令誰在危險操作前攔一下等你批準失敗了誰決定要不要重試這些「臟活累活」的集合就是 Harness。它做的遠不止給模型套一層 Prompt——狀態、工具、執行邊界、進度、審批這一整套圍繞模型運轉的系統都歸它管。OpenAI 官方的說法很直白「That surrounding execution system is the harness.」概念對齊之后兩種取向的分歧就好講了。Codex 的取向把執行層做成一臺一體化引擎Codex Harness 給人的第一印象是「重」。它的核心實現是 Rust倉庫里codex-rs目錄下有 104 個 crate子模塊涵蓋 agent loop、協議、傳輸、沙箱、身份認證一整套。這不是一個輕量腳本而是一臺編譯成原生二進制的執行引擎。它對外暴露能力的方式是三個層層遞進的原語Thread一段可以持續、可以恢復的長期工作回答「這段工作和歷史屬于誰」TurnThread 里當前這一輪目標回答「這一輪怎么開始、怎么引導、怎么結束」Item這一輪里產生的一條可持久化記錄比如一條用戶消息、一次推理、一條 shell 命令、一次文件改動你的應用通過一個叫app-server的進程連上它走 JSON-RPC 協議創建 Thread、啟動 Turn、流式接收 Item 和事件、在模型要執行危險操作時把審批請求交回給你的界面。Codex 的 VS Code 插件、CLI本質上都是這個 app-server 的客戶端。安全邊界也是「內建」的。源碼里按操作系統分了三套沙箱——Linux 走 landlock、macOS 走 seatbelt、Windows 單獨一套。也就是說「在什么范圍內能讀寫文件、能不能聯網」這層約束是 harness 自己在 OS 級別兜住的不用應用層自己去搭。這套設計的代價是它只跑 OpenAI 自己的模型。Codex 的 agent loop 深度依賴 OpenAI Responses API 的推理鏈條reasoning items傳遞和壓縮這套機制是 OpenAI 模型特有的。換句話說你拿到的是一臺調校好的引擎但油箱只認一種油。它的取向可以概括成一句話把執行層做厚、做穩、做成開箱即用代價是綁定一家模型、內核不可改。你能控制的是「給它什么工具、什么上下文、什么審批規則」但 agent loop 本身的重試策略、上下文壓縮策略你只能用 OpenAI 給的那套。dsh 的取向把一切拆成可替換的插件dsh 的第一印象正好相反——它很「薄」。它基于一個叫 Cordis 的運行時核心理念只有一句everything is a plugin一切皆插件。薄到什么程度在 dsh 里界面上的按鈕比如文件附件是插件系統提示詞是插件工具調用是插件——連 agent loop 本身都是一個插件。你看到的整個產品是一堆插件在 Cordis 上組裝出來的結果。這帶來一個 Codex 給不了的能力你可以把 loop 換掉。Codex 里 agent loop 的行為是 OpenAI 定死的dsh 里如果你覺得默認 loop 太啰嗦、愛跑偏可以寫一個自己的 loop 插件替換進去。dsh 還自帶一個類似 LangSmith 的 trajectory 視圖agent 每一步動作都能點開看是哪個插件產生的、為什么——這種顆粒度的可觀測性來自它「一切都是插件」的結構。模型這塊 dsh 也不綁定。它默認用 DeepSeek 自家模型但可以通過 API Key 接任意 provider包括走 OpenRouter 接一大堆第三方模型。最能體現取向差異的一點dsh 可以把 Codex、Claude Code 當成 sub-agent 來驅動。它有專門的插件能在一個 dsh 會話里把某個子任務委派給 Codex 去跑再收回結果。在 dsh 眼里Codex 不是競品而是「一個特別擅長 OpenAI 模型的可調用執行單元」。代價也很實在dsh 目前還是開發者預覽官方自己都說「迭代快到沒有一處是穩定的」。而且它「開箱即用」的能力比 Codex 弱——給你的是一個框架墻得你自己砌。它的取向也能概括成一句話把一切做成可插拔換來極致的靈活和可組合代價是穩定性和開箱體驗要你自己補齊。同一個問題的兩種答案三個分歧點把兩邊放到一起看分歧集中在三個地方。第一個分歧是模型綁定。Codex 為了在 OpenAI 模型上榨出最大性能深度適配了一家模型dsh 把模型當成可替換的 provider。這更像「專精」與「通用」的經典取舍談不上誰更先進——Codex 官方披露過一個 ARC-AGI-3 的例子僅靠 harness 層做「保留推理 上下文壓縮」兩項調整GPT-5.6 Sol 的得分從 13.3% 提到 38.3%同時輸出 token 減少。這種收益恰恰來自它跟模型的深度耦合換模型未必能復現。第二個分歧是內核可不可改。Codex 開源的是執行層和集成接口但 agent loop 的行為邏輯你只能用不能改dsh 把 loop 本身也做成插件行為邏輯對你是敞開的。前者適合「我信任你的調校別讓我操心」后者適合「我知道我要什么別擋著我」。第三個分歧是怎么擴展。Codex 的擴展入口是 MCP——你把自己的數據和操作包成 MCP 服務接進去harness 內核不動dsh 的擴展入口是插件——從 UI 到 loop 到工具哪一層都能換。一個是「在穩定內核外圍接東西」一個是「內核本身就是可拆的」。有意思的是這兩條路在協議層反而在慢慢靠攏。dsh、OpenClaw 這類項目都能通過標準協議把 Codex 接進來當運行時——設計取向不同不代表老死不相往來。那到底該用哪個先說結論這不是一道二選一的題判斷依據是「你的系統需要控制到哪一層」。如果你要的是在 OpenAI 模型上快速拿到一套調校好、開箱即用、還帶 OS 級沙箱的執行能力并且能接受綁定一家模型那 Codex Harness 是省心的選擇。尤其當你要把 agent 嵌進已有產品運營看板、工單系統、IDEapp-server 那套 Thread/Turn/審批的協議是現成的。如果你要的是跨模型切換、深度定制 agent 行為、或者把多個 harness 編排到一起那 dsh 的插件架構更貼合。它的價值不在開箱而在于你愿意花時間打磨之后能得到一個完全長成你團隊工作流樣子的 harness。還有一種常被忽略的情況你現在可能一個都不需要。如果你的場景是固定流程的 workflow已有的方案能穩定處理狀態、工具和執行邊界那沒必要為了「用上 harness」而引入 harness。它真正的用武之地是當任務要跨多輪持續、要在受控環境里調工具、要處理審批和失敗恢復的時候。一句話收尾Codex 把復雜度收進引擎里替你扛了dsh 把復雜度攤開交給你自己搭。選哪個取決于你想省心還是想掌控。數據口徑本文基于 OpenAI《Codex as a platform》官方文章、openai/codex倉庫Apache-2.0截至 2026-08-26 的快照與 dsh 公開資料整理。文中不對兩者做優劣判斷也不預測演進關系。