---
slug: warp-open-source-agent-workflow
title: Warp 開源之後怎麼用：重點不是 terminal，而是人和 agent 怎麼一起做事
status: published
excerpt: Warp 開源的是 client，而不是整套雲端工作流。這篇整理規格先行、agent 分工、進度追蹤、client/server/self-host 和收費額度。
category: AI
tags: [warp, terminal, agents, open-source, oz, cli, claude-code, codex, ai]
author: Seer
author_role: Author
read_time: 9 min
cover: "/static/warp-open-source-agent-workflow-cover.png"
closing_note: "Terminal 只是冷冰冰的殼，而協作的靈魂，永遠在於人類如何為它劃出第一道邊界。"
published_at: "2026-06-20T12:21:19Z"
updated_at: "2026-07-01T15:51:49Z"
---

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：

```bash
./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 可以匯出匯入，方便跨裝置搬移。你先寫這種規格：

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

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

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

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

---

## 人先定邊界， agent 才開始動

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

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

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

```text
把這個 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」。至少記做了什麼、沒做什麼、現在卡在哪、下一步誰負責。例如：

```text
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 匯入匯出

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

第一步，人類下規格：

```text
目標：
讓 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 然後跑前面提過的那三行：

```bash
./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`