摘要： 診斷出問題，對 production agent 來說只算走完一半；真正的難關在於診斷之後，它有沒有資格動手。給它唯讀身分，安全無虞，代價是永遠只能出建議；讓它整包繼承工程師的權限，做事痛快，但只要誤判一次，波及範圍就跟工程師本人一樣大。2026 年 7 月，Vercel 更新了 Vercel Agent，走的是兩個極端之外的路：用自己專屬的身分存在，平常維持唯讀，想動任何東西都得先交出 plan、等人工點頭，才換來一段限時的權限。
診斷出問題，對 production agent 來說只算走完一半；真正的難關在於診斷之後，它有沒有資格動手。給它唯讀身分，安全無虞，代價是永遠只能出建議；讓它整包繼承工程師的權限，做事痛快，但只要誤判一次，波及範圍就跟工程師本人一樣大。2026 年 7 月，Vercel 更新了 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：passing CI 看不見的 performance regression 和 risky change，Agent 會幫你標出來。CI 轉綠只證明測試還過得了，證明不了速度沒退化——它補的就是這個縫。
成本追蹤：帳單突然暴漲，Agent 負責揪出元兇——比方說某個 code change 害每個 request 都得重新 server-render，caching 被整個繞過；拿到批准後，它會把 fix 寫好並開出 PR。
修 broken build：先讀 logs、定位 failing config，接著請求更新權限，把 build 放進 sandbox 試跑，確認過了關，修復才會被端出來。
能否上線檢查：丟一個 feature flag 給它，Agent 讀完 code 和 live metrics，就會告訴你這功能此刻能不能安全 rollout。官方另外寫明了一條紅線，值得一併記住：你主動發問時，Agent 只會回答問題、或交出等著批准的 fix，production 它絕不擅自更動。
五項工作有一個共同的底：全都得靠跨系統的證據——code、log、部署歷史、成本數字——而這些證據原本就躺在同一個平台上。換成外掛式 agent 來做，前半段時間常常先燒在搬資料、重建 context 上。
安全模型的骨幹：專屬身分，權限不過戶
撐起這些能力的，是一套新的安全模型。官方把現況說得很直白：現有多數 agent 直接繼承使用者的全部權限，結果一個 bad prompt、或一個 confused sub-agent 出錯，波及範圍跟使用者本人沒有兩樣。
Vercel Agent 的對策拆成三件。身分：它用自己的 principal vercel-agent 跑，任何人的 session 都不冒用。Attribution：每一筆變更都留下紀錄——誰提出、誰批准、誰執行——照官方說法，Agent 經手的每件事都追得到源頭。Authority：使用者的 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 得先自證
Agent 生成的 code 一律先丟進 Vercel Sandbox 跑——那是個 ephemeral 的 Firecracker microVM，跟 live systems 和 host 環境彼此隔離。這個 sandbox 不是裝樣子的空殼，而是整個專案如實的複本：build、tests、linters 全用真的，Agent 就拿這些去檢驗生成的 code，通過的才會被端出來。
搭配的後盾是 immutable deployments：每一版部署都留著，壞版本想恢復，永遠只差一次 rollback。官方把這層設計稱作 anti-fragile infrastructure 的地基——安全的前提不是指望模型零失誤，而是讓 infrastructure 把犯錯的代價壓低。
限制與代價：信任由 infrastructure 提供
取捨同樣得攤在陽光下。這套安全模型的設計目標是圈住錯誤，不是讓錯誤消失：模型終究 non-deterministic，部署跟錯誤之間的相關性，有可能只是時間上的巧合，按下回滾之前，資料遷移與外部依賴還是得親自查過。它的視野也止步於 Vercel 平台，DNS 或第三方服務出事，雷達上不會有反應。approval 本身還會疲勞——什麼 plan 都照單全收，整個模型就淪為橡皮圖章。目前開放對象是 Pro 與 Enterprise teams，到 Dashboard 的 Agent section 即可啟用。
自建 agent 的團隊能整包搬走的順序
正在打造自家 production agent 的團隊，最能直接帶走的是那條順序：身分獨立、attribution 做滿，預設唯讀，靠 plan 換取短時 scoped 權限，生成的 code 先過 sandbox，收工立刻降權。不妨把它想成一條流水線：有身分，每一站才問得到責；有唯讀，調查才能零風險；plan 把「想做什麼」寫成可逐條核對的文字；短時權限把出錯窗口收到最小；sandbox 擋下壞 code；降權負責收尾。你真正要驗證的，從來不是這個 agent 可不可信，而是每次決定不信它時，退路夠不夠便宜。速度當然重要，但 agent 能不能靠近 production，靠的是可撤銷與可追蹤這兩個前提。