 |
從被動問數到實時行動，構建事件驅動的企業級智能體
作者：吳敏達，IBM 中國科技事業部數據與人工智能資深技術專家
北京2026年9月7日 /美通社/ -- 隨著生成式 AI 和智能體加速進入企業核心流程，數據基礎正在發生深刻變化。企業不僅需要從歷史數據和知識庫中獲取洞察，更需要讓智能體及時理解正在發生的業務事件，并在治理邊界內采取行動。圍繞這一目標，IBM Confluent 正從實時數據流平臺進一步演進為面向 AI 的實時上下文與行動底座。本文結合實際業務場景，梳理這一能力演進及其帶來的業務價值。
IBM Confluent 面向 AI 場景的能力演進
AI 時代的數據挑戰：從歷史洞察走向事件驅動
越來越多的企業正在利用 AI 加速業務流程并推動業務創新。傳統路徑通常包括兩類：一類是建設數據湖倉，從歷史結構化數據中提取業務洞察；另一類是通過檢索增強生成（RAG）構建知識庫，為智能體提供非結構化知識。前者回答經營數據發生了什么以及為什么發生，后者幫助智能體理解制度、文檔和經驗知識。
IBM 提出的"智慧經營"理念，與業界常說的"問數"路徑相近，即從指標查詢出發，進一步分析變化原因、觀察業務動態、定位根因并采取行動。這仍是當前企業智能化應用的重要模式。
AI 應用的一個關鍵躍遷，是從"回答問題"轉向"實現目標" —— 從"用戶提問、模型回答"的交互模式，轉向"業務事件發生、智能體實時感知并采取受治理的行動"的"事件驅動 AI"（Event-Driven AI）模式。其核心是讓持續流動的業務數據直接成為智能體的實時上下文，使智能體能夠感知業務變化并及時響應。在這一閉環中，智能體不再只依賴靜態知識，而是直接獲取經過篩選和關聯的實時事件。
作為IBM近年的重磅收購之一，IBM Confluent 可結合規則、復雜事件處理、機器學習和大模型能力，從海量數據中識別值得關注的信號，而不是把全部原始數據交給智能體。關鍵信號交由智能體研判后，智能體可以觸發相應行動，處置結果再寫回事件流，用于后續反饋、復盤和規則優化。由此形成"實時感知、上下文供給、智能決策、業務行動、反饋優化"的完整閉環。
這一模式帶來兩項關鍵轉變。其一，智能體由實時流數據觸發，而不是等待用戶提問；其二，AI 的價值從"回答問題"延伸到"執行操作"。
IBM如何重塑實時智能：貫通實時數據、智能體與 AI 輔助開發
在支撐上述轉變的技術架構中，Confluent 作為數據流平臺，確保賬戶、客戶、采購、交易、點擊流等業務數據通過基于 Kafka Connect 的連接能力持續接入。平臺在事件之間維護可關聯的業務上下文，并以事件驅動方式將經過處理的數據推送至右側的智能體平臺。IBM watsonx Orchestrate 則負責接收實時上下文，完成推理、編排和行動，并對智能體運行過程進行可觀測、可控制和可優化的閉環管理。
實時數據流與智能體平臺的總體架構
架構的底座是 AI 輔助開發能力。隨著 AI Coding 逐步進入企業研發體系，數據處理邏輯和智能體應用都可以通過 AI 輔助方式構建。IBM Bob 可輔助貫通從 Confluent 流處理到智能體開發的流程，支持數據處理邏輯、應用代碼和智能體能力的端到端開發。
DAY 1 與 DAY 2：構建實時處置和持續優化閉環
以銀行信用卡欺詐檢測為例，信用卡交易數據以流式方式接入 Confluent。整個業務閉環可以劃分為 DAY 1 和 DAY 2 兩個相互銜接的
信用卡欺詐檢測的 DAY 1 與 DAY 2 閉環
信用卡欺詐檢測：從實時篩查到決策反思
信用卡交易持續寫入 Kafka Topic，數據規模巨大，不適合直接全量交由大模型處理。更合理的方式是先使用 Apache Flink 結合已知業務規則進行流式篩查。例如，當同一賬戶在短時間內出現在不同地點且交易金額明顯增長時，系統可將其標記為異常候選。通過規則和流式分析，可以將千萬級交易壓縮為數千條高價值信號，再交由交易研究智能體進一步判斷。
智能體獲得異常數據后，可結合商戶觀察名單、客戶交易歷史和賬戶關系進行綜合研判，并按風險等級采取處置措施。高風險交易可觸發凍結或止付并向客戶發送通知；較低風險交易可進入二次確認流程；所有觸發規則的交易和處置動作均保留審計日志，以確保全流程可追溯。這構成了 DAY 1 的完整鏈路，即從事件流、規則過濾到智能行動。
DAY 2 的核心是反思與優化。智能體的決策結果寫回 Confluent 后，調查智能體可以借助基于模型上下文協議（MCP）的工具，讀取前一周期的交易數據、規則命中情況、爭議工單以及客戶溝通記錄，綜合判斷既有處置是否合理。
例如，一筆交易最初被判定為欺詐，后續調查卻發現客戶持有多張附屬卡，因此同一時段在不同地點出現多筆大額交易。調查智能體可以識別這一關聯，建議把"附屬卡與主卡關系"納入規則例外，從而減少誤報并改善客戶體驗。
復盤還可以發現新的風險維度。傳統規則可能只關注單一客戶和單筆交易，但某些風險集中于商戶側。若同一商戶在短時間內處理大量異常交易，系統就應增加以商戶為主體的風險檢測規則。DAY 2 通過持續回溯，幫助企業同時降低誤報與漏報。
這一復盤強調對事件發生時業務上下文的還原。湖倉仍然適合長期歷史分析、合規留存和跨域分析，但對于需要重現實時決策過程的場景，保留事件流中的時間順序、狀態變化和決策軌跡尤為重要。流式數據與湖倉并非替代關系，而是分別服務于實時行動和長期分析。
Confluent Intelligence三大核心能力：感知、供數與行動
作為Confluent平臺的關鍵組件，Confluent Intelligence 面向基于 Flink SQL 的智能體工作流，核心能力可以歸納為感知、供數和行動三個層次。
1. 感知：內置機器學習函數
Confluent 將多類機器學習能力集成到 Confluent Cloud for Apache Flink 中，使開發者能夠通過 Flink SQL 完成異常檢測、趨勢預測、情感分析和個人可識別信息檢測等任務。相關函數包括ML_DETECT_ANOMALIES（異常檢測）、ML_FORECAST（預測）、AI_SENTIMENT（情感分析）、AI_DETECT_PII（敏感信息識別）。
這些能力可以與規則及復雜事件處理結合，作為實時感知層從大規模事件流中提取高價值信號。先利用確定性規則和機器學習縮小數據范圍，再調用大模型進行復雜研判，可以兼顧效率、成本和準確性。由于大模型通常按 Token 或推理資源計費，這種分層處理方式也有助于顯著控制成本。
2. 供數：實時上下文引擎
實時上下文引擎通過 MCP（模型上下文協議）接口將 Kafka Topic 中的業務數據提供給外部智能體。啟用后，Topic 數據可被物化為面向低延遲查詢的表，智能體無需直接消費 Kafka 消息，即可通過 MCP 工具查詢訂單、庫存、設備狀態等實時業務信息，并在授權范圍內關聯多個數據主題。
對于生產數據，應遵循最小權限和職責分離原則。面向外部智能體的上下文查詢通常采用只讀方式，并結合身份認證、授權和治理策略，避免智能體直接改寫關鍵業務數據。訂單、供應商、交易和庫存等多個 Topic 可以被關聯為完整業務上下文，從而提升智能體決策質量。
3. 行動：流式智能體
Streaming Agents 使智能體能夠持續運行在事件流之上，并連接模型、工具與業務系統。通過 CREATE TOOL、CREATE AGENT、AI_RUN_AGENT 等能力，企業可以在流式工作流中定義工具、構建智能體并觸發執行。平臺還可以調用大模型對持續到來的數據進行總結、分類、翻譯或文本生成，再將結果交給下游系統。
例如，工單內容進入事件流后，可以先由大模型生成簡潔摘要，再交由運維流程處理。將三類能力串聯起來，就形成了"感知異常、提供實時上下文、觸發智能行動"的完整路徑，使 Confluent 成為企業實時運營的感知與響應基礎。
三類參考架構：從行業信號到業務行動
場景一：電信網絡異常檢測。用戶設備遙測數據和蜂窩基站指標實時流入 Confluent 后，Flink 可通過規則識別掉話等事件，再利用機器學習算法對掉話率進行異常評分，篩選出需要關注的信號。智能體進一步開展根因分析，判斷問題來自基站故障、施工干擾還是覆蓋不足，并在授權范圍內自動觸發處置。該模式也適用于制造、物聯網和設備運維等異常檢測場景。
場景二：實時產品個性化推薦。網頁端和移動端的實時點擊行為，與購物車、購買記錄和產品目錄在 Confluent 中匯聚后，可以形成持續更新的用戶偏好視圖。該視圖在用戶瀏覽過程中實時生成，并通過實時上下文引擎提供給外部智能體。大模型結合當前行為和歷史偏好生成個性化推薦，限時優惠也可以在分鐘級窗口內觸發，從而把事后分析轉化為當下行動。
場景三：AI 驅動的 IT 運維數據增強。Kubernetes 日志、Jira 工單以及存儲、操作系統和網絡日志可以持續進入 Confluent。大模型對日志和工單描述進行實時總結與增強，將關鍵信息直接推送給運維人員；在明確授權和安全控制下，智能體還可以執行擴容磁盤等標準化操作。理想狀態下，問題在工單創建前即可被識別和處理，從而減少重復工單并縮短平均修復時間。
寫在最后
隨著IBM 完成對 Confluent 的正式收購，實時數據流與 IBM 的數據管理、集成和企業基礎設施能力進一步結合，流式數據在企業 AI 戰略中的位置更加突出。其主要組件（如Confluent Intelligence 和 Confluent Connector）結合 Kafka + Flink 的強大底座，可以幫助企業從被動的"問數分析"走向主動的"實時行動"，讓 AI 真正融入持續變化的業務過程。
