构建基于多智能体协作的站点可靠性工程助手本文详细介绍如何利用某中心Bedrock AgentCore、LangGraph

构建基于多智能体协作的站点可靠性工程助手

站点可靠性工程师在现代分布式系统中面临日益复杂的挑战。生产事故期间，他们必须快速关联来自多个来源的数据——日志、指标、Kubernetes事件和操作手册——以识别根本原因并实施解决方案。传统监控工具提供原始数据，但缺乏智能来综合这些不同系统的信息，通常需要SRE手动拼凑系统故障背后的故事。

借助生成式人工智能解决方案，SRE可以用自然语言询问其基础设施问题。例如，他们可以问“为什么支付服务pod在崩溃循环中？”或“是什么导致了API延迟峰值？”并接收全面的、可操作的洞察，这些洞察结合了基础设施状态、日志分析、性能指标和分步补救程序。这种能力将事故响应从手动、耗时的过程转变为高效、协作的调查。

在本文中，将演示如何使用某中心Bedrock AgentCore、LangGraph和模型上下文协议构建一个多智能体SRE助手。该系统部署了专门的AI智能体，它们协作提供现代SRE团队有效事故响应和基础设施管理所需的深度上下文智能。将引导完成从设置演示环境到部署到某中心Bedrock AgentCore Runtime用于生产环境的完整实现。

解决方案概述

该解决方案采用全面的多智能体架构，通过智能自动化解决现代SRE操作的挑战。该解决方案由四个专门的AI智能体组成，它们在一个监督智能体的指导下协同工作，提供全面的基础设施分析和事故响应协助。

本文中的示例使用演示环境中生成的合成数据。后端服务器模拟真实的Kubernetes集群、应用程序日志、性能指标和操作手册。在生产部署中，这些桩服务器将替换为与实际基础设施系统、监控服务和文档存储库的连接。

该架构展示了几项关键能力：

自然语言基础设施查询 – 可以用简单的英语询问复杂的基础设施问题，并接收结合多个来源数据的详细分析
多智能体协作 – 专门用于Kubernetes、日志、指标和操作流程的智能体协同工作以提供全面的洞察
实时数据综合 – 智能体通过标准化API访问实时基础设施数据并呈现关联的发现
自动化手册执行 – 智能体检索并显示常见事故场景的分步操作程序
来源归属 – 每个发现都包含明确的来源归属，以供验证和审计之用

下图说明了解决方案的架构。

（架构图描述：展示了SRE支持智能体如何与某中心Bedrock AgentCore组件无缝集成：客户界面接收API响应时间降级的警报并返回全面的智能体响应；某中心Bedrock AgentCore Runtime管理多智能体SRE解决方案的执行环境；SRE支持智能体处理事故并编排响应；某中心Bedrock AgentCore Gateway通过OpenAPI接口将请求路由到专门的工具：Kubernetes API用于获取集群事件，日志API用于分析日志模式，指标API用于分析性能趋势，手册API用于搜索操作程序；某中心Bedrock AgentCore Memory存储和检索会话上下文及之前的交互以实现连续性；某中心Bedrock AgentCore Identity使用某中心Cognito集成处理工具访问的身份验证；某中心Bedrock AgentCore Observability收集和可视化智能体跟踪以进行监控和调试；某中心Bedrock LLMs通过Anthropic的Claude大语言模型为智能体提供智能。）

多智能体解决方案采用监督者-智能体模式，其中一个中央编排器协调五个专门智能体：

监督智能体 – 分析传入的查询并创建调查计划，将工作路由给适当的专家，并将结果汇总成综合报告
Kubernetes基础设施智能体 – 处理容器编排和集群操作，调查pod故障、部署问题、资源约束和集群事件
应用程序日志智能体 – 处理日志数据以查找相关信息，识别模式和异常，并关联跨多个服务的事件
性能指标智能体 – 监控系统指标并识别性能问题，提供实时分析和历史趋势
操作手册智能体 – 根据当前情况提供对记录的程序、故障排除指南和升级程序的访问

使用某中心Bedrock AgentCore原语

该解决方案展示了某中心Bedrock AgentCore通过使用多个核心原语的能力。该解决方案支持Anthropic的LLMs的两个提供商。某中心Bedrock支持用于某中心集成部署的Anthropic Claude 3.7 Sonnet，而Anthropic API支持用于直接API访问的Anthropic Claude 4 Sonnet。

