這篇文章整理 2026 年幾家公開分享做法的公司（Clay、Abnormal、Sentry）以及 GitHub、Sentry Seer 等工具的現況，回答三個問題：流程現在長什麼樣、誰分派誰修誰驗證、以及導入時最容易踩到的七個坑。
先說清楚：這是誰的現況
讀下去之前要先校準一件事：「agent 參與修 bug」至少有三個層次，三個層次的普及程度完全不同。把領先者的做法誤讀成業界普遍現狀，會讓自己以為落後很多，其實沒有。
| 層次 | 誰先碰票 | agent 做什麼 | 人做什麼 | 普及程度 |
| 第一層 工具輔助 | 人。工程師自己開 agent 來幫忙 | 協助重現、找根因、產生修正建議 | 讀票、分派、決定修法、review、驗證 | 已是常態 |
| 第二層 自動第一輪 | agent。票一進來就自動跑 | 去重、分類、重現、根因分析、開 PR | 審分析、審 PR、合併 | 工具成熟，採用仍是少數 |
| 第三層 自動關票 | agent。整條鏈自動走完 | 從分類到合併後驗證、自動關票 | 守兩道閘門，處理例外 | 少數 AI-native 公司 |
三個層次背後的數據：
- 第一層：JetBrains 2026 年 5–7 月對 15,000 多位專業開發者的調查：90% 每週至少用一次 AI coding agent，68% 每天用。
- 第二層：LinearB 分析 253 個組織、270 萬個 PR：即使是前 10% 的頂尖組織，自主 agent 開的 PR 也只佔 4.7%，30 天內合併率 79%（人寫的是 92%）；到前 60% 的組織，agent PR 合併率掉到 37%。
- 第三層：Clay 公開的數字是自動關掉 15% 的 bug，不是 80%。做得到的共通條件：產品可一鍵在隔離環境跑起來、測試覆蓋夠、歷史 bug 資料乾淨。
所以比較誠實的說法是：工具層面已經是常態，流程層面還不是。本文描述的流程是「領先者的現況、多數團隊的下一步」。台灣多數團隊大概落在第一層到第二層之間。
另一個值得放在心上的數字：amplifying.ai 抽樣 2026 年 7–8 月 268 個已合併的 agent PR（有一定規模的 repo），56% 沒有任何人類 reviewer 就合併了。這可以讀成「大家已經很信任」，也可以讀成「驗證瓶頸已經發生，只是還沒爆」。對 bug 修正這種高風險變更，第二種讀法比較可能，這也是本文第三節會一直回到「驗」的原因。
一、流程變成什麼樣了
過去的 bug 處理是一條「人接人」的鏈：PM 或 QA 讀票分派，工程師手動重現、找根因、寫修正，另一位工程師 review，最後 QA 或原報告者驗證關票。每一步都要等一個人有空。
現在的主流做法是讓 agent 先跑完第一輪，人只守兩道閘門。下圖是兩者的對照：
圖一：過去與現在的 bug 處理鏈。紅色是人，藍色是 agent，黃色是人守的閘門，綠色是確定性自動化。
1. 報告進來，agent 先做第一輪
舊流程是工程師先讀票、重現、找根因、起草修正，現在這一輪在工程師碰到票之前就先跑完了。Abnormal 的說法很直白：routine 的 bug 繞過工程部門，真正新型態的問題才得到更多人力關注。
2. 根因分析 → 提議修法 → 人審一次
Abnormal 的做法是在票上加一個標籤，agent 就會讀票、追根因、判斷要不要改 code、給出具體修法；審過之後再加第二個標籤，agent 才去實作並開 PR。注意這裡是兩道閘門，不是一次放行。
3. agent 自己重現、自己驗證修正
Clay 的 agent 每次會在預先設定好的環境裡把產品跑起來，端到端重現 bug，並驗證自己提的修正真的有效，然後把問題路由給擁有該功能面的團隊，由被指派的工程師驗證並合併 agent 產生的修改。他們公開的數字是：15 分鐘內跑完、關掉 15% 的 bug。
4. 工具端已經把整條鏈路產品化
Sentry 的 Seer Autofix 把流程切成 Triage、Summary、RCA、Solution、Create PR 幾步，「修」這一段可以交給 Seer、Cursor、Claude Code、Copilot 等 coding agent，而且每一步可以選不同的 agent。GitHub 的 Agentic Workflows 在 2026 年 2 月技術預覽、6 月公開預覽：issue 打上 bug 標籤就觸發 agent 調查，agent 寫修正、補測試、確認重現通過，合併後還有後續 workflow 驗證並關票。
二、誰分派、誰修、誰驗證
把上面幾家的做法疊起來，會得到一張共同的主流程圖。關鍵不是 agent 做了多少，而是人的兩道閘門分別守什麼：
圖二：AI 時代 bug 處理主流程。閘門 1 審「分析」，閘門 2 審「修正」；兩道閘門都是人，中間與尾端是 agent 和確定性自動化。
對應到角色，變化如下：
| 步驟 | 以前 | 現在 |
| 分派 | PM / QA / Lead 看票決定給誰 | agent 做分類、去重、判斷 owner；人只決定「給 agent 還是給人」 |
| 重現 | 開發者或 QA 手動 | agent 在隔離環境自動重現，附證據 |
| 修 | 被分派的工程師 | agent 開 PR，工程師是 reviewer 而不是作者 |
| 驗證 | QA 或原報告者 | agent 自驗 + 人審 PR + 合併後自動驗證 workflow |
三、七個要注意的地方
1. 不要讓 agent 驗自己的修正就算數
這是最大的坑。agent 說「我重現了、我修好了、測試過了」，那是它的主張，不是獨立證據。Clay 的設計有個值得學的地方：agent 可以充分運用 AI 的彈性做判斷，但實際採取動作的永遠是確定性的自動化。判斷是 AI 的，執行閘門是規則的。Sentry 自己的建議也很直白：把 Seer 寫的 PR 當成人寫的 PR 一樣對待，同樣的 review、同樣跑測試。
2. 分派的問題從「給誰」變成「這題適不適合交給 agent」
你需要一個明確的 fixability 判斷。Seer 不會對每個 issue 都自動開 PR，開之前會先評估這個問題的可修性與嚴重度。這條線要自己定義：
- 允許 agent 直接修：有明確 stack trace、影響範圍小、有測試覆蓋、單一服務內。
- 必須人先看：涉及資料遷移、安全、跨團隊、或根本是需求問題而不是 bug。
3. 「驗證」的定義要升級
以前驗證是「bug 不再出現」，現在至少要再加三件事：
- 修正有沒有附上會失敗的重現測試（先紅後綠）。
- 根因解釋跟修改的 code 是否對得上。
- 有沒有順手改了範圍外的東西。
Sentry 自己的經驗裡，被關掉而不是合併的 agent PR，有的是已有別的 PR 修了重複的問題，有的是工程師選擇做更完整的修正而不只是原 issue 的範圍。agent 很會做局部修補，但局部修補常常是症狀修補。
4. Bug 報告的品質變得更重要，不是更不重要
agent 的第一輪完全依賴票上的資訊。AI triage 的品質幾乎完全取決於你餵給它的歷史 bug 資料，而且上線前要先驗證 AI triage 的準確度。歷史資料裡如果標籤亂、duplicate 沒清、resolution 欄位不可信，agent 會把這些偏誤放大。
5. 權責不能跟著自動化一起消失
PR 是 agent 開的，merge 是人按的，出事算誰的？要明確：合併者就是 owner。Sentry 在做的一件事，就是讓 Seer 把 PR 指派給觸發它的那個使用者，目的是讓每個 agent PR 都有一個明確的人負責。
6. 度量要換
以前看 time-to-fix；現在修很快，真正該看的是：
- agent PR 的合併率 vs 關閉率。
- 合併後 7 天內的 regression 率。
- 人 review 一個 agent PR 平均花的時間。
- 被 agent 誤判為「可自動修」結果搞砸的比例。
Clay 的 15% 值得再看一次：是 15%，不是 80%。剩下的 85% 還是人的，只是人接手時已經有一份根因分析在手上。
7. 小心「驗證瓶頸」
當修正的產出速度變快十倍，review 和驗證的人力沒有跟著變，agent 開的 PR 就會堆在那裡等人看，或者更糟：被人草草看過就合併。生成端加速了，驗證端沒有，整個系統的瓶頸就移到驗證。
| 設計流程時該問的問題 與其問「怎麼讓 agent 修更多 bug」，不如問「我們每天有多少驗證容量，agent 的產出要怎麼限流，才不會淹掉它」。 |
四、導入前的檢查清單
如果你的團隊準備把 agent 放進 bug 流程，開工前先確認下面這幾件事：
- 現有 bug 流程有畫出來，每一步的停留時間、duplicate 比例、驗證退回率都有基準數字。
- 歷史 bug 資料清過：標籤一致、重複票合併、resolution 欄位可信。
- 寫下 fixability 規則：什麼樣的 bug 可以直接給 agent，什麼樣的必須人先看。
- 兩道閘門的 reviewer 是誰、SLA 多久，有明確定義。
- agent PR 必須附失敗→通過的重現測試，沒有就不進 review。
- 合併者 = owner 寫進團隊規範，agent PR 自動指派給觸發者。
- 度量換成合併率、regression 率、review 時間，而不是只看 time-to-fix。
- agent 產出有限流機制，不超過團隊每日的驗證容量。
- 先在一個低風險的專案或 repo 試跑，量過準確度再放大。
結語
AI 把修 bug 變便宜了，但沒有把「確認修好了」變便宜。流程設計的重點因此從排程人力轉向守住判斷：誰有資格說「這個 bug 修好了」。把這句話想清楚，agent 才是幫手；想不清楚，agent 只是讓錯誤合併得更快。
參考資料
- JetBrains Research — AI coding agent adoption 2026 https://blog.jetbrains.com/research/2026/08/ai-coding-agent-adoption-2026/
- LinearB — The AI engineering productivity gap: 2026 benchmarks https://linearb.io/resources/ai-engineering-productivity-gap
- amplifying.ai — State of coding agents (Aug–Oct 2026) https://edge.amplifying.ai/research/state-of-coding-agents
- Clay — How we run bug triage without a second of engineering time https://www.clay.com/blog/how-we-run-bug-triage
- Abnormal — AI Agents Are Absorbing the First Pass on Every Bug https://www.abnormal.ai/blog/ai-agents-are-absorbing-the-first-pass-on-every-bug
- Sentry — How we built an automated debugging workflow at Sentry https://blog.sentry.io/automated-debugging-workflow-sentry/
- Sentry Cookbook — Self-healing workflow with Seer https://sentry.io/cookbook/self-healing-workflow-seer/
- Sentry Docs — Seer https://docs.sentry.io/product/ai-in-sentry/seer
- Shake — Steps to automate bug triaging with AI https://www.shakebugs.com/blog/ai-bug-triaging-automation-steps/
- GitHub Changelog — GitHub Agentic Workflows is now in public preview (2026-06-11) https://github.blog/changelog/2026-06-11-github-agentic-workflows-is-now-in-public-preview
發佈留言