Perplexity 用 GPT-6 Astra 處理端到端系統：AI Agent 監督如何改變

快速解答

OpenAI 在 2026 年 9 月 14 日發布新的 Perplexity 客戶案例，指出 Perplexity 正使用 GPT-6 Astra 撰寫溝通內容、修改真實系統、監控生產軟體，並對應用程式進行端到端測試。Perplexity 共同創辦人暨策略長 Johnny Ho 表示，公司現在能把完整的端到端系統交給 Astra，並且比使用前幾代模型時大幅減少人工檢查頻率。

TowCue 認為，真正重要的訊號不是「生產環境的 AI Agent 已經不需要監督」，而是更強的 Agent 正讓人工審查從逐步盯著執行，轉向檢查證據、例外狀況與高影響動作。

更成熟的 Agent 工作方式應該是：讓系統在清楚邊界內執行工作，要求它證明自己做了什麼，再把人的注意力集中到出錯代價最高的地方。

延伸閱讀 TowCue 的 GPT-6 Astra 工作流成本指南、Codex 遠端工作流指南與 AI Agent 最佳實務指南。

Perplexity 實際把 Astra 用在哪裡

Perplexity 本身是答案引擎，因此模型推理與程式能力提升，可以直接影響搜尋產品的品質。OpenAI 9 月 14 日的案例中，Ho 表示，每當模型更會寫程式，Perplexity 的搜尋引擎也會跟著改善，因為模型可以寫出更好的程式去搜尋網路與內部資訊，再把結果精簡整理。

但更值得關注的改變，是模型離開單純資訊處理之後能做什麼。

根據官方案例，Perplexity 正讓 Astra：

撰寫溝通內容
修改真實軟體系統
監控生產環境軟體
為應用程式建立測試程式
模擬模型 API、connector 等外部服務的回應
從頭到尾測試完整工作流

這已經不是單純提供程式碼建議，而是讓模型進入「修改系統，再蒐集證據確認修改是否有效」的閉環。

OpenAI 的 GPT-6 Astra 官方發布資料則提供了能力背景：Astra 強調 computer use、瀏覽、軟體工程與多步驟專業工作，也能執行前端 QA、安裝與測試軟體，以及根據螢幕上的狀況排查問題。這些能力解釋了為什麼 Perplexity 類型的團隊開始嘗試更長、人工介入更少的工作流。

真正的訊號不是自主，而是驗證

「大幅減少檢查頻率」很容易被寫成「工程師可以不用看 AI 做什麼」。

TowCue 會更保守地解讀。

Perplexity 這個案例特別強調的是測試與證據。Ho 描述的做法，是要求 Astra 圍繞應用程式建立一套小型測試程式。模型可以生成類似外部服務會回傳的真實回應，例如模型 API 或 connector，然後觀察應用程式如何反應，測完整條工作流。

這改變的是監督模式。

較弱的 coding assistant 可能需要人逐步檢查，因為它無法可靠地自行完成閉環。更強的 Agent 則讓人逐漸可以把要求改成「完成結果，並附上證明」：

你改了什麼？
跑了哪些測試？
哪些項目通過？
哪些地方還沒測？
生產指標有什麼變化？
哪些訊號出現時應該回滾？

目標不是零監督，而是更高槓桿的監督。

Agent 越強，端到端測試越重要

Agentic coding 帶來一個新的生產力問題：程式碼生成速度可能開始超過人類審查速度。

如果 Agent 能一次修改多個檔案、呼叫工具並持續迭代一小時，要求工程師逐行閱讀它產生的所有程式碼，很可能成為新的瓶頸。這不代表 review 應該消失，而是團隊需要更強的行為驗證方式。

端到端測試的價值，在於它問的問題比「這個 diff 看起來合理嗎？」更直接：

當真實輸入、依賴與失敗情境都出現時，整個系統到底有沒有正確運作？

對許多工作流而言，一套好的證據包可能包括：

unit 與 integration test 結果
可重現的端到端情境
UI 行為的截圖或錄影
證明相關路徑確實執行的 logs
修改前後的效能指標
明確列出哪些項目尚未測試

Cognition 在 9 月 11 日公布的 Astra 案例也呈現類似方向：Devin 可以測試一款 iPhone 遊戲，回傳 simulator 錄影，同時提供哪些檢查通過、哪些範圍還沒測到的報告。雖然兩家公司工作流不同，但共同訊號很清楚：Agent 不只是能產出工作，而是能證明工作時，價值才會更高。