某中心Bedrock AgentCore Gateway组件将SRE智能体的后端API转换为模型上下文协议工具。这使得使用支持MCP的开源框架构建的智能体能够无缝访问基础设施API。

整个解决方案的安全性由某中心Bedrock AgentCore Identity提供。它支持入口身份验证以实现对连接到网关的智能体的安全访问控制，以及出口身份验证以管理与后端服务器的身份验证，提供安全的API访问而无需硬编码凭证。

用于在生产环境中部署SRE智能体的无服务器执行环境由某中心Bedrock AgentCore Runtime提供。它可以从零自动扩展以处理并发事故调查，同时保持完整的会话隔离。某中心Bedrock AgentCore Runtime支持OAuth和某中心身份和访问管理进行智能体身份验证。调用智能体的应用程序必须具有适当的IAM权限和信任策略。

某中心Bedrock AgentCore Memory将SRE智能体从无状态系统转变为智能学习助手，该助手根据用户偏好和历史上下文个性化调查。内存组件提供三种不同的策略：

用户偏好策略 – 存储个人用户的调查风格、沟通渠道、升级程序和报告格式偏好。例如，Alice（技术SRE）接收带有故障排除步骤的详细系统分析，而Carol（高管）接收带有影响分析的以业务为中心的摘要。
基础设施知识策略 – 积累跨调查的领域专业知识，使智能体能够从过去的发现中学习。当Kubernetes智能体识别出内存泄漏模式时，这些知识可用于未来的调查，从而实现更快的根本原因识别。
调查内存策略 – 维护过去事故及其解决方式的历史上下文。这使得解决方案能够建议经过验证的补救方法，并避免以前失败的反模式。

内存组件通过个性化调查展示了其价值。当Alice和Carol都调查“API响应时间在过去一小时恶化了3倍”时，她们会收到相同的技术发现，但呈现方式完全不同。

Alice收到技术分析：

memory_client.retrieve_user_preferences(user_id="Alice")
# 返回：{"investigation_style": "detailed_systematic_analysis", "reports": "technical_exposition_with_troubleshooting_steps"}

Carol收到执行摘要：

memory_client.retrieve_user_preferences(user_id="Carol")
# 返回：{"investigation_style": "business_impact_focused","reports": "executive_summary_without_technical_details"}

为SRE智能体添加可观察性

使用某中心Bedrock AgentCore Observability原语，为部署在某中心Bedrock AgentCore Runtime上的SRE智能体添加可观察性非常简单。这通过某中心CloudWatch实现了全面的监控，包括指标、跟踪和日志。设置可观察性需要三个步骤：

将OpenTelemetry包添加到pyproject.toml：

dependencies = [
    # ... 其他依赖项 ...
    "opentelemetry-instrumentation-langchain",
    "aws-opentelemetry-distro~=0.10.1",
]

为智能体配置可观察性以在CloudWatch中启用指标。
使用opentelemetry-instrument实用程序启动容器以自动检测应用程序。

以下命令被添加到SRE智能体的Dockerfile中：

# 使用OpenTelemetry检测运行应用程序
CMD ["uv", "run", "opentelemetry-instrument", "uvicorn", "sre_agent.agent_runtime:app", "--host", "0.0.0.0", "--port", "8080"]

启用可观察性后，您可以获得以下方面的可见性：

LLM调用指标 – 跨智能体的令牌使用、延迟和模型性能
工具执行跟踪 – 每个MCP工具调用的持续时间和成功率
内存操作 – 检索模式和存储效率
端到端请求跟踪 – 从用户查询到最终响应的完整请求流

可观察性原语无需额外代码更改即可自动捕获这些指标，提供开箱即用的生产级监控能力。

开发到生产流程

SRE智能体遵循从本地开发到生产的四步结构化部署流程，详细步骤记录在随附的GitHub存储库中的“开发到生产流程”中：

（流程图描述：部署流程包括四个阶段：1. 本地开发，使用本地代理和OpenAI/Anthropic API；2. 演示部署，配置网关和内存；3. 容器化，构建ARM64 Docker镜像；4. 生产部署，部署到某中心Bedrock AgentCore Runtime并启用可观察性。）

