共用 Harness，差異化介面

資料來源#

摘要#

每個同時打造程式碼代理程式與知識工作代理程式的供應商，都得回答這個架構問題：一套 harness 搭配不同前端，還是做成兩項產品？ OpenAI 的答案是一套。Akshay Nathan（OpenAI 生產力團隊產品工程主管）於 2026 年 7 月在 Latent Space 節目中直言：

「所以 harness 是相同的。這是共用的 harness……在 UX 方面，當你使用 Codex 模式時，我們有一些明確的設計主張……還有一些沙箱相關的差異，但底層 harness 和能力應該相同。」

Anthropic 的答案則是兩套：Claude Code 用於輸出為程式碼的工作，Cowork 用於輸出不是程式碼的工作；Cat Wu 把規則說成面向使用者的決策程序（「如果輸出不是程式碼，我就會用 Cowork 來做」）。

證據說明。 practitioner-opinion — 一位產品主管在 podcast 上描述自己的產品，沒有附上任何測量數據。以下所有採用率和品質數字都在文中標明出處，應視為 vendor-claim，且來自 practitioner-opinion 類型的來源。

兩種介面實際上有何差異#

Nathan 指出三項差異，而且只有三項：

面向	Codex 模式	ChatGPT Work 模式
Git 狀態	「動態島」預設你位於 git 儲存庫中；檔案編輯和差異會顯示出來	隱藏 git 狀態；同一個退休金計算器任務會顯示產出的成品，而不是差異
思維鏈顯示	以 diff 為主——「讓你一開始就能看到差異」	抽象化處理
沙箱預設值	適合開發者的預設值	預設值不同，「安全方面……要確保在一種狀態與另一種狀態下，我們都有適當的預設值」

其他一切——plugins、電腦操作、產物、記憶、子代理程式、排程任務、持續運作的電腦環境——都是共用的。Nathan 將這項不變原則表述為產品原則：「你在桌面版產品 Codex 區域能做的一切，在 ChatGPT Work 裡也能做，反之亦然。」 尤其是 plugins，這項功能「在本產品、ChatGPT 和雲端之間是統一的」。

值得注意的趨同：這就是 Cherny 所說的殘餘部分#

這三項差異是權限／沙箱，以及 UI。這幾乎逐字呼應另一家實驗室的 Boris Cherny 在被問到 Anthropic 刪除 Claude Code 系統提示中 >80% 後，harness 還剩下什麼時給出的回答：

「如果你看看 Claude Code harness 目前的程式碼，幾乎全部都在處理安全、權限和靜態分析，另外還有一堆 UI 程式碼。」

兩家供應商從相反方向出發——Anthropic 透過刪減 harness，直到只剩殘餘部分；OpenAI 則將同一介面分叉成兩種，找出必須有所差異之處——最後都落在同一份精簡清單上。這為 Harness Shrinkage as Models Improve 提供了 wiki 過去沒有的獨立佐證：縮減論點幾乎從頭到尾都來自 Anthropic，而這個非 Anthropic 的說法顯示，只有在這個論點大致正確時，該產品架構才說得通。如果能力仍依賴各介面的提示詞腳手架，「相同 harness，不同 UX」就無法推出上市。

同一方向的另一筆較小佐證：在傳統 ChatGPT harness 和 Work 模式之間切換，是模型的決定，不是 harness 邏輯。有人問這是否由路由器處理時，Nathan 回答：「這是模型做出的決定……它會看到你想做的事，用 Work 模式處理會更合適。」過去本可用腳手架實作的派發規則，如今成了行為。

分歧：依輸出類型拆分，還是完全不拆#

Nathan 明確考慮過 Anthropic 的做法，但最後否決：

「我們原本可以採取一種做法，把兩種體驗完全分開……做成不同的應用程式，或是放在同一個應用程式裡，但提供截然不同的體驗。」

他的理由不是技術考量，而是對使用者的判斷：角色正在模糊，因此任何依「你是誰」畫出的產品界線，都像畫在沙地上。「想依據你是誰來畫出硬性的界線，會很困難。我們應該讓使用者自行選擇，但不該把他們框住。」Anthropic 的界線是依輸出是什麼而非你是誰來劃，避開了部分反對理由——但這仍要求使用者在不知道任務會產生什麼之前，就先選擇介面；而 Nathan 的原則恰恰是不讓使用者被迫做這種選擇。

兩邊都沒有證據。應把這看成兩種產品賭注，而非已定論的問題——也要留意日期：wiki 上的 Cowork 資料來自 2026 年 5 月，Nathan 的說法則出自 2026 年 7 月，因此兩者的差異有些可能是資訊落差，而非理念不同。不是資訊落差的是明確表達的原則：Nathan 說「我們不希望使用者卡在某個分頁或某種體驗裡，無法使用產品的強大功能」，這是承諾，不是產品路線圖上的項目。

單一 harness 的賭注還帶來一項 Anthropic 的拆分策略不需要面對的推論：**開發者介面必須以品牌而不是程式碼庫的形式，在合併後繼續存在。**Nathan 強調 Codex 會保留下來——「開發者長期以來一直是我們的核心市場……這完全不會改變這一點」——並主張合併反而提高 Codex 的上限：「現在你可以在撰寫 diff、建立產物或進行搜尋之間流暢切換。」

合併的代價：對進階使用者徵收抽象化成本#

共用 harness 若要服務大眾市場，就會產生兩項產品的做法不必面對的壓力：開發者想要的每項功能，都得成為知識工作者不必看見的控制選項。這份逐字稿罕見地坦率揭露了目前在哪些地方付出這項成本。

