凌晨?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è)施,真的能接住嗎?
特別聲明:以上內(nèi)容(如有圖片或視頻亦包括在內(nèi))為自媒體平臺(tái)“網(wǎng)易號(hào)”用戶上傳并發(fā)布,本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.