Vercel Schedules 公開測試，AI 代理動態排程、Queues 與時間誤差怎麼看？

AI 代理答應明早交付摘要後，應用程式還需要有人記住時間並重新啟動工作。若每個使用者都要求不同時點，固定寫在部署設定裡的排程就不夠彈性。

Vercel Schedules 在 2026 年 11 月 4 日以公開測試形式公布，並於 11 月 5 日透過官方 X 公告。應用與代理可在執行時建立、修改或取消排程，不必每次重新部署。

動態排程透過 Queues 傳送一次性或週期性工作，並可附上 JSON 資料。排程服務負責時點與投遞，真正執行任務的程式仍由應用提供。

靜態排程則保留部署設定方式，能呼叫私有函式、HTTP 路徑或佇列主題。兩者支援能力不同，不能把動態範例直接套到每一種目標。

因此，判斷它是否適合代理產品，要看投遞路徑、時區、執行誤差與當下權限，而不是只看代理能否把自然語言改寫成時間。

動態排程如何把使用者要求留到未來執行

Vercel Schedules 讓應用在執行期間管理何時啟動工作。官方介紹文章以代理明天早上整理新聞為例，說明排程如何接進對話後的工作。

傳統做法可能先把請求和時間存進資料庫，再用固定週期工作檢查哪些任務到期。這樣可以運作，但應用需要自行維護待辦狀態與輪詢流程。

動態排程則讓程式直接建立未來工作。代理取得任務、日期與時區後，工具呼叫把這些資料交給 Schedules，到了時間再送回應用執行。

一次性任務適合特定日期的提醒，週期性任務則適合每日摘要或定期整理。兩者的時間表達不同，因此代理在建立前就應分清使用者要哪一種。

時區是其中一個明確欄位。官方使用 IANA 時區名稱，讓時間隨地區規則解讀，比只保留「早上九點」更能避免不同地區的使用者混淆。

公告範例將使用者說明和識別資料放進 payload。這個詞指隨工作一起送出的資料，讓未來執行程式知道要替誰處理什麼。

但排程建立成功，只表示工作已登記。到了時間，應用仍要接收要求、啟動代理、取得資料並保存結果，所以它沒有把一整項任務自動變成已完成。

這個區別影響產品回覆方式。應用可以先確認排程時間與內容，之後再用執行結果回報完成，避免把兩個階段混成一句模糊的承諾。

排程建立之後，佇列與應用仍需要各自承接後續工作。理解這段路徑，才知道動態排程的能力與限制落在哪裡。

Queues、payload 與 namespace，分別處理什麼

動態排程以佇列主題作為工作投遞目標。Queues 是讓工作訊息先排入系統，再由消費端程式處理的服務，能把登記時間與真正執行分開。

主題用來區分訊息送往哪一類處理程式。例如代理摘要與資料清理可以有不同主題，讓接收端使用相應邏輯，而不必全塞進同一個處理入口。

依 Schedules 官方文件，動態排程目前只能送往 Queue topic。若想直接呼叫私有函式或某個網頁路徑，則應看靜態排程的目標能力。

payload 是可選的 JSON 資料，JSON 是程式常用的結構化格式。應用可以放入任務與必要識別欄位，但仍應避免把不需要的資訊塞進每次投遞。

官方限制 payload 最大為 16 KB。這適合傳送任務參數，不適合直接把大型文件或整份資料庫內容當成每個排程的訊息。

namespace 則提供管理上的分組。多租戶應用可以按客戶分組，避免不同客戶的排程在管理介面與程式操作中混在一起。

但分組名稱本身不會替應用完成使用者授權。官方範例明確要求，收到未來工作時要重新檢查使用者當下的權限，再開始代理任務。

因為使用者可能在排程建立後取消訂閱、離開團隊或失去資料存取權。若只保存建立當時的狀態，就可能在未來執行時沿用已失效的資格。

