1999年那只控制机械臂的老鼠，把云厂商逼出了同一套架构

1999年《自然》杂志的一项实验，让几只老鼠成了云计算的祖师爷。研究人员把电极阵列植入它们的大脑运动皮层，实时解码神经信号，直接驱动机械臂——没有肌肉参与，没有传统运动通路，纯粹靠"事件"触发动作。26年后，这套逻辑被AWS、Google、Azure、IBM原封不动搬进了数据中心。

区别在于，现在的"神经信号"变成了存储桶里一个新上传的文件，"机械臂"换成了大模型Agent。云厂商们各自起了花哨的名字，但剥开来看，四层架构一模一样：事件源、事件路由器、执行编排、可观测性。这不像竞争，更像集体交作业。

存储桶成了新的"大脑皮层"

Amazon S3、IBM Cloud Object Storage、Azure Blob Storage、Google Cloud Storage——四大厂商的对象存储产品，本质上都是同一套设计：被动等待，主动通知。文件上传完成的那一刻，存储系统不会自己跑代码，而是发射一个离散信号。这和老鼠大脑里的神经元放电没有区别：不是持续扫描环境，而是状态变了才说话。

这种"懒"是刻意的。持续轮询（polling）像一个人每隔几秒就问"好了吗"，事件驱动则是对方主动拍你肩膀。后者省下的计算资源，在规模放大后不是小数目。AWS的S3事件通知、Azure的Event Grid、Google的Eventarc、IBM的Event Notifications，干的都是"拍肩膀"的活——但拍法略有不同。

AWS EventBridge的过滤规则可以细到JSON字段级别，支持内容型路由；Azure Event Grid更偏向HTTP推送，和自家函数计算绑定深；Google Eventarc去年才补上对Cloud Storage的直接支持，之前得绕Pub/Sub；IBM的Event Notifications则试图用一套API覆盖邮件、短信、Slack和Webhook，略显贪多。这些差异对架构选型有真实影响，但核心能力趋同：解耦生产者和消费者，让存储保持"单纯"。

路由层的暗战：谁在控制"意图"

事件从存储桶发出后，需要被路由到能"理解"它的Agent。这一步是厂商争夺的焦点，因为谁控制了路由逻辑，谁就能把自己的计算服务塞进去。AWS EventBridge的Schema Registry试图建立事件标准的话语权；Azure把Event Grid和Logic Apps、Functions焊在一起，降低跳转成本；Google则把Eventarc和Cloud Run、GKE深度集成，押注容器化执行。

路由层的真正价值不是传送，是决策前置。一个PDF上传事件，该触发OCR提取、病毒扫描、还是直接送进RAG管道？这个判断如果放在Agent里做，每次都要唤醒一个可能很重的执行环境；如果在路由层用规则过滤，就能省掉大量无效启动。四大厂商都在推"事件模式匹配"能力，但实现深度参差不齐。AWS支持用JSON Path写复杂过滤，Azure的逻辑应用连接器更丰富，Google和IBM相对轻量。

这种差异暴露了各家对"Agent"定义的分歧。AWS把Bedrock和SageMaker往EventBridge后面接，强调模型即服务；Microsoft的Copilot生态更激进，想把Office 365的事件流也纳进Event Grid；Google的Vertex AI和Eventarc的集成还在追赶；IBM的watsonx则选择先守住金融、医疗等合规场景，不急着铺量。

编排层：从"跑起来"到"别跑崩"

事件被路由到Agent后，真正的计算才开始。这一步的复杂度被严重低估——不是"调个API"那么简单，是状态管理、重试策略、并发控制、成本封顶的全套工程。AWS Step Functions、Azure Logic Apps、Google Workflows、IBM Cloud Functions，名义上是"工作流编排"，实际是在解决同一个问题：如何让AI Agent在事件触发下可靠运行，又不至于把账单跑穿。

重试语义是这里的隐形战场。S3事件通知原生不支持死信队列，得搭SQS或Lambda才完整；Azure Event Grid内置重试和死信，但超时窗口固定；Google Eventarc的重试策略和Cloud Run的实例生命周期纠缠在一起，调试起来像解毛线；IBM的OpenWhisk（Functions底层）冷启动延迟在四大里偏高，对事件驱动的低延迟场景不太友好。

可观测性 layer 是最容易被砍预算、也是出事时最后悔砍的地方。CloudWatch、Azure Monitor、Google Cloud Operations、IBM Cloud Monitoring，都能追踪事件流，但 granularity 差异大。AWS的X-Ray可以追踪跨服务调用链，EventBridge最近加了事件归档和重放，方便调试；Azure的Application Insights对Logic Apps的可视化更细；Google的Cloud Trace和自家服务集成深，第三方工具接入麻烦；IBM的监控仪表盘相对朴素，企业客户往往得另购Splunk或Datadog。

老鼠教会我们的事

回到1999年的那只老鼠。它的价值不在于"用脑控机械臂"这个噱头，在于证明了一件事：智能行为可以从离散信号的解码中涌现，不需要中央控制器持续发号施令。这个洞见被云厂商们各自独立地重新发现，最终收敛到同一套四层架构。

这种收敛不是抄袭，是约束条件下的最优解。对象存储的事件语义、Serverless的执行模型、按调用计费的商业模式，共同逼出了这个形状。差别只在于各家对"Agent"的野心大小——AWS想当你的AI基础设施，Microsoft想钻进你的办公软件，Google还在犹豫要不要把搜索的护城河拆一块出来，IBM则守着高客单价的企业客户慢慢磨。

一个值得玩味的细节：AWS EventBridge在2023年悄悄上线了Event Replay功能，可以把过去90天的事件重新注入系统。官方文档说是为了"调试和审计"，但明眼人看得出，这是在为Agent的"经验学习"铺路——让AI反复咀嚼历史事件，像那只老鼠反复训练神经回路一样。云厂商们嘴上不说，身体都很诚实地朝着同一个方向挪动。

你的存储桶里今天产生了多少事件？其中有多少被路由到了真正该去的地方，又有多少只是在日志里沉睡，等着某天被重新唤醒、重新解读？