Coding agent 能改前端、開啟預覽站、登入、點完流程，最後附上一張成功畫面的截圖。看起來，E2E 測試終於被完整自動化了。

問題是，程式由 agent 修改，瀏覽器由 agent 操作，成功證明還是 agent 自己挑的。速度確實變快，但實作者與驗收者也合併成同一個信任來源。只要 acceptance criteria 寫得不夠清楚，它很可能驗證「自己做出來的東西能不能照自己的理解運作」，而不是使用者要的功能。

所以我不會把 browser tool 當成 coding agent 多了一雙眼睛。它比較像一個拿著登入狀態、可以碰外部系統、還能產生測試證據的 privileged test runner。接上去以前，先把它的權限與證據邊界畫清楚。

截圖是證據材料，不是驗收結論

GitHub Copilot 在 VS Code 的 browser tools 已能導覽頁面、點擊、輸入文字、讀取內容、檢查 console error、截圖並執行 scripted flow。這些能力很適合縮短「改 code、開頁面、發現問題、再修一次」的迴圈。

不過，畫面看起來正確，只能證明某個時間點的某個 viewport 出現了那個結果。它沒告訴你：

• agent 是否用了規格允許的測試帳號；
• 登入狀態是不是沿用上一次成功的 session；
• 中途是否碰到不該存取的網域；
• 表單送出後，有沒有真的寫入預期資料；
• console 沒報錯時，關鍵 assertion 是否確實執行過。

Screenshot、console log 和操作紀錄都值得保存，但它們只是 evidence bundle 的內容。最後能不能通過，應由 repository 裡既定的 assertion、CI gate 或 reviewer 判斷，不能由執行流程的 agent 自己改寫標準。

先把瀏覽器關進一個最小權限環境

假設 agent 剛改完結帳頁的折扣碼功能。比較安全的流程會先把 production 排除在外，再替這類任務準備一條固定路徑：

1. 部署到每次任務獨立的 preview environment。
2. 注入一個專用、低權限、可隨時撤銷的測試身分。
3. 只允許預覽站與必要的測試 API 網域。
4. 使用一次性 browser profile，任務結束就銷毀 cookie、localStorage 與 token。
5. 對寄信、付款、刪除資料或發布內容等副作用，改接測試替身或要求人工核准。

這不是特定產品的設定格式，但團隊可以先用一份版本控制的 policy 把意圖寫清楚：

browser_test_policy:
  environment: preview
  identity: checkout-e2e-agent
  allowed_domains:
    - pr-1842.preview.example.com
    - api.sandbox.example.com
  blocked_domains:
    - app.example.com
    - api.example.com
  approval_required:
    - send_email
    - charge_payment
    - delete_record
  session:
    reusable: false
    destroy_after_run: true

Browser session 必須有可檢查的生命週期，上面的 YAML 只是把這個意圖固定在 repo 裡。Google 介紹 Managed Agents 時，已把隔離執行環境、檔案與可恢復狀態放進 agent runtime。狀態能跨越一次 prompt 之後，清理時機就不能靠「關掉聊天視窗」猜測。Browser session 也該用同樣標準處理。

GitHub 的 browser tools 設計包含 private tabs、明確權限提示與企業網域控制，提供了必要的控制點。團隊仍要決定自己的 allowlist、測試身分與核准條件，不能把產品提供了控制點，誤認成權限政策已經完成。

驗收條件要留在 repo，不要只存在對話裡

最容易被忽略的風險，是 agent 同時改了實作與成功定義。

例如需求只寫「折扣碼套用後金額要正確」，agent 可能檢查總額文字有變化就宣告通過。規格裡也許還有幣別、稅額、無效折扣碼，以及重新整理後不得重複套用。這些條件如果只散落在聊天內容，下一次換工具、換 session 或壓縮 context，就可能少掉一半。

Google Conductor 把 spec.md 與 plan.md 留在 repository 的做法，值得借來當測試邊界。互動工具可以換，驗收意圖不能跟著消失。以結帳流程為例，repo 至少要留下：

Given 使用未持有優惠權限的測試帳號
When 在 preview 環境輸入過期折扣碼
Then API 回傳明確的失敗狀態
And 訂單總額、稅額與資料庫紀錄都不得變更
And 流程不得向 production domain 發出 request

Agent 可以依這份規格產生或執行測試，但若它修改了 assertion，同一個 PR 就必須把規格差異攤開來 review。不能一邊放寬判定，一邊拿新的綠燈證明功能完成。

Evidence bundle 應該支援重跑

Microsoft Foundry 將 runtime、工具存取、memory、observability、governance 與 evaluation 分開處理。套到 browser agent 上，測試產物也需要保留足以重查流程的內容。

我會要求每次執行至少留下這些資訊：

• 使用的 commit、preview URL、測試身分識別碼與 policy 版本；
• 有時間戳記的操作步驟，以及每一步對應的 acceptance criterion；
• 實際執行的 assertion 與結果，不只是一段自然語言摘要；
• 關鍵 console output，以及有明確 checkpoint 名稱的 screenshot；
• 被拒絕的網域或動作，連同核准結果一起保存。

證據的用途是讓 CI 或 reviewer 能重查，不是把 agent 的工作過程拍成一部紀錄片。每次點擊都截圖，只會製造一堆沒人看的檔案；反過來只留成功頁，又無法知道中間發生了什麼。應該由驗收條件決定哪些 checkpoint 值得保存。

失敗路徑也要刻意演練。讓 session 在流程中途失效、嘗試跨到 allowlist 之外的網域、拒絕一次有副作用的操作，再確認 agent 會停止，而不是繞過限制或用舊 cookie 繼續。這類測試比再跑一次 happy path 更容易抓到權限漏洞。

Browser agent 的價值，取決於它能不能被不信任地使用

讓 coding agent 操作瀏覽器，確實能把前端修改與 UI 驗證接成更短的迴圈。可是一旦瀏覽器裡有身分、狀態與外部副作用，它就不再只是測試工具，也是一個需要治理的執行面。

一條可信的流程應該讓 agent 負責操作，讓 repo 保存成功定義，讓 policy 限制它能碰的範圍，再由 CI 或人根據可重查的證據決定是否通過。這樣即使不相信 agent 的自評，團隊仍然能安全地使用它。

自動化到這一步才算完整：每一次 UI 操作都有權限限制，結果也能重現；團隊不必採信 agent 的一句「測完了」。

Source notes

• Browser tools for GitHub Copilot in VS Code are generally available
• What’s new in Microsoft Foundry — Build Edition
• Evolving Spec-Driven Development: Conductor Now Supports Antigravity
• Google I/O 2026 developer highlights