這裡的重新檢查不是重新詢問時間，而是確認應用現在是否仍能代表該使用者處理資料。它應放在實際執行程式中，而非假設排程服務自動知道產品規則。

資料能送達之後，應用還得檢查執行時是否依然有權處理。這讓動態排程能接進現有帳號系統，也保留產品自己的權限邊界。

靜態與動態的目標、修改與測試差異

靜態排程和動態排程提供不同的管理方式。靜態時間寫在 vercel.json 或 Build Output API 設定，隨部署套用，適合屬於應用本身的固定工作。

例如每天清理過期紀錄，可以和程式一起管理。時間或目標改變時，修改設定再重新部署，讓版本紀錄保留這次調整。

動態排程則透過 SDK、CLI 或 API 管理。SDK 是應用可呼叫的程式套件，CLI 是命令列工具，讓執行中的服務能立即建立或修改使用者自己的排程。

兩者都支援週期性工作，但一次性執行與 JSON payload 只適用動態排程。靜態 namespace 固定為 default，動態則能選擇分組。

目標也有差異。靜態可選路徑、私有函式或佇列主題，動態只有佇列主題，因此選擇管理方式時也同時決定了後續接收架構。

私有函式沒有公開網址，Vercel 會直接呼叫並確認請求來自排程服務。這適合不需要暴露 HTTP 入口的固定工作，但函式內部的資料操作仍由應用程式負責。

設定的更新與刪除需要部署，不代表每次暫停也要部署。文件說明兩種類型都能透過管理介面或工具啟用、停用及立即執行，日常操作和設定版本是不同層次。

測試方面，Schedules 支援 Preview 分支與自訂環境。團隊可以先在測試環境驗證投遞與處理，降低直接用正式資料檢查第一個排程的需要。

官方也提供本機 vercel dev 與 Run Schedule。前者協助本機開發，後者讓團隊不用等到指定時點，就能觀察一輪執行結果與歷史。

文件將 Schedules 定位為 Cron Jobs 的接續方案，但仍明確標示 beta。介面、行為與限制可能在正式版前變動，因此遷移仍應依當時文件核對。

選定路徑後，再確認方案與時間誤差是否符合任務。這會決定應用能向使用者承諾多精確的執行時間。

時間誤差、權限與重複執行，需要怎樣設計

排程服務提供觸發機制，應用仍須管理任務完成條件。尤其 Schedules 使用時間抖動視窗，不能把指定時點直接說成精準到秒的完成保證。

抖動視窗是允許啟動時間分散的範圍。依 官方限制文件，Pro 與 Enterprise 可設定一至十五分鐘，預設一分鐘，Hobby 固定十五分鐘。

週期最短間隔也不能短於抖動視窗。因此 Hobby 最多每十五分鐘執行一次，Pro 與 Enterprise 在一分鐘視窗下可每分鐘一次，兩種方案不能混用同一條件。

這讓晨間摘要和精確秒級提醒有不同適配程度。若工作能接受數分鐘的啟動範圍，可以先測試，而有硬性即時期限的流程則需要另行評估。

方案配額也要連同管理方式看。團隊排程上限會合計所有專案、環境與分支，Hobby 為一千、Pro 一萬、Enterprise 十萬，不能把每個分支當成獨立額度。

一次性排程在投遞後不再占用該上限，雖然還會暫留可見紀錄。這是投遞狀態的安排，不能直接推成任務成果已完成並通過查核。

Hobby 每個計費週期還有建立五百個動態排程、執行五千次的限制，手動執行也計入。超限後部分操作會被阻擋，預定執行可能被略過，因此測試規模要事先估算。

Hobby 的單次部署最多還能宣告一百個靜態排程，超出會使部署失敗。這和團隊總排程上限不同，因此同時管理大量固定工作時，兩項限制都需要檢查。

方案降級也有影響。移往 Hobby 時，不符合頻率或抖動條件的排程會被刪除，之後升級不會自動恢復動態排程，所以轉移前應先整理設定。