部署流程在各个环境中保持一致性：核心智能体代码保持不变，而部署文件夹包含特定于部署的实用程序。通过环境配置，同一个智能体可以在本地和生产环境中工作，某中心Bedrock AgentCore Gateway在开发和部署的不同阶段提供MCP工具访问。

实现演练

在以下部分，将重点介绍某中心Bedrock AgentCore Gateway、Memory和Runtime如何协同工作来构建这个多智能体协作解决方案，并端到端地部署它，支持MCP和持久智能。

首先设置存储库并使用API密钥、LLM提供商和演示基础设施建立本地运行时环境。然后通过创建网关以进行标准化API访问、配置身份验证和建立工具连接，使核心AgentCore组件上线。通过AgentCore Memory添加智能，创建用户偏好和调查历史策略，同时加载角色以进行个性化事故响应。最后，配置具有专门工具的个人智能体，集成内存功能，编排协作工作流，并部署到具有完整可观察性的AgentCore Runtime。

每个步骤的详细说明在存储库中提供：

用例设置指南 – 后端部署和开发设置
部署指南 – 生产容器化和某中心Bedrock AgentCore Runtime部署

先决条件

使用某中心Bedrock AgentCore Gateway将API转换为MCP工具

某中心Bedrock AgentCore Gateway通过将现有后端API转换为代理框架可以使用的MCP工具，展示了协议标准化的力量。这种转换无缝发生，只需要OpenAPI规范。

上传OpenAPI规范

网关过程首先将现有的API规范上传到某中心简单存储服务。create_gateway.sh脚本自动将四个API规范上传到配置的S3存储桶，并带有适当的元数据和内容类型。这些规范将用于在网关中创建API端点目标。

创建身份提供商和网关

身份验证通过某中心Bedrock AgentCore Identity无缝处理。main.py脚本创建凭据提供商和网关：

# 创建具有JWT授权的AgentCore Gateway
def create_gateway(
    client: Any,
    gateway_name: str,
    role_arn: str,
    discovery_url: str,
    allowed_clients: list = None,
    description: str = "AgentCore Gateway created via SDK",
    search_type: str = "SEMANTIC",
    protocol_version: str = "2025-03-26",
) -> Dict[str, Any]:

    # 为Cognito构建身份验证配置
    auth_config = {"customJWTAuthorizer": {"discoveryUrl": discovery_url}}
    if allowed_clients:
        auth_config["customJWTAuthorizer"]["allowedClients"] = allowed_clients

    protocol_configuration = {
        "mcp": {"searchType": search_type, "supportedVersions": [protocol_version]}
    }

    response = client.create_gateway(
        name=gateway_name,
        roleArn=role_arn,
        protocolType="MCP",
        authorizerType="CUSTOM_JWT",
        authorizerConfiguration=auth_config,
        protocolConfiguration=protocol_configuration,
        description=description,
        exceptionLevel='DEBUG'
    )
    return response

使用凭据提供商部署API端点目标

每个API都通过网关成为MCP目标。解决方案自动处理凭据管理：

def create_api_endpoint_target(
    client: Any,
    gateway_id: str,
    s3_uri: str,
    provider_arn: str,
    target_name_prefix: str = "open",
    description: str = "API Endpoint Target for OpenAPI schema",
) -> Dict[str, Any]:

    api_target_config = {"mcp": {"openApiSchema": {"s3": {"uri": s3_uri}}}}

    # API密钥凭据提供程序配置
    credential_config = {
        "credentialProviderType": "API_KEY",
        "credentialProvider": {
            "apiKeyCredentialProvider": {
                "providerArn": provider_arn,
                "credentialLocation": "HEADER",
                "credentialParameterName": "X-API-KEY",
            }
        },
    }

    response = client.create_gateway_target(
        gatewayIdentifier=gateway_id,
        name=target_name_prefix,
        description=description,
        targetConfiguration=api_target_config,
        credentialProviderConfigurations=[credential_config],
    )
    return response

验证MCP工具已准备好供代理框架使用

部署后，某中心Bedrock AgentCore Gateway提供一个标准化的、受JWT令牌保护的/mcp端点。使用mcp_cmds.sh测试部署揭示了这种转换的强大功能：

