發布日期：2026 年 6 月 22 日
數位解決方案代理商 P2ER 使用代理程式專用的 Chrome 開發人員工具，確保只有經過驗證且可正常運作的軟體會交由專員進行最終審查。他們將工作流程轉變為以代理為核心的基礎架構，讓 AI 代理執行實證 UI 驗證，部署頻率從每週一次提高到每天多次。
挑戰：在現有應用程式中擴大規模，提升品質
P2ER 為全球品牌提供頂級數位體驗，包括汽車製造商、手錶品牌和飯店公司。與許多公司一樣，他們的主要挑戰是使用複雜的現有應用程式。這個團隊採用代理程式輔助程式碼編寫時，面臨了三項重大障礙：
- 脆弱的 UI 測試。標準測試套件難以處理動態資料，例如 P2ER 某些專案中波動的飯店價格或季節性產品。模擬資料通常會隱藏整合瑕疵，但人工測試人員會立即發現。
- 代理程式可靠性問題。如果沒有明確指令，AI 代理程式有時會聲稱已完成工作，但實際上並未驗證。
- 失去脈絡。廣泛的工作和模型逾時導致代理程式失去工作階段目標的追蹤能力。這讓開發人員難以追蹤及繼續代理程式已開始的工作。
解決方案：建構工藝基礎架構
P2ER 打造的基礎架構將 AI 視為「陪練夥伴」，可處理開發過程中重複性的工作。團隊可以專注於架構和解決問題的創意，藉此擴展工藝。
使用開發人員工具，對代理的 MCP 伺服器強制執行實證驗證
為確保可靠性，P2ER 制定了強制性實證驗證規則。這項工程授權已編碼至專案的 AGENTS.md 檔案，內容如下：
All claims regarding service availability and component rendering
MUST be empirically verified (log output, dev compiler, browser/devtools inspection)
before asserting to the user.
團隊並未直接採信客服專員的說法，而是使用 Chrome 開發人員工具，為客服專員提供安全環境，讓他們以視覺化方式導覽應用程式並進行互動。
這些「測試代理程式」會執行多項標準靜態測試遺漏的重要工作：
- 動態資料測試：即使在預先發布環境中，代理程式也會根據實際波動的資料 (例如不同季節的飯店價格變化) 進行測試，體驗應用程式的方式與使用者完全相同。這項功能是由代理的互動工具 (例如
new_page、navigate_page、fill、click和hover) 的開發人員工具啟用，並在github-issue-test技能中標示，讓代理能動態驗證及模擬真實的使用者點擊路徑。 - 視覺稽核：代理程式會找出 Figma 版面配置與實際實作之間的視覺差異。代理程式可使用開發人員工具中的
take_screenshot工具，figma-validate擷取 Storybook 即時算繪的高解析度螢幕截圖，並與 Figma 匯出內容進行並排比較。 - 可用性檢查：代理程式會找出自動指令碼經常忽略的缺漏翻譯或可用性錯誤。透過
take_snapshot和take_screenshot擷取無障礙樹狀結構並查看視覺快照後，代理程式會直接與無障礙樹狀結構互動，並主動掃描 UI 異常狀況 (例如 MISSING_MESSAGE 字串)，這也是自動驗證工作流程中的明確指示。
分解並保留子工作
為避免工作階段逾時和失去脈絡，P2ER 會透過子代理嚴格劃分工作。接著，他們會指示代理充當協調員，如下所示：
Rather than executing everything in the main thread, you must decompose large
or complex objectives into modular subtasks that can be delegated
to specialized subagents.
為確保產品負責人在這個過程中掌握最新資訊，團隊整合了代理程式的自訂技能，以便在 GitHub 問題中追蹤工作。這可確保每個子代理程式工作及其結果都會透過 GitHub API 持續記錄為子問題，建立清楚的稽核追蹤記錄和持續性環境，供其他開發人員接手。
隔離環境以平行執行
為擴展開發程序，讓多個代理程式平行執行程式碼，P2ER 規定代理程式必須為每個工作提供獨立環境。這樣可避免在 UI 驗證期間發生狀態衝突和網路問題。
這項隔離措施的技術設定包括：
- 獨立的 Git 工作樹：為避免多個代理程式並行運作時發生檔案衝突和工作區污染，系統會在獨立的 Git 工作樹中執行工作。每個代理程式都會取得專屬的檔案系統空間，環境變數會複製到該空間，依附元件則會以符號連結的形式存在，確保檔案變更不會互相覆寫。
- 專屬環境：每個代理程式和工作都會在專屬的獨立通訊埠上執行 Next.js 開發伺服器。根據專案規則，伺服器會以
npx next dev -p <custom_port> --turbopack動態啟動，確保平行執行作業，不會發生網路衝突。 - 資料庫副本：為避免平行測試期間發生資料衝突，P2ER 會在代理程式啟動時，以程式輔助方式將主要資料庫複製到工作專屬的結構定義。專員完成驗證並核准工作後，自動清除程序就會捨棄隔離的資料庫。這個生命週期可確保每個代理程式都在乾淨的工作區中運作，且不會留下任何懸而未決的資料。
- 目標測試：透過 Chrome 開發人員工具進行所有代理程式的瀏覽器測試時，必須以分配給該特定代理程式執行個體的確切自訂通訊埠為目標。測試授權禁止硬式編碼預設通訊埠，因此需要
http://localhost:<custom_port>等測試目標網址。
影響：開發速度提升 10 倍，同時維持品質
改用代理式編碼並搭配高信任度防護措施後，P2ER 的輸出內容品質大幅提升。這些變更原本是為了確保代理程式穩定運作，但同時也對整個開發生命週期有所助益：
- 工作週期加快 10 倍：現在大多數問題都能在一天內解決，相較於先前的平均 1 到 3 天，速度快上許多。部署頻率從每週一次躍升至每天多次。
- 品質確保團隊的策略重點：由於代理程式現在會找出基本迴歸和「唾手可得」的錯誤，因此真人測試團隊可以專注於更深入、複雜的測試情境。
- 為利害關係人提供穩健的實作：現在的實作更具彈性，因為測試已超出程式設計師的標準「順利路徑」。
- 更清楚的溝通和追蹤：強制執行「人為問題到實作子問題」規則後，利害關係人會收到清楚的指示，瞭解進行了哪些邏輯改善，而不必閱讀充斥技術實作細節的工單，以及如何測試。
舉例來說，P2ER 採用這種做法後，只花了六個月就建構出新平台，如果使用既有方法，可能要花上好幾年。人類仍是最後的品質把關者，負責審查代理程式已驗證的提取要求。
團隊適用的技術深入分析
在建構這項工作流程時，P2ER 發現幾項策略有助於他們從實驗階段，過渡到成熟的代理程式輔助開發模型。
這些策略可協助其他團隊改善自己的代理實作項目：
透過指令碼插入和 CLI 批次處理，盡可能減少權杖用量
如果代理程式只依賴逐步導覽 (例如擷取快照、尋找 ID、填寫輸入內容及等待)，MCP 伺服器在長時間的開發工作階段中可能會耗用大量權杖。為盡量減少這類負擔，P2ER 採用雙管齊下的做法：
- 內嵌指令碼注入：如要進行特定互動 (例如透過複雜的 React 表單驗證)，服務專員會使用
evaluate_script工具，直接將 Vanilla JavaScript 注入瀏覽器。這會略過內建的設定器覆寫，並一次執行多個動作，節省許多對話輪次。 - CLI 指令碼批次處理：當代理程式遇到「障礙」或瀏覽器流程過長且重複時，就會切換為 CLI 批次處理後備機制。P2ER 會提示 Chrome 開發人員工具 CLI 持續執行並批次處理瀏覽器動作，因此您不必花費權杖重複使用個別 MCP 工具，也不必從頭編寫自訂自動化指令碼。這項功能可讓代理程式一次以程式輔助方式執行整個多步驟流程，大幅減少模型與工具之間不斷通訊的負擔。
使用追蹤記錄分析功能自動追蹤效能
P2ER 團隊並非單純依賴人類感知，而是建立 review-performance 技能，讓服務專員使用開發人員工具執行自動 Lighthouse 稽核和效能追蹤。
代理程式會使用 performance_start_trace 和 performance_analyze_insight 工具擷取及調查 Core Web Vitals (LCP、INP、CLS)，並找出主要執行緒瓶頸或版面配置變化。為完善品質閘道，代理程式可以執行完整的 lighthouse_audit，專門防範無障礙 (a11y)、SEO 和一般網頁最佳做法的迴歸，確保只提交高品質的程式碼以供提取要求。
使用代理專用 Chrome 開發人員工具強化驗證
除了自訂技能外，P2ER 還會使用代理程式 MCP 伺服器的 Chrome 開發人員工具核心功能，執行功能驗證。包括使用伺服器模擬不同裝置，並測試回應式設計，確保使用者介面適用於不同螢幕大小和裝置。
代理程式可使用 MCP 伺服器瀏覽應用程式，找出版面配置與實際實作之間的視覺差異，並找出靜態測試經常忽略的錯誤。
資源
如要進一步瞭解 P2ER 的用途，請探索相關 GitHub 存放區中提及的所有技能。
如要自行開始使用，並進一步瞭解如何透過代理程式的開發人員工具實作類似的工作流程，請參閱下列資源：