Warp 開源之後怎麼用：重點不是 terminal，而是人和 agent 怎麼一起做事

Warp 開源了 client，repo 在 github.com/warpdotdev/warp，授權 AGPL。

但比起開源本身，我覺得更有意思的是它背後那套工作流：人定方向， agent 做重工，另一批 agent 做驗證，進度全部攤在 GitHub issue 上追。 Warp 想做的其實是一個 agentic development environment，讓 terminal 變成人和 agent 一起工作的地方。 terminal 只是那個殼。

先分清楚：開源的是 client，server 是另一回事

Warp repo 公開了，你可以 clone 下來本地 build：

./script/bootstrap
./script/run
./script/presubmit

這三行指令分別是用來裝環境、跑起來、跑測試。 Client 本身可以完整本地 build 和測試，這部分沒有問題。

Server 那邊， Warp 官方目前講的是 Oz（他們的 cloud agent orchestration platform）、build.warp.dev（看 agent 怎麼跑的 dashboard）、還有 Oz for OSS（給開源專案維護者的合作方案）。我翻過公開資料，沒有看到一套完整的 server 自架步驟。

所以比較準的理解是： client 開源可以本地跑， server 和 orchestration 目前還是 Warp / Oz 的雲端工作流。如果你是開源專案維護者，可以申請 Oz credits 走合作方案。

這個區分會影響後面怎麼看「怎麼用」。如果你是 contributor，本地跑 client 接自己的 agent 就能做事。如果你是 maintainer，用的是 Warp / Oz 那套公開流程來管 issue 、 spec 、 PR 、 review。

---

先寫規格，不要先寫 code

Warp 這套 workflow 我覺得最值得學的地方是規格先行。先不要想「我要叫 agent 幫我寫一個功能」，先想這個功能要怎麼被描述清楚。

舉個例子，你要做一個功能讓 Warp 的 settings file 可以匯出匯入，方便跨裝置搬移。你先寫這種規格：

目標
- 讓使用者可以把設定匯出成檔案
- 讓使用者可以在另一台機器匯入同一份設定

非目標
- 不改 terminal 核心行為
- 不處理 plugin 生態

驗收條件
- 匯出後可以在另一台機器成功匯入
- 匯入後設定一致
- 有基本測試覆蓋
- 不破壞現有設定流程

這段看起來很基本，但它給了 agent 一個可執行的邊界。跟「我想要一個匯出功能」比起來， agent 知道什麼該做、什麼不該碰、做完要驗什麼。這比寫得漂亮重要。

---

人先定邊界， agent 才開始動

Warp 的貢獻流程本質上就是把人類放在規格和驗證的位置， agent 放在實作和整理的位置。一個任務可以拆成幾段。

第一段是人類定 scope：做什麼、不做什麼、成功條件是什麼、哪些地方不能動。這一步不要交給 agent 自己猜， scope 一旦模糊後面就會一路發散。

第二段是讓 spec agent 補完整。第一個 agent 先寫 spec 不要寫 code，它做的事是把需求拆成可執行的子項、列出風險、列出會動到哪些檔案、列出測試點、補出你沒想清楚的地方。你可以直接下這種 prompt：

把這個 issue 變成一頁 spec。
請列出：
1. 問題定義
2. non-goals
3. implementation plan
4. test plan
5. risks
6. human review points

這一步的目的不是要它寫得漂亮，是要它幫你把事情拆開。拆完你才看得到哪裡本來沒想到。

第三段才是 implementation agent 進來寫 code。 Spec 清楚了之後，可以讓不同 agent 分工：一個負責 UI 、一個負責 state 、一個負責 tests 、一個負責文件。這裡就進入多 Agent 協作了。

---

多個 Agent 怎麼協調：每個 agent 只做一段

Warp 的思路是 agent 可以很多，但每個 agent 的責任要窄。我會這樣分：

• Spec Agent：負責讀 issue、寫 spec、補驗收條件、標出風險，產出一頁 spec 和一份 task breakdown。
• Implementation Agent：按 spec 寫 code，只動被允許的檔案，每次改完回報做了什麼，產出 PR 和變更摘要。
• Test Agent：補測試、跑 presubmit、找 regression，產出測試結果、失敗原因和建議修正。
• Review Agent：看 diff、看行為是否符合 spec、找邏輯漏洞、看是不是改太多，產出 review notes 和 accept / reject / needs changes 的判斷。

這樣切的好處是避免讓一個 agent 同時負責想需求、寫 code 、寫 test 、做 review 。什麼都做，但都不夠好。分開之後每個 agent 的 scope 窄，來回也比較可控。

---

人類在哪些階段要驗證

這部分我覺得是整個流程最容易被忽略的地方。人類不能只看最後結果。

我會放三個檢查點。第一個是 spec 寫完先驗一次： scope 有沒有跑掉、 non-goals 有沒有寫清楚、驗收條件夠不夠明確。這一步沒過就不要進實作，因為在 spec 階段的問題到實作階段會放大好幾倍。

第二個是 implementation 前先看 plan： agent 寫完 spec 或拆完 task 後，人類再看一次會動哪些檔案、會不會碰太多核心區、有沒有做超過需求的事。這一步是在防止 agent 一路做大，改到最後 diff 爆開。

第三個是功能完成後人類親手驗證。不要只看測試結果，要真打開 app 、真跑一次流程、真看行為是不是跟 spec 一樣。 Agent 很會把「看起來對」和「真的對」混在一起，測試通過不代表使用者跑得起來。

---

進度怎麼追： issue 當主線， dashboard 當鏡子

Warp 的公開流程拿 GitHub issue 當 source of truth 。 README 裡提到 ready-to-spec 和 ready-to-implement 這兩個 label ，代表 issue 不是放著等人看，它有狀態。