子代理程式的可見度。 子代理程式逐字稿預設隱藏。Nathan 稱這是刻意的取捨：「我們還可以再迭代，讓你確切看到它們在做什麼；不過這可能會讓資訊多到令人不堪負荷。所以這是我們目前刻意做出的取捨。」對照 Claude Code：它將子代理程式公開為由使用者編寫的 .claude/agents/ 檔案，並讓使用者逐一選擇模型——同一個基本功能，因為受眾不同，所以採取設定而非抽象化的方式呈現。
模型選項太多。「有 32 個選項。」Nathan 說：「有人可能會認為現在選項太多了，我們正在研究如何簡化。」
Ultra 移到進階設定裡。 上線後，OpenAI 將 Ultra（多代理程式模式）改為選擇加入，並把它藏得很深，「因為這是為特定對象設計的。這是給了解接下來會發生什麼的進階使用者，因為它也可能依你的使用情境而消耗更多額度。」

整體來看：**能力共用，但各介面會依受眾限制資訊的易讀性。**這與 HTML as the New Markdown 指出的面向模型與面向人類的不對稱情況相同——但在此，面向人類的 harness 不只是在擴大，還依受眾差異化地提供資訊；這比縮小或擴大都更難設計。

第三家供應商：把同一種架構當成採購建議來推銷#

OpenHands 在 2026 年 7 月發布的 GitHub 分析（Coding Agents and Technical Debt，case-study）從儲存庫而非產品角度得出相同架構，並發現這並非兩家供應商才有的模式，而是整個類別的預設形態：「『程式碼代理程式』聽起來像是一個程式。實際上，它是一個平台。」OpenHands 將架構拆分為四個公開儲存庫——app/server 共 404K 行、Software Agent SDK（執行環境）333K 行、Agent Canvas UI 246K 行、CLI 67K 行——並指出競爭對手雖只有一個儲存庫，內部也有相同分工：Codex 包含「CLI、數十個核心執行環境 crate、app server、MCP 支援，以及 Python 和 TypeScript SDK」；OpenCode 的 packages/ 則包含 core、server、cli、desktop、tui、web、兩個 SDK 和一套 plugin 系統。

值得玩味的是這種架構是賣給誰的。OpenAI 打造了一套 harness，並分出自己的介面；OpenHands 則主張企業應該租用執行環境，只擁有自己的介面——「你的團隊負責產品專屬的那一層，上游持續維護底下的執行環境……也就是說，每年 2,036 個 SDK PR 會繼續在上游完成，而不會變成你們的待辦事項。」同樣的界線，這次畫在兩家公司之間，而非兩種產品模式之間。若界線畫錯，代價是分叉的程式碼庫一年後會落後約 4,600 個 PR；供應商利益相關的注意事項請見 Harness Build-vs-Buy。

第四家供應商：將既有產品遷移到這種模式#

Cline 在 2026 年 9 月進行的遷移（How We Migrated 11 Million Users to Cline's Biggest Harness Upgrade，empirical，供應商自述）呈現的是轉換進行中的樣貌，而非已完成的架構。VS Code 擴充套件使用自己的私有核心；CLI、Desktop 和 JetBrains 則早已採用共用的 Cline SDK。這次遷移就是把最後一個、年代最久的介面，移到其他產品已在使用的同一個執行環境上——如今 @cline/core、@cline/agents、@cline/llms 和 @cline/shared 都同時供應 VS Code、CLI、JetBrains、Desktop 和 Hub，只有輕薄的介面專用轉接層（來源分別報為 21k 或 42k 行，未能核對）和 UI 留在共用引擎之外。完整說明見 Cline；各套件的行數，以及從 build-vs-buy 角度的解讀，見 Harness Build-vs-Buy。

待解決的問題#

隨著受眾範圍擴大，依 UX 層區分的單一 harness 是否仍能行得通？抑或抽象化成本（隱藏子代理程式、32 個模型選項、把 Ultra 藏在進階設定裡）最終會迫使產品再次拆分？
Anthropic 依輸出類型拆分成兩項產品，OpenAI 則推出一個合併介面——這是長期的架構分歧嗎？還是 Anthropic 的拆分只是 2026 年 5 月時的情況，後來的來源顯示雙方差距正在縮小？

資料來源#

Codex from 0 to 10M Users: Building ChatGPT Work - Akshay Nathan, OpenAI — Latent Space，2026-07-28（practitioner-opinion）：Akshay Nathan 談共用 harness、三項 UX 差異、合併理由，以及子代理程式和 Ultra 可見度方面的取捨
Coding Agents and Technical Debt — Rajiv Shah，OpenHands，2026-07-28（case-study，存在供應商利益考量）：以各儲存庫的程式碼行數說明「程式碼代理程式永遠不只是一個程式碼庫」，並以租用而非分叉的決策，建議採取相同的執行環境／介面分界
How We Migrated 11 Million Users to Cline's Biggest Harness Upgrade — Saoud Rizwan，Cline blog，2026-09-02（empirical，供應商自述）：最後一個產品介面遷移到既有共用 SDK，以及各套件的程式碼行數。完整說明見 Cline

共用 Harness，差異化介面

資料來源#

摘要#

兩種介面實際上有何差異#

值得注意的趨同：這就是 Cherny 所說的殘餘部分#

分歧：依輸出類型拆分，還是完全不拆#

合併的代價：對進階使用者徵收抽象化成本#

第三家供應商：把同一種架構當成採購建議來推銷#

第四家供應商：將既有產品遷移到這種模式#

延伸閱讀#

待解決的問題#

資料來源#