AWS Summit Taipei 2026 觀察：AI Agent 正在如何改變 DevOps
這次 AWS Summit Taipei 2026，我最在意的不是又多了哪些模型或產品，而是 AI Agent 開始真正走進軟體交付與維運流程之後，DevOps 的工作會怎麼變。
兩天的內容從 Amazon Quick、Kiro CLI、Amazon EKS Auto Mode、AWS DevOps Agent，一路談到 Amazon Bedrock AgentCore、AWS Transform、Codex 與 Claude。看起來各自處理不同問題，放在一起卻指向同一件事：模型能力已經不是唯一瓶頸。要讓 Agent 進入正式工作，還需要正確的脈絡、受控的工具權限、可觀測的執行環境、可驗證的結果，以及清楚的人機責任邊界。
這也是我認為 DevOps 接下來最重要的轉變。重點不只是會不會用更多 AI 工具，而是能不能把交付與維運流程設計成 Agent 看得懂、做得到、查得到證據，出錯時也停得下來、回得去。
我先講結論
- AI Agent 的價值不在多一個聊天視窗，而在能否帶著工作脈絡使用工具，完成一段可驗證的流程。
- Coding 變快之後，瓶頸會往 code review、security、release 與 operations 移動。只加速寫程式，通常只是把問題推到下一站。
- Incident investigation 很適合先導入 Agent，因為它能整合 topology、metrics、logs、events 與 deployment context。但調查、建議與修復應該維持不同權限層級。
- DevOps 不會因為 Agent 而消失。相反地，權限、平台介面、可觀測性、供應鏈、變更證據與回復能力會變得更重要。
- 自主程度不該一開始就拉滿。比較務實的路線是從唯讀調查開始，再逐步開放低風險、可回復且可觀測的寫入動作。
Keynote：Agent 不是功能，而是一套工作系統
Day 1：從寫程式走向完整交付閉環
第一天最清楚的訊息，是企業已經不太需要繼續辯論「要不要用 AI」，真正需要回答的是：要把 AI 放在哪些高價值工作上，以及怎麼控制風險。
如果每次任務都能取得需求、規格、文件、組織關係、歷史決策與回饋，Agent 才有機會累積脈絡，讓結果逐步改善。反過來說，如果人還是要在 email、文件、ticket、程式碼與監控系統之間手動搬資料，AI 再聰明也只是更快的搜尋與文字產生工具。
軟體交付被拆成三個連續階段：
- Write it right：用需求、規格、技術標準與測試脈絡約束程式碼產生，不只追求寫得快。
- Ship it fast：讓 review、security、test、release 與 deployment 跟上開發速度。
- Keep it modern：把舊系統分析、升級與技術債處理變成持續能力，而不是幾年一次的大型專案。
Kiro、AWS DevOps Agent 與 AWS Transform 分別落在這條閉環的不同位置。這個組合提醒我一件很實際的事：當 coding agent 大幅提高程式碼產量，原本藏在後段的瓶頸會立刻浮出來。測試環境不穩、審查排隊、權限混亂、發布流程脆弱，最後都會比寫程式本身更慢。
Agent 要進正式環境，也需要三層基礎：
- 安全與治理：決定可以讀什麼、做什麼，哪些動作一定要人工核准。
- 執行基礎：提供 runtime、memory、identity、tool integration、observability 與穩定的 orchestration loop。
- 資料與脈絡：把企業文件、結構化資料、歷史紀錄與組織知識放進同一個決策環境。
Amazon Bedrock AgentCore 處理的是 Agent 生產化所需的 runtime、memory、identity、policy 與 observability。Codex 則呈現另一個角度：軟體工程正在從 autocomplete、人機協作，走向把較完整的任務交給 Agent 執行。這時候真正值得衡量的，不是產生多少行程式碼，而是完成多少經過測試、審查與驗證的工作。
Day 2：可信任的 AI，底下仍然是可靠的基礎設施
第二天把焦點拉回資料在地、低延遲、韌性與企業信任。AWS Asia Pacific (Taipei) Region 提供三個 Availability Zone，讓台灣的 workload 有更好的在地架構條件，但 Region 與多 AZ 只是設計材料，不會讓系統自動符合監管要求，也不會自動變成高可用。
Nasdaq 的案例讓這件事更具體。當市場逐步朝接近全天候運作前進，維護窗口會縮小，跨時區 on-call、無停機變更、容量管理與回復能力都會變得更嚴格。這些不是模型問題，而是很典型的 SRE 與平台工程問題。
KBS 的應用則顯示，AI 原生流程不是把 AI 塞進現有步驟，而是重新設計內容擷取、辨識、分析、製作、直播與分發方式。對軟體交付來說也是如此。真正的改變不只是讓某個步驟快一點，而是重新思考需求、開發、驗證、部署與營運之間怎麼傳遞脈絡。
我把第二天的核心理解成一句話：可信任的 AI，不只取決於模型，也取決於資料、權限、基礎設施、監督與營運控制能不能一起成立。
Workshop：從知識工作一路做到 Kubernetes 維運
Amazon Quick：把日常判斷變成可重複的流程
Amazon Quick 的實作不是單純做 email 摘要，而是把 email、通訊、行事曆、文件、排程與個人判斷串成一條工作流程。
實際操作涵蓋：
- 連接 email、通訊與行事曆，設定工具使用前的授權偏好。
- 用 Activity Feed 集中未讀資訊、分類內容、產生摘要與建議動作。
- 建立 Scheduled task，定期整理信件與待辦事項。
- 把客戶、專案、活動優先順序等個人判斷寫成 Agent 可讀的規則。
- 建立專用 Agent，同時參考 email、行事曆、團隊資料與個人規則，提出排序與下一步建議。
- 使用 Browser Automation 操作網頁流程，或讓 Deep analysis 先提出研究計畫，再進行較長時間的資料蒐集與分析。
這裡最值得帶回 DevOps 的，不是信件分類，而是 把隱性判斷外顯化。Incident priority、change risk、service tier、escalation path、maintenance policy，很多時候都存在資深工程師腦中。Agent 要可靠地協助工作，這些規則必須變成有版本、有 owner、有適用範圍，也能定期覆核的 operational context。
如果規則只藏在某個人的 prompt 裡，它不會變成團隊能力，也很難治理。
Kiro CLI、EKS Auto Mode 與 AWS DevOps Agent：一條完整的實作路徑
另一個 Workshop 把開發、部署、擴縮、可觀測性與故障調查串在一起。
Kiro CLI 先透過幾個控制面建立工作邊界：
- Steering 保存專案、架構與部署規則。
- Skills 封裝可以重複使用的工作方法。
- MCP Servers 提供 AWS、EKS、文件與外部資料的工具介面。
- Permissions 與 trust 決定哪些工具可以自動執行，哪些動作必須逐次核准。
接著由 Kiro CLI 建立 React 前端，完成 build 與 test，再建立 Docker image、推送到 Amazon ECR、產生 Kubernetes resources，最後部署到 EKS Auto Mode。應用程式透過 Application Load Balancer 對外服務，並加入 Horizontal Pod Autoscaler 與 CloudWatch Container Insights。
這條流程證明 Coding Agent 已經可以跨越程式碼、本機工具、AWS API 與 Kubernetes API。但「成功部署」和「production-ready」仍是兩件事。正式環境還需要容器與相依套件掃描、完整 IAM 設計、負載測試、告警、SLO、備份、升級、rollback 與失敗復原驗證。
後半段改用 AWS DevOps Agent 調查 EKS 故障，包括 CPU 壓力、回應變慢、JVM memory、OOM 與 Pod restart。Agent 可以把 EKS resources、Pod logs、events、node health 與 CloudWatch telemetry 放進同一條調查路徑，從自然語言問題一路追到可能的 root cause 與 mitigation plan。
這裡有一條很重要的邊界：AWS DevOps Agent 對 EKS 的整合是唯讀的。它可以查 resources、讀 logs、看 events、整理原因與建議，但不能直接建立、修改或刪除 cluster resources。這不是限制，反而是很合理的導入起點。調查可以加速，實際變更仍然經過原本的 review、deployment、rollback 與 post-validation 流程。
AI Agent 會怎麼改變 DevOps 工作
1. 從寫自動化腳本，走向設計控制系統
傳統自動化通常由人先寫好固定步驟，再讓 pipeline 或 runbook 重複執行。Agent 則會根據目標與現況動態選擇工具。
DevOps 因此要往上一層設計：
- 任務意圖是什麼？
- 可以使用哪些資料與工具？
- 哪些動作需要核准？
- 成功條件和停止條件是什麼？
- 失敗時怎麼回復？
- 最後要留下哪些證據？
Shell、Terraform、Kubernetes 與 CI/CD 不會因此不重要。Agent 反而更依賴穩定、清楚且可預期的工具介面。原本含糊、缺乏錯誤處理、只有少數人知道怎麼用的 script，交給 Agent 後只會更難控制。
2. 開發速度提高，交付瓶頸會往後移
Coding Agent 可以加快程式碼、測試、容器與 manifest 的產生，但整體交付速度仍受 code review、security review、release window、環境容量與 incident response 影響。
如果只追蹤 coding throughput，很容易得到錯誤結論。更值得一起觀察的是：
- Lead time
- Review time
- Change failure rate
- Rollback rate
- Incident rate
- 修復後驗證時間
當前段突然加速，後段控制若沒有跟上，風險只會更快堆積。
3. Incident investigation 會比自動修復更早成熟
On-call 最耗時間的部分，常常不是執行修復指令，而是先弄清楚服務拓樸、找到正確的 dashboard、比對 deployment、查 logs、看 events，再排除彼此矛盾的線索。
Agent 很適合把這些資訊串起來，讓調查從「哪個服務變慢」開始，而不是要求人先知道正確的 CloudWatch query 或 Pod 名稱。
但 investigation、recommendation 與 remediation 應該是三個權限層級。我的理想導入順序會是：
- 先開放唯讀資料，要求每個 finding 都附來源。
- 讓 Agent 提出修復方案與風險，但不直接執行。
- 低風險動作改成核准後執行。
- 只有在可回復、可觀測且累積足夠成功紀錄後，才考慮自動執行。
4. Context 與 telemetry 會成為平台產品
Agent 的輸出品質取決於它拿到的脈絡。Service catalog、owner、dependency、SLO、runbook、deployment history、feature flag、incident、postmortem 與成本資料，以後不只是文件，而是 Agent 執行工作的輸入。
這些資料也需要品質管理。過期 runbook、錯誤 owner、缺漏 telemetry，都可能讓 Agent 很快得出錯誤答案。平台團隊除了建立 chat 或工具入口，也要處理資料新鮮度、引用來源、權限與可觀測性。
5. MCP 與工具供應鏈會成為日常風險
MCP 讓不同 Agent 用一致方式連接檔案、AWS、Kubernetes 與各種外部服務，但 MCP 本身不是安全邊界。MCP Server 仍可能執行本機程式、讀寫檔案、取得 credentials、連線外部服務或修改雲端資源。
正式環境至少要確認：
- 來源、版本與更新方式
- 實際暴露的 tool list
- IAM 與 credentials handling
- Filesystem 與 network access
- 操作 logs 與撤銷方式
- 寫入範圍與人工核准點
trust-all 類設定只適合可丟棄的沙盒，不適合拿來換取正式環境的方便。
6. Agent 越快，證據鏈越不能省
Agent 可以在短時間內跨越多個系統，因此除了 ticket、diff、review、test 與 deployment log，還要能回答：
- 它讀了哪些 context？
- 呼叫了哪些 tools？
- 採用了哪些假設？
- 產生或修改了哪些 artifacts？
- 人在什麼時間點核准了什麼？
- 部署後的系統狀態是否符合預期？
沒有這條證據鏈，就無法區分「Agent 說完成了」與「系統真的完成了」。
7. 模型成本與可用性也會進入 SRE 範圍
Agent 在規劃、執行與自我檢查時，可能在單一任務中多次呼叫模型。規模放大後，token 使用量、model latency、quota、throttling、tool failure、retry 與 session duration 都會影響成本和可靠度。
這類 workload 最後也需要 SLI、SLO、告警、成本歸屬與人工 fallback。否則 Agent 會從提升效率的工具，變成新的單點故障。
這些工具各自適合放在哪裡
| 工具或平台 | 適合處理的工作 | 需要自己守住的邊界 |
|---|---|---|
| Amazon Quick | 串接 email、行事曆與企業資料，建立摘要、排程、自訂 Agent、瀏覽器操作與深度分析流程 | 資料授權、排序規則、排程失敗處理與高風險輸出覆核 |
| Kiro CLI | 依專案規則與工具介面完成程式碼、測試、容器與部署 artifacts | 規格品質、tool trust、IAM、供應鏈、測試深度與 production readiness |
| Amazon EKS Auto Mode | 管理更多 node、compute autoscaling、load balancing、networking 與 storage 基礎元件 | Application availability、security、monitoring、VPC 與 EKS 設定仍是自己的責任 |
| CloudWatch Container Insights | 蒐集與呈現 container、Pod、Node 與 cluster telemetry | Retention、告警、dashboard、SLO、成本與事件脈絡 |
| AWS DevOps Agent | 關聯 topology、metrics、logs、events、code 與 deployment，協助 incident investigation | EKS 整合為唯讀；實際變更、rollback 與驗證仍走既有流程 |
| AWS Transform | 協助 legacy analysis、文件整理、程式轉換與系統現代化 | 功能等價性、資料遷移、整合測試、效能、資安與切換證據 |
| Amazon Bedrock AgentCore | 提供 Agent runtime、memory、identity、policy、observability 與 evaluation 能力 | Agent logic、工具權限、資料品質、評估集與失敗處理 |
| Codex、Claude 等 Coding Agent | 分析 codebase、修改程式碼、執行測試並整理結果 | 規格、驗收條件、repository 權限、review、secret handling 與部署授權 |
| MCP | 讓 Agent 與不同工具用共同協定互通 | 來源、工具能力、credentials、network 與 filesystem access 都要另外治理 |
如果要在團隊裡開始，我會這樣做
- 選一條窄而高價值的流程：例如已知 incident 的唯讀 replay、pull request 風險摘要、變更前檢查或每日營運摘要。
- 建立人工 baseline：先記錄處理時間、正確率、誤判、人工步驟、成本與既有風險。
- 把隱性知識外顯化：整理 service owner、SLO、runbook、severity、escalation 與 rollback 規則，並設定版本和 owner。
- 從唯讀工具開始：要求 finding 附來源，測量可追溯性與人工覆核時間。
- 把寫入拆成小能力：限制 AWS account、Region、cluster、namespace、repository、branch、filesystem path 與 tool allowlist。
- 用歷史事件做盲測：挑選已有 postmortem 的 incidents，隱藏根因，評估 finding precision、調查時間、成本與錯誤建議。
- 保留完整變更證據：讓 diff、test、scan、deployment output、監控變化、rollback 與 post-validation 都能回查。
- 最後才提高自主性：只在低風險、可回復、可觀測且長期表現穩定的工作上擴大自動核准範圍。
結語
AWS Summit Taipei 2026 讓我更確定，DevOps 接下來面對的不是「AI 會不會取代工程師」，而是軟體交付與維運將從固定步驟的自動化，走向能根據脈絡規劃並使用工具的執行模式。
Agent 讓程式碼、部署與調查變快，也會讓錯誤權限、過期文件、缺漏監控與不完整驗證更快進入正式環境。真正可持續的做法，是把 Agent 放進規格、最小權限、change management、observability、testing 與 rollback 的系統裡，而不是用一個聊天介面繞過它們。
所以我不認為 DevOps 的角色會縮小。它會更靠近平台與控制系統的設計者：提供一條讓人與 Agent 都能安全完成工作、留下證據，並在失敗時回復的 paved path。