【2026 最新】Pi vs OpenCode vs DeepSeek Harness：同模型怎麼公平比？（設定＋盲測協議＋決策樹）

Pi vs OpenCode vs DeepSeek Harness 到底該選哪一個？如果你把三款 Coding Agent 接到不同模型、給不同工具，再憑「感覺比較快」下結論，測到的其實是三套完全不同的系統，不是 Harness 本身。

這篇不會假裝公布一個沒有跑過的冠軍。它專為第一次評估本機 Coding Agent 的讀者寫：我們會先釘選 2026 年 8 月 22 日可核對的版本，接到同一個 OpenAI-compatible endpoint，再用三個 repo 任務、盲評 patch 與同一份紀錄表，做出能在你自己硬體重跑的選型協議。

先說結論：不要先問誰最快，先證明你比的是同一件事

三款工具都能成為 Coding Agent 的執行層，但重心不同：Pi 偏向精簡、可嵌入的終端工作流；OpenCode 偏向完整的日常開發介面與供應商整合；DeepSeek Harness 偏向插件化 runtime、可追溯 session 與可組合 profile。這些是產品定位，不是效能排名。

請記住本文的錨點：公平比較＝鎖住外部 envelope，再測完整 Harness 行為。Envelope 包含同一 endpoint／server build 與模型 revision、decoding／reasoning／context／output 上限、repo commit、task／prompt、acceptance tests／盲評器，以及外部資源、權限、cache 與執行順序；Harness 自帶的 system prompt、tool schema、compaction 與原生 retry 則是被測差異。

Harness 是什麼？它不是模型，而是模型的「工作現場」

模型像會寫程式的大腦；Harness 則負責把 repo、終端機、檔案編輯器、工具權限、上下文、重試與 session 紀錄接到這顆大腦。你可以先讀 AI Agent Harness 是什麼，再回來看三款成品怎麼取捨。

因此，即使用同一個模型，Harness 仍可能因為送入的檔案不同、工具回傳格式不同、壓縮上下文的時間不同，而得到不同 patch。反過來說，若模型、量化、context window 或 reasoning 設定也跟著換，你就不能把差異全部算在 Harness 頭上。

Pi vs OpenCode vs DeepSeek Harness：三款工具先看定位

Pi：把核心做小，再用 extension 與 RPC 往外長

本文釘選 Pi v0.84.2。固定版文件把自訂 provider 放在 ~/.pi/agent/models.json；JSON mode 會輸出 JSONL 事件，session 本身也是可續跑、分叉與匯出的 JSONL tree。若你要用很薄的 CLI、自己寫 extension，或透過 RPC 嵌進自動化流程，Pi 是值得先試的起點。

OpenCode：把 TUI、client／server 與 provider 生態整成日常工具

本文釘選 OpenCode v1.18.21，只採用穩定版 v1 文件，不混用另行安裝為 opencode2 的 V2 beta 語法；官方明示 beta 的 API、config 與 plugin API 仍可能改變。固定版 CLI 文件列出 opencode run、JSON 格式輸出、session export 與 stats；自訂 provider 可在 opencode.json 接 OpenAI-compatible endpoint。若你想要完整 TUI、供應商選擇與插件整合，先從 OpenCode 試跑。

DeepSeek Harness：把 runtime、工具與 UI 都視為插件

本文釘選 DeepSeek Harness v0.1.1-rc.2。官方稱它仍是 developer preview，並明示可能出現相容性破壞。它的 session backend 以邏輯 append-only log 保存提示、reasoning、工具呼叫、結果與排程，Web UI 的 Trajectory 則是這些事件的檢視層。Standard／PTC／Minimal／Creator 是 UI 名稱，對應 preset ID standard／code／minimal／cordis；headless 是另一層的 CLI profile。若你的優先順序是可觀測性與插件化 runtime，可以把它列入候選，但升級要另開測試批次。

步驟 1：先把三款版本釘死

