Cornerstone OnDemand 如何藉助 Amazon Bedrock 將資料庫診斷時間縮短 78%

Cornerstone OnDemand, Inc. (Cornerstone) 是全球領先的員工就緒方案供應商，服務遍及 186 個國家的 1.4 億名用戶。公司建立了一套多代理 AI 系統，將資料庫營運從被動救火轉變為主動、自我協調的工作流程。這套名為 Orion AI 的系統採用 Amazon Bedrock 和 Strands Agents；後者是 AWS 的開源代理編排框架，用於協調專用代理。

在 Orion AI 推出前，Cornerstone 的 Enterprise DataOps 團隊每宗資料庫事件最多要花 45 分鐘，手動查詢系統檢視並交叉比對日誌，之後才將事件交接給其他團隊。採用 Orion AI 後，資料庫診斷時間由 45 分鐘縮短至 10 分鐘，減少 78%。一支三人團隊在六個月內交付了這套系統。

本文將介紹 Cornerstone 面對的營運問題、Orion AI 的設計方式、所衡量的成效，以及其他團隊可沿用的設計決策。

營運挑戰

在 Orion AI 推出前，Cornerstone 的 Enterprise DataOps 團隊採取被動應對方式，反覆面對四項痛點：

資料庫效能調查每宗約需 45 分鐘，工作分散在多種工具和系統檢視之間。
資料庫生命週期工作流程需要 10 個或以上的手動步驟，從建立連線到傳達狀態更新均須人手處理。
網站可靠性工程（SRE）團隊與資料團隊之間的報告有 15 分鐘延遲。
重複且重疊的警示造成大量雜訊，掩蓋了重要訊號。

這些問題令工程師把時間花在手動協調，而非解決問題上。

解決方案：Orion AI

Orion AI 是一套多代理系統，由協調代理（元編排器）將工作分派給按中樞輻射式拓撲排列的專用子代理。工程師透過網頁應用程式與系統互動，在他們原本協調營運工作的同一處提出問題及批准操作。各代理負責基礎架構監控、資料庫診斷、資料庫生命週期操作、客戶分析，以及知識導向支援。

建置過程遵循兩項原則：依據共同責任模型使用 AWS 控制措施保障資料私隱，以及與現有營運工具深度整合。Amazon Bedrock 提供基礎模型的託管存取服務，而 Strands Agents 則提供編排層。

成效

Orion AI 在診斷速度和準確度方面帶來可量化的改善，亦讓團隊毋須再進行手動協調。Cornerstone 透過自動化處理手動流程中的瓶頸，並簡化跨團隊工作流程，取得以下成效。

指標	之前	之後	改善幅度
資料庫診斷時間	45 分鐘	10 分鐘	快 78%
手動生命週期步驟	10+ 個步驟	1 次互動	減少 70%
`SRE-to-data-team` 報告延遲	15 分鐘	瞬間完成	即時
重複警示	基準數量偏高	經篩選	減少 65%（中位數）

加快效能問題排查

縮短資料庫診斷時間，是 Orion AI 至今帶來的最大單項效率提升。過去，工程師要手動連線至受影響的 SQL Server 執行個體，查詢系統檢視以找出阻塞鏈和等待類型，交叉比對日誌以找出長時間執行的查詢，再綜合證據形成根本原因假設。每宗事件平均約需 45 分鐘。

Orion AI 由三個專門 Agent 分擔調查工作，各自負責不同階段。除了診斷，Orion AI 還會跟進問題直至完成修復：找出根本原因、建議修復方法，並建立已填妥資料、指派給合適當值工程師的 Jira 工單。原本需要四個步驟的手動交接流程，現在縮減為單次互動。

自動化資料庫生命週期管理

過往需要超過 10 個手動步驟的工作，從建立資料庫連線、執行跨系統查詢到傳達狀態更新，現在只需透過一次自然語言互動即可完成。Orion AI 會找出合適的工具和資料來源、執行跨系統查詢、驗證結果，並提供整合回覆。從工程師的角度來看，工作已縮減為向 Orion AI 輸入提示詞，並驗證它回報的調查結果。

