Cornerstone OnDemand 用 Amazon Bedrock 构建多智能体系统 Orion AI，数据库诊断时间缩短 78%

Cornerstone OnDemand, Inc.（Cornerstone）是劳动力就绪解决方案领域的全球领导者，为 186 个国家的 1.4 亿用户提供服务。该公司构建了一套多智能体 AI 系统，将数据库运营从被动的救火式处理转变为主动的、自编排的工作流。该系统名为 Orion AI，使用 Amazon Bedrock 和 Strands Agents（AWS 推出的开源智能体编排框架）来协调各专业智能体。

在 Orion AI 出现之前，Cornerstone 的企业 DataOps 团队每次处理数据库事故时，都要花费长达 45 分钟手动查询系统视图并交叉比对日志，然后再跨团队交接。借助 Orion AI，数据库诊断时间从 45 分钟降至 10 分钟，缩短了 78%。这套系统由一个三人团队在六个月内完成交付。

在本文中，我们将介绍 Cornerstone 面临的运营问题、他们如何设计 Orion AI、他们衡量到的成果，以及其他团队可以复用的设计决策。

运营挑战

在 Orion AI 出现之前，Cornerstone 的企业 DataOps 团队采用被动响应的工作方式，存在四个反复出现的痛点：

数据库性能调查每次事故大约需要 45 分钟，且分散在多个工具和系统视图之间。
数据库生命周期工作流需要 10 个或更多手动步骤，从建立连接到传达状态更新。
站点可靠性工程（SRE）团队与数据团队之间的报告存在 15 分钟的延迟。
冗余且重叠的告警制造了大量噪音，掩盖了真正重要的信号。

这些问题叠加在一起，意味着工程师把时间花在手动协调上，而不是解决问题上。

解决方案：Orion AI

Orion AI 是一个多智能体系统，其中一个协调智能体（元编排器）将工作分派给以中心辐射拓扑结构组织的专业子智能体。工程师通过一个 Web 应用程序与之交互，在他们已经用来协调运营工作的同一位置提问并批准操作。这些智能体涵盖基础设施监控、数据库诊断、数据库生命周期操作、客户分析以及知识驱动的支持。

两项原则指导了这次构建：一是依据共担责任模型使用 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，三个专门的智能体共同承担调查工作，各自负责一个不同的阶段。除了诊断之外，Orion AI 还会将问题推进到修复环节：识别根本原因、推荐修复方案，并创建一个内容完整的 Jira 工单，指派给合适的值班工程师。原本需要四步的手动交接流程被简化为单次交互。

自动化数据库生命周期管理

以前需要超过 10 个手动步骤的任务，从建立数据库连接到运行跨系统查询，再到沟通状态更新，现在只需一次自然语言交互即可完成。Orion AI 会识别合适的工具和数据源，跨系统运行查询，验证结果，并返回统一的响应。从工程师的角度来看，这项工作被简化为向 Orion AI 发出提示词并验证它反馈的结果。

实时监控并减少告警疲劳

Orion AI 消除了 15 分钟的 SRE-to-data-team 报告延迟，用持续的跨系统可视化取代了周期性的手动检查。

Orion AI 通过去重、阈值过滤和跨信号关联，将冗余告警的中位数减少了 65%。以前每生成 10 条告警，现在只有 3–4 条会送达工程师。告警会直接路由到负责的团队，无需中间告警层。

关键设计原则

三项决策塑造了 Orion AI，你也可以在自己的多智能体项目中应用它们：

按领域而非任务复杂度拆分智能体：每个智能体只承载面向单一运维领域的少量工具集成。这使模型的上下文保持专注，并提高工具选择的准确性，而不是让一个通用智能体包揽所有事情。
默认使用关键词路由，回退到语义搜索：可预测的请求通过关键词匹配以保证速度。模糊的请求回退到语义搜索以保证准确性。这样既能保持低延迟，又不会在较难的查询上牺牲正确性。
将会话记忆限定在会话范围内，实时指标绕过记忆：持久化记忆支持多轮对话，但运维问题始终读取当前系统状态。让实时指标绕过记忆有助于防止陈旧数据污染实时诊断。

