hero

OpenAI 在 2026 年 10 月 14 日刊出的 Amp 客戶案例，有一個比「AI 也會寫行銷文案」更值得追的轉變：代理開始從寫程式跨到決定做什麼、查詢同事對話、管理其他代理、撰寫文件和設計產品頁面。若這些步驟串起來，效率不再由單一模型的輸出速度決定，而由交接、權限與最後的驗收決定。這篇分析對照OpenAI 的客戶故事與Amp 自己發布的功能紀錄，分清已展示的能力、企業的願景和仍缺的成效證據。

原文摘要

OpenAI 呈現了什麼

Amp 原本以程式開發代理為核心。OpenAI 的案例引述執行長 Quinn Slack 說，Amp 按任務效果選用模型，而 OpenAI 模型占平台 token 使用量多數。受訪者描述，有些使用者一週會消耗約 100 億 token；Amp 推出的「Sign in with ChatGPT」則據稱讓使用者取得更多 token 與模型，包括 GPT-6 Astra，減少逐枚計算使用量的心理壓力。這些是受訪者陳述與供應商刊載的案例，沒有同時列出使用者分布、訂閱限制、計費分攤或效率對照。100 億不是典型用戶的數據，也不能拿來推估每個團隊的月費。

案例再描述 Amp 自己約二十人的團隊如何使用代理：除寫程式外，也協助行銷、改善新手體驗、製作文件與設計頁面。Slack 說團隊沒有專職行銷人員，卻有一個投入行銷的代理；這表達的是團隊的工作分配，不是「代理已取代一名員工」的因果測量。文中還有家庭實驗：把住宅平面圖交給 GPT-6 Astra 做 Blender 立體模型，再與孩子改造成遊戲場景。它示範模型可跨素材與工具工作，卻不能直接作為商用設計的品質指標。

最後，OpenAI 介紹 Calling Puck：讓使用者以即時語音和 Amp 的 Puck 助理對話，甚至從手錶協調正在執行的代理；案例稱它採用 GPT-Live-1。同篇說 Amp 正在測試 GPT-6 Astra 的 Ultrafast 模式，Slack 預期更快的回應會改變並行工作的方法。這裡的用字很關鍵：「正在測試」不是已公開驗證吞吐量、任務完成時間或品質改善。案例沒有對照組、錯誤率、返工時數，也沒有從模型成本到人工成本的完整帳。

從功能清單，看懂代理究竟跨了哪幾道界線

Amp 7 月的 Puck 發表文列出的例子並不只是聊天：Puck 能幫人找到舊討論、建立新專案、啟動代理調查 CI 失敗、安排多個代理重跑腳本，並彙整結果。它比較像「代理的入口和調度台」，而不是一個只回答問題的聊天視窗。若一個任務從 Slack 的問題回報開始，跨到查閱歷史對話、啟動環境、修改程式、回報同事，Puck 所管理的是上下文與工作流，不只是生成一段文字。

同期的 Slack 整合說明提供更具體的場景：用 @Amp 發起 bug 修復、搜尋頻道中的脈絡，或從監控警報找出可疑變更、核對生產日誌並修改 Terraform 設定。這些是 Amp 自己展示的例子，不應寫成獨立驗證過的普遍能力；但它們足以說明風險的分層。搜尋舊討論屬於讀取，回覆同事可能影響決策，提交基礎設施變更則是可造成生產後果的寫入。若三者都被描述為「請代理處理」，讀者就無從知道何時必須由人批准。

語音把這道界線又往前推。Amp 8 月的 Puck 語音介紹說，可以口頭詢問哪些執行緒需要輸入、讓它讀 Slack 中提及自己的訊息，或指派代理修 CI 並持續報告。10 月 13 日，Amp 又宣布透過 MCP 從 ChatGPT、Claude 等其他助理呼叫 Puck，在原有對話裡指派 orb 執行工作、檢查進度。此時一個口語構想可以穿過外部對話介面 → Puck → Amp orb → 檔案／服務。每過一道邊界，都要問：誰的身分在授權？哪段對話會被帶入？代理能讀哪些舊資料？最後的寫入要在哪一關確認？MCP 是工具連接方式，不是自動具備權限隔離的保證。

模型選擇的細節：一個產品，不是一顆模型

OpenAI 客戶故事把 GPT-6 Astra、GPT-Live-1、Ultrafast 排在同一篇文章中，容易讓人以為所有 Amp 任務都由同一模型跑完。Amp 的模式與子代理文件呈現不同的產品邏輯：主代理、專門的 Oracle／Librarian 等子代理，以及處理影像、音訊或摘要的輔助模型，各有自己的路由；預設模型可能更換。文件還提醒，主代理若走 ChatGPT 訂閱，其他子代理仍可能走 Amp 的額度計費。於是「用 ChatGPT 登入」不等於整條工作鏈都由 OpenAI 承擔成本，也不等於每一步都使用相同模型。

這個架構有商業上的吸引力：產品可以依速度、品質和成本調整不同角色，不必把體驗鎖在單一模型版本。但它也把評測變得更難。若一次任務含主代理規劃、子代理查資料、影像模型讀截圖，以及人最後返工，成果屬於整套系統；拿單一模型的 benchmark 或一個人的使用心得，就不能回答哪一環真正在創造價值。企業採購時應要求的是端到端任務結果，而非只問主模型名字。

如何驗收「程式碼以外」的工作

程式碼至少有測試、差異檔與部署回滾等相對明確的把關方式；「產品生命週期」的每個產物則需要不同的驗收者。代理規劃功能時，應核對使用者需求和決策紀錄；編寫文件時，應逐項驗證介面、版本與操作步驟；產出行銷頁面時，應有人對未交付功能、法律宣稱與品牌用語負責；要改生產設定時，則應限制作用範圍並經審查。不能因為同一代理都能生成，就假設這些任務用同一個「看起來不錯」的標準過關。

一個可檢驗的試點可分三類任務：只讀並摘要舊討論、在沙盒中改程式並跑測試、產出對外文件但待人工核准。分別記錄端到端耗時、人工審查與返工、模型／平台費用、錯誤後的回復成本，以及最後被採用的比例。若啟動代理的次數升高，但採用率下降、人工清理變多，「更多 token」就只代表更多活動，不代表更多成果。這是本文提出的評估框架，不是 Amp 已發表的實驗結果。

Ultrafast 的承諾同樣需要這種框架。低延遲可能讓人少開幾條平行任務，頻繁確認一條代理的進度；也可能讓它更快堆出未審核的改動。要判斷速度是否真的有用，至少得看從需求到驗收的整體時間、每次中斷後能否正確恢復，以及在較快流程下錯誤是否變多。單次回覆快，並不自動縮短等待審批、跨團隊協調或修正錯誤的時間。

案例無法直接回答的治理問題

Amp 的發表文讓人看見代理入口從網頁、Slack、語音延伸到其他助理；但可用性、可控性與可衡量的效益是三個不同問題。案例沒有公開說明每種跨系統操作的人工核准條件，也沒有給出人工返工與可採用產物的比較資料。這些缺口不表示產品沒有控制措施，而表示不能從客戶故事推定已有足夠的控制與效益證明。真正的驗收應依操作影響分層：查詢資料、起動測試代理、修改生產設定與對外發布，不宜共用同一個核准門檻。