1999年《自然》雜志的一項實驗，讓幾只老鼠成了云計算的祖師爺。研究人員把電極陣列植入它們的大腦運動皮層，實時解碼神經(jīng)信號，直接驅(qū)動機械臂——沒有肌肉參與，沒有傳統(tǒng)運動通路，純粹靠"事件"觸發(fā)動作。26年后，這套邏輯被AWS、Google、Azure、IBM原封不動搬進了數(shù)據(jù)中心。

區(qū)別在于，現(xiàn)在的"神經(jīng)信號"變成了存儲桶里一個新上傳的文件，"機械臂"換成了大模型Agent。云廠商們各自起了花哨的名字，但剝開來看，四層架構(gòu)一模一樣：事件源、事件路由器、執(zhí)行編排、可觀測性。這不像競爭，更像集體交作業(yè)。

存儲桶成了新的"大腦皮層"

Amazon S3、IBM Cloud Object Storage、Azure Blob Storage、Google Cloud Storage——四大廠商的對象存儲產(chǎn)品，本質(zhì)上都是同一套設(shè)計：被動等待，主動通知。文件上傳完成的那一刻，存儲系統(tǒng)不會自己跑代碼，而是發(fā)射一個離散信號。這和老鼠大腦里的神經(jīng)元放電沒有區(qū)別：不是持續(xù)掃描環(huán)境，而是狀態(tài)變了才說話。

這種"懶"是刻意的。持續(xù)輪詢（polling）像一個人每隔幾秒就問"好了嗎"，事件驅(qū)動則是對方主動拍你肩膀。后者省下的計算資源，在規(guī)模放大后不是小數(shù)目。AWS的S3事件通知、Azure的Event Grid、Google的Eventarc、IBM的Event Notifications，干的都是"拍肩膀"的活——但拍法略有不同。

AWS EventBridge的過濾規(guī)則可以細到JSON字段級別，支持內(nèi)容型路由；Azure Event Grid更偏向HTTP推送，和自家函數(shù)計算綁定深；Google Eventarc去年才補上對Cloud Storage的直接支持，之前得繞Pub/Sub；IBM的Event Notifications則試圖用一套API覆蓋郵件、短信、Slack和Webhook，略顯貪多。這些差異對架構(gòu)選型有真實影響，但核心能力趨同：解耦生產(chǎn)者和消費者，讓存儲保持"單純"。

路由層的暗戰(zhàn)：誰在控制"意圖"

事件從存儲桶發(fā)出后，需要被路由到能"理解"它的Agent。這一步是廠商爭奪的焦點，因為誰控制了路由邏輯，誰就能把自己的計算服務(wù)塞進去。AWS EventBridge的Schema Registry試圖建立事件標準的話語權(quán)；Azure把Event Grid和Logic Apps、Functions焊在一起，降低跳轉(zhuǎn)成本；Google則把Eventarc和Cloud Run、GKE深度集成，押注容器化執(zhí)行。

路由層的真正價值不是傳送，是決策前置。一個PDF上傳事件，該觸發(fā)OCR提取、病毒掃描、還是直接送進RAG管道？這個判斷如果放在Agent里做，每次都要喚醒一個可能很重的執(zhí)行環(huán)境；如果在路由層用規(guī)則過濾，就能省掉大量無效啟動。四大廠商都在推"事件模式匹配"能力，但實現(xiàn)深度參差不齊。AWS支持用JSON Path寫復雜過濾，Azure的邏輯應(yīng)用連接器更豐富，Google和IBM相對輕量。

這種差異暴露了各家對"Agent"定義的分歧。AWS把Bedrock和SageMaker往EventBridge后面接，強調(diào)模型即服務(wù)；Microsoft的Copilot生態(tài)更激進，想把Office 365的事件流也納進Event Grid；Google的Vertex AI和Eventarc的集成還在追趕；IBM的watsonx則選擇先守住金融、醫(yī)療等合規(guī)場景，不急著鋪量。

編排層：從"跑起來"到"別跑崩"

事件被路由到Agent后，真正的計算才開始。這一步的復雜度被嚴重低估——不是"調(diào)個API"那么簡單，是狀態(tài)管理、重試策略、并發(fā)控制、成本封頂?shù)娜坠こ獭WS Step Functions、Azure Logic Apps、Google Workflows、IBM Cloud Functions，名義上是"工作流編排"，實際是在解決同一個問題：如何讓AI Agent在事件觸發(fā)下可靠運行，又不至于把賬單跑穿。

重試語義是這里的隱形戰(zhàn)場。S3事件通知原生不支持死信隊列，得搭SQS或Lambda才完整；Azure Event Grid內(nèi)置重試和死信，但超時窗口固定；Google Eventarc的重試策略和Cloud Run的實例生命周期糾纏在一起，調(diào)試起來像解毛線；IBM的OpenWhisk（Functions底層）冷啟動延遲在四大里偏高，對事件驅(qū)動的低延遲場景不太友好。

可觀測性 layer 是最容易被砍預算、也是出事時最后悔砍的地方。CloudWatch、Azure Monitor、Google Cloud Operations、IBM Cloud Monitoring，都能追蹤事件流，但 granularity 差異大。AWS的X-Ray可以追蹤跨服務(wù)調(diào)用鏈，EventBridge最近加了事件歸檔和重放，方便調(diào)試；Azure的Application Insights對Logic Apps的可視化更細；Google的Cloud Trace和自家服務(wù)集成深，第三方工具接入麻煩；IBM的監(jiān)控儀表盤相對樸素，企業(yè)客戶往往得另購Splunk或Datadog。

老鼠教會我們的事

回到1999年的那只老鼠。它的價值不在于"用腦控機械臂"這個噱頭，在于證明了一件事：智能行為可以從離散信號的解碼中涌現(xiàn)，不需要中央控制器持續(xù)發(fā)號施令。這個洞見被云廠商們各自獨立地重新發(fā)現(xiàn)，最終收斂到同一套四層架構(gòu)。

這種收斂不是抄襲，是約束條件下的最優(yōu)解。對象存儲的事件語義、Serverless的執(zhí)行模型、按調(diào)用計費的商業(yè)模式，共同逼出了這個形狀。差別只在于各家對"Agent"的野心大小——AWS想當你的AI基礎(chǔ)設(shè)施，Microsoft想鉆進你的辦公軟件，Google還在猶豫要不要把搜索的護城河拆一塊出來，IBM則守著高客單價的企業(yè)客戶慢慢磨。

一個值得玩味的細節(jié)：AWS EventBridge在2023年悄悄上線了Event Replay功能，可以把過去90天的事件重新注入系統(tǒng)。官方文檔說是為了"調(diào)試和審計"，但明眼人看得出，這是在為Agent的"經(jīng)驗學習"鋪路——讓AI反復咀嚼歷史事件，像那只老鼠反復訓練神經(jīng)回路一樣。云廠商們嘴上不說，身體都很誠實地朝著同一個方向挪動。

你的存儲桶里今天產(chǎn)生了多少事件？其中有多少被路由到了真正該去的地方，又有多少只是在日志里沉睡，等著某天被重新喚醒、重新解讀？