架构概览

Orion AI 以容器化服务的形式部署在 Amazon Elastic Container Service（Amazon ECS）上。用户通过一个 Web 应用程序进行交互，该程序将每个请求路由到相应的智能体，调用所需的工具，并组装响应。下图展示了这些组件在 AWS 云中的连接方式。

图 1：Orion AI 架构：Amazon ECS 上的元编排器将请求路由到专门的智能体，这些智能体通过 Portal-Tools MCP 服务器访问数据源，并使用 Amazon Bedrock 提供模型、长期记忆和检索增强生成

架构深入解析

前述设计原则在架构中得到了具体体现。本节的其余部分将逐一介绍 Orion AI 的核心组件。

使用 Strands Agents 构建中心辐射型模式

Orion AI 使用少量 Strands Agents 原语来表达其拓扑结构。Agent 类是专家智能体和元编排器的构建基石。每个智能体的工具都是标记了 @tool 装饰器的普通 Python 函数。它会从函数的类型提示和文档字符串派生工具规范，因此无需单独维护 schema。BedrockModel 封装了每个智能体所运行的 Amazon Bedrock 模型，MCPClient 则将智能体连接到外部工具服务器。

拓扑结构：

中心是一个单独的 Strands Agent，充当元编排器（TaskExecutor）。它不持有任何领域工具——只有路由工具（find_relevant_agents、call_agent）和控制流工具（emit_plan_step、emit_confirmation_gate），以便它能逐步推理请求。
分支是通过基于装饰器的注册表懒加载的独立 Agent 实例。每个实例都带有自己的模型、领域工具和本地化的系统提示词。

在运行时，中心通过注册的 call_agent 工具按名称调用专家智能体。每个专家智能体运行自己的工具调用循环，并将综合后的文本返回给中心，由中心组装最终响应。

混合路由

Orion AI 采用关键字优先、语义搜索兜底的路由方式。大约 80% 的查询通过内存中的关键字快速路径在不到一毫秒内完成解析。当关键字不足以判断意图时，系统会回退到由 Amazon Titan Text Embeddings V2 驱动的语义搜索，按含义进行路由。有关各 AWS 区域的模型可用性，请参阅 Amazon Bedrock 中按 AWS 区域支持的模型。

当直接调用工具不合适时，会激活一条回退链：Amazon Bedrock Knowledge Bases 这一完全托管的检索增强生成（RAG）功能会检索操作文档，使响应立足于已批准的流程，而不是在没有上下文的情况下凭空生成。

领域专用智能体及其边界

Orion AI 使用了 13 个领域专用智能体。三个 SQL Server 智能体说明了领域拆分如何对应真实排查过程的各个阶段：

数据库诊断智能体揭示阻塞链、等待类型和长时间运行的查询，然后将技术发现转化为业务影响并提供修复建议。它回答“正在发生什么以及这意味着什么”。
会话阻塞分析智能体使用推理模型运行多步骤排查，将阻塞链映射到根本阻塞者。它回答“为什么会发生这种情况以及根本原因是什么”，并提供从立即终止会话到长期架构修复的优先级建议。
实时 SQL 诊断智能体通过 Cornerstone 的 DATAOPS API 直接查询 SQL Server 实例，以获取实时阻塞数据和高 CPU 会话分析。它回答“当前真实情况是什么”。

其余智能体遵循同样的窄域负责原则：基础设施监控、运营分析、数据库生命周期管理、客户分析、从运维手册中检索知识、通知路由、复合查询分解、Availability Group 监听器解析以及模型连接预热。

工具集成与服务连接

Orion AI 通过两种模式访问数据源：

Model Context Protocol（MCP），用于多个智能体共享的工具（例如实时 SQL 诊断）。Strands @tool 函数通过可流式 HTTP 调用 Portal-Tools MCP 服务器上的 MCPClient，该服务器连接 SQL Server 和 DATAOPS API。Jira 集成也通过外部 Atlassian MCP 工具采用相同方式。
直接 SDK 或 REST API 调用，用于不需要共享 MCP 接口的数据源。这包括指标与仪表板、值班安排表，以及通过 AWS SDK for Python (Boto3) 访问的 Amazon Bedrock Knowledge Bases。

