馬來西亞最新 5G 網絡供應商 U Mobile，同 AWS 同 AWS 合作夥伴 Axrail 一齊建咗一個叫 AiDaH（AI-Driven Agentic Helpdesk，AI 驅動代理式客服系統）嘅平台，架喺 Amazon Bedrock AgentCore 上面，目標係幫內部營運團隊減少人肉排查。平台啟動後喺一年內，已覆蓋 6 個業務部門超過 150 個文件化嘅營運場景，公司內部計量顯示，關鍵類別嘅故障工單量下跌最多 84.5%。
問題出喺邊
電信公司嘅 IT 系統散佈喺本地同雲端，包括業務支援系統、客户關係管理系統、流動號碼可攜性平台、大數據分析同基礎設施監控工具。以前即使係最普通嘅診斷，客户服務人員都必須手動查日誌、查用户資質、再對照知識庫入面嘅業務政策，每次查詢都係一次上下文切換。如果揾唔到原因，就升級俾後端 IT 團隊，用户就要再等多耐。傳統自動化工具可以幫寫回覆，但唔幫跨系統協調、分析結果、提出修正建議。
Agent 做乜
資料圖片：Pixabay
以一個例子：用户無法購買數據加值包。AiDaH 會自動拉取接口日誌入面嘅錯誤代碼、查詢業務支援系統嘅 API 確認用户資格、再對照內部知識庫嘅相關業務政策，先至草擬回覆。呢個就係佢哋所講嘅「agentic architecture」——唔單止回答問題，而係跨系統執行多步診斷同建議修正。
邊個揀嘅呢個 stack
U Mobile 資訊系統部（ISD）話，揀 AgentCore 有兩個主要原因：managed agent runtime（託管代理運行時）唔使自行運維代理基礎設施；內建記憶（built-in memory）可以喺多輪對話間保持上下文，唔使另建狀態儲存。佢哋策略分三層：Reach（代理實時協調多個後端系統）、Depth（多步 root cause analysis 嘅 chain-of-thought reasoning，即鏈式思維推理）、Community（安全多租户框架，原文截斷）。
阿調搞兩下
84.5% 呢個數字係 U Mobile 自己計嘅，冇獨立第三方驗證。佢哋冇披露呢 150 個場景邊啲已完全自治、邊啲仲要人介入；84.5% 覆蓋邊幾「關鍵類別」、總工單量點計，都冇講。呢個係廠商（AWS）嘅 blog，唔係 U Mobile 獨立公告，角度偏向賣 AgentCore 呢點要留意。電信業唔似銀行，工單解決錯誤通常唔至傷亡，所以佢哋對「完全無人工介入」嘅容忍度會高啲——但點樣界定「解決」、錯誤自動處理嘅風險點，材料都冇講。
