Google 為佢嘅分散式資料庫 Spanner 加咗一個新功能：原生訊息佇列（Message Queue）。成件事嘅核心，就係將「更新資料庫」同「派送後續任務」呢兩個動作，塞進同一筆交易入面。要嘛一齊成功，要嘛一齊取消，唔容許出現「改咗單但任務冇走」嘅尷尬局面。
點解要咁做？
AI 代理（Agent）做嘢，例如批退款、調整庫存、或者將工作轉交俾其他代理，通常唔止改一下資料庫紀錄咁簡單，仲要把接下來要做嘅嘢送進訊息佇列。之前呢兩個動作由唔同系統各自處理，就容易出現問題：資料改咗，但任務冇送出去；或者任務送咗出去，資料庫改動卻喺最後一刻失敗。開發團隊就必須額外寫代碼去對齊兩邊嘅狀態，非常麻煩。
Spanner 而家將訊息佇列直接嵌入資料庫。舉例嚟説，一個 AI 代理核准退款，可以喺同一筆交易內同時將訂單狀態改做「已核准」，並將實際執行退款嘅任務加入佇列。整筆交易成功提交，兩樣嘢先會一齊生效；交易失敗，兩樣都唔會生效。
執行任務嘅程式可以透過 SQL 由佇列取出任務，完成後再更新處理結果並移除訊息。系統亦支援指定任務稍後才開始執行，例如等待主管核准一段時間後自動升級處理；如果代理需要較長時間呼叫外部服務或完成多步驟工作，處理端可以延長持有任務嘅時間。
「至少一次」嘅限制
要注意，Spanner 嘅訊息可靠性保證係「至少送達一次」（at-least-once delivery）。呢個意思係，當網絡或執行出現失敗時，同一項工作可能會再次出現。對於退款、付款呢種唔可以重複執行嘅動作，應用程式仍然需要加入防止重複處理嘅設計，唔可以預設所有外部操作都只會執行一次。
原生訊息佇列目前提供俾 Spanner Enterprise 同 Enterprise Plus 版本。另外，Spanner 既有嘅 Change Streams 功能繼續負責持續擷取資料變化俾下游系統使用，兩者定位唔同。
阿調搞兩下
呢個更新好「基建」。佢唔會令邊個模型變勁，但會令 AI 代理做嘢時少出錯、少執手尾。當代理要改資料又要觸發後續動作，之前呢兩步之間嘅縫隙就係 bug 嘅温床。而家 Google 將呢個縫隙用交易機制封埋，係一個務實嘅選擇。但「至少送達一次」嘅設計亦提醒我哋：基建再好，應用層嘅冪等設計（idempotency）仍然係你嘅責任，唔好將呢個推俾資料庫。
阿調｜深度調教