痛點：Harness 更新很快，同一個名字隔週可能已不是同一套行為。解法是版本釘選：安裝前先記錄 registry 回傳值，再安裝本文核對的版本；之後升級就建立新批次，不覆蓋舊結果。

npm view @earendil-works/pi-coding-agent@0.84.2 version dist.integrity
npm view opencode-ai@1.18.21 version dist.integrity
npm view @deepseek-ai/dsh@0.1.1-rc.2 version dist.integrity

npm install -g --ignore-scripts @earendil-works/pi-coding-agent@0.84.2
npm install -g opencode-ai@1.18.21
npm install -g @deepseek-ai/dsh@0.1.1-rc.2
dsh web --no-open

Pi 這條 npm 安裝路徑要求 Node.js 22.19.0 以上。把 registry integrity、release commit、Node.js 版本、作業系統、CPU／GPU、RAM／VRAM、三個 package 版本、模型檔 hash 與 endpoint server build 一起寫入 environment.json。在同一個已載入模型的 endpoint 上，runner 不會改變權重檔本身大小；但 prompt 長度、context、並行 subagent、KV cache、工具子程序與 runner 常駐量都會改變總記憶體，必須分項量測。

步驟 2：把 Pi、OpenCode、DeepSeek Harness 接到同一個 endpoint

假設你的本機服務在 http://127.0.0.1:1234/v1 提供 OpenAI-style /chat/completions，模型 ID 是 local-coder。以下的 context 與 output 數字只是設定範例，必須改成模型與 server 真正支援的值；若本機服務不驗證金鑰，仍可放一個不具權限的 dummy 值。若服務只有 /v1/responses，OpenCode 官方要求改用 @ai-sdk/openai，不能混進這條 chat-completions lane。

Pi：~/.pi/agent/models.json

{
  "providers": {
    "local": {
      "baseUrl": "http://127.0.0.1:1234/v1",
      "api": "openai-completions",
      "apiKey": "local",
      "compat": {
        "supportsDeveloperRole": false,
        "supportsReasoningEffort": false
      },
      "models": [{
        "id": "local-coder",
        "reasoning": false,
        "input": ["text"],
        "contextWindow": 32768,
        "maxTokens": 8192
      }]
    }
  }
}

Pi 的固定版 custom model 文件也提供 compatibility 欄位。若 endpoint 支援 reasoning，三組都要用同一種開關與 effort；不能只替某一組開啟。endpoint gateway 必須固定 sampling 參數，並保存去除敏感內容後的 provider-wire request metadata，避免三個 client 的預設值不同。

OpenCode：專案根目錄的 opencode.json

{
  "$schema": "https://opencode.ai/config.json",
  "model": "local/local-coder",
  "provider": {
    "local": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Local endpoint",
      "options": {
        "baseURL": "http://127.0.0.1:1234/v1"
      },
      "models": {
        "local-coder": {
          "name": "Local Coder",
          "reasoning": false,
          "limit": {"context": 32768, "output": 8192}
        }
      }
    }
  }
}

DeepSeek Harness：$DSH_HOME/settings.yaml

agent-default-model:
  provider: local
  model: local-coder

llm-pi-ai:
  providers:
    local:
      displayName: Local
      apiKeyEnv: LOCAL_API_KEY
      api: openai-completions
      baseURL: http://127.0.0.1:1234/v1
      defaultContextWindow: 32768
      defaultMaxTokens: 8192
      retryPolicy:
        mode: normal
        maxRetries: 0
      compat:
        supportsDeveloperRole: false
        maxTokensField: max_tokens
      models:
        - id: local-coder
          contextWindow: 32768
          maxTokens: 8192
          reasoningEfforts: false

依固定版 provider 指南設定後，再把 LOCAL_API_KEY 指向你的服務要求的值。agent-default-model 讓新 agent／headless 選到這條 route；reasoningEfforts: false 把範例宣告成非 reasoning 模型，gateway 仍必須證明實際 request 沒有偷偷開啟 reasoning。