即時監察與減少警示疲勞

Orion AI 消除了 15 分鐘的 SRE-to-data-team 報告延遲，並以持續掌握跨系統狀況取代定期手動檢查。

Orion AI 透過去重、閾值篩選及跨訊號關聯分析，將重複警示減少了中位數 65%。過往每產生 10 個警示，現在只有 3–4 個會送達工程師。警示會直接傳送至負責團隊，毋須經過中間警示層。

關鍵設計原則

有三項設計決策塑造了 Orion AI，你也可以將它們應用於自己的多 Agent 專案：

按領域而非任務複雜程度拆分 Agent：每個 Agent 只整合一小組工具，並專注於一個營運領域。這樣可讓模型的上下文保持聚焦，並提升工具選擇的準確度，而非要求一個通用 Agent 包辦所有工作。
預設採用關鍵字路由，必要時改用語義搜尋：可預測的請求會以關鍵字配對，以提升速度；含糊不清的請求則改用語義搜尋，以確保準確性。這樣可維持低延遲，同時確保較難查詢的結果正確。
將對話記憶限制於工作階段，查詢即時指標時則略過記憶：持續性記憶支援多輪對話，但營運相關查詢一律讀取系統目前狀態。查詢即時指標時略過記憶，有助避免過時資料影響即時診斷結果。

架構概覽

Orion AI 以容器化服務形式部署於 Amazon Elastic Container Service (Amazon ECS)。用戶透過網頁應用程式互動；該程式會將每項請求路由至合適的 Agent、呼叫所需工具，並組合回覆。下圖展示這些元件在 AWS 雲端中的連接方式。

圖 1：Orion AI 架構：Amazon ECS 上的元協調器會將請求路由至專用 Agent；這些 Agent 透過 Portal-Tools MCP 伺服器連接資料來源，並使用 Amazon Bedrock 提供的模型、長期記憶及檢索增強生成

深入瞭解架構

前述設計原則在架構中均有具體體現。本節其餘部分將逐一介紹 Orion AI 的核心元件。

使用 Strands Agents 建立中心輻射式模式

Orion AI 透過少量 Strands Agents 基本元件呈現其拓撲。Agent 類別是專用 Agent 和元協調器的基本構件。每個 Agent 的工具都是以 @tool 裝飾器標記的一般 Python 函式。這個裝飾器會根據函式的類型提示和文件字串推導工具規格，因此無須另行維護結構描述。BedrockModel 封裝每個 Agent 所使用的 Amazon Bedrock 模型，而 MCPClient 則將 Agent 連接至外部工具伺服器。

拓撲：

中樞是一個擔任元協調器（TaskExecutor）的 Strands Agent。它不包含任何領域工具，只有路由工具（find_relevant_agents、call_agent）和控制流程工具（emit_plan_step、emit_confirmation_gate），讓它可以逐步推理用戶的要求。
輻射端是獨立的 Agent 執行個體，透過以裝飾器為基礎的登錄表按需載入。每個執行個體都有自己的模型、領域工具和本地化系統提示詞。

執行期間，中樞會透過已註冊的 call_agent 工具按名稱呼叫專用 Agent。每個專用 Agent 都會執行自己的工具呼叫循環，並將整理後的文字傳回中樞，由中樞組合成最終回應。

混合式路由

Orion AI 採用關鍵字優先路由，並以語義搜尋作為後備。約 80% 的查詢會透過記憶體內的關鍵字快速路徑，在不到一毫秒內完成解析。當關鍵字不足以判斷意圖時，系統會改用由 Amazon Titan Text Embeddings V2 支援的語義搜尋，按含義進行路由。如需瞭解各 AWS 區域提供的模型，請參閲 Amazon Bedrock 各 AWS 區域支援的模型。

