我用 15 個 Claude Code Agent 跑了一條自動 QA Pipeline — 兩週 17 個 merged PR

前陣子我寫過一篇 〈你的 100% Coverage 是假的〉，介紹我做的 CLI 工具 test-audit — 專門抓那些「line coverage 綠綠的、但 branch 根本沒被驗證」的 function。那篇發完之後有讀者問：「你是不是有更完整的 QA 自動化？」

答案是有。test-audit 只是整條 pipeline 的其中一個節點。真正在公司 repo 上跑的是一套更完整的系統 — 15 個 Claude Code agent、spec-driven、每天兩個班次、自己開 Linear issue、自己發 PR。過去兩週 merge 了 17 個修 bug 的 PR、追蹤 53 個 bug、累積 9 條跨 session learned pattern。

這篇是這個系列的開篇，把整個系統先拉出來讓你看到全景。後面 5 篇會分別深挖 spec-driven、learned-patterns、launchd、Linear、以及兩週 retrospective。

Pipeline 一圖看懂

整條 pipeline 有 5 個階段、兩條分叉、一個跨 session 記憶：

collector ─┐
           ├─→ analyzer ─→ issue-filer ─┬─→ fixer ───→ reviewer ─→ reporter
spec ──────┘                            └─→ explorer ─→ reporter
                                                          ↑
               learned-patterns.json (持續累積，跨 session)┘

五個核心階段：

1. collector 跑 E2E + unit test，收 Playwright trace、coverage、screenshots
2. analyzer 把結果跟 spec 比對，把 divergence 分類成 code-bug / test-bug / coverage-gap / flaky / perf-regression / needs-spec-review
3. issue-filer 把 analyzer 的發現開到 Linear（帶 qa-bot label、指定 priority、附 trace 連結）
4. fixer（修已知 bug）或 explorer（產新 test 覆蓋 spec gap）領 issue，改 code / 改 test / 發 PR
5. reporter 寫當班摘要、更新 progress.md 跟 learned-patterns

每天 08:00 跑 AM shift、00:00 跑 night shift。典型 shift 約 37 分鐘（median），最短 19 分鐘、最長實測 66 分鐘。Lock file 的 buffer 設到 4 小時（MAX_LOCK_AGE=14400），是留給極端 collector hang 的 paranoid 天花板，#4 會展開。

15 個 agent 各自在幹嘛

看到「15 個 agent」第一個反應通常是「太多了吧」。實際上分成三組，每組職責很清楚：

QA 核心（9 個）— 自動 pipeline 的主體

Agent	角色
qa-planner	讀 spec / source / test，產出 test plan（整條 pipeline 的 SSOT）
qa-collector	跑 E2E + unit，收集 trace、coverage、screenshots
qa-analyzer	比對 spec vs 實際行為，分類 divergence
qa-explorer	找 spec 有但 test 沒覆蓋的區域，產出新 test
qa-issue-filer	把 analyzer 發現的 divergence 開到 Linear
qa-fixer	修 code-bug / test-bug / coverage-gap，發 PR
qa-reviewer	審 fixer 開的 PR — 關鍵：跟 fixer 分離以避開 self-validation bias
qa-reporter	每班寫摘要、更新 learned-patterns 的 meta
qa-weekly	週報：過去 7 天成果、類別分布、pattern 演化

工程輔助（4 個）— 不屬於自動 pipeline，但共用 spec 語境

code-reviewer / e2e-runner / frontend-engineer / ui-designer

守門員（2 個）— 跨 agent 被呼叫

security-reviewer（fixer 動到敏感路徑時被呼叫）/ tdd-guide（新 feature 沒 test 就擋）

為什麼要切這麼細？因為 LLM 有 self-validation bias — 同一個 agent 做 + review 時傾向覺得自己做對了。把 fixer 跟 reviewer 切開、讓 reviewer 只看 diff + spec + test（完全看不到 fixer 的 thought trace），等於給系統一個二次人類 reviewer 的效果。這個架構決策對 false-positive rate 的改善超過我做過的任何 prompt tuning。

兩週真實數字

