教學：利用代理人工智慧建立端對端的啟動器規則

Fabric Activator 偵測串流資料中的模式，並在條件達成時採取行動。 在這個教學中，你會使用 AI 代理建立端到端的管線。 管線會監控一連串遙測事件，偵測持續過熱，並呼叫 Fabric 使用者資料函數（UDF）來提交修復作業。 你寫提示;代理人負責撰寫。

本教學以元件製造機的遙測資料作為貫穿全文的範例，但相同的提示詞幾乎適用於任何每個實體都有穩定 ID 的時間序列資料，例如物聯網裝置、車隊、物流事件、金融逐筆資料、應用程式指標等。 替換欄位名稱和閾值，以符合你的資料形狀。

在本教學課程中，您會完成下列工作：

如果你是Fabric啟動器新手，請參考什麼是Fabric啟動器？。 如果你是Fabric使用者資料函數的新手，請參考 什麼是Fabric使用者資料函數？。

案例概觀

某家製造商在多座工廠中運行一批零件製造機。 每台機器都會將遙測數據——溫度、震動、壓力、運行狀態——傳送到 Azure 事件中心。 當機器持續高溫運行時，需要在故障前進行維修檢查。

在本教學中，每個事件使用一個小型代表性結構：每台機器的 ID （machine_id）、位置標籤（plant_id）、用於監控的數值指標（temperature_c）、以及執行狀態欄位（state）。 欄位名稱本身並不重要——相同的提示格式適用於任何每個實體的 ID，再加上一個你想設定門檻的指標。

你建立一條 Fabric 管線來監控遙測串流，套用持續閾值規則，並呼叫使用者資料函式來提交修復工作。 規則會依 machine_id 將事件分組，並在 temperature_c 持續高於 50°C 達 5 分鐘時觸發。 當它觸發時，會將 machine_id、plant_id 和目前的溫度傳遞給該動作。

先決條件

在開始之前，您需要：

• 一個 F4（或更高）容量的 Fabric 工作區，並擁有作者權限。 想了解工作區，請參見「工作區」。
• 一個技能相容的代理程式——例如GitHub Copilot CLI 或 GitHub Copilot in Visual Studio Code——並安裝 Fabric skills。
• 用於串流遙測資料的 Azure 事件中樞 命名空間和中樞。 你需要 FQDN 命名空間、集線器名稱，以及一個 Listen+Send 連接字串。

設定事件串流

在此步驟中，你建立訂閱事件集線的事件串流。 你向客服提示，並在入口網站驗證結果。

1. 將以下提示提供給代理程式，並以事件中樞中的值取代預留位置：

   Create a Fabric eventstream in my workspace called `WidgetMachineTelemetry` that ingests from this Azure event hub:
   
   - Namespace: `<your namespace FQDN>`
   - Hub name: `<your hub name>`
   - Connection string: `<your Listen+Send connection string>`
   
   When you're done, give me a direct portal link to the eventstream item so I can verify it.
   

2. 代理會呼叫事件流創作技能。 它建立事件串流項目，將事件中心設定為來源，並在 Fabric 入口中回傳可點擊的項目 URL。 你不需要目的地——Activator 直接訂閱串流。

3. 選擇客服給你的連結。 在 即時檢視 中，確認事件中樞來源為 已連線，且 widget-machine 遙測事件有持續傳入。

   

   圖 1： WidgetMachineTelemetry 事件串流——事件 widget-telemetry 從事件樞紐來源經由串流流到 WidgetMachineMaintenance 啟動器目的地。

建立使用者資料函式

在此步驟中，你建立啟動器規則所呼叫的使用者資料函式。 這個函式會將修復工作請求傳送到你的下游 API。

1. 給經紀人這個提示：

   Create a Fabric User Data Function called `MaintenanceDispatcher` in my workspace, written in Python, with a function `file_repair_job(machine_id, plant_id, temperature_c)` that sends those values as JSON in a POST request to `https://contoso.com/maintenance/fileRepairJob` and returns the parsed response.
   
   When you're done, give me a direct portal link to the UDF item so I can verify it.
   

2. 代理程式會叫用 Fabric UDF 撰寫技能。 它會架構一個Python UDF 項目，實作 file_repair_job，並httpx，發佈 UDF，確認函式可呼叫，並回傳可點擊的項目 URL。

3. 選取代理程式提供給您的連結，然後使用內建的 Test 窗格，以範例承載資料叫用 file_repair_job。 例如： machine_id="widget-press-042"、 plant_id="plant-eu-01"、 temperature_c=52.7。 對 contoso.com 的呼叫會回傳 HTTP 錯誤——這是預期中的，因為該預留位置端點無法解析。 重要的是，UDF 已完成部署、註冊，並且已執行到出站 HTTP 呼叫這一步。

   

   圖 2： MaintenanceDispatcher 使用者資料功能——file_repair_job 將過熱機器的詳細資訊傳送給維護系統。

撰寫啟動器規則

在此步驟中，你會建立啟動器規則，監控事件串流並在機器過熱時呼叫你的 UDF。

1. 給經紀人這個提示：

   Create an Activator rule in my workspace subscribed to the `WidgetMachineTelemetry` eventstream, that triggers my `file_repair_job` UDF when a machine's temperature stays above 50°C for 5 minutes.
   
   When you're done, give me a direct portal link to the rule so I can verify it.
   

2. 代理程式會叫用 Activator 撰寫技能，並建立 Activator 項目。 代理會依據 machine_id 將規則分組，建立持續閾值偵測機制，並設定動作以使用 machine_id、plant_id 和目前溫度來呼叫你的 UDF。 代理程式接著回傳該規則的可點擊 URL。

3. 選擇客服給你的連結，然後依照這份清單走一遍：

   • 資料正流入此規則。 在檔案總管窗格中開啟規則底層的 Activator 物件，確認近期事件是否以非空machine_idtemperature_c值顯示在動態資料表中。
   • 規則正在執行。 確認規則是否處於 啟動 或 執行 狀態，並且 Activator 物件摘要顯示你的機器為活躍實例。
   • 代理程式會記錄啟用情況。 當機器過熱超過50°C持續5分鐘時，規則的歷史標籤中會出現條目，每條顯示machine_id觸發的項目、點火時的溫度，以及成功呼叫。file_repair_job

   

   圖 3：OverheatingDispatch 啟動器規則——當機器溫度持續 5 分鐘維持在 50°C 以上時，會呼叫 file_repair_job，並傳入機器的識別資訊、廠區及目前溫度。

清理資源

完成後，從工作區刪除事件串流、使用者資料功能和啟動器項目，並從 Azure 入口網站刪除事件中心命名空間以停止收費。

相關內容

• 什麼是網狀架構啟動器？
• 什麼是Fabric 使用者資料功能？
• 事件串流來源與目的地
• 在 Fabric 使用者資料函式中存取資料來源