教你的代理證明它做完了——WorkOS 的 Nick Nisi 與 Zack Proser

WorkOS 的工程經理 Nick Nisi 主張，代理（agent）唯有能自行驗證成果，才值得信任；而解法不是寫更好的提示詞，而是打造一個確定性、針對特定應用打造的驗證 CLI，讓它回傳「收據」而非口頭宣稱。他與 WorkOS 應用 AI 團隊工程師 Zack Proser 花了整小時的大部分時間談這個驗證迴圈：該檢查什麼、怎麼建、以及它如何改變團隊出貨的方式。節目以引發這套做法的真實事件開場——一個代理在九秒內刪掉生產資料庫——但這故事只是引子；本集主體是一場實作工作坊，圍繞著一款叫 Midnight Snack 的示範應用，那是一套「破壞者與偵探」的抓蟲遊戲，再加上兩位主持人各自的工具實驗。

兩位講者都是實戰派而非評論者：Nisi 說他自 2025 年 7 月 30 日、也就是從 Laracon 回來那天起就沒再寫過程式；Proser 則說他平均一天開 18 到 30 個終端分頁跑代理。他們的論點是：如今規模化的瓶頸已從程式碼審查轉移到驗證，而每月能出數百個 PR 的團隊，正是那些替代理打造了單一指令、讓它能自行證明改動有效的團隊。讀者讀完應該帶走三樣東西：這個指令的具體架構、清楚理解 LLM 擔任評審（LLM-as-judge）適用與失靈的界線，以及為何要把每一次執行都儲存下來，當作未來自我改進 harness 的訓練資料。

一個確定性指令，勝過一整段指示

核心建議是：把用散文寫的驗證提示（「記得重新載入，確認資料有儲存」）換成一個由真實瀏覽器自動化支撐的 CLI 指令。Nisi 的論點是，提示詞留有詮釋空間，還會隨應用變動而走鐘；指令碼則每次都跑同一套檢查，並把結構化輸出餵回代理。Proser 補上一致性論點：LLM 本身不具確定性，30 個代理拿到同一段提示會各自分歧；反觀一個綁死實際 bash 與 Playwright 呼叫的指令，可重現性高得多。

兩位主持人引用 Lauren Tan——Nisi 稱她是「X 上很有名的那顆馬鈴薯」——那句定調名言：「如果代理無法驗證自己的成果，其他一切都不重要。」Proser 說，那些每月做到數千個 PR 的實務工作者（Tan 也在其中）都先集中火力解決這件事，之後才釋放出速度。Nisi 版的說法是「狀態來自紀錄，不是模型的吹噓」——拿出收據，別只會宣稱。

工作坊用的工具 Snack 刻意不做成可重複使用的產品，而是針對你手上實際應用的範本：

| 指令 | 作用 |
|---|---|
| snack up / down | 啟動與停止應用及瀏覽器工作階段 |
| snack doctor | 檢查 Node、Chromium、工作階段狀態、建置健康度 |
| snack join <email> | 操作候補名單表單 |
| snack storage | 讀取本機儲存／持久化狀態 |
| snack snapshot | 將頁面狀態輸出為 JSON |
| snack screenshot | 擷取渲染後的頁面 |
| snack reload | 重新載入並再次檢查狀態 |
| snack prove | 執行確定性的 Playwright 斷言 |
| snack judge | 把證據送給系統一模型做較寬鬆的檢查 |

現場示範就是這套論點的縮影。Nisi 輸入一組 email，看到成功訊息，只測 UI 的測試會過關——但重新載入頁面後什麼都沒儲存。「我們只檢查了 UI……另一半根本沒驗，」他說。依序跑 snack doctor、snack join ada@example.test、snack storage，結果回傳「storage is empty」。Proser 的重點是：「這一刻你的代理才意識到我還沒做完，而且我不會把這件工作丟在地上不管。」

截圖要有說服力，前提是抵達路徑是真的

Nisi 最尖銳的提醒是「截圖成功不等於證明」。代理可以產出一張顯示預期狀態的截圖，但走的是 UI 上根本不可能的路徑，或在過程中在別處造成副作用。截圖必須是一趟從乾淨狀態出發、走完真實使用者旅程的執行終點。