不適合直接呼叫工具時，系統會啟動後備鏈：Amazon Bedrock Knowledge Bases 這項完全受管理的檢索增強生成（RAG）功能會擷取操作文件，讓回應以經批准的程序為依據，而非在缺乏上下文的情況下生成。

特定領域 Agent 及其職責界限

Orion AI 使用 13 個特定領域 Agent。三個 SQL Server Agent 展示瞭如何將領域拆分對應至實際調查的各個階段：

資料庫診斷 Agent 會找出阻塞鏈、等待類型和長時間執行的查詢，再將技術結果轉化為業務影響分析，並提出修復建議。它回答「目前發生甚麼事？這代表甚麼？」
工作階段阻塞分析 Agent 使用推理模型進行多步調查，梳理阻塞鏈並找出根本阻塞來源。它回答「為何會發生這種情況？根本原因是甚麼？」並提供按優先次序排列的建議，涵蓋立即終止工作階段以至較長遠的架構修正。
即時 SQL 診斷 Agent 透過 Cornerstone 的 DATAOPS API 直接查詢 SQL Server 執行個體，取得即時阻塞數據並分析高 CPU 使用率的工作階段。它回答「此刻的實際情況是甚麼？」

其餘 Agent 同樣遵循職責範圍明確的原則，分別負責基礎架構監察、營運分析、資料庫生命週期管理、客戶分析、從操作手冊擷取知識、通知路由、複合查詢拆解、Availability Group 接聽程式解析，以及模型連線預熱。

工具整合與服務連線

Orion AI 透過兩種模式連接資料來源：

Model Context Protocol (MCP) 用於多個 Agent 共用的工具（例如即時 SQL 診斷）。Strands @tool 函數會透過可串流 HTTP 呼叫 MCPClient，連接至 Portal-Tools MCP 伺服器；該伺服器會連接 SQL Server 和 DATAOPS API。Jira 整合亦透過外部 Atlassian MCP 工具採用相同方式。
直接呼叫 SDK 或 REST API，用於不需要共用 MCP 介面的來源。這包括指標和儀錶板、值班安排，以及透過 AWS SDK for Python (Boto3) 存取 Amazon Bedrock Knowledge Bases。

這種分工讓每個 Agent 都能按其資料來源採用最輕量合適的機制，同時由 MCP 伺服器集中管理多個 Agent 共用的工具。這些連線均透過 TLS 傳輸，而 MCP token 和 REST API 授權等憑證會在每次請求中提供，不會嵌入 Agent 程式碼。

對話記憶

Amazon Bedrock AgentCore 是一個可配合任何框架或模型，大規模建置、連接及最佳化 Agent 的平台，並提供跨工作階段記憶層。Orion AI 透過中央記憶管理器協調上下文；該管理器會並行讀取三個層級，每個層級均設有各自的逾時設定和 token 配額。

Orion AI 透過三個層級協調上下文。短期記憶會將同一工作階段的上下文保存在 Amazon DynamoDB 中，並預設採用靜態加密；同時配合由 Amazon Nova 2 Lite 非同步產生、持續更新的對話摘要。長期記憶則透過 AgentCore memory（Amazon Bedrock AgentCore 的一項功能）提供跨工作階段檢索，並按用戶 ID 劃分命名空間。任務完成時，Orion AI 會呼叫 create_event，觸發自動擷取、摘要及整合。第三個層級是 Agent 間記憶，這是一個短暫存在記憶體中的暫存區，會在單一任務內的子 Agent 步驟之間傳遞分析結果。

記憶管理器會在 500 毫秒的硬性逾時上限及 4,000 個 token 預算內，從各層級擷取資料，並由最近最少使用快取提供支援。當請求涉及系統目前狀態時，Agent 會完全略過記憶，直接讀取即時資料，避免過時的上下文幹擾即時診斷。

負責任 AI 與防護機制

由於 DataOps 安全性取決於特定領域規則，例如哪些資料庫操作會造成幹擾，團隊因此建立自訂防護邏輯，而非依賴通用內容過濾器。Orion AI 從四個層面實施控制：

