Cornerstone用Amazon Bedrock打造多智能体系统，数据库诊断时间缩短78%
AWS博客披露，Cornerstone OnDemand的Orion AI将单次数据库故障诊断从45分钟降至10分钟，手动生命周期步骤减少70%，重复告警中位数减少65%。该系统由三人团队在六个月内完成。
AI解读：AWS博客文章称，Cornerstone OnDemand构建了一个名为Orion AI的多智能体系统，用于将数据库运维从被动应对转变为主动编排。该系统基于Amazon Bedrock和AWS开源智能体编排框架Strands Agents，由三人团队在六个月内交付。
据该文章，Orion AI将单次数据库故障诊断时间从约45分钟降至10分钟，降幅78%；手动数据库生命周期步骤从10步以上减少为1次交互，降幅70%；SRE与数据团队之间的报告延迟从15分钟变为实时；重复告警经去重、阈值过滤和跨信号关联后中位数减少65%，每10条告警中仅3至4条到达工程师。
文章将上述结果归因于三项设计原则：按运维域而非任务复杂度拆分智能体、默认关键词路由并以语义搜索作为回退、对话记忆按会话划定范围且对实时指标绕过记忆。文章还提到，由于Amazon Bedrock AgentCore运行时在项目启动时尚未可用，团队选择将计算部署在Amazon ECS上，目前正在评估未来迁移至AgentCore的可能性。
AWS在其机器学习博客发布文章，介绍了Cornerstone OnDemand构建多智能体AI系统Orion AI的过程。该文章由Derek Ziehl撰写，署名机构为AWS Machine Learning。
文章称，Cornerstone OnDemand是一家workforce readiness解决方案提供商，服务186个国家的1.4亿用户。其企业DataOps团队此前处理单次数据库性能调查平均需要约45分钟，需手动查询系统视图、交叉比对日志并在团队间交接。
Orion AI使用Amazon Bedrock和Strands Agents构建，采用中心辐射型拓扑：一个元编排器（meta-orchestrator）将任务分派给多个专业子智能体。工程师通过Web应用提问并批准操作。
文章给出的量化结果为：数据库诊断时间从45分钟降至10分钟，减少78%；手动生命周期步骤从10步以上降至1次交互，减少70%；SRE与数据团队之间的报告延迟从15分钟变为实时；冗余告警中位数减少65%。
Orion AI要解决的四个运维痛点
文章将Cornerstone此前的运维模式描述为被动响应，并列出四项重复出现的问题：数据库性能调查每次约45分钟，涉及多个工具和系统视图；数据库生命周期工作流需要10个以上手动步骤，从建立连接到沟通状态更新；SRE团队与数据团队之间的报告存在15分钟延迟；冗余和重叠告警产生噪音，掩盖了重要信号。
文章称，这些问题共同导致工程师将时间花在手动协调上，而非解决问题本身。
- 单次数据库性能调查约45分钟
- 数据库生命周期工作流需10个以上手动步骤
- SRE与数据团队报告延迟15分钟
- 冗余告警产生噪音
系统结构与设计原则
Orion AI被部署为Amazon ECS上的容器化服务。用户通过Web应用提交请求，请求被路由到相应智能体，调用所需工具并组装响应。
文章称，系统包含13个领域特定智能体，涵盖基础设施监控、数据库诊断、数据库生命周期操作、客户分析、知识驱动支持等。三个SQL Server智能体分别负责：呈现阻塞链、等待类型和长时间运行查询并转化为业务影响；运行多步骤调查，将阻塞链映射到根阻塞者并划分优先级；通过Cornerstone的DATAOPS API直接查询SQL Server实例，获取实时阻塞数据和高CPU会话分析。
文章列出三项设计决策：按领域而非任务复杂度拆分智能体，使每个智能体携带窄范围工具集成；默认使用关键词路由，模糊请求回退到语义搜索，约80%的查询通过内存关键词快速路径在1毫秒内完成解析，关键词不足时使用Amazon Titan Text Embeddings V2进行语义搜索；对话记忆按会话划定范围，但对实时指标绕过记忆，操作性问题始终读取当前系统状态，防止过期数据污染实时诊断。
在工具集成方面，Orion AI通过两种模式访问数据源：对多个智能体共享的工具使用Model Context Protocol（MCP），例如实时SQL诊断通过Strands工具函数经可流式HTTP调用Portal-Tools MCP服务器，再访问SQL Server和DATAOPS API；Jira集成同样通过外部Atlassian MCP工具完成。对不需要共享MCP接口的数据源，直接使用SDK或REST API调用，包括指标和仪表板、值班排班以及通过AWS SDK for Python（Boto3）访问Amazon Bedrock Knowledge Bases。
- 元编排器持有路由工具（find_relevant_agents、call_agent）和控制流工具（emit_plan_step、emit_confirmation_gate），不持有领域工具
- 共13个领域特定智能体
- 约80%查询通过内存关键词快速路径在1毫秒内完成解析
- 记忆管理器在500毫秒硬超时和4000 tokens预算内跨层检索
- 三个SQL Server智能体分别回答“正在发生什么”、“为什么发生及根因是什么”、“当前真实情况是什么”
效果衡量与安全控制
文章称，除诊断时间外，Orion AI还把此前需要四个步骤的手动交接缩减为一次交互：识别根因、推荐修复方案、创建填充好的Jira工单并分配给正确的值班工程师。
在负责任AI方面，文章称团队没有依赖通用内容过滤器，而是构建了定制护栏逻辑，应用于四个层面：提示级安全约束注入每个智能体的系统提示，阻止危险建议（例如终止关键数据库进程）并强制非破坏性方法；人工确认门暂停破坏性操作，用户需在五分钟窗口内确认，超时默认拒绝；定制护栏模块负责输入验证（长度限制、提示词和SQL注入拦截）、输出净化（遮蔽密钥和个人身份信息）、速率限制、基于角色的访问控制和按请求成本追踪；路由级保护阻止从记忆回答操作性查询，强制对当前状态问题执行实时工具调用。
可观测性方面，Orion AI使用Amazon CloudWatch提供指标和结构化日志，覆盖路由置信度、延迟和智能体调用活动；AWS X-Ray追踪跨智能体执行的分布式调用，提供端到端请求路径可见性。
文章最后提到，团队将计算部署在Amazon ECS上，原因是项目启动时Amazon Bedrock AgentCore运行时尚不可用，目前正在评估将其作为未来迁移选项。
- 人工确认门超时默认拒绝
- 每10条告警中仅3至4条到达工程师
- AgentCore运行时尚不可用时选择Amazon ECS部署
- 正在评估未来迁移至AgentCore