這就是為什麼 prove 指令寫成一整套 Playwright 流程，而不是單純的狀態斷言：清空候補名單、填入 email 欄位、點選加入按鈕、斷言狀態元素顯示「waitlisted」、再斷言該 email 出現在 inner text 中。任何寫過 Playwright 或 React Testing Library 端到端測試的人都能寫出這段，代理接著就能把它當工具執行、自行回報，而且——關鍵在於——日後頁面變動時再跑一次當回歸檢查。

Proser 把回報框架成「失敗驅動後續工作」。如果某個迴圈在你開會或開始下一件事時失敗，代理會自己再試一次並重新驗證。把這件事乘上每一條工作線，差別就是：一天結束時回來看到的是完成的 PR，還是一整排需要你逐步催促的待辦。

好的錯誤訊息，現在是代理的燃料

Nisi 問全場誰會寫好的錯誤訊息，幾乎沒人舉手。他的回應是：這種訊息比以往任何時候都重要，因為代理極擅長讀懂詳細的失敗原因並據此修復。一個說清楚為何失敗、系統如何走到這一步的錯誤，能讓代理在無人介入下自我修復。

同樣的邏輯適用於把模型看不見的狀態攤出來。Nisi 提到 AMP 團隊一篇關於畫布遊戲的文章——一顆球在圓圈內彈跳，圓圈上有個能讓它逃出的缺口——而模型完全看不到畫布。只要每一幀印出球的座標，bug 就現形了：如果球每輪移動超過一個畫素，就代表有問題。「只要你能把這攤給模型看，它就能幫你除錯，」他說；否則模型根本沒有眼睛。

約束目的地，而非路徑

兩位主持人都反對過度規定。Nisi 說，如果你告訴代理「你得先到這裡、再到這裡、再到這裡」，它就不會偏離——但你其實希望它偏離得夠多，才能抓到邊界情況，或問出一個能解鎖新思路的問題。Proser 的說法是：約束可以等於自由——給代理地圖和「完成」的定義，讓它自己找路。Nisi 把這套做法可行的功勞歸給當前的前沿模型——他點名 Fable、Astra、Sol 6.1 和 Opus 55——認為是這些模型直到最近才讓這件事成真。

他們建議的迴圈，是把 TDD 式的紅—綠—重構套用到驗證本身：驗證、重現、修復，然後拿出修復的證明。證明和補丁一樣重要，因為那才是讓人類得以抽身的關鍵。

LLM 評審能抓到脆弱斷言漏掉的東西

當應用的文案改了——確認訊息從「waitlisted」變成「you're in, your seat is confirmed」——寫得死緊的文字斷言即使功能正常也會失敗。對著那個狀態跑 snack judge 也會失敗，因為模型看不到相符之處。解法是系統一模型：一種快速、便宜的檢查，判斷「這大致上是對的結果嗎」，而不是逐字比對字串。

Proser 把這套術語紮根於心理學：系統一是你不假思索做出的閃避；系統二是訂 Airbnb 前反覆斟酌三天。套用到模型上，他舉 Gemini 以及兩天後 Cloudflare 推出的更快跟進方案為例，說明快速檢查這一層正迅速成熟。Nisi 的比喻是房裡的黃燈——你瞬間就知道它是黃的（系統一）；要解釋背後的物理原理才需要深思（系統二）。

Nisi 對評審的提醒是：它只提供方向，不具權威性。他用它確認自己走在正確方向上，然後在它外面包上單元測試，確保行為不會隨程式碼變動而走鐘。

破壞者遊戲揭示驗證真正斷在哪裡

工作坊的練習是讓 Snack 隨機注入一個 bug（pnpm snack up --bug random），參加者扮演偵探：只用 Snack 找出 bug、說出它是什麼、並提出證明。現場執行並不完美——Nisi 的輸出出了狀況，他自嘲說自己那套刻意設計的驗證範例也需要驗證測試——但真正的重點是評分標準。結果分成幾類：

• 附證據指出 bug，且正確
• 宣稱功能正常，但其實沒有
• 宣稱功能正常，且確實正常
• 把不存在的 bug 栽贓進去
• 找到正確的 bug，卻沒有證據

示範也暴露出一個真實的失效模式：snack doctor 回報一筆上一次執行留下的過期收據，標記為「fail」，但對應的程式碼早已不存在。Nisi 的重點是：證明會腐壞——程式碼會變、日期會移、情境會不同——所以驗證器必須做得夠有彈性，才不會被昨日的證據騙倒。

