上一篇的 Ops Agent 再方便，也需要使用者主動提出需求 Agent 才會進一步處理，但是網站上有很多潛在的隱藏問題並不是那麼容易被使用者發現：某個品牌的購買連結失效了、上架品牌的主圖不見了、半夜該跑的資料整理工作其實沒有跑，或是新改的程式不小心讓搜尋按鈕按不下去。有部分的問題我們可以用 Sentry 來追蹤（例如：用戶點擊到失效的連結），但有些內容則沒辦法（例如：資料處理沒有跑、購買連結失效等）。為了「主動」找到這些潛在問題，每天半夜我會跑下列兩個 Agentic Workflow：

• Health Agent：檢查正式網站的資料，像是連結、品牌資料、排程和資料整理工作，確認原本應該成立的條件都還成立。
• E2E Testing Agent：在 staging（正式上線前的測試環境）上，用程式模擬使用者把網站走一遍，在新程式上線之前，先抓到被改壞的功能。

這一篇就來聊聊這兩個 Agent 怎麼運作、檢查完的結果怎麼處理，以及想自己做一套要從哪裡開始。

Health Agent：每天檢查正式網站的資料

之前談上線監控的那一篇，介紹過日誌、儀表板和告警這些方法，用來發現系統有沒有異常。這篇的 Health Agent 和 E2E Testing Agent，則是「主動」去大範圍檢查網站和資料庫的健康狀態，確認原本應該成立的條件都還成立，例如每個上架品牌的購買連結，都應該連到品牌自己的商店；探索頁的搜尋框，輸入關鍵字後要能送出查詢。這些條件不再成立的時候，只要沒有使用者剛好用到這個功能，系統通常不會留下任何錯誤紀錄，前面提到的監控也抓不到，因此需要這兩個 Agentic Workflow 主動去把問題找出來。

Health Agent 直接讀資料庫和外部服務，檢查的內容大致可以分成以下幾類：

• 連結是否有效：購買連結還能不能打開，有沒有被改成指向社群網站或第三方目錄。
• 品牌資料是否完整：上架的品牌有沒有缺主圖、介紹是不是太短、中英文內容有沒有放反。
• 排程是否準時：每天、每週該跑的工作，有沒有在預期的時間內跑過。
• 資料整理工作是否卡住：有沒有工作一直沒開始、跑到一半就沒有回應，或大部分都失敗。
• 外部服務是否正常：Slack、Linear 這些服務的金鑰還能不能用；送一筆測試用的錯誤給錯誤追蹤服務，確認真的收得到。

查出問題之後，Health Agent 會自己判斷下一步。以程式錯誤為例，它會先讀過錯誤內容，判斷嚴重程度、可能的原因，以及能不能直接修，再決定怎麼處理：

• 能直接修的問題：送出修復請求，交給 Claude Code 追原因、改程式。
• 需要人判斷的問題：開一張 ticket 留給我。

整段流程不需要我開口，我只要審核 PR、處理 ticket 就好。

E2E Testing Agent：上線之前，先用程式把網站走一遍

E2E Testing（End-to-End Testing，端對端測試）是軟體開發裡很常見的做法：先定好使用者會怎麼操作、操作完應該看到什麼，再用程式照著走一遍，確認網站的表現跟預期的一樣。Health Agent 看得到資料，卻看不到畫面；使用者卡在某個按鈕上的問題，要靠 E2E Testing Agent 來抓。它每天清晨會對 staging 跑一輪測試。

為什麼測的是 staging，而不是正式網站？主要有兩個原因：

• 在上線之前就抓到問題：新程式會先部署到 staging，測試通過、我確認過之後，才會更新到正式網站。功能在 staging 上壞掉，使用者根本不會看到。
• 測試不會弄亂正式資料：測試會登入、送出表單、寫入資料。staging 有自己獨立的資料庫，測試留下的資料不會混進正式網站，也不會算進流量統計。

我用的是 Playwright，一個常用的瀏覽器測試工具。Playwright 的最佳實務指引裡有兩個建議：

• 測使用者看得到的東西：用畫面上的文字、按鈕名稱和欄位標籤去找元素，不依賴 CSS class（替網頁元素套樣式用的名稱）這類內部細節，網站改版時，測試比較不會莫名其妙壞掉。
• 每個測試各自獨立：每個測試有自己的登入狀態和資料，不依賴上一個測試留下的結果，失敗時比較容易找出問題在哪裡。