工具摘要：
================
找到的工具总数：21

工具名称：
• x_amz_bedrock_agentcore_search
• k8s-api___get_cluster_events
• k8s-api___get_deployment_status
• k8s-api___get_node_status
• k8s-api___get_pod_status
• k8s-api___get_resource_usage
• logs-api___analyze_log_patterns
• logs-api___count_log_events
• logs-api___get_error_logs
• logs-api___get_recent_logs
• logs-api___search_logs
• metrics-api___analyze_trends
• metrics-api___get_availability_metrics
• metrics-api___get_error_rates
• metrics-api___get_performance_metrics
• metrics-api___get_resource_metrics
• runbooks-api___get_common_resolutions
• runbooks-api___get_escalation_procedures
• runbooks-api___get_incident_playbook
• runbooks-api___get_troubleshooting_guide
• runbooks-api___search_runbooks

通用代理框架兼容性

这个MCP标准化的网关现在可以配置为MCP客户端的可流式HTTP服务器，包括某中心Strands、某机构的代理开发框架、LangGraph以及CrewAI。

这种方法的优势在于现有API无需修改——只需要OpenAPI规范。某中心Bedrock AgentCore Gateway处理以下内容：

协议转换 – 在REST API和MCP之间
身份验证 – JWT令牌验证和凭据注入
安全性 – TLS终止和访问控制
标准化 – 一致的工具命名和参数处理

这意味着您可以获取现有的基础设施API，并通过单一、安全、标准化的接口立即将它们提供给支持MCP的AI代理框架。

使用某中心Bedrock AgentCore Memory实现持久智能

某中心Bedrock AgentCore Gateway提供无缝API访问，而某中心Bedrock AgentCore Memory则将SRE智能体从无状态系统转变为智能的学习助手。内存实现展示了如何用几行代码实现复杂的个性化和跨会话知识保留。

初始化内存策略

SRE智能体内存组件构建在某中心Bedrock AgentCore Memory基于事件的模型上，具有自动命名空间路由。在初始化期间，解决方案创建了三种具有特定命名空间模式的内存策略：

from sre_agent.memory.client import SREMemoryClient
from sre_agent.memory.strategies import create_memory_strategies

# 初始化内存客户端
memory_client = SREMemoryClient(
    memory_name="sre_agent_memory",
    region="us-east-1"
)

# 创建三种专门的内存策略
strategies = create_memory_strategies()
for strategy in strategies:
    memory_client.create_strategy(strategy)

这三种策略各自服务于不同的目的：

用户偏好 – 个人调查风格和沟通偏好
基础设施知识 – 跨调查积累的领域专业知识
调查摘要 – 历史事故模式和解决方案

加载用户角色和偏好

该解决方案预配置了用户角色，用于演示个性化调查。manage_memories.py脚本加载这些角色：

# 加载 Alice - 技术SRE工程师
alice_preferences = {
    "investigation_style": "detailed_systematic_analysis",
    "communication": ["#alice-alerts", "#sre-team"],
    "escalation": {"contact": "alice.manager@company.com", "threshold": "15min"},
    "reports": "technical_exposition_with_troubleshooting_steps",
    "timezone": "UTC"
}

# 加载 Carol - 高管/总监
carol_preferences = {
    "investigation_style": "business_impact_focused",
    "communication": ["#carol-executive", "#strategic-alerts"],
    "escalation": {"contact": "carol.director@company.com", "threshold": "5min"},
    "reports": "executive_summary_without_technical_details",
    "timezone": "EST"
}

# 使用内存客户端存储偏好
memory_client.store_user_preference("Alice", alice_preferences)
memory_client.store_user_preference("Carol", carol_preferences)

自动命名空间路由在行动中

某中心Bedrock AgentCore Memory的强大之处在于其自动命名空间路由。当SRE智能体创建事件时，它只需要提供actor_id——某中心Bedrock AgentCore Memory会自动确定事件属于哪个命名空间：

# 在调查期间，监督智能体存储上下文
memory_client.create_event(
    memory_id="sre_agent_memory-abc123",
    actor_id="Alice",  # AgentCore Memory自动路由此信息
    session_id="investigation_2025_01_15",
    messages=[("investigation_started", "USER")]
)

