Harness 是模型之外的工作設計。
OpenCode、Plugins、OmO、Pi、oh-my-pi、Codex。不是把名字排成排行榜，而是拆開執行位置、交接方式與驗收。
研究筆記01
先把 Model 和 Harness 分開。
模型回答能力，和工作環境能做什麼，是兩個問題。
我說 Harness，指的是讓模型參與工作的一整套外層：讀檔、編輯、Shell、LSP、瀏覽器、權限、Context、分工與回報。模型是其中一個零件，不是整個工作流程。
同一個模型放進不同 Harness，能看到的檔案、能呼叫的工具、能否平行處理和要在哪裡停下來確認，都可能不同。只比較模型名字，會把真正影響結果的條件藏起來。
所以我先問工作要在哪裡完成，再問哪個模型適合。
- Context
- 把相關資料交給模型
- 工具
- 讓模型能讀、改、跑
- 規則
- 定義能做與要停下來的事
02
Plugin 把工作環境接到事件上。
OpenCode 的插件不是神奇按鈕，而是可檢查的擴充邊界。
OpenCode 官方文件把 Plugin 放在 project 或 global 的 .opencode/plugins，也可以從 npm 載入。Plugin 可以掛在 permission、tool.execute、session、message 等事件上，改變交代前後的行為。
我會先讓 AI 閱讀官方文件，把 Plugin 的事件與限制整理成白話，再和它討論真正想解決的重複工作。接著才設計要讓它在哪個事件介入、讀哪些 Context，以及什麼時候停下來讓我確認。
對我來說，Plugin 不是把能力全部打開，而是把一個明確動作交給 AI 操作；每一步仍要能從差異、權限與輸出回看。我會先做小範圍原型，確認它沒有改變不相關的 Shell 參數或把資料送出，再決定是否留下。
- 01
載入
project / global / package
- 02
事件
在明確事件上介入
- 03
檢查
看差異、權限與輸出
03
OmO 把編排做大，也把成本做大。
多代理人不會自動變成更好的判斷。
oh-my-opencode（後續文件也使用 oh-my-openagent 的名稱）把 OpenCode 擴成多代理人、專門角色、LSP / AST 工具與 MCP 的組合。它適合需要規劃、研究、實作、Review 同時展開的工作。
OmO 是我主要拿來做開發的工作面：需要跨檔案理解、規劃、實作與 Review 時，我會讓它協助把工作拆開並持續交接。但小任務不需要這麼厚；當 OmO 的交接、設定或執行狀態出問題，我會切回 Codex 直接處理，讓差異和驗收回到單一工作面。
編排層越厚，Context、模型配置、Hook、權限和失敗路徑也越多。我會把 OmO 當成一種工作模式，而不是預設開關：先用一個小任務確認交接，再決定要不要開更完整的隊伍。
| 步驟 | 得到 | 成本 | 停點 |
|---|---|---|---|
| 平行研究、專門角色、工具整合 | 包含 | 不含 | 不含 |
| 更多 Context、權限與回報路徑 | 不含 | 包含 | 不含 |
| 要知道何時縮回單一 Agent | 不含 | 不含 | 包含 |
04
Pi 讓 Agent 回到可組裝的終端。
oh-my-pi 的重點，是把 IDE 級能力放進可組裝的核心。
我把 OpenCode 看成較厚的工作台：官方 Plugin 可以從 project 或 global 設定載入，掛到事件與工具，讓 Context、Agent 和工作規則一起長大。Pi 則把自己定位成最小的 terminal coding harness，把核心 loop 留小，再由使用者用 extension、skill 和 package 組裝；oh-my-pi 再把 LSP、AST、Browser、Python、Subagents、SDK 與 RPC 接上。兩者的差異在於，哪些能力一開始就有、哪些要由使用者自己組起來。
DeepSeek Harness 是我目前的研究對象，它在 developer preview 中把 model、tool、session、sandbox、loop 都做成可替換的 plugin。MiniMax Code 則是另一條路：官方把它做成 terminal coding agent，將專案理解、修改、測試、搜尋、Plugin 與多模態工具放在同一個 CLI 工作面。我沒有把這兩個拿來做日常開發，這段是我讀完官方文件後整理出的設計差異。
我自己的使用感覺是，GPT 這類模型放回原生 Harness 時，讀專案、叫工具、回到差異與驗收比較容易接在一起；Cursor 也一樣，Composer 2.5 與 Grok 4.6／4.7 在 Cursor 裡的整合感較好，脫離 Cursor 後我常遇到上下文或工具銜接不穩。這是我目前的使用經驗。
核心
Agent loop 與終端工作
擴充
LSP、AST、Browser、Subagents
承擔
設定、更新、相容性
05
Codex 讓交代、修改和驗收連成一條線。
真正重要的是差異能不能回到人手上。
Codex CLI 的價值不只在模型，而是它把讀專案、改檔案、跑命令與 approval 放進同一個工作面。對我來說，這讓每次修改都比較容易回到差異和測試。
我不會把 OpenCode、Codex、Pi 當成誰取代誰。它們的差異在於 Context 怎麼交、工具怎麼接、權限怎麼停、結果怎麼回來。
當工作需要對外送出、發布或部署，Harness 的最後一個功能應該是停下來讓人確認，而不是默默把流程跑到底。
- 差異
- 改了什麼
- 檢查
- 怎麼知道沒壞
- 邊界
- 哪裡還沒做
06
日常工作的主力，是 OpenCode 和 Codex。
其他 Harness 是用來研究差異的。
日常開發的主力是 OpenCode 與 Codex。OpenCode 是我主要用來讀多個檔案、規劃、實作和 Review 的工作面；Codex 則讓我在同一個專案裡把差異、命令、測試與驗收接在一起。
Pi、DeepSeek Harness、MiniMax Code 等工具，我是拿來研究它們怎麼接模型、維持 Context、呼叫工具和處理權限。它們是用來理解差異的試用，不是要取代我每天工作的主力。
Google 的 Gemini CLI 也有另一個現實限制：第三方 Harness 不能直接借用 Gemini CLI 的 OAuth 訂閱憑證去轉接服務。若要從第三方開發環境使用 Gemini，應該走 Google AI Studio API key 或 Vertex AI 這類官方支援的方式。
- 日常
- OpenCode / Codex
- 研究
- Pi、DeepSeek Harness、MiniMax Code
- 連接
- 官方 API 與權限邊界