周三下午，你正在用某款A(yù)I繪圖工具，輸入一串提示詞，點擊“生成”，然后盯著屏幕等了幾秒鐘……沒反應(yīng)。十幾秒過去了，頁面開始卡頓。四十秒后，瀏覽器彈出“請求超時”。你刷新頁面，發(fā)現(xiàn)剛剛充值的積分已經(jīng)扣了，但圖片庫空空如也。

這個場景并不罕見。很多團隊在做AI圖像生成功能時，第一反應(yīng)就是做成“用戶輸提示詞→等結(jié)果→返回圖片”的直筒子流程。Demo階段這么做沒毛病，可一旦進入生產(chǎn)環(huán)境，這套同步邏輯就像紙糊的腳手架，根本扛不住真實流量。

核心問題在于，圖像生成的時間跨度太大了——短則幾秒，長則幾分鐘。而服務(wù)商那邊也不是每次都痛痛快快把圖畫好塞給你：有些先把任務(wù)編號扔回來，讓你自己過會兒去拿成品；有的走網(wǎng)絡(luò)鉤子推送結(jié)果；還有的只告訴你“去某個接口輪詢吧”。如果運氣不好，請求可能在中途掛掉、超時，或者圖片生成完了但用戶早就關(guān)掉了頁面。

所以，把AI圖像生成設(shè)計成異步工作流，幾乎是所有生產(chǎn)級產(chǎn)品的必選項。這也是我在開發(fā)Image 2——一個多模型圖像生成與編輯平臺——時采用的架構(gòu)思路。

先看最直觀的做法：用戶請求直接打到接口路由，路由把任務(wù)交給AI服務(wù)商，服務(wù)商返回結(jié)果再原路傳回。這套鏈路簡單明了，但埋著好幾個坑。超文本傳輸協(xié)議的請求窗口撐不住長耗時，一旦超時，前端拿不到任何東西；想重試？很容易生成重復(fù)任務(wù)，白白浪費算力和成本；前端界面的響應(yīng)速度完全綁死在服務(wù)商的處理延遲上；扣費邏輯嵌在同步流程里，防護起來極其頭疼；服務(wù)商返回的圖片鏈接多半是臨時性的，過幾天就打不開；而且請求一旦結(jié)束再失敗，幾乎沒有補救機會。

稍微靠譜一點的方案，是把“用戶請求”和“生成工作”拆成兩條線。大致流程變成這樣：用戶發(fā)出請求后，系統(tǒng)先建一條生成記錄，接著把消息推進隊列，后臺工作進程接管后續(xù)——向服務(wù)商提交任務(wù)、等待網(wǎng)絡(luò)鉤子或輪詢拿到結(jié)果、把最終素材存入自家存儲、刷新這條記錄的狀態(tài)。而用戶端在創(chuàng)建任務(wù)之后立刻就能拿到一個狀態(tài)回執(zhí)，界面可以展示“排隊中”“處理中”“已完成”或者“失敗”。所有慢動作都在后臺發(fā)生，不影響用戶繼續(xù)操作。

這種異步模式給系統(tǒng)留出了足夠多的緩沖空間。服務(wù)商處理慢，任務(wù)就掛在“處理中”不動；服務(wù)商接口掛了，系統(tǒng)可以把任務(wù)標(biāo)成失敗，自動退回消費額度；網(wǎng)絡(luò)鉤子推送沒收到，還有定期輪詢來兜底；即便鉤子和輪詢同時拿到了同一張成圖，終端狀態(tài)也能做到冪等——多次觀測到同一個結(jié)果的情況下，系統(tǒng)不會重復(fù)結(jié)算。最后這點特別要緊，生產(chǎn)環(huán)境中同一份生成結(jié)果被看到兩次，是完全可能發(fā)生的事情。

狀態(tài)模型不用一上來就搞太復(fù)雜。五個狀態(tài)足夠起步：創(chuàng)建、排隊、處理、完成、失敗。創(chuàng)建意味著請求已被接收，排隊表示后臺任務(wù)已排期，處理是服務(wù)商已經(jīng)開始跑活兒，完成代表最終素材已經(jīng)入庫可用，失敗就說明這條任務(wù)走不下去了。關(guān)鍵規(guī)則只有一條：終端狀態(tài)必須設(shè)防。一旦任務(wù)被標(biāo)記為完成或失敗，重試機制和重復(fù)回調(diào)都不能再把同樣的結(jié)果應(yīng)用一次。

還有一個容易被忽略的環(huán)節(jié)：圖片該存哪兒？不少AI服務(wù)商返回的是臨時的統(tǒng)一資源定位符，可能幾天后就失效，而且文件掌控權(quán)在服務(wù)商手里。做正式產(chǎn)品時，更穩(wěn)妥的做法是拿到結(jié)果后，立刻把圖片文件拉取下來存入自有存儲體系，同時更新記錄里的素材引用。這樣一來，用戶下次打開作品集時，不會看到成片的裂圖；計費系統(tǒng)也能基于自己庫里的生成記錄來核賬，不必依賴外部鏈接的存活狀態(tài)。

說到底，同步生成和異步生成的差別，不在于技術(shù)炫不炫，而在于容錯能力能不能撐住真實用戶場景。Demo可以走直線，產(chǎn)品必須繞彎——這個彎，就是消息隊列、狀態(tài)流轉(zhuǎn)和結(jié)果歸倉構(gòu)成的異步三角。如果你的項目正在從原型邁向生產(chǎn)，把生成鏈路從“請求-響應(yīng)”改成“創(chuàng)建任務(wù)-后臺處理-狀態(tài)反饋”，可能會省掉往后相當(dāng)多的運維頭疼。