前面幾篇，我讓 AI 從程式碼找出弱點，再根據這些弱點設計並執行混沌實驗。
最開始想確認的是現在的 AI 能不能自己提出假設、執行實驗、判讀 metrics，最後再驗收修復？

經過 EXP-002 與 EXP-003，這套流程已經完整走過。今天回頭看看 AI 做到了哪些事情、哪些環節仍然需要人類把關，以及整套流程還有哪些地方可以改善。

檢視 AI 跑過的流程

這次 AI 完成的工作，已經涵蓋一場混沌實驗從開始到結束的主要步驟：

實驗使用的 YAML、執行結果、監控證據與報告會先加入 Raw Sources，再經過 Ingest 整理進 Wiki。下一輪就能讀取這些新證據，繼續選擇要驗證的弱點。資料走回知識層後，整套流程才真正接成一個循環。

當然，真的跑起來沒有圖上這麼順。EXP-002 第一次的負載太低，測了半天也拿不到足夠證據，AI 只好調高負載再跑一次。到了 EXP-003，AI 又漏掉交接文件裡的 busy 預期，而且這次它自己完全沒發現，是我回頭比對文件時才抓到。最後是我檢視整體流程時才發現。

AI 與人類的職責

這樣分工後，Agent 負責大量閱讀、整理、比對與記錄，人類則把重點放在授權、風險與安全限制。

混沌工程會真的改變系統狀態。如果直接給 AI 一個擁有 admin 權限的 kubeconfig，還讓它自由發揮，真的很容易用嘴巴破壞 Kubernetes。因此，實驗目標、允許範圍、禁止項目與停止條件都要先寫清楚。

可以改進的地方

1. 寫下的文件不易閱讀

AI 寫出的文件很難閱讀。例如: EXP-002 的第四個假設原本是這樣寫的：

（足夠 load 下）thread 耗盡 → teller liveness 失敗 → 重啟：teller kube_pod_status_ready 1→0。⚠️ 依賴 load 強度（並發/RPS 逼近 Tomcat 200 thread）；無直接 thread metric（無 micrometer），只能由 #2（SERVER 延遲飆）+ #4（ready 掉）間接推論。注意：teller 自己的 probe 是 node→teller（方向非 to account），不被本 chaos 延遲 → teller ready 掉 = thread 真耗盡（health 端點無 thread 回應）的真實後果，非注入假象。

寫得頭頭是道，該有的關鍵資訊也都有寫進去。但我看完後只想說：寫得很好，下次別寫了。 有用過 Claude 的人應該多少都能體會這種情況，每句話看起來都有道理，全部放在一起卻很難抓到重點。最後我還是得請 AI 再解釋一次，才整理成 Day 11 裡比較白話的說明。

這部分我覺得可以回頭調整 chaos-agent 裡的 Markdown 規範，讓 AI 把假設與報告寫得更容易理解，免得每次都要再找另一個 AI 幫忙翻譯。

2. 補跑應另開實驗

一般實驗報告會照著摘要、穩態、假設、方法、觀察、結論與行動建議一路寫下來。讀者看到結論時，前面的實驗應該已經結束，接下來只要確認結果與後續建議。

EXP-002 原本也照這個順序寫到第 6 節結論，但第一次實驗因為負載不足，後來又補跑 Run 2，內容直接接在結論後面變成第 6.5 節，接著才進入第 7 節行動建議。整份報告因此變成「先下結論、再跑一次實驗、最後才提建議」，這樣補跑的實驗並沒有完整的報告。

3. chaos-agent 的職責

EXP-002 報告根據實驗結果，建議加入 Circuit Breaker 與 HTTP client timeout，這部分還算合理。不過 chaos-agent 接著幫 lite-bank-demo 的 repo 準備了修復文件，裡面直接指定 Maven dependency 與版本、Java annotation、fallback method，以及 application.yml 的設定參數等等。

不過我認為 chaos-agent 管得有點太多，應該產出實驗報告就好，至於程式碼要怎麼改，應該交由人類或是負責 lite-bank-demo 的 repo AI 來決定，這樣分工比較明確 。

結論

這幾篇一路做下來，可以看到 AI 在混沌工程裡能接手的範圍已經變大。以前是人類提供實驗情境後，假設、執行、觀察與報告都得自己處理；現在 AI 可以先理解系統架構，再設計實驗、執行、分析結果與整理報告。對混沌工程這種步驟固定、又要反覆查資料的工作來說，確實省下很多人力。

不過在讓 AI 接手前，要先確認監控系統運作正常，這次實驗需要的 telemetry 也都能正常查詢。AI 的判讀品質高度依賴 metrics、traces 與 logs，目標服務缺少必要資料，或監控系統本身發生異常，都可能讓 AI 取得不完整甚至錯誤的證據。

我覺得這套流程有價值的地方，是每次實驗都會留下假設、原始證據、限制與修正紀錄。下一個 Agent 可以直接沿用這些知識繼續設計實驗，不用每次都從頭猜測系統發生了什麼。人類則把時間放在審查實驗風險與結果，以及決定系統真正需要改善的地方。

最後大家可以想想，如果要讓 AI 接手混沌工程在你的環境裡，你會怎麼設計這套流程？
AI 混沌工程這段就先收在這裡。下一篇開始換個主題，繼續看看 AI 還能接手哪些工作。

今天就寫到這裡，我們明天見！