retryPolicy 只把 DeepSeek Harness 這條 provider route 的模型請求重試設為 0。Pi 預設另有三次 agent-level retry，OpenCode v1.18.21 對 transient error 內建最多五次重試，stock 版本沒有相同的公開零重試開關。因此共同基準把原生 retry 視為 Harness 行為，用 gateway request ID 與 attempt log 實際計數；若要做零重試實驗，必須另建並釘選修改版 lane。

步驟 3：建立「共同基準」與「原生體驗」兩條賽道

共同基準賽道回答「同一外部 envelope 下，哪套完整 Harness 行為最適合這批任務？」這是目標條件，不是三款 stock 預設已經等價。由同一個外部 container／VM 強制 cwd mount、網路、CPU／記憶體、hard timeout 與 approval policy；只有全部通過 preflight 的 run 才納入。三組只開放等價的讀檔、寫檔、shell 與測試能力，但不強求工具名稱相同。

原生 system prompt、tool schema、compaction 與 retry 是 Harness 的一部分，應逐 run 保存而不是假裝已被控制。外部 runner 負責固定可控制的邊界；gateway log 負責證明實際 model request、attempt 與時間。

原生體驗賽道回答「我每天真的用哪套比較順？」這時允許各自的 extension、plugin、TUI、session 與 trajectory 能力，但要把啟用清單與設定檔一起保存。兩條賽道不能混成一個總分：前者測控制條件，後者測完整產品。

如果你想更深入理解工具 schema 為何會影響 token，可搭配 MCP vs CLI token A/B 測試；要自己搭最小 loop，則讀 30 行 Harness 實作。

步驟 4：用三個 repo 任務，不用一題 demo 決勝負

先挑你有權使用、可公開重建的 fixture，釘選 commit。每題各跑三次只是找明顯不穩定的起點，不是統計保證；真正選型前應擴充到你的真實工作分布。

1. 小型修復：給一個會失敗的單元測試，要求找原因、修正並讓既有測試通過。
2. 跨檔變更：調整一個 API，更新呼叫端與測試，驗收 backward-compatibility 規則。
3. 長上下文任務：在較大的 repo 重構模組、補文件與測試，檢查是否漏改引用。

每次從乾淨副本開始，使用同一份 TASK.md、同一 commit、同一環境變數與測試命令。任務答案不得放在 agent 可搜尋的檔名、branch 名或 prompt。順序用隨機 manifest 打散以平衡 order effect；cold lane 仍須清除或切換獨立 cache namespace，warm lane 則要定義可重播的相同前綴，不能把隨機化當成 cache reset。

步驟 5：先定義「通過」，再讓 Agent 動手

Agent 說「完成了」不算通過。每題先寫機器可執行的 acceptance test，再加少量人工 rubric：是否改到允許範圍、是否留下不必要依賴、是否違反 API 約束。評分者只拿到隨機 run ID、最終 patch 與測試輸出，不知道 Harness 名稱。

一筆最小紀錄可以長這樣；沒有回傳 usage 的欄位用 null，不能寫成 0：

{
  "run_id": "R-7F2A",
  "fixture_commit": "...",
  "task_id": "api-change-01",
  "harness_version": "...",
  "model_sha256": "...",
  "prompt_sha256": "...",
  "pass": true,
  "prompt_tokens": null,
  "output_tokens": null,
  "cache_read_tokens": null,
  "wall_time_ms": 0,
  "tool_calls": 0,
  "retries": null,
  "human_interventions": 0,
  "exit_reason": "completed",
  "patch_sha256": "..."
}

wall_time_ms 與確定可觀測的計數欄位由 runner 實際填入；範本中的 0 不是測試結果，無法確認的 retry 則維持 null。首要指標是 acceptance pass rate，其次才是通過任務的時間、token、重試與人工介入。失敗任務不能只從速度圖消失，否則最快的方法可能只是最快放棄。

