Perplexity 共同創辦人兼首席策略官 Johnny Ho 在 OpenAI 於 2026 年 9 月 14 日發布的客戶案例中，描述了一個不少團隊都遇過的瓶頸：搜尋品質可以靠更好的模型持續改善，但要把這些能力接到真實系統上，難度是另一個層級。他的說法是，GPT‑6 Astra 讓他們能讓模型撰寫對外溝通內容、修改實際運作中的系統，並監控正式環境的軟體，這是前幾代模型做不到的事。
測試工作先被交出去
在 Ho 的用法裡，最實用的一塊是測試程式碼。他提到自己手動測試的時間有限，因此會請 GPT‑6 Astra 圍繞某個應用寫一個小型測試程式。
關鍵在於模型能產生逼真的回應，模擬另一個服務會送出的內容，例如語言模型 API 或某個 connector。由模型代替這些服務之後，就能觀察應用怎麼反應，並把整條 workflow 從頭到尾跑一遍。
這裡的訊號不是「模型會寫測試」這麼簡單，而是它被允許扮演系統邊界上的對手。對產品團隊來說，這正好對應到一個常見痛點：整合測試最貴的部分往往不是斷言，而是把外部依賴準備好。
信任的單位從單次輸出變成整條流程
Ho 的另一句話更值得注意：他們現在能把完整端到端系統交給模型負責，檢查的頻率比前幾代模型低很多。
這句話的份量在於「檢查頻率」。如果一個模型每次產出都要人逐行看過，它省下的只是打字時間；只有當團隊願意拉長檢查間隔，自動化才真的改變人力配置。案例把這個轉折歸因於 GPT‑6 Astra 的能力，而不是流程重新設計。
不過，案例沒有說明 Perplexity 用什麼方式界定可接受的檢查間隔，也沒有交代失敗時的回復流程。這些細節在提供的來源中並未出現，因此不應自行補上。
對正在導入 agent 的團隊意味著什麼
把這段經驗放回一般產品開發情境，有兩個可以立刻檢查的地方。
第一，你的 agent 有沒有被授權去「模擬別人」？很多團隊只讓模型產生程式碼，卻沒有讓它扮演外部服務、產生假回應來驗證流程。少了這一層，測試覆蓋率看起來很高，實際上邊界條件仍然空白。
第二，你怎麼定義「檢查頻率」？這其實是風險分級的題目。哪些系統改動可以低頻檢查，哪些必須每次人工確認，取決於改動的爆炸半徑，而不是模型當下的表現。先前我們在流程編排的三種執行模型談過，先決定誰能做決定，再談工具；同樣的順序在這裡也適用，只是這次被授權的對象換成了模型。
案例沒有回答的部分
這是一份客戶案例，不是技術白皮書。它沒有提供測試程式的實際結構、監控正式系統的具體做法，也沒有量化「檢查頻率降低」到底降了多少。Ho 的敘述是 Perplexity 自身經驗的轉述，不是可重複的實驗結果。
對正在評估類似做法的團隊，務實的下一步不是照抄，而是先挑一條邊界清楚、失敗成本可控的流程，讓模型同時負責產生模擬服務與驗證回應，並記錄人工介入的次數。等這個數字穩定下降，再考慮擴大授權範圍。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。