AWS Machine Learning Blog · 2026/10/7 15:38:28
Cornerstone 用 Bedrock 构建多智能体系统，数据库诊断提速 78%
企业软件公司 Cornerstone OnDemand 基于 Amazon Bedrock 和 Strands Agents 框架构建了名为 Orion AI 的多智能体系统。该系统将数据库故障诊断时间从平均 45 分钟缩短至 10 分钟，效率提升 78%，实现了从被动响应到主动编排的转变。
报道全文原始报道全文
本文目录18 个章节
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 的企业数据运营团队处于被动响应模式，主要面临四大反复出现的痛点：
- 数据库性能调查每次耗时约 45 分钟，且需在多个工具和系统视图间切换。
- 数据库生命周期工作流需要 10 步以上的手动操作，涵盖建立连接至状态更新沟通等环节。
- 站点可靠性工程（SRE）团队与数据团队之间的报告存在 15 分钟的延迟。
- 冗余且重叠的告警制造了大量噪音，掩盖了真正重要的信号。
上述问题导致工程师将大量时间耗费在手动协调上，而非专注于解决实际问题。
解决方案：Orion AI
Orion AI 是一套多智能体系统，采用中心辐射型（hub-and-spoke）拓扑结构：由一个协调智能体（元编排器）将任务分派给各专用子智能体。工程师通过 Web 应用与其交互，在原本用于协调运营工作的同一界面中提出问题并审批操作。这些智能体覆盖基础设施监控、数据库诊断、数据库生命周期管理、客户分析以及知识驱动的支持服务。
两大原则指导了构建过程：在 AWS 责任共担模型 下利用 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 消除了 SRE-to-data-team 之间 15 分钟的报告延迟，用持续的跨系统可见性取代了周期性的手动检查。
Orion AI 通过去重、阈值过滤和跨信号关联，将冗余警报的中位数减少了 65%。此前每生成 10 条警报，现在仅有 3–4 条会送达工程师手中。警报直接路由至负责团队，无需经过中间警报层。
核心设计原则
以下三项决策塑造了 Orion AI，你也可以将它们应用于自己的多智能体项目：
- 按领域而非任务复杂度拆分智能体：每个智能体仅承载针对单一运营领域的窄范围工具集成。这有助于保持模型上下文的聚焦，并提高工具选择的准确性，而不是要求一个通用型智能体处理所有任务。
- 默认采用关键词路由，回退至语义搜索：对于可预测的请求，通过关键词匹配以实现快速响应；对于模糊请求，则回退到语义搜索以确保准确性。这种方法在保持低延迟的同时，不会牺牲对复杂查询的正确性。
- 将会话记忆限定于会话范围内，并在实时指标中绕过记忆：持久化记忆支持多轮对话，但运营类问题始终读取当前系统状态。在处理实时指标时绕过记忆，有助于防止陈旧数据污染实时诊断结果。
架构概览
Orion AI 以容器化服务的形式部署在 Amazon Elastic Container Service (Amazon ECS) 上。用户通过 Web 应用程序进行交互，该应用会将每个请求路由至相应的智能体，调用所需的工具，并组装最终响应。下图展示了这些组件在 AWS Cloud 中的连接方式。
图 1：Orion AI 架构：运行在 Amazon ECS 上的元编排器将请求路由到专业代理，这些代理通过 Portal-Tools MCP 服务器访问数据源，并使用 Amazon Bedrock 进行模型调用、长期记忆存储和检索增强生成
架构深入解析
前述设计原则在架构中得到了具体体现。本节其余部分将详细阐述 Orion AI 的核心组件。
使用 Strands Agents 构建中心辐射型模式
Orion AI 通过少量 Strands Agents 原语来表达其拓扑结构。Agent 类是构建专业代理和元编排器的基础模块。每个代理的工具都是带有 @tool 装饰器的普通 Python 函数。这意味着工具规范直接从函数的类型提示和文档字符串推导而来，无需单独维护架构定义。BedrockModel 封装了每个代理运行的 Amazon Bedrock 模型，而 MCPClient 则将代理连接到外部工具服务器。
拓扑结构如下：
- 中心节点是一个单一的 Strands Agent，充当元编排器（TaskExecutor）。它不持有领域工具——仅持有路由工具（
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 展示了领域划分如何映射到真实调查的各个阶段：
- 数据库诊断智能体 识别阻塞链、等待类型和长时间运行的查询，然后将技术发现转化为业务影响并提供修复建议。它回答“正在发生什么以及这意味着什么”。
- 会话阻塞分析智能体 利用推理模型执行多步调查，将阻塞链映射到根本阻塞源。它回答“为什么会发生这种情况以及根本原因是什么”，并提供从立即终止会话到长期架构修复的优先级建议。
- 实时 SQL 诊断智能体 通过 Cornerstone 的 DATAOPS API 直接查询 SQL Server 实例，获取实时阻塞数据和高 CPU 会话分析。它回答“当前真实情况是什么”。
其余智能体遵循同样的窄职责原则：基础设施监控、运营分析、数据库生命周期管理、客户分析、从运维手册中检索知识、通知路由、复合查询分解、可用性组监听器解析以及模型连接预热。
工具集成与服务连接
Orion AI 通过两种模式访问数据源：
- Model Context Protocol (MCP) 用于多个智能体共享的工具（例如，实时 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。
这种划分意味着每个智能体使用最适合其数据源的最轻量级机制，而 MCP 服务器则集中管理多个智能体共享的工具。这些连接通过 TLS 运行，且诸如 MCP 令牌和 REST API 授权等凭证是按请求提供的，而非嵌入在智能体代码中。
对话记忆
Amazon Bedrock AgentCore 是一个支持任意框架或模型、以规模化方式构建、连接和优化智能体的平台，提供了跨会话的记忆层。Orion AI 通过一个中央记忆管理器协调上下文，该管理器并行读取三个层级，每个层级都有独立的超时设置和 token 分配额度。
Orion AI 在三个层级上协调上下文。短期记忆将同一会话的上下文存储在 Amazon DynamoDB 中，默认启用静态加密，并配合由 Amazon Nova 2 Lite 异步生成的滚动对话摘要。长期记忆通过 AgentCore memory（Amazon Bedrock AgentCore 的一项功能）提供跨会话召回能力，并按用户 ID 进行命名空间隔离。任务完成后，Orion AI 调用 create_event 以触发自动提取、摘要和整合。第三层是智能体间记忆，这是一个临时的内存暂存区，用于在单个任务的子智能体步骤之间传递发现结果。
记忆管理器在 500 毫秒的硬性超时限制内跨层级检索，针对 4,000 token 预算，并由最近最少使用（LRU）缓存支持。当请求涉及当前系统状态时，智能体会完全绕过记忆直接读取实时数据，从而防止过时的上下文污染实时诊断。
负责任的 AI 与护栏机制
由于 DataOps 安全性依赖于特定领域的规则（例如哪些数据库操作具有破坏性），团队构建了自定义护栏逻辑，而非依赖通用的内容过滤器。Orion AI 在四个层级应用控制措施：
- 提示级安全约束：注入到每个智能体的系统提示中，阻止危险建议（例如终止关键数据库进程）并强制采用非破坏性方法。
- 人在回路确认门控：暂停破坏性操作，直到用户在五分钟窗口期内确认，超时则默认拒绝。
- 用于输入验证的自定义护栏模块：包括长度限制、提示注入和 SQL 注入拦截；输出净化（脱敏机密和个人身份信息）、速率限制、基于角色的访问控制以及每请求成本跟踪。
- 路由级保护：阻止从记忆中回答运维查询，强制对当前状态问题进行实时工具执行。
可观测性
Orion AI 使用标准的 AWS 可观测性服务进行监控和调试。Amazon CloudWatch 提供关于路由置信度、延迟和智能体调用活动的指标和结构化日志。AWS X-Ray 追踪跨智能体执行的分布式调用，以实现端到端的请求路径可见性。
经验教训
让 Orion AI 成为可能的那些设计决策，你完全可以复用。按领域拆分智能体（Agent），使每个智能体只需承载窄范围的工具集成，从而避免单个模型的上下文窗口臃肿。默认采用关键词路由，并将语义搜索作为后备方案，既保持了低延迟，又未牺牲对模糊请求的准确性。将会话记忆限定在会话范围内，同时在处理实时指标时绕过该机制，确保了实时诊断的可信度。
团队还做出了务实的基础设施选择。他们选择在 Amazon ECS 上部署计算资源，因为项目启动时 Amazon Bedrock AgentCore runtime（Amazon Bedrock AgentCore 的一项功能）尚不可用，目前他们正将其评估为未来的迁移选项。如果你今天正在构建类似系统，请为你的技术栈权衡同样的取舍：从当前稳定且可用的组件开始，随着托管功能的成熟再重新审视架构。
结论
Orion AI 将数据库诊断时间从 45 分钟缩短至 10 分钟，避免了 70% 的手动生命周期步骤，并将告警噪音降低了 65%。一个三人团队在六个月内基于 Amazon Bedrock 交付了该系统。支撑这些成果的模式可供其他运维团队采纳：领域限定的智能体、混合路由，以及带有实时指标旁路机制的会话级记忆。
要在 AWS 上开始多智能体编排，请参阅 AWS Solutions Library 指南。