Day 9：llm-wiki 與 chaos-agent 的分工

2026 iThome 鐵人賽

DAY 9

AI 自動化

讓 AI 接手工程師的 SOP：30 天 AI 自動化實戰系列第 9 篇

18th鐵人賽

dommgifer

2026-09-02 11:35:56

69 瀏覽

分享至

前兩天我們定義了 llm-wiki 的 Schema，也準備好 Raw Sources。接下來應該開始 Ingest。不過在讓 Agent 動手前，你可能有個疑問：

既然 llm-wiki 已經有規則、有資料，也能整理知識，那誰來負責找弱點、設計混沌實驗、控制安全範圍，再把找到的弱點與實驗證據整理回 Wiki？

所以我在 llm-wiki 外層加了一個 chaos-agent，負責找弱點、設計實驗，以及控制可以操作的範圍。執行弱點掃描、實驗設計或故障注入時，Agent 會遵守外層的 chaos-agent/CLAUDE.md。進行 Ingest、Query 或整理 Wiki 時，則會遵守 llm-wiki/AGENTS.md。

只要工作會修改 Wiki，兩份規則都要一起遵守。

整體目錄結構大致長這樣：

chaos-agent/                 # Agent 行動層
├── CLAUDE.md                # 定義 Agent 要做什麼、怎麼做，以及哪些操作禁止
├── config/
│   └── targets.yaml         # 目標系統與允許操作的範圍
└── llm-wiki/                # 知識層
    ├── AGENTS.md             # Wiki 結構、證據與寫入規則
    ├── sources/              # Raw Sources
    ├── templates/            # Wiki 頁面範本
    └── wiki/                 # 整理後的系統知識

llm-wiki 和 chaos-agent 的職責

這個專案有兩份主要規則檔：

規則檔	負責內容
`llm-wiki/AGENTS.md`	Raw Sources、Wiki 目錄、頁面格式、引用規則、Ingest、Query、Wiki 規則檢查
`chaos-agent/CLAUDE.md`	Agent 身份、弱點掃描、實驗設計、故障注入、反思流程、安全邊界

llm-wiki：管理知識

llm-wiki 會規定：

已經收錄到 Raw Sources 的檔案不能直接覆寫。架構來源更新時要重新建立 snapshot，新的實驗資料則依實驗 ID 加入 experiment-runs/。
每個結論都要附上可以追溯的來源；引用程式碼時，要記錄 commit、檔案路徑與行號。
Service、Infrastructure、跨服務的共通弱點（Pattern）與實驗紀錄，都要放在固定位置。
弱點要使用 TX-W001 這類 ID，並記錄狀態與可信度 (Confidence)。
每次修改 Wiki 後，都要同步檢查 index.md 並追加 log.md。

llm-wiki 的工作重點是整理、保存與追溯。它讓 Agent 過幾天重新回來時，還能知道一個結論從哪裡來，也能看懂之前做過哪些實驗。

chaos-agent：調查與驗證

chaos-agent 負責接下來要調查什麼，以及怎麼安全地驗證。

它會負責：

選擇要分析的 Service。
根據 Wiki 裡的待調查項目讀取相關程式碼。
執行弱點掃描，找出 timeout、connection pool、retry 等問題。
從弱點中挑選實驗目標，建立假設。
設計 Chaos Mesh YAML、觀測指標，以及發生哪些情況時必須立刻停止實驗。
控制實驗的 namespace、Pod 數量和執行時間。
分析實驗結果，把 YAML、數據與報告放進 Raw Sources。

像 PostgreSQL、Kafka 這類基礎設施預設禁止成為實驗目標，允許使用哪些 Chaos Mesh 實驗情境、最多影響幾個 Pod，也都由 chaos-agent 的規則控制。這些限制可以降低 Agent 把整個環境炸掉的機率。

兩層如何合作

兩層實際合作時，資料會這樣流動：

llm-wiki 先把 Raw Sources 整理成可以查證的系統知識。chaos-agent 再使用這些知識選擇調查目標、設計實驗。實驗產生的 YAML、數據與報告會放進 Raw Sources，經過整理後再補進 Wiki。
這個流程會反覆進行。Wiki 累積越多可靠證據，chaos-agent 下一次選擇目標時就越有依據；實驗產生的新證據，也會成為下一輪整理知識的來源。

這樣拆成兩層，主要是為了讓規則更容易維護。全部內容放在同一份規則裡，短期內可以運作，時間一久就容易把知識整理、弱點掃描與實驗限制混在一起。

llm-wiki 的知識管理方式可以套用到其他領域，Raw Sources、證據引用與 Ingest 流程都能繼續使用，實際頁面結構再依領域調整。chaos-agent 這一層會依實際系統調整。如果把這套分層設計套用到另一套系統，允許的實驗類型、安全範圍、弱點分類和觀測方式都要重新定義。分開管理後，修改弱點掃描不會打亂 Wiki 結構，調整 Wiki 頁面格式也不會碰到實驗的安全限制。