摘要： AWS 於 2026 年 9 月 2 日在機器學習部落格提出支援營運的兩層式生成式 AI 架構。第一層以 Bedrock 與 Strands Agents SDK 把影片轉成 SOP、分析工單並呈現流程瓶頸，第二層用 Amazon Quick 做負載管理、工單分類與 SLA 風險預測。設計保留人類審核與稽核軌跡，但文章沒有給出具體效能數據或成本估算。
支援單位的現場很少出現單一的大型事故，更常見的是許多細碎效率缺口一層層疊上來：流程早就改了、文件還停在舊版；工單湧入的速度快過找到指引的速度；資深同仁被例行問題占滿而成為卡點；主管能看到的只有落後於現況的指標。AWS Machine Learning Blog 在 2026 年 9 月 2 日刊出的〈Modernizing and scaling support operations with generative AI on AWS〉，端出的是一套以 Amazon Bedrock 為核心的兩層式架構，切入點放在流程本身，而不是去最佳化某一張工單或某一份文件。
這篇並非紙上推演，它直指支援營運的痛處：SOP、錄影檔與資深員工腦中的經驗各自為政，分析師因此把大量時間花在找資料，而不是解決問題。AWS 端出的組合是：把影片轉成 SOP、用 RAG 引導工單處理、以 ML 預測 SLA 風險，再加上 agentic workflows 自動處理標籤、留言與狀態更新，同時以 human-in-the-loop 守住準確度。
問題的核心：知識留不下來，流程也看不見
AWS 文中列出的幾個現象，值得正在做產品的人細想。首先是 SOP 的撰寫單位通常是「功能」：各團隊只寫下自己那一段，跨部門的端到端視角因此缺席。一旦流程調整，文件更新落後，文件與實務之間的落差只會越拉越大。更麻煩的是，許多營運知識是存在訓練錄影與 troubleshooting 會議裡的，會議一散，知識就被封在冗長的影片中，團隊往往得回頭重看舊影片，才能拼回當初的做法。
其次，工單能不能處理得好，很大程度上取決於個人資歷。新人只有 escalation 一途，資深的人則被 routine 問題綁住，於是形成瓶頸。就算找到了 SOP，那份 SOP 也往往只反映單一功能的角度，分析師還得自己把多份文件與 tribal knowledge 湊起來。最後，管理層手上的報表屬於落後指標，反映不出工作流的即時狀態，瓶頸被察覺得太晚，容量決策也跟著延後。
這幾個問題彼此扣在一起：知識碎片化造成 workload 不均，workload 不均又讓 mentoring 取代了標準化，最後想擴張就只能加人，而不是改流程。AWS 的切入順序是：先讓知識能從營運活動中被自動捕捉，再讓系統依工單內容自動找出對應的指引，最後把流程攤開來，讓管理者看得見 handoffs 與 dependencies。
兩層架構：執行與分析綁在一起
AWS 的設計分成兩個彼此緊密耦合的層次，而非各自獨立的工具。第一層是 operational intelligence workspace，對象是分析師的日常工作，裡面有三項能力：
- Video-to-SOP：把訓練錄影與系統 walkthrough 自動轉成結構化 SOP。作法是透過 Amazon Bedrock 上的多步驟 model invocations，將畫面內容、口頭說明與介面操作轉為逐步程序，並把截圖與驗證指引一併嵌進去。
- Ticket analyzer：以 NLP、semantic retrieval 與 RAG 分析 incoming tickets，比對出相關程序，產出帶有情境的解決指引。它把檢索到的 SOP 與 policy documents 和 foundation models 結合，生成符合組織標準的建議。另外，它透過 AWS Strands Agents SDK 建立 agentic workflows，讓多個 autonomous agents 分工完成 ticket tagging、commenting、status updates，但全程都在 human-in-the-loop 框架內運作。
- Value stream intelligence：把解決流程畫成互動式 swim lane maps，呈現工作如何在團隊與系統之間流動，並把瓶頸標示出來，讓 stakeholders 很快看出 delays、approval friction 與 coordination gaps。
第二層是 analytics and decision intelligence layer，立基於 Amazon Quick，為分析師與主管提供即時洞察。內容包括 workload management dashboards（呈現工單如何依 volume 與 complexity 分配）、ML-based ticket categorization 與 SLA risk prediction（替高風險案件打分數），以及 embedded agentic experience（由 Amazon Quick agent 提出 workload rebalancing 建議，再經 supervised workflows 執行，並留下 audit trails）。
重點是這兩層並非各做各的，而是構成一個 compounding loop：Video-to-SOP 把原本鎖在錄影與 tribal expertise 裡的知識取出來，Ticket analyzer 拿這些結構化知識支援即時解決，Value stream intelligence 則把 function-by-function SOP 看不到的端到端流程模式攤在陽光下。
給 product builders 的提醒：先把流程理順，再談 AI
對於正在評估生成式 AI 的團隊，文章給出幾點實用提醒。第一，別急著把 AI 工具搬進來，先檢查知識到底有沒有被好好捕捉。AWS 的 Video-to-SOP 之所以有用，在於它把「重看錄影」這種隱形成本轉為自動化流程，知識才得以持續累積。如果你的團隊仍靠 wiki 與 shared drives 四散存放文件，AI 進來只會讓混亂跑得更快。
第二，RAG 並非萬靈丹，它得靠良好的知識結構才站得住。Ticket analyzer 能給出準確建議的前提，是 SOP 與 policy documents 被有系統地整理過，而不是堆著一堆過時文件。AWS 強調「從營運活動中捕捉知識」，這種做法比事後靠人工整理更可靠。
第三，agentic workflows 的用處在於接手 routine 操作，但 human-in-the-loop 的設計不能省。AWS 讓 agents 去做 tagging、commenting、status updates，同時保留人類審核，這在合規要求高的產業尤其關鍵。
最後，analytics 層的 SLA risk prediction 是個提醒：與其等工單真的 breach 了才處理，不如用 ML 先把風險算出來，讓團隊能 proactive 地 prioritization。這背後要靠資料品質支撐，AWS 也坦言 intake 階段資料不完整是挑戰，因此方案本身必須能處理 messy data。
導入時的現實考量：先從單一 use case 做起
AWS 在文中以一個真實營運 use case 做示範，並指出這套做法可延伸到金融服務、醫療保健、物流、製造與能源等產業。對大多數團隊來說，並不需要一次到位。可以先挑 Video-to-SOP 或 Ticket analyzer 其中一項能力試跑，確認知識捕捉與檢索真的帶來效益，再往 analytics 層接上去。
有幾點需要留意：文章沒有給出具體的效能數據或成本估算，而這正是評估 ROI 時最關鍵的資訊。另外，AWS Strands Agents SDK 與 Amazon Quick 都屬於 AWS 生態系服務，若團隊本來就在 AWS 上，整合會順得多；否則就得把遷移成本算進來。
整體來看，這篇文章提供的是一份可參考的藍圖：生成式 AI 的價值不在取代人，而在讓知識流得動、流程看得見、風險能預測。對 product builders 而言，關鍵是先把知識捕捉與流程對齊的機制設計好，再讓 AI 在其中扮演加速器，而不是期待它憑空生出價值。