# 内存系统自动执行：
# 1. 检查策略命名空间
# 2. 将actor_id "Alice"匹配到/sre/users/Alice/preferences
# 3. 在用户偏好策略中存储事件
# 4. 使事件可用于未来的检索

验证个性化调查体验

当Alice和Carol调查同一个问题时，内存组件的影响变得清晰。使用相同的技术发现，解决方案对相同的基础内容产生完全不同的呈现方式。

Alice的技术报告包含针对技术团队的详细系统分析：

技术调查摘要

根本原因：支付处理器内存泄漏导致OOM终止

分析：
- Pod重启频率在14:23 UTC增加了300%
- 内存利用率达到峰值8.2GB（容器限制的80%）
- JVM垃圾收集延迟峰值达到2.3秒

后续步骤：
1. 实施堆转储分析 (`kubectl exec payment-pod -- jmap`)
2. 查看最近的代码部署以寻找内存管理更改
3. 考虑增加内存限制并实施优雅关闭

Carol的执行摘要包含针对高管利益相关者的以业务影响为重点的内容：

业务影响评估
状态：严重 - 客户支付处理降级
影响：23%的交易失败率，47,000美元收入面临风险
时间线：问题于14:23 UTC检测到，解决预计时间45分钟
业务行动：- 已通过状态页面启动客户沟通 - 已提醒财务团队进行收入影响跟踪 - 如果未在15:15 UTC前解决，将升级至工程副总裁

内存组件在实现这种个性化的同时，不断从每次调查中学习，构建组织知识，随着时间的推移改进事故响应。

使用某中心Bedrock AgentCore Runtime部署到生产环境

某中心Bedrock AgentCore使得将现有代理部署到生产环境变得简单。该过程涉及三个关键步骤：容器化代理、部署到某中心Bedrock AgentCore Runtime以及调用已部署的代理。

容器化代理

某中心Bedrock AgentCore Runtime需要ARM64容器。以下代码显示了完整的Dockerfile：

# 使用uv的ARM64 Python基础镜像
FROM --platform=linux/arm64 ghcr.io/astral-sh/uv:python3.12-bookworm-slim

WORKDIR /app

# 复制uv文件
COPY pyproject.toml uv.lock ./

# 安装依赖项
RUN uv sync --frozen --no-dev

# 复制SRE代理模块
COPY sre_agent/ ./sre_agent/

# 设置环境变量
# 注意：设置DEBUG=true以启用调试日志记录和跟踪
ENV PYTHONPATH="/app" \
    PYTHONDONTWRITEBYTECODE=1 \
    PYTHONUNBUFFERED=1

# 暴露端口
EXPOSE 8080

# 使用OpenTelemetry检测运行应用程序
CMD ["uv", "run", "opentelemetry-instrument", "uvicorn", "sre_agent.agent_runtime:app", "--host", "0.0.0.0", "--port", "8080"]

现有代理只需要一个FastAPI包装器即可与某中心Bedrock AgentCore兼容，并且添加了opentelemetry-instrument以通过某中心Bedrock AgentCore启用可观察性。

部署到某中心Bedrock AgentCore Runtime

使用deploy_agent_runtime.py脚本部署到某中心Bedrock AgentCore Runtime很简单：

import boto3

# 创建AgentCore客户端
client = boto3.client('bedrock-agentcore', region_name=region)

# 代理的环境变量
env_vars = {
    'GATEWAY_ACCESS_TOKEN': gateway_access_token,
    'LLM_PROVIDER': llm_provider,
    'ANTHROPIC_API_KEY': anthropic_api_key  # 如果使用Anthropic
}

# 将容器部署到AgentCore Runtime
response = client.create_agent_runtime(
    agentRuntimeName=runtime_name,
    agentRuntimeArtifact={
        'containerConfiguration': {
            'containerUri': container_uri  # 您的ECR容器URI
        }
    },
    networkConfiguration={"networkMode": "PUBLIC"},
    roleArn=role_arn,
    environmentVariables=env_vars
)

print(f"Agent Runtime ARN: {response['agentRuntimeArn']}")

某中心Bedrock AgentCore自动处理基础设施、扩展和会话管理。

调用已部署的代理

使用invoke_agent_runtime.py调用已部署的代理同样简单：