提示詞層級的安全限制會注入每個 Agent 的系統提示詞中，阻止提出危險建議（例如終止關鍵資料庫程序），並強制採用不會造成幹擾的方法。
人工介入確認關卡會暫停破壞性操作，直至用戶在五分鐘內確認；若逾時，預設拒絕。
用於輸入驗證的自訂防護模組（長度限制、阻擋提示詞注入和 SQL 注入）、輸出淨化（遮蔽機密資料和個人資料）、速率限制、角色型存取控制，以及逐次請求成本追蹤。
路由層級防護會阻止系統依據記憶回答操作查詢，並強制在詢問目前狀態時即時執行工具。

可觀測性

Orion AI 使用 AWS 標準可觀測性服務進行監察及除錯。Amazon CloudWatch 提供指標及結構化日誌，用於監察路由信心度、延遲及代理程式呼叫活動。AWS X-Ray 會追蹤代理程式執行期間的分散式呼叫，讓端到端的請求路徑清晰可見。

經驗總結

讓 Orion AI 得以實現的設計決策，其他團隊亦可採用。按領域拆分代理程式，讓每個代理程式只需整合範圍較窄的工具，避免單一模型的上下文過於臃腫。預設採用關鍵字路由，並以語義搜尋作後備，既能降低延遲，亦不會犧牲對含糊請求的準確度。將對話記憶限制在工作階段內，並在處理即時指標時略過記憶，則可確保即時診斷結果可靠。

團隊亦作出了務實的基礎架構選擇。他們在 Amazon ECS 上部署運算資源，因為項目開始時，Amazon Bedrock AgentCore runtime（Amazon Bedrock AgentCore 的一項功能）尚未提供；目前他們正評估日後將其作為遷移選項。如果你現在着手開發，請為自己的技術堆疊權衡同樣的取捨：先採用目前穩定且可用的方案，並隨着託管功能逐漸成熟再重新評估。

結論

Orion AI 將資料庫診斷時間由 45 分鐘縮短至 10 分鐘，省去 70% 的手動生命週期步驟，並減少 65% 的警報雜訊。一支三人團隊在六個月內以 Amazon Bedrock 建成 Orion AI。其他營運團隊亦可採用帶來這些成果的模式：按領域劃分代理程式、混合式路由，以及限制於工作階段的記憶，並在處理即時指標時略過記憶。

如要開始在 AWS 上使用多代理程式協調，請參閲AWS Solutions Library 指引。

作者簡介

Harpreet Chawla

Harpreet Chawla（Cornerstone OnDemand, Inc.）是策略資料與 AI 基礎架構高級主管，在推動全球企業大規模數碼轉型及營運卓越方面擁有逾 20 年經驗。他專門在 AWS 上擴展關鍵任務數據平台，同時推動轉向 Agentic AI 和自主平台工程。

Derek Ziehl

Derek 是 AWS 資深技術客戶經理（TAM）。他具備設計大型網絡系統及管理雲端遷移的經驗。身為 TAM，他樂於協助客戶在 AWS 上運行具韌性且經過最佳化的工作負載。

Madhu Pai

Madhu 是 AWS 負責生成式 AI 與機器學習的首席專業解決方案架構師，協助獨立軟件供應商及企業將 AI 從實驗階段推展至大規模生產應用。他與業界不同機構合作，協助它們克服採用 AI 時面對的實際障礙：管治、合規、數據準備度及信任。憑藉豐富的實戰經驗，Madhu 以務實且不偏向任何供應商的角度，探討團隊如何負責任地擴展 AI。

Nishchai JM

Nishchai 是 Amazon Web Services 的資深解決方案架構師，專門為獨立軟件供應商（ISV）提供數據、分析及生成式 AI 方面的支援。他協助客戶將數據平台現代化、建構大型分散式應用程式，並發掘雲端 AI/ML 工作負載的價值。