執行端則需要考慮佇列重試。如果同一工作再次送達，重複寄送或重複寫入可能造成問題，因此應用可用工作識別碼記錄是否已處理，這是本文的工程設計建議。

這種避免重複效果的設計常稱為冪等處理，意思是相同工作再次執行時，不會再次產生不該重複的結果。實際做法仍取決於任務與資料儲存方式。

費用也隨目標資源發生。函式與路徑會產生 Functions 呼叫，佇列目標會產生 Queues 訊息與消費端工作，因此不能把建立排程當成整個代理任務免費。

API 也有速率限制，超限會回傳 rate_limited，文件要求依 retryAfter 等待再試。這和排程的執行頻率是不同限制，管理程式不能因一筆失敗就立即無限重送。

時間承諾與執行驗收都要留在產品設計裡。排程、投遞、處理與結果保存各自可查，應用才知道失敗發生在哪一段。

方案變更與管理速率，會影響哪些既有工作

升級方案不一定改變所有既有排程。官方說明，原本明確設定十五分鐘抖動的工作，升級後仍保留該設定，只有未指定值的排程會套用新的預設。

所以，如果應用希望升級後提高執行頻率，還要核對現存設定。帳號已升級與每個排程已採用較短時間視窗，是兩件需要分開確認的事。

API 管理速率也按團隊合計，SDK、CLI 與管理介面的同類操作共用額度。若程式與人工同時大量管理排程，不能把每個入口都當成各自獨立的限制。

查詢與建立更新在 Pro、Enterprise 為每秒一百次，Hobby 則是每分鐘一百次。單位差異很大，所以自動化程式應先確認所屬方案，避免沿用另一方案的發送速度。

刪除或停用，以及手動觸發，另有較低的操作上限。這些是管理請求的限制，並不代表同一時間應用最多只能處理相同數量的任務結果。

執行歷史保留九十天，可協助觀察排程何時觸發。但歷史紀錄仍需要和應用保存的結果對照，才能知道一次投遞是否完成預期業務工作。

文件也說明停用或刪除能停止後續排程用量。對一次性測試，團隊應確認測試排程是否仍會重複投遞，避免把沒有再打開管理頁誤當成工作已停止。

FAQ：Vercel Schedules 常見問題

它已經正式版了嗎？

11 月 4 日官方文章公布的是 Public Beta，11 月 5 日官方 X 再介紹。文件也提醒行為、介面與限制可能改變，不能把 beta 寫成所有條件已固定的正式版。

動態排程可以直接呼叫我的 HTTP 路徑嗎？

目前動態排程只支援 Queue topic。靜態排程才有路徑與私有函式目標，所以需要先按管理方式與接收架構選擇。

設定早上九點，就一定九點整完成嗎？

不一定。Schedules 有一至十五分鐘的抖動視窗，Hobby 固定十五分鐘，任務本身也需要處理時間。應用應分開說明預定時間、啟動與完成狀態。

任務登記後還需要重新確認權限嗎？

需要由應用檢查使用者當下權限。官方範例把這一步放在收到佇列工作之後，避免沿用建立排程時已經失效的帳號或資料資格。

先用非緊急且可核對結果的工作測試完整投遞路徑，再決定是否適合納入代理的日常服務。想追蹤代理基礎設施的功能與限制，可訂閱 AI 郵報。

延伸閱讀

Browser Use 與 Computer Use 差在哪？AI 代操作工具選擇指南可協助理解代理取得網路資料的另一段工具選擇。

AI 說完成之後，怎麼驗收？文件、網站與資料任務的檢查方法整理任務結果驗證，適合搭配排程的完成狀態設計。

資料來源

本文依據 Vercel 公告、Schedules 文件、方案限制及 官方 X 貼文整理，條件於 2026 年 11 月 6 日台灣時間查核。本文未部署或測試服務。