上一篇 Day 3 我們聊過用程式碼當骨架、LLM 負責理解情境產出 YAML 來實現自訂流程的混沌實驗。這種做法雖然穩，但老實說，寫一堆流程控制的程式碼實在累人，而且只要流程一改，程式碼就得重寫，很費時間。

在這之後，Model Context Protocol (MCP) 出現了，在社群上非常紅。

雖然大家可能多多少少都聽過，但我還是要在這裡說明一下什麼是 MCP：簡單地說，它就是一套讓 LLM 能夠透過各種工具來與外部世界互動的協議。

這一次，我們改用 MCP 實作，並且搭配 n8n 這類流程自動化平台來搭建 AI Agent。
這樣一來可以擺脫撰寫流程控制程式碼的負擔。我們只需要在 n8n 上維護好 System Prompt，就能讓 Agent 自己思考、自己去調用對應的 MCP 工具完成任務，不需要做太多的程式碼調整。

n8n + MCP 流程自動化架構

在我們的團隊，專案管理和工作流程主要依賴 Azure DevOps。我們希望將混沌工程實驗與現有的 Task 管理系統結合，達到實驗紀錄與追蹤的自動化管理。

那為什麼要選 n8n 呢？ 純粹是他有提供 webhook server ，又可以很快地把流程接起來，所以就用了，也不是 n8n 特別厲害

理論上每次的混沌實驗，都要有紀錄你注入的 yaml 以及最後報告，然後記錄在某個地方供團隊檢視，這件事也是蠻麻煩的，所以我們的目標是：在 Azure DevOps Task 內寫混沌工程情境，然後執行人員去留言請執行，就能觸發 webhook 去呼叫 n8n 來啟動 LLM 自動生成並注入混沌實驗。

為了讓 LLM 能使用 MCP 工具，我們使用 n8n 來搭建 AI Agent。以下是整體的架構圖：

在這個模式下，我們不需要撰寫任何流程控制邏輯，直接透過 System Prompt 告訴 LLM 如何一步步執行任務。將任務拆解為以下幾個核心：

1. 觸發與輸入：設定 Azure DevOps service hook，當 Azure DevOps Task 出現特定關鍵字留言（例如「實驗開始」）時，觸發 Webhook，將 Task 的詳細描述傳送給 n8n。
2. Agent 配置：在 n8n 中配置 AI Agent，這裡我們使用 Azure OpenAI 作為 LLM 大腦，並提供 K8s MCP 與 Azure DevOps MCP 作為 Agent 的手腳（工具）。
3. System Prompt：利用提示詞來定義 LLM 必須遵守的嚴格操作流程與防呆規則。

實際操作與執行結果

我們來看看如何透過 Task 中的描述和簡單的留言，讓 LLM 自動搞定整個混沌實驗，並將結果回寫到原始的專案管理任務中。

1. 任務發起：留言即指令

執行人員只需在 Azure DevOps 的 Work Item Task 內，清晰描述實驗情境（通常寫在 Description 欄位），然後輸入關鍵字留言「實驗開始」即可觸發整個流程。

• 自然語言輸入：Task 描述中寫道：「front-end 服務對 carts 網路延遲 10000ms」
• 觸發機制：留言「實驗開始」觸發 Webhook。

2. n8n 流程執行與 LLM 推理

Webhook 收到訊息後，n8n 的工作流被喚醒。AI Agent 根據 User Prompt 和 System Prompt 開始進行推理與工具呼叫。

User Prompt 負責從 Webhook 傳來的資訊中擷取有用的訊息，例如實驗描述與 Task ID：

System Prompt 則是我們的總指揮，其核心架構定義如下：

1. 語意分析：從自然語言中萃取持續時間、情境與 Namespace。
2. 資源檢查：呼叫 K8s MCP 工具，確認目標服務與資源在叢集中確實存在。
3. 組織 Chaos YAML：遵循 Chaos Mesh CRD 規範生成對應的 YAML 設定。
4. 執行與回饋：呼叫 K8s MCP 注入 YAML，並用 Azure DevOps MCP 工具將產出的 YAML 及執行結果回寫到原始的 Task 中。

3. AI agent 串接 Model 和 MCP 工具

這部分就不贅述，直接在 n8n 的 AI Agent 節點中完成 Azure OpenAI 與 MCP 節點的連線配置即可：

4. 測試流程

當 Webhook 被呼叫後，我們可以在 n8n 執行的流程下方看到日誌。LLM 會根據提示詞，自動呼叫需要的 MCP Tool 逐步完成任務。

最後回到 Azure DevOps Task 查看，可以看到 LLM 已經把注入的 YAML 回寫到 Task 內，方便未來追蹤混沌實驗的歷史紀錄：

5. 混沌成效驗證

我們一樣透過 Grafana Dashboard 來驗證實驗成效。

下圖顯示，在故障注入後，Carts Latency（延遲） 指標瞬間飆升，而 QPS (Query Per Second) 則急劇下降至接近零。這證明了 LLM 確實理解了我們的指令，並且成功完成了故障注入。

完整的混沌工程還包含結果判讀與報告撰寫。目前這一版跑完後，還是要由人接手處理。要讓 AI 往後接手實驗設計、觀察與報告，還得先準備一套我們熟悉的系統與監控環境，這部分下一篇再繼續。

結論

透過 AI Agent 搭配 MCP 的方式，擺脫了寫程式碼的麻煩。只需要精心設計 System Prompt，就能實現非常有彈性的混沌實驗。依照目前 AI 和工具發展的速度，我們甚至可以大膽地想像未來某一天的場景：

我們能將系統的架構圖、服務相依性、歷史監控數據，甚至業務邏輯都作為 Context 提供給 LLM，它應該可以：

1. 自己找實驗方向：LLM 先看服務之間的相依關係，找出「服務 A 延遲，會不會連帶拖垮服務 C」這類問題，再整理成下一個值得驗證的故障假設。
2. 自己調整實驗參數：根據當下的系統負載和流量，判斷這次要注入 500ms 還是 1000ms 的延遲。以後設實驗參數，總算不用每次都靠人拍腦袋決定。
3. 把整個流程接起來：從實驗前的狀態檢查、故障注入、觀察系統反應，一路做到清理和結果摘要。人類先把安全邊界說清楚，剩下的執行工作就交給 Agent。

想像歸想像，AI 最後能做到哪一步，還是得真的跑過才知道。後面就拿實際的系統繼續測看看。