這是整篇文章最有重量的部分。資料來自 pipeline 的 shift logs、.issues-state.json、.learned-patterns.json、以及 git log：

指標	數字
總 shift 次數	16
成功完成的 shift	15（成功率 93.8%）
典型 shift 時長（median）	37 分鐘
Merged qa-bot PRs	17
追蹤到的 bug 數（Linear issue，排除 meta 記錄）	53
已關閉	46（77%）
仍 open	13
有掛 fix PR 的 issue	40
平均 turnaround（issue 開到 close）	2.9 天
中位數 turnaround	2 天
累積 learned patterns	9 條
升級成 .claude/skills 的 pattern	4 條
Pattern 自動被套用次數	22

一個有意思的比例：17 個 PR 關掉了 40 張 issue — 因為 fixer 常常一個 PR 同時解多個 sibling bug（這是 learned-patterns 帶來的放大效應，下一篇 #3 會講）。

Bug 類別分布

53 個真實 bug 按類別：

類別	數量	佔比
coverage-gap（spec 有、test 沒覆蓋）	27	51%
code-bug（source 不符 spec）	12	23%
test-bug（test 不符 spec）	6	11%
needs-spec-review（spec 本身不清楚）	5	9%
flaky（行為對但不穩）	3	6%

按模組：auth 佔一半（25）、core 16、settings 5、dashboard 4、stores 3。Auth 比例高不是巧合 — 驗證流程是整個 SPA 最容易有 edge case 的地方（401 / 429 / 過期 token / 多分頁 session），也是最值得讓 agent 去把 coverage gap 全部補掉的領域。

一個早期觀察：QA agent 最擅長抓的是「人類 engineer 知道該處理但懶得處理」那類 bug — 401 沒處理、empty state 沒寫、i18n 漏字、FastAPI 錯誤訊息格式不一致、按鈕 disabled state 缺失。每個都不痛、加起來卻讓產品像還沒 polish 的 demo。這個觀察後面 #6 retrospective 會展開。

為什麼我做這個 — 不是為了 demo

坦白講一下動機。我一個人維護公司產品的 frontend（git log 顯示我占 96% 的 commits）。QA 永遠是那個「應該做但永遠排不上」的事。

有兩條路：

1. 再找一個人來幫我做 QA
2. 讓 agent 做

我選 2 不是因為我相信 agent 能完全取代 QA engineer，而是因為 agent 能做完人類永遠沒耐心做的那層 — 去掃所有 hook、所有 route、所有 spec requirement，逐一比對。

這層勞動以前沒人做得完。現在能做了。而且能做成持續跑的 pipeline、不是一次性 audit。

為什麼這系列不寫「Claude Agent SDK 教學」

2026 年已經不缺 agent 框架入門文。打開 Twitter / Dev.to / Medium，每天都有新的 Claude SDK hello world / LangGraph 5 分鐘上手。

這個系列的每一篇會帶 receipts：實際 prompt、實際 bash 腳本、實際 git log、實際 Linear API call、實際的失敗案例。抄得走、能自己用的，不是看完點讚然後繼續寫自己的 CRUD 那種。

接下來的 5 篇

• #2 Test-driven 是錯的 — 為什麼我的 QA Agent 看 spec 不看 test — 讓 LLM 修 test 只會讓錯的 test 變得更漂亮。spec 才是 SSOT。
• #3 讓 Agent 教 Agent：跨 Session 自我進化 — 9 條 pattern、22 次自動 apply 背後的 feedback loop。這篇最硬核。
• #4 用 launchd 跑 Autonomous Agent — 不用 cloud、不用 Kubernetes。一台 Mac、兩個班、17 個 PR。
• #5 把 Linear 當成 AI Agent 的 Work Queue — 不要為 agent 造新 queue，用人類已經在用的那個。
• #6 兩週 retrospective — 真實數字、踩到的坑、重來我會怎麼做 — post-mortem，不是 case study。

---

如果你正在設計類似的 pipeline、或者在做 agent 系統的工程決策卡住，Twitter（@waiting7777）或 GitHub 找我。

下一篇會開始進到實作細節。#2 講為什麼我整條 pipeline 的 SSOT 是 spec，而不是 test。