步驟 6：三種輸出格式，要先轉成同一份 ledger

正式計時前先各跑一次不計分 smoke test，完成 package、profile 與 model 初始化。先把前述 Pi models.json 複製到 /path/to/run/pi-config/；下面的 Pi smoke command 會隔離全域資源並關掉外掛與舊 session：

PI_CODING_AGENT_DIR=/path/to/run/pi-config PI_OFFLINE=1 \
pi --mode json --provider local --model local-coder --thinking off \
  --tools read,write,edit,bash --no-extensions --no-skills \
  --no-prompt-templates --no-themes --no-context-files \
  --no-approve --no-session \
  "讀取 TASK.md 並完成任務" > pi.events.jsonl

opencode run --model local/local-coder --format json \
  "讀取 TASK.md 並完成任務" > opencode.events.jsonl

dsh --profile headless \
  "讀取 TASK.md 並完成任務" > dsh.final.txt

Pi 與 OpenCode 會產生 newline-delimited CLI events。DeepSeek Harness 的 headless command 會依前面的 agent-default-model 選到 local route 並保存 session，但官方 headless 是完整 composition，不是兩工具 Minimal；上面三行只能示範輸出與連線，不能直接當成已完成的 matched benchmark。

DeepSeek Harness 的正式共同基準要建立釘選的 benchmark Cordis composition 或 user agent preset，保存原始 agent.cordis.yml、host／provider settings 與 SHA-256。--dump-config 只能展開已存在 CLI profile 的 host／plugin tree，不能證明另外兩款已對齊；跨 Harness 邊界仍由外部 runner manifest 與 gateway log 證明。

若你要從官方最小範例改起，可讀固定 commit 的 Python Minimal agent。它原本掛的是 DeepSeek-compatible adapter，改成通用 OpenAI-compatible route 時要明確記錄這項 adaptation；官方 Python SDK 教學也標明原始 composition 是 danger-full-access、editor 使用裸本機檔案系統，persistent PTY 不支援 Windows agent，因此只在 disposable container 或 checkout 執行。

不要假設三套 JSON 欄位同名，也不要用輸出字數猜 token。你的 adapter 只做格式映射：endpoint 明確回報什麼就保存什麼；cache、reasoning token 或 tool usage 沒有官方欄位時就留空。OpenCode 的 JSON mode 不是完整 wire trace，也不包含 retry status；retries 要用 endpoint／gateway 的 request ID 與 attempt log 計算，無法確認就填 null。保存原始 CLI 事件輸出、session export 與去敏 request metadata 供覆核。

決策層：Pi、OpenCode、DeepSeek Harness 怎麼選？

先選 Pi：你想要精簡終端 runner、JSONL／RPC 自動化，並願意自己組 extension 與權限邊界。

先選 OpenCode：你要的是日常 TUI、廣泛 provider 設定、session 管理與插件生態，不想先寫自己的外殼。

先選 DeepSeek Harness：你想檢視模型請求、reasoning 與工具事件的 trajectory、組合 profile 與插件化 runtime，且能接受 developer preview 的升級成本。

低顯存先別按 Harness 選：先用 本機 LLM 顯存指南決定模型、量化與 context，再測三款 runner 的額外常駐記憶體。長任務則把通過率、壓縮後漏改與人工救援放在速度前面。

常見坑：六種看似公平、其實失真的比較

1. 模型偷換：provider alias 指到不同 checkpoint；保存實際 model ID、server log 與檔案 hash。
2. 工具不等權：一組能搜尋全 repo，另一組只能讀當前檔案；比較前先畫 capability map。
3. 冷熱 cache 混在一起：固定 server build、cache mode／namespace 與指標定義，cold 與 warm 分開，不把 missing usage 當零。
4. 只看最漂亮的一次：保存所有重試、逾時、事件輸出與人工救援，不能只挑成功 run 當代表。
5. 讓 Agent 自己打分：通過必須由外部測試與盲評者判定。
6. 升級後覆蓋舊資料：版本、設定或 prompt 一變就另開 batch，避免把不同條件硬算趨勢。

