Production agent 最難的不是診斷，而是診斷之後的權限問題。唯讀的 agent 很安全，但只能留下建議；直接繼承工程師完整權限的 agent 很方便，但一次誤判的爆炸半徑與本人相同。Vercel 在 2026 年 7 月更新的 Vercel Agent 選了第三條路：以自己的身分存在、預設唯讀，任何變更都要先提 plan、經人批准後才取得短時權限。
三分鐘的實戰：從 500 到 rollback
官方部落格給了一個完整情境：checkout 端點開始回 500，Vercel Agent 自主調查 logs、metrics 與 deployments，把錯誤追溯到四分鐘前上線的那個部署，建議立即 rollback；值班工程師批准 plan，Agent 執行回滾。從 alert 到 mitigated，官方帳面時間不到三分鐘。
這組數字是 Vercel 自己的示範案例，屬於廠商自述，引用時應保留出處屬性。但它揭示的結構優勢是真的：Agent 內建於部署與執行 app 的平台，能從 Vercel Dashboard、GitHub 與 CLI 接觸，讀的就是部署與執行的第一手資料，不需要等人開筆電、貼 log、補 context。人類留下的位置是批准，不是操作。
五種日常工作：調查只是其中一項
調查是起點，官方列出的日常工作還涵蓋四種真實痛點。
PR review：Agent 能標記 passing CI 抓不到的 performance regression 與 risky change。CI 綠燈代表測試沒壞，不代表沒有變慢，這正是它補位的地方。
成本追蹤：帳單暴增時，Agent 可以找出元兇，例如某個 code change 讓每個 request 都重新 server-render 而不是 caching；經批准後直接寫 fix 並開 PR。
修 broken build：Agent 讀 logs、找 failing config、請求更新權限、在 sandbox 裡測 build，確認能過才把修復端出來。
能否上線檢查：問它一個 feature flag，Agent 會讀 code 與 live metrics，告訴你這個功能現在能不能安全 rollout。另值得記下官方明寫的紅線：你主動提問時，Agent 只回答問題或交付待批准的 fix，絕不自行變更 production。
這五種工作的共同點值得注意：每一項都需要跨系統的證據——code、log、部署歷史、成本數字——而這些證據本來就在同一個平台上。同樣的任務交給外掛式 agent，前半段往往先花在搬資料與重建 context。
安全模型：自己的身分，不繼承你的權限
這套能力的底層是一個新的安全模型。官方的觀察很直白：多數現有 agent 繼承使用者的完整權限，於是一個 bad prompt 或一個 confused sub-agent 的爆炸半徑，與使用者本人完全相同。
Vercel Agent 的解法是三件事。身分：Agent 以自己的 principal vercel-agent 執行，不冒用任何人的 session。Attribution：每個變更都記錄誰提出、誰批准、由誰執行，官方的說法是 Agent 做的每一件事都可追蹤。Authority：Agent 不繼承使用者的 access，只取得 plan approval 明確授予的權限，而且不超過下指令者本身擁有的權限。對稽核而言，這三件事合起來回答了一個共享帳號永遠無法回答的問題：這個變更到底是誰做的——不是哪個 token，而是哪個請求、哪個批准、哪個執行者。
Plan 就是 permission
運作上的關鍵是 plan 即 permission。需要 rollback、改 config 或清 cache 時，Agent 先提出 plan，說明要做什麼、為什麼；你批准後，它取得僅限該 plan 的短時 capability，做完立即回到唯讀。
技術上，plan 批准後 Agent 的每次 API call 都要通過三重檢查：plan 授予的 capability、token 的 scope、團隊既有權限。檢查機制放在 platform 層而不是 prompt 裡——就算模型被注入或判斷失準，它能做的仍被 plan 邊界框住。官方把這套命名為 plan-to-permission prompt model，訴求是把 least privilege 變成 by design，而不是祈禱模型表現良好。
Sandbox：生成程式碼先證明自己
生成的 code 在 Vercel Sandbox 執行——一個 ephemeral 的 Firecracker microVM，與 live systems 及 host 環境隔離。Sandbox 不是空殼，而是專案的真實副本：Agent 拿實際的 build、tests、linters 去驗證生成的 code，只把通過的結果端出來。
配套的是 immutable deployments：每個部署都被保留，壞的版本離恢復永遠只有一次 rollback 的距離。官方把這稱為 anti-fragile infrastructure 的基礎——安全不是假設模型不出錯，而是讓 infrastructure 把錯誤變便宜。
限制與取捨：信任來自基礎設施
取捨也要攤開講。安全模型是設計來圍堵錯誤，不是消除錯誤：模型仍然 non-deterministic，部署與錯誤的相關性可能只是時間巧合，回滾前仍要檢查資料遷移與外部依賴。Agent 的視野以 Vercel 平台為邊界，DNS 或第三方服務的問題不在它的雷達上。批准本身也會疲勞，照單全收的 approval 會讓整個模型退化成橡皮圖章。開放範圍目前是 Pro 與 Enterprise teams，在 Dashboard 的 Agent section 啟用。
Builder 可以直接搬走的清單
對自建 production agent 的團隊，這篇文章最有價值的是可複製的順序：獨立身分與完整 attribution、預設唯讀、以 plan 取得短時 scoped 權限、sandbox 驗證生成 code、做完即降權。把它想成一條流水線：身分讓每一站可以問責，唯讀讓調查零風險，plan 把「想做什麼」變成可核對的文字，短時權限把出錯窗口壓到最小，sandbox 擋住壞 code，降權收尾。你要驗證的從來不是 agent 值得信任，而是每一次不信任都有便宜的退路。速度重要，但可撤銷與可追蹤才是 agent 能靠近 production 的前提。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。