E2E Testing 的每一個測試，驗證的都是一段真實的使用者流程，例如輸入關鍵字、按下搜尋、看到搜尋結果，看的是整段操作做完之後，結果對不對。某個按鈕、某個函式單獨運作正不正常，則是單元測試（unit test）的工作。這兩種測試要分開來寫：單元測試抓得到元件本身的錯誤，卻看不出元件之間有沒有接好；E2E Testing 看得出整段流程走不走得通，卻不容易指出是哪一個元件壞掉。

下面這段範例程式，測試的是一個搜尋流程：打開探索頁，在搜尋框輸入「送禮」，按下搜尋，再確認網址帶有查詢參數、畫面出現對應的結果標題。

import { test, expect } from "@playwright/test";

test("搜尋後，網址帶有查詢參數、畫面出現結果標題", async ({ page }) => {
  await page.goto("/discover"); // 打開探索頁
  await page.getByLabel("搜尋商品").fill("送禮"); // 用欄位標籤找到搜尋框，輸入「送禮」
  await page.getByRole("button", { name: "搜尋", exact: true }).click();
  await expect(page).toHaveURL(/q=/); // 網址帶有查詢參數
  await expect(
    page.getByRole("heading", { name: "符合「送禮」的商品" })
  ).toBeVisible(); // 畫面出現結果標題
});

每個測試跑完，會有三種結果：

• 通過：照著寫好的步驟走完，結果都符合預期。
• 失敗：某個步驟走不下去，或結果跟預期不同，重試之後還是失敗。
• 不穩定（flaky）：第一次失敗，重試之後才通過。

不穩定的測試最容易被忽略，因為重試之後就通過了。但它背後可能藏著兩種問題：

1. 測試本身寫得不夠穩，例如等待的時間抓得太死，或依賴上一個測試留下的資料。
2. 網站真的時好時壞，例如某個 API 偶爾回應太慢，真實的使用者也會遇到。

放著不管的話，我們就無法確定這個測試到底是不是真的通過；而且不穩定本身就是一個訊號，代表測試或網站有地方需要調整。所以我會在每天的 Slack 摘要裡，單獨列出不穩定測試的數量。

每天早上，我會收到哪些結果？

每天半夜這兩個 Agentic Workflow 跑完之後，要怎麼接回前面談過的 Human-in-the-loop，讓我來做最後判斷呢？我們目前將結果分成三條路：

• Slack 摘要：我開了一個 Slack 頻道專門追蹤這兩個 Agent 的執行，每天的結果會整理成摘要貼在頻道裡，早上打開 Slack 就能看到最新的健康狀態。
• Linear ticket：遇到需要我判斷的問題，會透過 Linear 的 API 自動開一張 ticket（Linear 是我用來管理待辦的工具），每天早上看一下 Linear，就知道今天有哪些問題要處理。
• 直接修復：修正方法明確的問題，例如套件的安全性更新、錯誤追蹤服務回報的程式錯誤，或是 E2E Testing Agent 發現的失敗測試，會透過上一篇的 Ops Agent 叫起一個 Claude Code Routine，查原因、改程式，最後開成一個 PR，早上由我審核、決定要不要合併。

為什麼不讓 Health Agent 和 E2E Testing Agent 直接叫 Claude Code，而要經過 Ops Agent？因為這樣一來，不管是我在 Slack 開口，還是這兩個 Agent 自己發現的問題，修正工作都從同一個入口出去，紀錄也都留在 Slack 的討論串裡，事後要追查比較方便。

想替自己的網站做一套，要從哪裡開始？

Health Agent：從資料應該滿足的條件開始

1. 先列出應該一直成立的條件：例如購買連結要能打開、每天的排程要準時跑完。從最怕壞掉、壞了又最不容易發現的地方開始。
2. 每個條件寫成一項檢查：直接查資料庫或外部服務，每一項只檢查一件事，壞掉的時候才知道是哪裡出了問題。
3. 需要判斷的地方才交給模型：例如判讀一筆程式錯誤嚴不嚴重、能不能直接修。其他的檢查用程式規則就夠了，每一輪的結果也比較穩定。
4. 同一個問題只通知一次：替每個問題記下一個固定的識別，開過 ticket 就不要重複開，不然很快就會被通知淹沒，最後乾脆不看了。

E2E Testing Agent：從最重要的使用者流程開始

1. 先挑最重要的幾段流程：例如打開首頁、搜尋商品。每個測試走完一段完整的流程，確認結果符合預期。
2. 測 staging，不測正式網站：跑之前先確認 staging 已經部署好這次要測的版本，不然很容易把「還沒部署好」誤判成「功能壞了」。
3. 報告讀不到，不能算通過：測試中途當掉、報告讀不到，或一個測試都沒跑，就要發警告，不能當成沒問題。
4. 不穩定的測試要追：在每天的摘要裡單獨列出數量，同一個測試反覆不穩定，就找時間查清楚。