安全性也要另列 hard gate。Pi v0.84.2 安全文檔明示它會以啟動使用者的權限執行，且沒有內建 sandbox；這至少提醒你：本機模型不等於低權限執行環境。DeepSeek Harness rc.2 CLI 契約則顯示，新 session 預設 workspace-write 主要限制 Bash／filesystem 寫入，reads 與 network 並未一起封鎖，process visibility 也依 sandbox backend 而異。對三套工具都應使用測試帳號、隔離 fixture、最小檔案權限與人工確認規則，不把正式憑證放進 benchmark repo。

截至 2026 年 8 月 22 日，重跑前要重新核對什麼？

本文版本快照是 Pi 0.84.2、OpenCode 1.18.21、DeepSeek Harness 0.1.1-rc.2。重跑前重新查 registry 與 release notes，但不要直接升級舊批次；先複製設定、更新一個新 batch，確認 provider 語法、CLI flag、event schema 與 session 路徑，再比較前後差異。

DeepSeek Harness 官方資料處理聲明稱 session／工具紀錄預設留在本機，但也可能回報匿名化設定與 project list，並提供停用或改 reporting address 的方式；你主動設定的外部模型、web tool、MCP 或 plugin 也可能上傳 user data，由該服務商處理。因此「本機 Harness」只描述執行位置，不自動代表所有資料都不離機。

FAQ：Pi vs OpenCode vs DeepSeek Harness 常見問題

1. 哪一款 Harness 最快？

目前不能只憑產品名回答。模型、server、cache、任務與工具都會改變時間；請先在相同條件下量通過任務的 wall time。

2. 社群票數高，就代表 Pi 一定最好嗎？

不代表。社群討論能顯示興趣，卻不是控制模型、版本、硬體與任務後的比較。

3. 三款工具必須使用完全相同的 tool 名稱嗎？

不用。共同基準要對齊的是能力、權限與觀察結果；名稱逐字相同不會自動帶來公平。

4. cache hit 可以直接跨 Harness 比嗎？

條件很嚴格。只有同一 endpoint、同一模型 revision、同一 cache namespace 與相同指標定義，並保存 request prefix hash 與 cache-eligible input tokens，才比較 hit ratio／cached tokens；否則各自保留原始欄位，不合併。OpenCode v1.18.21 的 stats 實作會把缺失 cache usage 正規化成 0，沒有 gateway 原始 usage 時仍記 null。

5. 低 VRAM 應該直接選 Pi 嗎？

先不要這樣推論。先固定模型、量化與 context，再在同一外部 envelope 下分項量測 runner、工具程序與 KV cache 的常駐資源。

6. DeepSeek Harness 已經是穩定版嗎？

不是。截至 2026 年 8 月 22 日，官方 release 仍標為 rc.2，專案也明示 developer preview 與相容性破壞風險。

7. 接本機模型就安全了嗎？

不一定。Harness 仍可能讀寫檔案、執行 shell、呼叫外部工具；本機 endpoint 與 OS sandbox 是兩件事。

8. 每題跑三次就能決定公司標準嗎？

不能。三次只適合找明顯不穩定；正式決策要涵蓋真實 repo 分布、失敗成本與多批版本。

給新手的 7 個重點

1. 先釘版本、模型、endpoint、repo commit 與 prompt，再談勝負。
2. 共同基準與原生體驗分兩條賽道，不混成一個分數。
3. 用三種難度的 repo 任務，不用一題 demo 選冠軍。
4. 先看 acceptance pass，再看時間、token、重試與人工介入。
5. 評分者只看匿名 patch 與測試證據，不能看 Harness 名稱。
6. 缺少 usage 欄位就留空，永遠不要把 missing 寫成 0。
7. 先按工作方式選兩款進決賽，再用自己的硬體重跑。