以下是翻譯後的繁體中文版本：
我們從在 Devin 的虛擬機器中打造端到端測試能力學到的事。
三個月前，我加入 Cognition 協助打造軟體工程的未來。Devin 自推出成為第一位 AI 軟體工程師以來，已經走了很長一段路，而親眼看到團隊每天實際使用 Devin，著實讓我驚嘆不已。
其中一個亮點是 Devin 如何利用其電腦在雲端自主驗證工作。從驗證我們的 Slack 整合到測試複雜的 Windsurf 功能，團隊總是有一群 Devin 處於測試模式。在這篇文章中，我將分享為什麼我們如此專注於端到端的雲端 Agent 驗證，以及我們如何著手建立這項能力。
非同步軟體工程的轉變
在 Cognition，我們最近達到了一個新的里程碑。首次，透過事件、自動化、排程和其他 Devin 觸發的非同步 Devin 數量超越了同步觸發。我們預期隨著我們最近推出的 Auto-Triage，這個趨勢會持續加速。
隨著我們過渡到這個非同步的世界，開發者能夠回來看到已經驗證且準備好合併的結果，變得至關重要。今年稍早，我們推出了 Devin Review，一個能擴展人類對複雜程式碼差異理解能力的程式碼審查工具。它不僅標記錯誤——Devin 會關閉迴圈，修復每個發現直到差異清除為止。但僅有乾淨的審查往往是不夠的——工程師希望看到變更經過端到端測試，就像他們自己測試一樣。
當 Devin 在你甚至還沒看到錯誤頻道中的訊息之前，就提出一個修復用戶投訴的 PR，這感覺很棒。而讓它更魔幻的是，當這個 PR 附帶了修復確實有效的證明。而這個魔幻可能很快就會變成必需品——隨著越來越多的 PR 來自主動式 Agent 的崛起，未經驗證的變更很快就會變得無法管理。
從一開始
自從 Devin 推出以來，它一直能夠在雲端虛擬機器上展示其工作成果。大約 6 個月前，我們擴展了 Devin 的電腦使用能力。在實際應用中，這意味著我們在 Devin 的工具箱中新增了工具來擷取螢幕截圖、移動滑鼠、點擊、拖曳、打字、按鍵、滾動、等待、縮放，以及開始/停止錄影。電腦使用功能已經存在一段時間，但我們覺得來自前沿實驗室的最新一批模型已經開始真正擅長使用這些工具。
電腦使用為 Devin 解鎖了一些有趣的新能力，例如建構並玩一款桌面遊戲，或使用其瀏覽器在 Amazon 上訂購產品。但我們注意到的真正突破是 Devin 測試自己工作的能力。Devin 會啟動應用程式、點擊操作、並確認其變更確實有效，就像工程師會做的一樣。一切都在雲端執行，並且可以平行擴展。當我看到工程師同時執行 10 到 20 個 Devin，每個都有各自的開發伺服器，處理變更時——這實在讓我印象深刻，因為在單一筆電上根本無法做到。自動化雲端測試開始為我們節省了大量時間，因為我們不再需要在本機執行和驗證程式碼。
老實說，要達到這個目標並非一帆風順。我們一路上遇到了許多失敗模式，每一種都讓我們學到了如何讓這個系統更可靠。
提升可靠性
在早期版本中，Devin 在測試過程中很容易偏離方向。它以各種方式發生：過度測試產品的無關部分、在到達功能之前迷失在設定中，或者乾脆錯過了 PR 原本要改變的核心行為。
為了解決這個問題，當 Devin 進入測試模式時，我們讓它先寫出一個測試計畫，詳細說明要測試的明確目標。這個計畫必須基於原始碼，而不是假設。如果沒有程式碼作為基礎，我們發現模型傾向於假設它們可以走進應用程式中不存在的路徑。此外，測試計畫極大地增加了 Devin 能夠成功測試的變更複雜度。我們一些最雄心勃勃的請求包括需要執行多個服務、配置特定管理員設定、並啟用正確旗標的功能，然後才能觸及該行為。當提前閱讀程式碼時，Devin 更有可能正確設定環境，而不是在測試中途才發現缺少某些東西。測試計畫作為一種預先對齊的形式，讓 Devin 在積極測試時較不容易偏離。
當 Devin 按照計畫進行時，它會將自己的註解添加到時間軸中。這些包括設定筆記、每個命名測試的開始，以及標記為通過、失敗或未測試的斷言。我們發現，如果 Devin 在執行動作之前先註解其預期的行為，它會比較不會對其發現結果說謊——很像測試驅動開發，如果你事先承諾預期結果，就很難將意外的結果合理化為通過。
測試流程的某些部分幾乎在每次執行中都會重複。登入是經典例子：透過電腦使用驅動登入表單通常意味著輸入電子郵件、完成 SSO、點擊通過重定向，並在每次頁面載入時等待，一個截圖接著一個截圖。這在時間和 token 上可能成本很高。為了提高這些動作的可靠性和成本，Devin 將工作提取為一個確定性指令碼，該指令碼存在於我們儲存庫中的一個測試技能中。這樣，Devin 可以在幾秒鐘內執行指令碼並獲得一個已驗證的瀏覽器階段，然後跳入測試的核心部分。這些指令碼的確定性特性大幅降低了波動性。我們還更新了 Devin，讓它自己也能關閉這個迴圈。當它用困難的方式弄清楚一個設定步驟時，Devin 可以建議將該知識作為測試技能保存在儲存庫中，並以一次點擊 PR 的形式將修復提回給用戶。
我們也在實驗將測試階段路由到不同的模型。由於測試依賴於與編寫程式碼不同的優勢，例如閱讀截圖、追蹤 UI 狀態、以及決定下一步瀏覽器動作，有些模型在這方面比你通常選擇用來編輯程式碼的模型要好得多。
今天如何在 Devin 中使用自主測試
Devin 目前透過兩種方式進入測試模式：明確要求測試某個變更，或者，在 Devin 建立 PR 後，它會視情況提供測試該變更的選項。從那裡，它會建立測試計畫並開始工作。
通常當你第一次開始使用 Devin 的測試能力時，它會需要你的協助。一個很好的例子是，如果它需要機密資訊才能在本機執行你的應用程式。為了讓這個過程更順暢，Devin 能夠在工作階段中向你詢問任何憑證或其他可能遺失的資訊。對於更困難的情況，你可以接管 Devin 的電腦並輸入像 OTP 碼這類的東西。好消息是，一旦 Devin 完成你的儲存庫設定，它就能夠以 YAML 藍圖的形式保存一個宣告式配置，該配置會為未來每個階段產生一個快照來啟動。
你會得到什麼回饋
當 Devin 完成測試時，它不僅告訴你應用程式是否運作。原始螢幕錄影是有用的，但我們覺得單獨看還不夠——你需要了解你在看什麼、為什麼 Devin 採取每個動作、以及測試的哪些部分通過或失敗。
為了快速審查，Devin 會回傳一份測試報告，其中包含從執行過程中關鍵時刻擷取的標記截圖，讓你可以快速看到 Devin 測試了什麼以及應用程式在過程中的樣子。
如果你想要更深入的審查，Devin 還會產生一個包含豐富播放器 UI 的測試影片，影片有章節讓你可以跳轉到測試的各個部分、瀏覽整個執行過程，並以時間軸列表檢視通過或失敗的斷言。在後處理中，動作之間的閒置時間會被壓縮，而動作周圍的時刻則以正常速度播放。這樣做使得一個長時間的執行被濃縮成一個你真的能觀看的錄影。這些成品可在我們的網頁介面中取得，如果 Devin 是從 Slack 啟動的，也會分發到 Slack。
棘手邊界
電腦使用仍然有棘手邊界。一個例子是時機——如果 Devin 正在測試一個 toast 通知，截圖取得太早或太晚可能會完全錯過 toast，而模型可能會對預期行為是否真的發生感到困惑。
另一個失敗模式是作弊。放任不管，模型有時可能會過度依賴在瀏覽器中執行 JavaScript 以程式方式觸發狀態，而不是透過 UI 點擊。這對測試功能可能有用，但用戶通常會希望看到 Devin 像真實用戶那樣操作應用程式。
我們正在積極透過改進的評測、更嚴格的 harness 護欄、以及每一代在電腦使用上更好的新模型來處理這些問題。
非同步開發的未來是經過驗證的
在過去幾個月中，Devin 上每天核准的測試執行次數翻了一倍以上。這個增長反映了簡單的事實：非同步 Agent 只有在開發者能夠信任它們帶回來的結果時才有用。而這種信任通常不能僅來自程式碼：對於許多變更，你會想知道應用程式確實被執行了、重要的流程被測試了、而且結果是以一種你可以輕鬆檢查的方式被捕捉下來的。
這就是 Devin 中自主測試的設計目的。Devin 規劃測試、操作應用程式、記錄並註解發生的事情，最後回傳讓結果可審查的成品。還有很多可以改進的地方，但我們相信這是未來正確的方向：Agent 不僅非同步完成工作，而且會帶著證明回來。
我們不斷驚訝於 Devin 透過測試自己的工作為我們節省了多少時間，並且覺得許多客戶仍然沒有充分利用 Devin 的自動化測試功能。為了支援實驗，我們目前對測試模式收費為正常使用成本的 1/5。
請在 devin.ai 或 windsurf.com 試用我們的工作。如果你對解決這類問題感興趣，請聯繫 ido [at] cognition.ai