# 准备查询，包含用于内存个性化的user_id和session_id
payload = json.dumps({
    "input": {
        "prompt": "API响应时间在过去一小时恶化了3倍",
        "user_id": "Alice",  # 用于个性化调查的用户
        "session_id": "investigation-20250127-123456"  # 用于上下文的会话
    }
})

# 调用已部署的代理
response = agent_core_client.invoke_agent_runtime(
    agentRuntimeArn=runtime_arn,
    runtimeSessionId=session_id,
    payload=payload,
    qualifier="DEFAULT"
)

# 获取响应
response_data = json.loads(response['response'].read())
print(response_data)  # 完整响应包括代理的调查输出

某中心Bedrock AgentCore Runtime的主要优势

某中心Bedrock AgentCore Runtime提供以下主要优势：

零基础设施管理 – 无需配置服务器、负载均衡器或扩展
内置会话隔离 – 每个对话完全隔离
某中心IAM集成 – 安全的访问控制，无需自定义身份验证
自动扩展 – 从零扩展到数千个并发会话

完整的部署过程，包括构建容器和处理某中心权限，都记录在部署指南中。

实际用例

让我们探讨SRE智能体如何处理具有实际调查的常见事故响应场景。

当面临生产问题时，可以用自然语言查询系统。解决方案使用某中心Bedrock AgentCore Memory根据您的角色和偏好个性化调查：

export USER_ID=Alice
sre-agent --prompt "API响应时间在过去一小时恶化了3倍"

监督者从内存中检索Alice的偏好（详细系统分析风格），并根据她作为技术SRE的角色创建量身定制的调查计划：

调查计划
1. 使用metrics_agent分析API性能指标，包括响应时间、错误率和资源利用率，以识别减速的程度和模式
2. 使用logs_agent检查与API响应慢相关的应用程序日志错误，重点关注数据库连接问题和内存错误
3. 使用kubernetes_agent检查pod状态和资源约束，特别是web服务和数据库pod，寻找CrashLoopBackOff状态和缺失的ConfigMaps
复杂度：简单
自动执行：是
涉及的代理：指标代理、日志代理、Kubernetes代理

智能体根据计划依次进行调查，每个智能体贡献其专门的分析。然后，解决方案将这些发现汇总成一个全面的执行摘要：

执行摘要
关键洞察
- 根本原因：数据库服务故障，由于生产命名空间中缺少ConfigMap 'database-config'，导致数据库pod反复崩溃
- 影响：严重的性能降级，API响应时间从150ms增加到5000ms（慢了33倍）
- 严重性：高 - 数据库不可用，内存耗尽（100%），CPU饱和（95%）导致75%的错误率
后续步骤
1. 立即处理（< 1小时）：在生产命名空间中创建/更新ConfigMap 'database-config'并重启数据库pod
2. 短期处理（< 24小时）：
   - 修复 '/var/lib/postgresql/data' 目录的权限
   - 增加web服务的Java堆空间以解决OutOfMemoryErrors
   - 优化导致内存问题的UserService.loadAllUsers方法
3. 长期处理（< 1周）：
   - 实施资源监控，对CPU（>80%）、内存（>90%）设置警报
   - 优化慢速数据库查询，特别是 "SELECT * FROM users WHERE status='active'"
   - 扩展web服务的资源或实施自动扩展
关键警报
- 数据库pod (database-pod-7b9c4d8f2a-x5m1q) 处于CrashLoopBackOff状态
- Web服务在UserService.loadAllUsers(UserService.java:45)处经历OutOfMemoryErrors
- Node-3经历内存压力（>85% 使用率）
- Web-app-deployment显示准备就绪探测失败，出现503错误
故障排除步骤
1. 验证ConfigMap状态：`kubectl get configmap database-config -n production`
2. 检查数据库pod日志：`kubectl logs database-pod-7b9c4d8f2a-x5m1q -n production`
3. 创建/更新ConfigMap：`kubectl create configmap database-config --from-file=database.conf -n production`
4. 修复数据目录权限：`kubectl exec database-pod-7b9c4d8f2a-x5m1q -n production -- chmod -R 700 /var/lib/postgresql/data`
5. 重启数据库pod：`kubectl delete pod database-pod-7b9c4d8f2a-x5m1q -n production`