減少監督應該按照風險分級

不是每個 Agent 動作都值得相同程度的人工審查。

一個可逆、測試完善的小修改，可以比資料庫 migration、權限修改、付款動作或 production deletion 更早放寬人工檢查。

TowCue 會把 Agent 工作實務上分成三層。

低風險、容易回復的工作

例如格式整理、測試生成、文件更新，以及受到完善自動測試保護的獨立程式修改。

這類任務通常可以讓 Agent 跑得更久，最後由人檢查結果與證據。

中等風險的系統修改

例如改變應用程式行為、connector 或部署設定。

這類工作應要求更完整的測試證據、有限權限、staging 或 canary 環境，以及清楚的 rollback 計畫。

高影響或難以回復的動作

例如刪除生產資料、大範圍權限修改、金融操作、具有法律影響的對外溝通，或不可逆的基礎設施變更。

即使模型過去測試紀錄很好，這些動作仍應保留確定性的人工批准關卡。

模型越強，可以擴大的應該是它的執行範圍，而不是無限權限。

團隊可以直接複製的 Perplexity 工作方式

1. 讓 Agent 一起建立測試框架

不要把測試當成 Agent 寫完程式之後才開始的另一件工作。把 realistic mocks、fixtures 與端到端檢查直接納入實作任務。

2. 完成任務時必須附證據

好的 Agent 完成訊息不能只有「done」。

要求它列出行為變更、測試指令、結果、必要的截圖或 logs、已知缺口，以及可能影響正確性的假設。

3. 把證據與信心分開

「我很有信心」不是證據。

優先看可以被機器驗證的輸出：tests、traces、diffs、metrics 與可重現步驟。

4. 權限保持最小化

只提供完成任務真正需要的 credentials 與工具。Production 權限應比 development 更窄，破壞性操作繼續保留批准關卡。

5. 追蹤人工介入率

如果團隊想知道新模型是否真的帶來更多自主能力，就追蹤人需要介入多少次、為什麼介入、測試攔下多少問題，以及已宣告完成的任務有多少需要返工。

只有品質維持或提升時，「更少檢查」才有意義。

誰最值得注意這個變化

這種模式最適合已經把 coding agent 用在多步驟工作，而不只是 autocomplete 的工程團隊。

特別適合以下環境：

應用程式已有有意義的自動測試
工作流能在 sandbox 或 staging 重現
Agent 可以觀察自己動作造成的結果
權限可以限制範圍
失敗可以 rollback
團隊能持續比較人工介入率與 defect rate

如果系統規格本身不清楚、沒有人知道正確行為是什麼、production 是唯一可用的測試環境，或失敗難以回復，這套方式就不適合。

在那種環境中，讓更強的模型獲得更多自主權，可能只是讓錯誤發生得更快。

工作流真正的變化：不只 review 產物，也 review 證據

過去幾年，AI coding 工具通常用它產出的 artifact 評估：一段 completion、一個 function、一個 patch 或一個 pull request。

Perplexity 與 Cognition 的案例指向一個更完整的工作單位：

產物 + 執行 + 驗證證據。

而且這不只適用軟體工程。Research Agent 應該展示來源；Browser Agent 應該留下修改紀錄；金融工作流應保留計算與批准記錄；客服 Agent 應記錄 tool actions 與 escalation decisions。

當 Agent 開始能真正採取行動，輸出就不只是文件或程式碼。輸出還包括一條讓人可以判斷結果是否值得信任的 audit trail。

TowCue 結論

OpenAI 9 月 14 日發布的 Perplexity 案例值得關注，因為 Perplexity 不只讓 GPT-6 Astra 寫程式，而是開始讓模型接觸真實系統、監控軟體並執行端到端測試，同時比前幾代模型減少人工檢查頻率。

TowCue 的判斷很簡單：

Agent 生產力的下一步，不是消滅人工 review，而是把持續盯著 Agent，改造成以證據和風險為核心的 review。

團隊採用更強的 coding agent 或 computer-use agent 時，不要先問：

「我們可以讓模型在沒有人的情況下做多少事？」

更好的問題是：

「Agent 必須提供哪些證據，我們才能安全地減少對這類任務投入的人力注意力？」

Perplexity 讓 GPT-6 Astra 處理端到端系統：減少人工監督真正應該代表什麼