2026年10月7日，AWS 喺 Machine Learning Blog 發了一帖教學，示範點樣把 DevOps Agent 做嘅事故調查，接埋一條「自動修復」流程。重點唔係佢能診斷——呢樣佢一直做緊——而係點樣安全到可以俾 AI 動手執機房，而唔會自己亂搞到爆。
DevOps Agent 係 AI 驅動嘅運維代理，靠相關指標（metrics）、日誌（logs）同應用拓撲全天候分類事故，俾出根源分析（RCA）同建議。但 AWS 講明，企業通常會將觀察類 agent 放喺「觀察+報告」模式：診斷可以，但唔直接改生產資源。呢個教學要填嘅，就係由「報告」到「修復」嗰段空。
架構用緊四樣嘢：Lambda Durable Functions（持久函式，可跑長達一年、自動存檔中斷點、斷咗可恢復）、Amazon EventBridge（事件觸發）、Amazon Bedrock（大模型服務），同埋一批被准許嘅 Lambda 工具。流程大致咁行：
- DevOps Agent 完成調查，發出包含症狀、發現同 RCA 嘅事件。
- EventBridge 收到事件，觸發 devops-agent-trigger。
- 呢個函式打包調查摘要，呼叫 devops-agent-remediation-durable。
- 持久函式將調查內容送畀 Bedrock 分析、揾適用嘅修復方案。
- Bedrock 喺一個「精心挑選嘅允許清單」（curated allowlist）入面列出可用工具——每個都係專建、只負責單一明確動作嘅 Lambda 函式。
- Bedrock 據調查結果同可用工具，提出具體修復動作。
- 分界來了：讀取類（read-only）動作，持久函式自動執行；涉及改基礎設施，流程暫停，等人工批核（human approval）。
- 批核後先執行。
持久函式跑成一個 agentic loop（代理循環），反覆呼叫 Bedrock、執行已批工具、將結果回灌對話，直至修復完成。AWS 指，呢個設計將調查摘要轉成「預先驗證好、只等一個批核動作」嘅修復，目的係縮短平均修復時間（MTTR），放低 on-call 工程師重複診斷嘅負。
阿調搞兩下：呢套設計最有趣嘅唔係 AI 多勁，而係佢點樣「唔令」AI 做某啲嘢。讀取自動、改動要人批、工具限白名單、全程可審計——權限分界畫得清清楚楚。呢啲先係值得問嘅問題：邊個可以放寬白名單？批核人可以唔可以係遠程、無人值夜班嘅情況？自動「觀察」同「動手」之間嘅分界，由邊個定、邊個改？AI 能自己執機房，但攞鎖匙嘅人依然係我哋。
阿調｜深度調教