这项调查展示了某中心Bedrock AgentCore原语如何协同工作：

某中心Bedrock AgentCore Gateway – 通过MCP工具提供对基础设施API的安全访问
某中心Bedrock AgentCore Identity – 处理入口和出口身份验证
某中心Bedrock AgentCore Runtime – 托管具有自动扩展功能的多智能体解决方案
某中心Bedrock AgentCore Memory – 个性化Alice的体验，并存储调查知识以供未来事故使用
某中心Bedrock AgentCore Observability – 在CloudWatch中捕获详细的指标和跟踪以进行监控和调试

SRE智能体展示了智能代理编排，监督者根据调查计划将工作路由给专家。解决方案的内存功能确保每次调查都能构建组织知识，并根据用户角色和偏好提供个性化体验。

这项调查展示了几项关键能力：

多源关联 – 它将数据库配置问题与API性能降级联系起来
顺序调查 – 智能体系统地按照调查计划工作，同时提供实时更新
来源归属 – 发现包括特定的工具和数据源
可操作的洞察 – 它提供了清晰的事件时间线和优先的恢复步骤
级联故障检测 – 它可以帮助显示一个故障如何在系统中传播

业务影响

实施AI驱动的SRE协助的组织报告了关键运营指标的显著改善。以前需要30-45分钟的初步调查现在可以在5-10分钟内完成，为SRE在深入详细分析之前提供了全面的上下文。调查时间的急剧缩短直接转化为更快速的事故解决和减少的停机时间。

该解决方案改善了SRE与其基础设施的交互方式。工程师无需在多个仪表板间切换，而是可以用自然语言提问，并从相关数据源接收聚合的洞察。这种上下文切换的减少使团队在关键事故期间能够保持专注，并减少调查期间的认知负荷。

也许最重要的是，该解决方案实现了团队内部知识的民主化。所有团队成员都可以访问相同的全面调查技术，减少了对部落知识的依赖和值班负担。该解决方案提供的一致方法确保了调查方法在团队成员和事故类型之间保持一致，提高了整体可靠性，并减少了遗漏证据的可能性。

自动生成的调查报告为事后审查提供了有价值的文档，并帮助团队从每次事故中学习，随着时间的推移建立组织知识。此外，该解决方案扩展了现有的某中心基础设施投资，与某中心CloudWatch、某中心Systems Manager和其他某中心操作工具等服务协同工作，提供统一的运营智能系统。

扩展解决方案

模块化架构使得为您的特定需求扩展解决方案变得简单。

例如，可以为您所在的领域添加专门的智能体：

安全智能体 – 用于合规性检查和安全事故响应
数据库智能体 – 用于数据库特定的故障排除和优化
网络智能体 – 用于连接性和基础设施调试

还可以用与实际系统的连接替换演示API：

Kubernetes集成 – 连接到您的集群API以获取pod状态、部署和事件
日志聚合 – 与您的日志管理服务集成
指标平台 – 连接到您的监控服务
手册存储库 – 链接到存储在wiki、Git存储库或知识库中的操作文档和手册

清理

为避免产生未来费用，请使用清理脚本删除演示期间创建的可计费某中心资源：

# 完全清理 - 删除某中心资源和本地文件
./scripts/cleanup.sh

此脚本自动执行以下操作：

停止后端服务器
删除网关及其目标
删除某中心Bedrock AgentCore Memory资源
删除某中心Bedrock AgentCore Runtime
删除生成的文件

有关详细的清理说明，请参阅清理说明。

结论

SRE智能体展示了多智能体系统如何将事故响应从手动、耗时的过程转变为高效、协作的调查，为SRE提供快速、自信解决问题所需的洞察。

通过将某中心Bedrock AgentCore的企业级基础设施与MCP中的标准化工具访问相结合，创建了一个可以适应基础设施演进和新功能出现的基础。

完整的实现在GitHub存储库中提供，包括演示环境、配置指南和扩展示例。鼓励您探索该解决方案，根据您的基础设施进行定制，并与社区分享您的经验。

要开始构建自己的SRE助手，请参阅以下资源：

在您的应用程序中使用AI代理自动化任务
某中心Bedrock AgentCore示例GitHub存储库
模型上下文协议文档
LangGraph文档