凌晨?jī)牲c(diǎn)，你的AI代理還在幫用戶比價(jià)、填表、等審批。突然，500個(gè)代理同時(shí)啟動(dòng)，每個(gè)要跑十幾個(gè)步驟——你的后臺(tái)扛得住嗎？

Cloudflare的工程師最近就遇到了這個(gè)問題。他們發(fā)現(xiàn)，原本為人類點(diǎn)擊設(shè)計(jì)的工作流引擎，正在被機(jī)器以百倍速度調(diào)用。這不是簡(jiǎn)單的流量增長(zhǎng)，而是整個(gè)使用場(chǎng)景的質(zhì)變。

從"人等系統(tǒng)"到"系統(tǒng)等機(jī)器"

Cloudflare Workflows最初的設(shè)計(jì)假設(shè)很樸素：用戶注冊(cè)、下單、提交表單——人的手速能有多快？一個(gè)用戶同時(shí)跑一個(gè)工作流實(shí)例，綽綽有余。

但過去兩年，數(shù)據(jù)講了一個(gè)完全不同的故事。

人類觸發(fā)的工作流在減少，代理觸發(fā)的工作流在暴增。這些AI代理不是瞬時(shí)完成的工具調(diào)用，而是可能持續(xù)運(yùn)行數(shù)小時(shí)甚至數(shù)天的"數(shù)字員工"。它們需要記住進(jìn)度、等待外部事件、在失敗時(shí)從斷點(diǎn)恢復(fù)——這正是工作流引擎的強(qiáng)項(xiàng)。

更關(guān)鍵的是架構(gòu)層面的變化：代理本身開始用工作流來實(shí)現(xiàn)核心循環(huán)。一個(gè)代理會(huì)話可能同時(shí)啟動(dòng)幾十個(gè)嵌套工作流，成百上千個(gè)代理并發(fā)運(yùn)行時(shí)，實(shí)例創(chuàng)建速度從"每秒幾次"跳到了"每秒幾千次"。

Cloudflare的Agents SDK集成加速了這一趨勢(shì)。代理可以實(shí)時(shí)獲取工作流進(jìn)度，形成雙向反饋。隨著Project Think的發(fā)布，這個(gè)速度只會(huì)更快。

數(shù)字背后的架構(gòu)重構(gòu)

面對(duì)這種壓力，Cloudflare公布了新的性能上限：

? 并發(fā)實(shí)例數(shù)：4,500 → 50,000（11倍提升）
? 每秒創(chuàng)建實(shí)例：100 → 300（3倍提升）
? 單工作流隊(duì)列深度：100萬 → 200萬（2倍提升）

這些數(shù)字不是簡(jiǎn)單的擴(kuò)容，而是控制平面的徹底重寫。

V1架構(gòu)中，單個(gè)Durable Object（持久化對(duì)象）充當(dāng)整個(gè)賬戶的中央注冊(cè)表和協(xié)調(diào)器。這在人類速度下沒問題，但面對(duì)機(jī)器速度時(shí)成了瓶頸。

V2拆成了兩個(gè)新組件，實(shí)現(xiàn)水平擴(kuò)展。所有客戶在零停機(jī)的情況下完成了遷移——這意味著Cloudflare在重構(gòu)核心架構(gòu)的同時(shí)，還要保證線上流量不受影響。

為什么"持久化"成了代理時(shí)代的剛需

Workflows的核心設(shè)計(jì)哲學(xué)在原文中寫得很清楚：每個(gè)步驟獨(dú)立可重試、可暫停等人機(jī)交互、故障不丟進(jìn)度。這三點(diǎn)在代理場(chǎng)景下變得至關(guān)重要。

代理不像傳統(tǒng)API調(diào)用那樣"請(qǐng)求-響應(yīng)"即結(jié)束。它們可能在第5步等待用戶確認(rèn)郵件，在第12步等外部系統(tǒng)回調(diào)，在第20步因?yàn)橄掠畏?wù)超時(shí)自動(dòng)重試。如果中間服務(wù)器重啟，人類可以刷新頁面重新登錄，代理卻需要底層引擎幫它"記住"剛才做到哪了。

Cloudflare把這叫作"durable harnesses"（持久化 harness）——工作流成了代理的"生命維持系統(tǒng)"，確保這些自主運(yùn)行的程序不會(huì)中途"猝死"或"失憶"。

一個(gè)典型的工作流代碼結(jié)構(gòu)展示了這種設(shè)計(jì)：

步驟1：調(diào)用API獲取數(shù)據(jù)
步驟2：等待"approval"類型事件，最長(zhǎng)等24小時(shí)
步驟3：處理并存儲(chǔ)結(jié)果

第二步的等待是代理時(shí)代的典型模式。代理可以去做別的事，工作流引擎幫它守著這個(gè)"坑位"，事件到來時(shí)自動(dòng)喚醒繼續(xù)執(zhí)行。

這對(duì)開發(fā)者意味著什么

性能提升只是表象，更深層的信號(hào)是：云廠商正在重新劃定"基礎(chǔ)設(shè)施"的邊界。

傳統(tǒng)的無服務(wù)器函數(shù)（Serverless Functions）假設(shè)執(zhí)行是短暫的、無狀態(tài)的。但代理需要狀態(tài)、需要持久化、需要跨時(shí)間的協(xié)調(diào)能力。這推動(dòng)Cloudflare把工作流引擎從"輔助工具"升級(jí)為"代理的基礎(chǔ)設(shè)施層"。

對(duì)構(gòu)建AI應(yīng)用的開發(fā)者來說，選擇執(zhí)行環(huán)境時(shí)多了一個(gè)關(guān)鍵考量：你的代理能"活"多久？能記住多少？能同時(shí)養(yǎng)多少個(gè)？

Cloudflare的答案很明確：5萬個(gè)并發(fā)實(shí)例，每個(gè)可以等上數(shù)天，每秒還能新增300個(gè)。這個(gè)規(guī)格已經(jīng)足以支撐相當(dāng)規(guī)模的自動(dòng)化代理集群。

但這也引出一個(gè)開放的問題：當(dāng)代理開始以機(jī)器速度批量創(chuàng)建工作流，傳統(tǒng)的計(jì)費(fèi)模式、調(diào)試工具、監(jiān)控體系是否還跟得上？Cloudflare沒有透露遷移后的單位成本變化，但架構(gòu)層面的復(fù)雜度顯然在上升。

如果你的AI代理明天需要同時(shí)啟動(dòng)一萬個(gè)長(zhǎng)時(shí)任務(wù)，你現(xiàn)在用的基礎(chǔ)設(shè)施，真的能接住嗎？