你可以直接用一串狀態來追： open → ready-to-spec → spec done → ready-to-implement → implementing → testing → human review → ready to merge → merged 。

每次更新不要只寫一句「done」。至少記做了什麼、沒做什麼、現在卡在哪、下一步誰負責。例如：

2026-04-28
- spec 已補完
- 切出 settings import/export / tests / docs 三段
- human review 還沒過
- 下一步：implementation agent 只做 import/export parser

Warp 官方還提供 build.warp.dev ，可以看到哪些 issue 正在被 agent triage 、哪些 spec 已經寫了、哪些功能正在實作、哪些 PR 在 review 、 active agent session 有哪些。這種 dashboard 把整個 agent 生產線攤開給你看，看的是過程而不只是成果。

---

一個完整例子： settings file 匯入匯出

用這個例子把整條流程串起來。

第一步，人類下規格：

目標：
讓 Warp 支援 settings file 匯出與匯入，方便跨裝置同步。

非目標：
不改 terminal 核心輸入流程。
不處理第三方 plugin 兼容性。

驗收：
1. 可匯出設定
2. 可在另一台機器匯入
3. 匯入後設定一致
4. 測試通過
5. 人類手動驗證流程正常

這份規格跟前面提的格式一樣：目標、非目標、驗收條件。寫完之後人類先看一遍，確認 scope 沒有跑掉。

第二步， spec agent 補文件。它產出的是需要動哪些模組、 parser 要怎麼設計、 settings schema 怎麼寫、哪些測試要補。這時候人類看的是它有沒有碰不該碰的東西。

第三步， implementation agent 分工。可以拆成三個：一個做 settings schema and serialization、一個做匯出 UI 和 command、一個做匯入流程和 error handling。每個 agent 只碰自己的範圍，不會互相踩。

第四步， test agent 先跑驗證。它負責單元測試、端到端測試、跑 ./script/presubmit。如果有 fail ，它不是自己修全部，而是把失敗點整理給對應的實作 agent。這裡的設計是 test agent 不碰實作，只負責回報。

第五步， human review。人類最後看匯出內容是不是完整、匯入是不是有副作用、失敗提示是不是清楚、會不會覆蓋掉不該動的設定。過了才進 merge。

---

client / server / self-host 怎麼看

Warp client 已經開源，可以直接從 repo 拉下來本地 build 、 run 、測試。對 contributor 來說這很重要，你不一定要先懂整個雲端架構，可以先從 client 的變更下手。

Server 和 orchestration 的部分，公開資訊看起來是 Oz 和 build.warp.dev 這套。現階段你比較像是用 Warp 的公開 client，接入 Warp / Oz 的 agent 工作流，或把自己的 CLI agent 接進去。 README 也明講 Warp 可以用 built-in coding agent，或帶你自己的 CLI agent，像 Claude Code 、 Codex 、 Gemini CLI 或其他 agent。

Self-host 的部分，就目前公開文件來看，我沒看到完整的 server 自架步驟。能自架的是 client 的本地 build， server 和 orchestration 目前偏 Warp 的雲端工作流。如果你是開源專案維護者，可以看 Oz for OSS 走合作方案。

---

本地怎麼跑

要自己玩的話，最直接就是 clone repo 然後跑前面提過的那三行：

./script/bootstrap
./script/run
./script/presubmit

bootstrap 裝環境， run 把 Warp 跑起來， presubmit 跑格式、 lint 和 tests。如果你是 contributor，這比先研究一堆抽象概念更實際，先把環境跑起來再說。

---

Warp 怎麼收費？免費額度夠用嗎？

大家最關心的通常是：Warp 開源了 client，那雲端 AI 服務要收費嗎？ 答案是：Client 本身在本地跑是免費的，但如果你要用它內建的雲端 AI、團隊協作功能和 Agent 額度，就會依方案計費。

Free 版 ($0/月)

適合個人嚐鮮或輕度開發者。每個月前 2 個月有 150 個 AI credits，之後會降到 75 個。你可以開 4 個 concurrent cloud agents，有 30 個對話儲存空間。但要注意，免費版不支援自帶 API Key（Bring your own API key），也無法使用 GPT-4o 或 Claude 3.5 Sonnet 這類 frontier AI models。 另外，大家常問的「可以放幾個專案」，在 Warp 裡是算 Warp Drive 的 workflows。免費版提供 10 個 workflows 與 3 個 notebooks。

Build 版 ($20/月)

個人重度使用者或獨立開發者的起點。每月提供 1,500 個 AI credits，20 個 concurrent cloud agents。這個版本最大的優勢是支援自帶 API Key 和 MCP（Model Context Protocol），且可以直接接上 OpenAI/Anthropic/Google 等外部大模型。

Max / Business / Enterprise 方案

主要是針對企業與團隊。Max 版 ($200/月) 提供 18,000 個 AI credits，適合成員重度使用；Business 版 ($50/user/月) 則提供最高 40 個 concurrent cloud agents 和完整的團隊管理後台；Enterprise 則是針對高安全防護與大規模控管的客製化報價。

---

目前我會怎麼看 Warp 開源

Warp 開源這件事，對我來說重點不在 terminal 本身，而在它把 terminal 推到 agent 工作流裡的這個定位。把它當 ADE（agentic development environment）來看，會比把它當 terminal 來看更清楚它在做什麼。

目前我會把這套流程當成一個參考框架：規格先行、 agent 分工窄責任、人類卡三個檢查點、 issue 當進度主線。不一定要用 Warp 的工具才能做，但這個拆法本身值得借鏡。

參考資料

• Warp 官方博客：Warp is now open-source
• Warp 開源 repo：github.com/warpdotdev/warp
• Warp Pricing：https://www.warp.dev/pricing