收據是自我改程序式碼庫的訓練集

Proser 的前瞻論點是：今天每一次執行都是有雙重價值的資料。現在，因為它能餵給 LLM 換取修復；未來，因為當遞迴式自我改進 harness 成為標準配備時，一份關於你的系統如何運作的乾淨資料集，正是讓代理能對照全面性評測做爬山式最佳化的關鍵。他說，沒有這座資料山的團隊，會比握有它的競爭對手走得慢。

他描述自己的實驗 CTX：最初是一個跨 harness 的記憶層，讓 ChatGPT、Claude Code 等能共享記憶。後來它變成一個部署於 Cloudflare 的網路服務，能在不暴露憑證的前提下將金鑰交給代理，現在還負責指派驗證器：代理透過 MCP 回來，說明自己完成了什麼，CTX 就會對 GitHub API 執行一個評估器——最初是簡單的 CLI，後來硬化成可重複使用的元件——確認 PR 存在、合併檢查通過。只有這樣，工作流程節點才會被標記為滿足；否則代理會帶著具體的失敗原因被導回重做。

Nisi 的對應工具是 Riker，一個以工程為核心的機器人，接下任務後全程看顧：它建立檢查、執行所需工具、保留證據、在確認整體目標仍成立的前提下修正審查意見，只在需要時才通知他。他的框架是：他想停止看顧出貨的最後 10%，把時間花在思考這項工作為何存在。

flowchart TD
    A["人類指派成果與完成定義"] --> B["代理在自己的工作線內執行"]
    B --> C["代理執行驗證 CLI"]
    C --> D{"確定性檢查通過？"}
    D -- 否 --> E["回傳結構化失敗輸出"]
    E --> B
    D -- 是 --> F["系統一評審檢視證據"]
    F -- 失敗 --> E
    F -- 通過 --> G["儲存收據，附上截圖與錄影"]
    G --> H["人類審查證據，而非程式碼"]

主持人建議從哪裡起步

Proser 的收尾建議很直白：如果你有網路應用卻沒有自訂的驗證器 CLI，那就去建一個——這是你能做、槓桿最高的事情之一。搭配一套基礎評測，把「好」對你的應用而言長什麼樣編碼進去，並給代理 Chrome DevTools，讓它能看見效能、網路、流量與渲染。至於原生 iOS 或 macOS 客戶端，他提到已有替代專案，且還會持續出現，但原則不變：把你身為開發者會看到的一切都交給代理。

在強制執行上，Proser 不太倚賴 skills，因為模型要不要遵循全憑它自己；他更傾向用 CI 強制執行這些指令。Nisi 最低門檻的做法是在 repo 裡放一份 agents.md——刻意不叫 claude.md——指示任何代理在開 PR 前先跑驗證，再加上供本機開發用的共用 hook。他強調 CI 只是輔助，不是重點：價值在於那個快速的本機迴圈，讓他在研討會當天能同時跑三個代理，平常則跑 10 到 15 個。

信任階梯講得很明白。Nisi 說他靠 Greptile 的 X 分之 5 審查分數加上 CI 通過，就足以相信某個改動不會搞壞生產環境；兩位主持人也提到，全場大多使用 Greptile、CodeRabbit、Codo 這類自動審查工具。但一萬行程式碼、什麼都不做卻拿到 5 分之 5，仍是意圖上的失敗——這正是為什麼驗證迴圈除了確保安全，也是讓代理不偏離正軌的手段。

尚未化解的張力，是有位聽眾針對生產環境提出的疑問。Proser 承認這種不安人人都有，並描述一個逐漸成形的模式：先把代理做出的改動導向預覽環境，在那裡驗證，再升級到生產環境，同時派一個專責代理盯著指標、Datadog 與功能旗標，隨時能判定某次上線有問題並回滾。這是否真能弭平「在預備環境驗證過」與「在生產環境安全」之間的落差，節目並未給出答案——同樣懸而未決的是，當收據、評審與自動審查工具全都點頭之後，還剩多少人工審查。兩位主持人的賭注是：答案會隨模型進步而改善，而握有乾淨證據資料集的團隊，將是唯一能從中受益的一群。