觀點 · 資訊分享
Cloudflare Workflows 設定少一段:排程工作直接寫在 exports,Worker 自己就能叫用
Cloudflare 讓 Workflows 可以直接宣告在 Wrangler 設定檔的 exports 欄位,9 月 27 日起同一個 Worker 也能透過 ctx.exports 呼叫它,不必再為了「定義」和「呼叫」各寫一個 binding。
- 發布
- 2026-09-27
- 篇幅
- 約 5 分鐘 · 2,097 字
- 結構
- 7 節 + 4 題常見問題
- 標籤

一句話看懂:Cloudflare Workflows 的設定變簡單了,背景流程直接寫在 exports 就能部署,同一個 Worker 也能直接叫用,不用再多寫一段 binding。

先用白話講:Workflows 是什麼?
想像一張外送訂單:接單、通知店家、等餐點做好、派外送員、送達後寄收據。每一步都可能卡住,也可能要等好幾分鐘。
Cloudflare Workflows 就是幫你管這種「多步驟、要等很久」流程的服務。每一步失敗會自動重試,系統重啟也能從中斷的地方繼續,不必自己寫一堆狀態紀錄。
以前有個小麻煩:就算只是想「定義」一個 Workflow,也必須在設定檔加一個 binding(綁定),等於同一件事要寫兩次。
發生什麼事
Cloudflare 開發者更新日誌分兩次公布:
- 9 月 24 日:Workflows 可以直接宣告在 Wrangler 設定檔的
exports欄位,不必再加workflowsbinding - 9 月 27 日:定義這個 Workflow 的 Worker,可以透過
ctx.exports直接呼叫它,用法和 binding 一樣
另外兩個重點:
- binding 和 export 用同一個
name時會共用執行個體,所以從 binding 改成 export,不會遺失已經在跑的流程 - 本機開發在
wrangler dev、Cloudflare Vite 外掛、Workers Vitest 整合都能用
這次改動會影響誰
- 新專案:可以直接用 exports 寫法,設定檔裡只需要描述一次 Workflow,部署時一起建立
- 既有專案:不需要改,binding 寫法繼續有效;想整理設定時,可以逐一把 Workflow 從 binding 搬到 exports
- 跨 Worker 呼叫:如果是 A Worker 要呼叫 B Worker 定義的 Workflow,仍然要用 binding,這次的 ctx.exports 只適用於同一個 Worker 內部
- 測試流程:用 Vitest 寫測試的團隊要留意,部分檢查工具還是需要 binding,測試設定可能要另外補一段
簡單說,這次是把「自己定義、自己使用」這種最常見的情境變簡單,其他情境維持原樣。
給開發者的技術細節
設定檔寫法(依官方範例改寫):
{
"exports": {
"ReportWorkflow": {
"type": "workflow",
"name": "report-workflow",
"schedules": ["0 0 * * *"]
}
}
}
在 Worker 裡直接叫用:
const instance = await ctx.exports.ReportWorkflow.create({
params: { name: "World" },
});
版本與限制:
| 需求 | 版本 |
|---|---|
| 在 exports 宣告 Workflow | Wrangler 4.139.0 以上 |
| 本機開發用 ctx.exports | Wrangler 4.142.0、Vite 外掛 1.61.0、Vitest 外掛 1.3.0 以上 |
- exports 可以設定
limits、schedules、default_retention,和 binding 相同 - binding 和 export 可以並存,但必須是同一個類別,設定值也不能互相衝突
- 指向「另一個 Worker」的 binding 不能和本 Worker 的 export 用同一個名稱,因為 Workflow 名稱在同一個帳號內必須唯一
- Vitest 的
introspectWorkflow()仍需要 binding,測試時可以加一個專用的
我的看法
這是一個很小、但很實用的改動。在 Cloudflare 上做排程或背景工作時,binding 名稱和類別名稱對不上是很常見的錯誤,往往部署後才發現叫不到。現在定義和呼叫都收在 exports 一個地方,設定檔清爽很多。
對已經在跑的專案,不需要急著改;官方也保證同名的 binding 和 export 會共用執行個體,真的要搬時可以一次搬一個,風險不大。新專案就可以直接用新寫法。
名詞小辭典
- Cloudflare Workers:跑在 Cloudflare 全球節點上的無伺服器程式。
- Binding(綁定):在設定檔裡宣告「這個 Worker 可以使用哪些資源」,例如資料庫、儲存空間或 Workflow。
- Wrangler:Cloudflare Workers 的命令列工具,用來開發、測試與部署。
- 執行個體(Instance):某個 Workflow 被觸發後實際在跑的那一次流程。
資料來源
常見問題
Cloudflare Workflows 是什麼?
Cloudflare 上用來跑「多步驟、可能要等很久」背景工作的服務,例如每天產報表、下單後依序寄信與對帳。每一步都會自動重試,失敗也能從中斷的地方繼續。
我現有的 workflows binding 要改嗎?
不用。binding 照常可用,兩種寫法也能並存;只要兩邊用同一個類別、設定值不衝突就好。
exports 裡可以設定哪些東西?
和 workflows binding 一樣,可以設定 limits(例如步驟上限)、schedules(排程)與 default_retention,執行 wrangler deploy 時會一起建立或更新。
測試時有什麼要注意?
在 Vitest 裡,introspectWorkflow() 和 introspectWorkflowInstance() 仍然需要 Workflow binding;要檢查宣告在 exports 的 Workflow,官方建議加一個只給測試用的 binding。
接著讀
全部觀點 →Cloudflare Python Workers 正式上線:FastAPI、Django 直接跑在全球邊緣,還能連 MySQLCloudflare 宣布 Python Workers 正式版(GA):Python 成為 Workers 平台的一等公民,FastAPI、Django、Flask 可以直接部署,透過 Hyperdrive 連 PostgreSQL、MySQL,openai、langchain 這類 AI 套件也能用了。閱讀 →Cloudflare Workers 的排程工作本機就能測:Local Explorer 點一下觸發 Cron,AI 代理也能呼叫Cloudflare 讓本機開發用的 Local Explorer 可以手動觸發 Worker 的 Cron 排程,不必等時間到、也不用自己組網址;同時提供 API,讓腳本與 AI 代理也能觸發測試。閱讀 →Cloudflare 官方 MCP 伺服器開始附送「技能包」:AI 代理連上一個網址,就學會怎麼用 CloudflareCloudflare API MCP 伺服器透過 MCP 的 Skills 擴充,直接提供官方整理的 Cloudflare 技能。支援的 AI 工具連上 mcp.cloudflare.com,就能同時拿到 2,500 多個 API 端點和「怎麼正確使用」的操作說明。閱讀 →