把 AI agent 接進事件溯源的詐欺偵測

066Divakar Kumar（FlyersSoft）21:362026-07-30 上架

Let's integrate AI Agents in Event-Sourced Systems — Divakar Kumar, FlyersSoft

Divakar Kumar 以即時詐欺偵測為例，說明既有的事件溯源系統怎麼在規則與 ML 之外加一層 agent，只處理灰色地帶的交易。

這場講了什麼

• Agent 不只是聊天機器人：Divakar Kumar 認為 agent 的價值在套進企業既有的業務流程，這場拿即時詐欺偵測當題目，架構則是公司過去幾年已經投資的那一套。
• 規則和 ML 之外多一層 agent：原本的規則引擎與第三方訓練的 ML 模型處理大部分交易，只有落在灰色地帶、分不出是詐欺還是正常的交易，才交給第二層的 agent 處理。
• 把跨領域的即時資料餵給 agent：交易、帳戶、裝置、付款各自是獨立的 bounded context，彼此不共享資料。做法是用 CDC 或訊息佇列把各 context 的事件送進 projection 層，由 worker 整理成一個 semantic layer（materialized view）給 agent 查。
• 事件溯源提供資料來源：使用者的指令一律當作事實附加進 Cosmos DB 事件儲存，不改狀態；change feed 再把變更推到不同的 read model 與 projection 層。
• 短記憶與跳出迴圈的條件：交易處理必須在 500 毫秒以內完成，所以 agent 只用記憶體內的短期記憶，並且要事先定好指標，超過就跳出推理迴圈，避免無限迴圈。
• 兩個分析 agent 加一個裁決 agent：風險分析與行為分析兩個 agent 平行處理同一個事件，第三個 agent 看完兩邊的結論才做最後裁決，結果再以事件發回訊息佇列，接續 saga 流程。

影片從哪一段開始看14 段

1. 00:12開場與目標這場要學的是怎麼把 AI agent 接進事件溯源、事件驅動，或任何公司已投資多年的架構。
2. 01:05被擋下的筆電交易Divakar Kumar 一個月前買一台約 3,500 美元的筆電，刷了兩次都被拒，客服打來確認，卻答不出為什麼被擋，帶出即時詐欺偵測這個題目。
3. 02:33為什麼不確定的地方放 agent灰色地帶本來就不確定，agent 又是非確定性的，為什麼還要放？Divakar Kumar 的回答是：規則引擎和 ML 拿不到足夠的即時情境，agent 可以拿到各個 bounded context 的資料再下判斷。
4. 03:25從規則引擎到 ML 模型規則引擎五年前還堪用，但詐欺手法一直變、規則得天天改，才找第三方用交易歷史訓練 ML 模型，產出風險代碼。
5. 04:46灰色地帶與兩層設計多數交易低於或高於門檻就能放行或擋下，灰色地帶才交給第二層 agent，第一層的既有系統照留。
6. 05:45四個 bounded context交易、帳戶、裝置、付款各管各的資料，彼此不共享，只能像微服務那樣非同步溝通。
7. 07:34Orchestrator 層加上類似 saga 的 orchestrator，所有溝通都經過它，再透過訊息佇列傳給有興趣的服務，agent 也放在這一層裡。
8. 08:28事件溯源與事件儲存交易 context 內有 domain event 與來自其他 context 的 integration event，全部附加進 Cosmos DB。
9. 09:45Read model 與 semantic layerchange feed 把變更推到時間線、客戶資訊、風險視圖等 read model，再由 worker 整理成 materialized view 給 agent。
10. 11:42Agent 的組成與迴圈語言模型、工具、記憶三塊；用短期記憶守住 500 毫秒的 SLA，並要定好結束推理迴圈的條件。
11. 13:56兩層處理與 fan-out第一層是規則與 ML，第二層用 fan-out 把事件同時丟給風險分析與行為分析兩個 agent，再交給第三個裁決 agent。
12. 15:43兩個 agent 的工具風險分析 agent 查詐欺歷史、裝置信任度與搬過來的業務規則；行為分析 agent 用兩個 plugin 分析交易模式。
13. 16:55Agent 如何取得情境各 context 把交易統計、裝置與位置、帳戶狀態與 KYC、近期付款整理進 semantic layer，供工具查詢。
14. 18:49合成資料 POC 展示用合成資料做的 POC：模擬事件陸續流過交易、帳戶、付款各 context。serverless 模式的資料庫起得慢，Divakar Kumar 改用說明帶過預期結果：兩個 agent 各給結論，第三個做最後決定，再以事件發回訊息佇列。

值得記的話5 句

• these AI agents are not just for the chatbots or the coding assistants這些 AI agent 不只是給聊天機器人或寫程式助手用的00:47

• earlier in the rule-based engine or the ML-based engine, like we don't have enough context.早先的規則引擎或 ML 引擎，沒有足夠的情境資料02:52

• we are not mutating the state, but instead like we are appending all the events as when it arrives.我們不改狀態，而是事件一到就附加進去09:15

• for the transaction to be processed, it should be sub-500 milliseconds.交易要處理完，必須在 500 毫秒以內12:18

• you should really know when to stop this loop你得真的知道什麼時候該停下這個迴圈13:06

名詞與人物10 個

Event sourcing

使用者指令當成業務事實附加進事件儲存，不直接改狀態，這場的資料基礎

Cosmos DB

這個系統用來當事件儲存的 NoSQL 資料庫

Bounded context

交易、帳戶、裝置、付款各自擁有資料、彼此不共享的領域邊界

CDC / change feed

事件儲存有變更時通知下游，把變更推到各個 read model 的機制

Read model

為查詢最佳化的資料視圖，這場有時間線、客戶資訊、風險視圖三種

Semantic layer（materialized view）

把各 context 的資料整理成一份給 agent 查的視圖

Saga orchestration

orchestrator 經訊息佇列協調各服務的流程，agent 的裁決也發回這條流程

Tier one / tier two

第一層是規則引擎與 ML 模型，第二層是處理灰色地帶的 agent

Fan-out pattern

同一個事件同時分給風險分析與行為分析兩個 agent

Verdict agent

第三個 agent，綜合兩個分析 agent 的結論做最後裁決

提到但沒有展開

• Divakar Kumar 提到 agent 用的語言模型不一定要是大型模型，SLM 或開源模型都可以。
• 裁決那一步可以只是一個分數指標，也可以是另一個 agent。團隊發現只看分數又回到規則式的老路，誤擋（false positive）的案例很多，所以裁決改由第三個 agent 來做。
• 其他團隊不一定採用事件溯源，所以這套設計同時支援 CDC 與訊息佇列兩種方式，把事件送進 projection 層。

Agent開發工具安全

在 YouTube 看原片 ↗