这种划分意味着每个智能体都使用适合其数据源的最轻量机制，而 MCP 服务器则集中管理多个智能体共享的工具。这些连接均通过 TLS 运行，MCP 令牌和 REST API 授权等凭据按请求提供，而不是嵌入在智能体代码中。

对话记忆

Amazon Bedrock AgentCore 是一个可使用任何框架或模型大规模构建、连接和优化智能体的平台，提供跨会话的记忆层。Orion AI 通过一个中央记忆管理器协调上下文，该管理器并行读取三个层级，每个层级都有自己的超时和令牌配额。

Orion AI 跨三个层级协调上下文。短期记忆通过 Amazon DynamoDB 保存同一会话内的上下文，默认静态加密，并搭配一个由 Amazon Nova 2 Lite 异步生成的滚动对话摘要。长期记忆通过 AgentCore 记忆（Amazon Bedrock AgentCore 的一项能力）提供跨会话回溯，并按用户 ID 划分命名空间。在任务完成时，Orion AI 调用 create_event 触发自动提取、摘要和整合。第三个层级是智能体间记忆，它是一个临时的内存暂存区，用于在单个任务内的各个子智能体步骤之间传递发现结果。

记忆管理器在 500 毫秒的硬超时内针对 4,000 令牌预算跨各层级进行检索，并辅以最近最少使用（LRU）缓存。当请求涉及当前系统状态时，智能体会完全绕过记忆而直接读取实时数据，从而避免过时的上下文污染实时诊断。

负责任的 AI 与护栏

由于 DataOps 的安全性依赖于领域特定规则（例如哪些数据库操作具有破坏性），团队构建了自定义护栏逻辑，而不是依赖通用的内容过滤器。Orion AI 在四个层面应用控制措施：

提示词级安全约束，注入到每个智能体的系统提示词中，阻止危险建议（例如终止关键数据库进程），并强制采用无破坏性的方法。
人在回路的确认关卡，它会暂停破坏性操作，直到用户在五分钟窗口内确认，超时则默认拒绝。
用于输入验证的自定义护栏模块（长度限制、提示词注入和 SQL 注入拦截）、输出净化（遮蔽机密和个人身份信息）、速率限制、基于角色的访问控制，以及按请求的成本跟踪。
路由级保护，禁止智能体从记忆中回答运维类查询，强制针对当前状态的问题执行实时工具调用。

可观测性

Orion AI 使用标准的 AWS 可观测性服务进行监控和调试。Amazon CloudWatch 为路由置信度、延迟和智能体调用活动提供指标和结构化日志。AWS X-Ray 跟踪智能体执行过程中的分布式调用，实现端到端请求路径的可见性。

经验教训

让 Orion AI 成为可能的设计决策是可以复用的。按领域拆分智能体，使每个智能体只需携带窄范围的工具集成，而不会让单一模型的上下文臃肿不堪。默认使用关键词路由并以语义搜索作为后备，在模糊请求上保持准确性的同时降低了延迟。将对话记忆限定在会话范围内，同时对实时指标绕过该记忆，保证了实时诊断的可信度。

团队还做出了务实的基础设施选择。他们将计算部署在 Amazon ECS 上，因为 Amazon Bedrock AgentCore 运行时（Amazon Bedrock AgentCore 的一项能力）在项目启动时尚不可用，目前他们正将其评估为未来的迁移选项。如果你今天开始构建，请为自己的技术栈权衡同样的取舍：从现在稳定可用的方案入手，并随着托管能力的成熟而重新评估。

结论

Orion AI 将数据库诊断时间从 45 分钟缩短到 10 分钟，避免了 70% 的手动生命周期步骤，并将告警噪音降低了 65%。一个三人团队在 Amazon Bedrock 上用六个月完成了它。这些成果背后的模式是其他运维团队可以采用的：领域范围的智能体、混合路由，以及带实时指标绕过的会话范围记忆。

要开始使用 AWS 上的多智能体编排，请查阅 AWS Solutions Library 指南。