你的代理人會診斷問題並修正它們。 它能重啟服務、擴展資源、強化安全設定並收集診斷資料，所有這些都能依你選擇的控制層級進行。
[!影片 <VIDEO_URL>/Azure_SRE_Agent__Verified_Fix.mp4]
小提示
- 請你的代理人解決問題。 它提出解決方案，你核准，然後執行修正。
- 完整的稽核追蹤：是誰觸發的、哪些改變了，以及它是否有效。
- 選擇你的信任等級：審查模式（批准每個行動）或自主模式（代理人處理）。
問題是：診斷而不採取行動只會浪費時間
你找出了問題所在。 接下來呢？ 你進入 Azure 入口網站，找到正確的刀片，確認資源，點選確認對話框，等待操作完成，然後確認是否有效。 調查花了五分鐘。 修正又花了十分鐘。
這種摩擦存在於您的營運工作流程中：
- 日常營運：根據預期負載調整資源，並在維護期間重新啟動服務。
- 合規檢查：強化數十個儲存帳戶的安全設定。
- 隨叫隨到回應：快速執行已知的修正，讓工程師能重新入睡。
- 主動優化：在問題發生前，根據使用模式調整 SKU。
你的代理程式如何完成迴圈
當你的代理程式發現問題時，不會只停留在告訴你問題所在。 它會提出特定的修復行動，並根據你的 運行模式，會等待你的批准或立即執行該動作。
代理程式遵循一致的模式： 診斷→識別動作→檢查權限→執行（或建議）→驗證修復是否有效。 每個動作都會被記錄，並記錄是誰觸發了它、發生了什麼改變、原因以及是否成功。
調查完成後，您的業務員可以直接採取行動、建立追蹤項目，或通知您的團隊——每一項都有完整的背景說明。
這和劇本有什麼不同
劇本很死板。 它們在任何背景下都執行相同的動作。 你的經紀人會先對情況進行推理。 它會考慮調查時發現的資訊、過去事件的記憶，以及你的 技能 和 知識基礎 所建議的內容。 相同的症狀，可能在某一種情況下導致重新啟動，而在另一種情況下導致擴展，因為 Agent 會根據證據調整行為。
跑步模式 會給你逐步的信任感。 從 審查 模式開始，由經紀人提出建議，你批准。 當你對這個模式有信心時，再轉成 自主 模式。 對於那些只監控且從未採取行動的代理，請使用 ReadOnly 功能。
你的代理人能做什麼
你的代理程式可以透過 Azure CLI 指令執行任何 Azure 動作。 如果你能在 az 執行，那麼你的代理程式也能執行。 此功能包括管理任何資源類型、修改設定、建立資源，以及執行任何 Azure 操作。
| 命令類型 | 它所帶來的意義 |
|---|---|
| 讀取指令 | 查詢任何 Azure 資源 - az webapp list， az containerapp show， az vm list， ， az network vnet show。 立即啟動，無需批准。 |
| 寫入指令 | 修改任何 Azure 資源： az webapp restart， az containerapp update， az vm resize， az role assignment create， 。 需要在審查模式下核准。 |
代理的行為僅受其管理身份所指派的權限限制。 如果你在資源群組上授予貢獻者，代理人就能管理該群組內的所有事務。 如果你授予一個自訂角色並執行特定動作，代理人只能執行這些動作。
安全護欄
代理人在命令層級執行安全約束。
-
刪除操作被阻擋 — 代理程式從未執行
delete並remove執行指令。 它會回傳錯誤，指引使用者前往 Azure 入口網站進行刪除。 -
金鑰庫指令被封鎖 — 代理程式會封鎖所有
az keyvault指令，以防止憑證外洩。 - 管理鎖被尊重 — 在修改任何資源前，代理程式會檢查 Azure 的管理鎖。 含有 ReadOnly 鎖的資源無法被修改。
- 訂閱驗證 — 代理會在執行指令前驗證訂閱 ID 是否為正確的 GUID 格式。
前後比較
下表比較了人工緩解流程與代理輔助方法。
| 之前 | 之後 | |
|---|---|---|
| 修正執行 | 瀏覽至 Azure 入口網站、找到資源，再逐一點選各個窗格 | 問經紀人，核准，就完成了 |
| 驗證 | 手動檢查修復是否有效 | 代理人核實並回報結果 |
| 稽核 | 希望有人有記錄他們的做法 | Application Insights 的完整審核紀錄 |
| 知識 | 有一位工程師知道該怎麼解決 | 代理人持續套用所學到的模式 |
權限需求
預設情況下，代理擁有 讀取 器權限，無法執行任何操作。 您可透過將角色指派給 Agent 的受控識別，明確授與寫入權限。
| Scope | 代理人可以採取哪些行動 | 建議用於 |
|---|---|---|
| 資源 | 僅提供單一資源 | 最大限制，從這裡開始 |
| 資源群組 | 所有資源集中於一組 | 生產工作負載 |
| 訂閱 | 訂閱中的任何資源 | 僅限開發與測試 |
警告
代理程式在修改任何資源前會檢查 Azure 管理鎖。 你無法用唯讀鎖修改資源，不管權限或執行模式如何。 刪除和移除操作完全被封鎖。 你可以用 Azure 入口網站來刪除資料。
替代反應路徑
直接緩解不是唯一的選擇。 許多團隊偏好將發現導向工作項目或工單系統，而非直接執行操作。 當需要人工審查或變更管理流程時，工作項目特別有幫助。
| 回應路徑 | 運作方式 | 最適合用於 |
|---|---|---|
| 直接緩解 | Agent 會執行重新啟動、擴展或強化 | 受信任的模式，非生產模式 |
| 建立工作項目 | 代理建立 GitHub issue 或 Azure DevOps 工作項目 | 人類參與迴路、變更管理 |
| 發送通知 | 經紀人會把訊息發到 Teams 或寄電子郵件 | 無行動的覺知 |
| 觸發器工作流程 | Agent 會派送 GitHub Actions 或 Logic Apps | CI/CD 整合、多步驟流程 |
透過 連接器設定工作項目建立與通知。 例如，連接 GitHub MCP 伺服器讓代理程式建立問題，或連接 Azure DevOps 自動建立工作項目。
欲了解更多資訊，請參閱 「發送通知 」與 「工作流程自動化 」，以串接這些回應類型。
範例：事件觸發緩解
以下範例展示了你的客服人員如何在你睡覺時處理凌晨3：47的記憶事件。
凌晨3：47 — PagerDuty 發出警報：「prod-api 記憶體過高」
你的代理，在審核模式中，會處理所有事情。
已確認事件 — PagerDuty 顯示「已由 SRE 代理確認」。
自動調查：
- 查詢 App Insights：記憶體達到 94%，且在 2 小時內持續上升。
- 檢查部署歷史：沒有近期部署。
- 記憶中回想：「上次發生這種情況，重新啟動解決了。」
提出修正建議 — 事件討論串發文：
Memory at 94% on prod-api (App Service). Recommended action: Restart the App Service. Evidence: - Memory climbing since 1:30 AM - No recent deployments - Past incident: restart resolved similar issue on 2026-01-15 [Approve] [Deny]你批准 （或在自主模式下，代理會立即執行）。
代理執行並驗證：
✓ Restarted prod-api ✓ Memory now at 42% ✓ Incident resolved
發生了什麼事： 你點 選 Approve ，客服負責調查、行動和驗證。
稽核線索
系統會記錄每一個緩解行動及完整的背景。
| 領域 | 擷取資訊 |
|---|---|
| 身分識別 | 代理程式與受管理的身分 |
| Action | 具體操作 |
| 時間戳 | 當操作執行時 |
| Trigger | 導致該行動的診斷或狀況 |
| 結果 | 成功或失敗，並附有事後驗證 |
你可以透過客服入口網站的 監控 > 日誌 ，在 Application Insights 查詢稽核軌跡。 系統會將每個 az 指令記錄為 AgentAzCliExecution 自訂事件。 欲了解更多資訊，請參閱 審計代理人的行動。