代理型 AI 要先補資料管線

代理型 AI 在 demo 裡很帥。模型接任務、呼叫工具、回答案，10 秒搞定。可是一碰到付款、訂單、通知、審核，事情就開始變髒。Oracle 的資料庫團隊直接點出一個現實：真正上線的 agentic 系統，不能只靠模型，還要靠交易式訊息與整合式資料庫。

講白了，這類系統本質上就是分散式系統。中間多了一個 LLM，出錯點只會更多。只要有一筆事件漏掉、重送、順序亂掉，原本像助理的 AI，就可能變成客服地獄製造機。

Demo 很順，正式環境很吵

Demo 通常很單純。模型只碰一個工具、一份資料、一條流程。你看起來會覺得，哇，這東西蠻猛的。

正式環境完全不是這樣。一次任務可能同時碰到 PostgreSQL、向量資料庫、物件儲存、訊息佇列，還有好幾個 API。每多一層，就多一次延遲、重試、部分失敗、排序錯誤。

Oracle 在 Oracle Database Blog 的說法很直白。代理型 AI 不是單一模型問題，而是資料一致性問題。當系統能做出實際副作用時，原本藏在角落的小瑕疵，會被放大成事故。

• 一個 agent 流程常跨 4 類元件：模型、工具、資料庫、訊息系統
• 每多一個 hop，就多一次失敗機率
• 很多問題不是模型錯，而是資料不同步
• 流量一放大 10 倍，重送與重複事件就會冒出來

交易式訊息，重點是一起成功或一起失敗

交易式訊息的核心很簡單。資料庫提交成功，事件也一起成立。資料庫失敗，事件就不會送出去。這件事聽起來很土，但在 AI 工作流裡超實用。

因為 agent 常常不是只回文字。它可能會核准退款、更新訂單、發通知、改權限。這些動作如果分開做，就很容易出現「資料寫進去了，事件沒出去」的情況。

Oracle 這篇文章的論點是，把訊息當成交易的一部分，會比事後補送穩得多。你不用再賭事件匯流排有沒有跟上，也不用在凌晨兩點抓重複通知的 bug。

“The database is the only place where you can atomically update state and publish the event that describes that state change.” — Tim Hall, Oracle

這句話很硬，但也很實際。代理型 AI 不需要更多玄學。它需要更少會互相打架的元件。當 agent 真的會動到金流或庫存，原子性就不是課本名詞，而是事故保險。

這也關係到稽核。像理賠、費用核銷、客戶資料更新這些流程，都需要可追溯紀錄。交易式設計可以讓你知道，哪一步先發生，哪一步沒發生。

整合式資料庫，少搬幾次資料就少幾次出包

Oracle 主打的另一個重點，是 Oracle Database 這種 converged database。意思是，關聯式資料、文件、向量、事件、分析工作，不用拆成一堆獨立產品硬湊。

這種做法的好處，不只是少裝幾套軟體。更重要的是少了同步工作。資料一旦分散到不同系統，就會開始有快取、同步 job、ETL、重建索引、延遲寫入這些麻煩事。

你如果看很多團隊現在的堆疊，通常是這樣：PostgreSQL 放交易資料，Redis 放快取，Apache Kafka 管事件，再加一套向量資料庫做 RAG。這不是不能做，但維運成本真的不低。

• Oracle Database：把交易、分析、向量等工作放在同一系統
• PostgreSQL：彈性高，但常要外掛或外部服務補齊 AI 工作流
• Apache Kafka：事件管線很強，但它還是獨立系統
• Redis：速度快，適合快取，不是系統主帳本

我覺得這裡沒有標準答案。整合式資料庫可以簡化架構，但也把風險集中到單一供應商與單一平台。你要的是少出錯，還是要組件自由度，這要看團隊規模與 SLA。

如果你們是小團隊，少一個同步層，常常就少一個夜晚。反過來說，如果你們已經有很成熟的事件平台與資料治理，模組化架構還是有它的價值。

競品怎麼比，差別就在資料一致性

代理型 AI 真正麻煩的地方，不是模型會不會講話，而是它能不能安全地做事。只要 agent 會寫入資料、發事件、改狀態，你就得先問自己：這條路徑能不能原子化。

很多團隊會先想到把 LLM 調得更準。這方向沒錯，但常常不夠。因為錯誤很多時候不是推理錯，而是資料層斷掉。模型答對了，系統還是可能因為重送事件而重複扣款。

Oracle 這次的主張，等於把焦點拉回資料庫。它不是說模型不重要，而是說模型外面的資料管線，才是正式上線時最常炸的地方。

• 單一資料庫方案：一致性高，但平台綁定較深
• PostgreSQL + Kafka：彈性高，但整合與維運成本高
• Redis + 向量資料庫 + 主資料庫：速度快，但資料複製多
• 事件驅動微服務：擴充性好，但除錯難度也高

如果拿實務來看，差別常常不是 5% 或 10%。而是故障時你要花 20 分鐘修，還是 2 小時對帳。前者是工程問題，後者是營運問題。

所以我會把這場討論看成一個很務實的選擇題。你要的是更多工具，還是更少不同步。對 agentic AI 來說，後者通常比較值錢。

這其實是分散式系統老問題

代理型 AI 只是把老問題包了一層新皮。以前是微服務、事件流、資料同步。現在只是多了一個會講人話的中介。

這也解釋了為什麼很多 AI 專案在 demo 階段很順，到了正式環境就卡住。不是模型突然變笨，而是系統開始面對真實世界。真實世界有重試、有延遲、有人工審核，也有一堆例外流程。

所以，這波討論其實是在提醒大家一件事：AI 架在什麼資料底座上，比模型名字更重要。你如果底層資料亂，GPT、Claude、LLM 再強，也只是把錯誤說得更順。

很多企業現在急著導入 agent。我反而覺得，先看資料治理比較實在。先把事件、交易、審核、稽核軌跡整理好，再來談 agent 自動化，成功率會高很多。

這裡沒有什麼神秘公式。就是工程基本功。資料要一致，事件要可追，失敗要能回復。聽起來很老派，但真的很管用。

先把交易邊界畫好，再談 AI 自動化

如果你現在在做 agentic AI，我會建議先畫出三件事。第一，agent 能碰哪些資料。第二，哪些動作一定要原子化。第三，失敗後誰負責補救。

Oracle 這篇文章的重點，不是叫大家全換成同一套產品。它是在提醒：當 agent 開始做事，資料管線不能再用 demo 思維。你要的是可預期，不是看起來很炫。

我的預測很簡單。接下來 12 到 18 個月，會有更多團隊把 agent 從聊天視窗，搬進訂單、客服、理賠、採購、內部審批。到那時候，誰的交易邊界畫得清楚，誰就比較少半夜救火。

如果你現在也在做這種系統，先問自己一句：你的 agent 真的會做事嗎，還是只是會講得很像會做事？