在现代分布式系统中，网站可靠性工程师（Site reliability engineers，后文简称SRE）面临着日益复杂的挑战。处理生产环境中的故障事件时，他们必须迅速关联来自日志、指标、Kubernetes事件及运维手册等多个来源的数据，以确定根本原因并实施解决方案。

传统监控工具虽能提供原始数据，但缺乏跨不同系统综合分析信息的智能能力，迫使SRE往往需要手动拼凑出系统故障背后的完整情况。

*图片源自亚马逊云科技官网

借助生成式AI解决方案，SRE可通过自然语言发起查询提问。例如，可以询问“支付服务容器组为何出现崩溃循环？”或“是什么导致API延迟飙升？”，随后便能获得全面且可落地的洞察，这些洞察整合了基础设施状态、日志分析、性能指标及分步故障修复流程。

这一能力将事件响应从耗时耗力的手动操作，转变为高效协作的调查过程，极大提高工作效率。

本文将介绍如何借助Amazon Bedrock AgentCore、LangGraph及模型上下文协议（Model Context Protocol，MCP）构建多Agents SRE助手。该系统部署了多个专业化的AI Agent，通过协同工作，为现代SRE团队提供事故响应处理与基础设施管理工作所需的深度、基于上下文的智能支持。

本文将逐步讲解完整的实现流程，内容涵盖从搭建演示环境，到部署至Amazon Bedrock AgentCore Runtime以供生产使用的全部步骤。

解决方案概述

该解决方案采用全面的多Agents架构：4个专业化的AI Agent，在1个主管Agent的统筹下协作，共同提供全面的基础设施分析与事故响应支持，通过智能自动化应对现代SRE运维工作中的各类挑战。

*图片源自亚马逊云科技官网

本文中的示例使用来自演示环境的合成生成数据，后端服务器模拟了真实的Kubernetes集群、应用程序日志、性能指标及运维手册。

投入至生产环境部署时，与实际基础设施系统、监控服务及文档存储库的连接，将替换这些模拟服务器。

该架构具备以下几项核心能力：

  • 自然语言查询：用户可使用自然语言针对基础设施提出复杂问题，并获取整合了多源数据的详细分析结果。

  • 多Agents协作：负责Kubernetes、日志、指标及运维流程的专业Agent协作，共同提供全面洞察。

  • 实时数据整合：Agent通过标准化API获取基础设施实时数据，并呈现关联分析结果。

  • 运维手册自动化执行：Agent可检索并展示常见故障场景下的分步操作流程。

  • 来源追溯：每项分析结果均包含明确的来源标注，以供验证与审计。

该解决方案架构如下图所示。

该架构展示了SRE支持Agent如何与Amazon Bedrock AgentCore组件无缝集成，具体如下：

1.用户交互界面：接收关于API响应时间下降的告警，并返回Agent生成的完整响应结果。

2.Amazon Bedrock AgentCore Runtime：管理多Agents SRE解决方案的执行环境。

3.SRE支持Agent：多Agents协作系统，负责处理事故并协调响应流程。

4.Amazon Bedrock AgentCore Gateway：通过OpenAPI接口将请求路由至专用工具，包括：

  • Kubernetes API：用于获取集群事件

  • 日志API：用于分析日志模式

  • 指标API：用于分析性能趋势

  • 运维手册API：用于检索运维流程

5.Amazon Bedrock AgentCore Memory：存储并检索会话上下文及历史交互记录，确保连续性。

6.Amazon Bedrock AgentCore Identity：集成Amazon Cognito，处理工具访问的身份验证。

7.Amazon Bedrock AgentCore Observability：收集并可视化Agent追踪信息，以便监控与调试。

8.Amazon Bedrock大语言模型（ LLM）：借助Anthropic的Claude LLM，为Agent提供智能支持。

该多Agents解决方案采用“Supervisor-Agent” 模式，由一个中央协调器统筹调度五个专业Agent协作，具体分工如下：

  • 主管Agent：分析查询请求并制定排查方案，将任务分配给对应专业Agent，同时汇总结果生成完整报告。

  • Kubernetes基础设施Agent：负责容器编排与集群运维，排查Pod故障、部署问题、资源限制及集群事件。

  • 应用日志Agent：处理日志数据以提取相关信息，识别数据模式与异常情况，并跨多个服务关联相关事件。

  • 性能指标Agent：监控系统指标并识别性能问题，提供实时分析结果与历史趋势数据。

  • 运维手册Agent：根据当前情况，提供文档化的操作流程、故障排查指南及问题升级处理流程。

使用Amazon Bedrock AgentCore

基础组件

该解决方案通过运用多个核心基础组件，充分展现了Amazon Bedrock AgentCore的强大能力。此方案为Anthropic的LLM提供了两种接入方式：

1.针对亚马逊云科技集成部署场景，Amazon Bedrock支持调用Anthropic的Claude 3.7 Sonnet模型。

2.针对直接API访问场景，则可通过Anthropic API调用Anthropic的Claude 4 Sonnet模型。

Amazon Bedrock AgentCore Gateway组件会将SRE Agent的后端API（包括Kubernetes API、应用日志API、性能指标API及运维手册API），转换为MCP工具。这使得采用基于MCP的开源框架（如本例使用的LangGraph）构建的Agent，可以无缝访问各类基础设施API。

Amazon Bedrock AgentCore Identity为整个解决方案提供安全保障。该组件支持两类认证功能，使方案可实现安全的API访问，且无需硬编码凭证：

  • 入站认证：为连接至网关的Agent提供安全访问控制。

  • 出站认证：管理Agent与后端服务器之间的认证流程。

Amazon Bedrock AgentCore Runtime为在生产环境中部署SRE Agent，提供了Serverless执行环境。该组件支持从零开始按需扩展，以应对并发事故排查需求，同时确保会话完全隔离。

Amazon Bedrock AgentCore Runtime支持OAuth协议与Amazon IAM两种Agent认证方式。调用Agent的应用程序必须具备相应的Amazon IAM权限与信任策略。

更多详细信息，请参阅《Amazon Bedrock AgentCore身份与访问管理指南》。

《Amazon Bedrock AgentCore身份与访问管理》

https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/security-iam.html

Amazon Bedrock AgentCore Memory将SRE Agent从无状态系统转变为智能学习助手，能够根据用户偏好与历史上下文定制个性化排查方案。该组件提供三种不同策略：

1.用户偏好策略

（/sre/users/{user_id}/preferences）

存储用户在排查风格、沟通渠道、问题升级处理流程及报告格式方面的偏好。例如，作为技术型SRE的Alice会收到包含故障排查步骤的详细系统性分析，作为管理人员的Carol则会收到聚焦业务视角的总结报告及影响分析。

2.基础设施知识策略

（/sre/infrastructure/{user_id}/{session_id}）

在排查过程中积累相关领域专业知识，让Agent能够从中学习。例如，当Kubernetes Agent识别出某类内存泄漏模式后，该知识将可供后续调查使用，有助于更快确定根本原因。

3.排查记忆策略

（/sre/investigations/{user_id}/{session_id}）

留存过往事件及其解决方案的历史上下文。凭借这一策略，解决方案可推荐经实践验证的故障修复方案，并规避此前已证实无效的错误模式。

个性化排查过程充分体现了存储组件价值。当Alice与Carol同时排查“过去一小时内API响应时间下降了3倍”这一问题时，两人获得的技术分析结果完全相同，但呈现形式却截然不同。

Alice收到的是一份技术分析报告。

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

左右滑动查看完整示意

Carol收到的则是一份高管摘要报告。

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

左右滑动查看完整示意

为SRE Agent添加可观测性功能

借助Amazon  Bedrock AgentCore Observability基础组件，可轻松为部署在Amazon Bedrock AgentCore Runtime上的SRE Agent添加可观测性功能。该组件支持通过Amazon CloudWatch全面监控指标、追踪数据与日志等。

*图片源自亚马逊云科技官网

完成以下三个步骤，即可配置可观测性功能：

1.将OpenTelemetry软件包添加至pyproject.toml文件。

dependencies = [    # ... other dependencies ...    "opentelemetry-instrumentation-langchain",    "aws-opentelemetry-distro~=0.10.1",        ]

左右滑动查看完整示意

2.为Agent配置可观测性功能，以便在Amazon CloudWatch中启用指标监控功能。

3.使用opentelemetry-instrument工具启动容器，实现应用程序的自动检测。

将以下命令添加至SRE Agent对应的Dockerfile中。

# Run application with OpenTelemetry instrumentation CMD ["uv", "run", "opentelemetry-instrument", "uvicorn", "sre_agent.agent_runtime:app", "--host", "0.0.0.0", "--port", "8080"]

左右滑动查看完整示意

如下图所示，启用可观测性功能后，用户可清晰掌握以下信息：

  • LLM调用指标：各Agent的Token使用量、调用延迟情况及模型性能数据。

  • 工具执行追踪数据：每次MCP工具调用的耗时与成功率。

  • 存储操作数据：检索模式与存储效率。

  • 端到端请求追踪：从用户查询到最终响应的完整请求流程。

无需额外修改代码，可观测性基础组件即可自动采集这些指标，开箱即用般提供生产级监控能力。

从本地开发到投入生产应用

SRE Agent遵循一套结构化的四步部署流程，实现从本地开发环境到生产环境的过渡。有关具体详细步骤，请参阅配套GitHub代码库中的《从本地开发到投入生产应用》文档。

《从本地开发到投入生产应用》

https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/02-use-cases/SRE-agent#development-to-production-deployment-flow

该部署流程可确保各环境间的一致性：核心Agent代码（sre_agent/）保持不变，部署专用工具则存放在deployment/文件夹中。通过环境配置，同一Agent既可在本地运行，也可投入生产环境使用。

同时，Amazon Bedrock AgentCore Gateway能在开发与部署的不同阶段，为Agent提供访问MCP工具的能力。

实施流程

下文将重点介绍AgentCore Gateway、AgentCore Memory与AgentCore Runtime三大组件如何协作，构建该多Agents协作解决方案，并借助MCP支持以及持久化智能能力，实现端到端的部署。

首先，搭建代码库，并构建本地运行时环境，包括设置API密钥、指定LLM提供方及部署演示环境基础设施。

其次，通过创建标准化API访问网关、配置身份认证机制及建立各类工具连接，启动Amazon Bedrock AgentCore核心组件。

然后，利用AgentCore Memory为方案注入智能能力：针对用户偏好和调查历史制定策略，同时加载角色配置以实现个性化事件响应。

最后，为各个Agent配置专用工具、集成存储功能、编排协作流程，并将方案部署至已具备完整可观测性功能的AgentCore Runtime。

代码库中提供了详细操作说明，具体包括：

  • 用例搭建指南：涵盖后端部署与开发环境配置。

  • 部署指南：包含生产环境容器化流程及Amazon Bedrock AgentCore Runtime部署步骤。

用例搭建指南：

https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/02-use-cases/SRE-agent#use-case-setup

部署指南：

https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/02-use-cases/SRE-agent/docs/deployment-guide.md

准备条件

您可参阅README文件的“准备条件”部分，了解端口转发要求及其他设置说明。

README文件——准备条件：

https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/02-use-cases/SRE-agent#prerequisites

使用AgentCore Gateway

将API转换为MCP工具

Amazon Bedrock AgentCore Gateway通过将现有后端API转换为Agent框架可调用的MCP工具，充分展现了协议标准化的重要价值。并且这一转换过程实现了无缝衔接，仅需依赖OpenAPI规范即可完成。

上传OpenAPI规范文件

网关配置流程始于将现有API规范上传至Amazon S3。create_gateway.sh脚本会自动将四项API规范文件（即Kubernetes、日志、指标和运维手册）上传至已配置好的Amazon S3存储桶，并自动设置恰当的元数据和内容类型。之后，这些规范文件将用于在网关中创建API端点目标。

创建身份提供方与网关

身份认证通过AgentCore Identity实现无缝处理。main.py脚本会同时创建凭证提供方与网关。

# Create AgentCore Gateway with JWT authorizationdef 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]:        # Build auth config for 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 key credential provider configuration    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工具已可供Agent框架使用

部署完成后，Amazon Bedrock AgentCore Gateway会提供一个标准化的/mcp端点，该端点通过JWT token保障安全性。使用mcp_cmds.sh脚本测试部署情况，可直观体现此次转换的强大作用。

Tool summary:================Total tools found: 21
Tool names:• 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

左右滑动查看完整示意

通用Agent框架兼容性

现在，这个符合MCP标准的网关可配置为面向MCP客户端的Streamable-HTTP服务器，支持的客户端包括：

  • Amazon Strands：亚马逊云科技官方Agent开发框架。

  • LangGraph：本方案实现SRE Agent所用的框架。

  • CrewAI：一款多Agents协作框架。

该方案的优势在于，无需对现有API进行任何修改，仅需提供OpenAPI规范即可。Amazon Bedrock AgentCore Gateway负责处理以下事项：

  • 协议转换：实现REST API与MCP之间的转换。

  • 身份认证：完成JWT token验证与凭证注入

  • 安全防护：提供TLS终止与访问控制功能。

  • 标准化处理：统一工具命名规则与参数处理逻辑。

因此，借助这一单一、安全且标准化的接口，用户可直接将现有基础设施API（如Kubernetes、监控、日志、文档相关API），开放给支持MCP的AI Agent框架即时使用。

利用AgentCore Memory

实现持久化智能

Amazon Bedrock AgentCore Gateway的核心作用是提供无缝的API访问能力，Amazon Bedrock AgentCore Memory则专注于将SRE Agent从无状态系统转变为智能的学习型助手。

借助该功能，仅需几行代码，就能为Agent赋予复杂的个性化能力与跨会话知识留存能力。

初始化内存策略

SRE Agent的内存组件基于Amazon Bedrock AgentCore Memory的事件驱动模型构建，并具备自动命名空间路由能力。在初始化阶段，该方案会创建三种分别具有特定命名空间模式的存储策略。

from sre_agent.memory.client import SREMemoryClientfrom sre_agent.memory.strategies import create_memory_strategies
# Initialize memory clientmemory_client = SREMemoryClient(    memory_name="sre_agent_memory",    region="us-east-1")
# Create three specialized memory strategiesstrategies = create_memory_strategies()for strategy in strategies:    memory_client.create_strategy(strategy)

左右滑动查看完整示意

三种策略各有用途：

1.用户偏好策略

（/sre/users/{user_id}/preferences）

存储用户个人的排查风格与沟通偏好等相关信息。

2.基础设施知识策略

（/sre/infrastructure/{user_id}/{session_id}）

留存用户在历次排查过程中积累的领域专业知识。

3.排查记忆策略

（/sre/investigations/{user_id}/{session_id}）

记录历史事故的规律特征与解决方案。

加载用户角色配置与偏好设置

该方案已预配置了用户角色配置，可用于演示个性化排查流程，manage_memories.py脚本负责加载这些角色配置。

# Load Alice - Technical SRE Engineeralice_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"}
# Load Carol - Executive/Directorcarol_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"}
# Store preferences using memory clientmemory_client.store_user_preference("Alice", alice_preferences)memory_client.store_user_preference("Carol", carol_preferences)

左右滑动查看完整示意

自动命名空间路由的实际应用

Amazon Bedrock AgentCore Memory的一大优势在于其自动命名空间路由功能。当SRE Agent创建事件时，只需提供actor_id即可，Amazon Bedrock AgentCore Memory会自动判断该事件所属的命名空间。

# During investigation, the supervisor agent stores contextmemory_client.create_event(    memory_id="sre_agent_memory-abc123",    actor_id="Alice",  # AgentCore Memory routes this automatically    session_id="investigation_2025_01_15",    messages=[("investigation_started", "USER")])
# Memory system automatically:# 1. Checks strategy namespaces <!-- "all" is necessary here for technical accuracy --># 2. Matches actor_id "Alice" to /sre/users/Alice/preferences# 3. Stores event in User Preferences Strategy# 4. Makes event available forfuture retrievals

左右滑动查看完整示意

验证个性化排查体验

当Alice与Carol排查同一问题时，内存组件的作用便显而易见。即便基于完全相同的技术排查结果，该解决方案仍能以截然不同的形式呈现同一核心内容。

Alice收到的技术报告提供了详细的系统性分析，专门面向SRE技术团队。

Technical Investigation Summary
Root Cause: Payment processor memory leak causing OOM kills
Analysis:- Pod restart frequency increased 300% at 14:23 UTC- Memory utilization peaked at 8.2GB (80% of container limit)- JVM garbage collection latency spiked to 2.3s
Next Step:1.Implement heap dump analysis(`kubectl exec payment-pod -- jmap`)2. Review recent code deployments for memory management changes3. Consider increasing memory limits and implementing graceful shutdown

左右滑动查看完整示意

Carol收到的高管摘要则聚焦业务影响，专门面向企业高管层利益相关方。

Business Impact AssessmentStatus: CRITICAL - Customer payment processing degradedImpact: 23% transaction failure rate, $47K revenue at riskTimeline: Issue detected 14:23 UTC, resolution ETA 45 minutesBusiness Actions: - Customer communication initiated via status page - Finance team alerted for revenue impact tracking - Escalating to VP Engineering ifnot resolved by 15:15 UTC

左右滑动查看完整示意

内存组件不仅实现了个性化呈现，还能从每次排查中持续学习，不断积累专业领域知识，并随时间推移逐步优化事故响应流程。

利用AgentCore Runtime

部署至生产环境

借助Amazon Bedrock AgentCore，可更简单更直接将现有Agent部署至生产环境。整个流程包含三个关键步骤：

  • 将Agent容器化。

  • 部署至Amazon Bedrock AgentCore Runtime。

  • 调用已部署的Agent。

将Agent容器化

Amazon Bedrock AgentCore Runtime要求使用ARM64架构的容器。

以下代码展示了完整的Dockerfile文件。

# Use uv's ARM64 Python base imageFROM --platform=linux/arm64 ghcr.io/astral-sh/uv:python3.12-bookworm-slim
WORKDIR /app
# Copy uv filesCOPY pyproject.toml uv.lock ./
# Install dependenciesRUN uv sync --frozen --no-dev
# Copy SRE agent moduleCOPY sre_agent/ ./sre_agent/
# Set environment variables# Note: Set DEBUG=true to enable debug logging and tracesENV PYTHONPATH="/app" \    PYTHONDONTWRITEBYTECODE=1 \    PYTHONUNBUFFERED=1
# Expose portEXPOSE 8080
# Run application with OpenTelemetry instrumentationCMD ["uv", "run", "opentelemetry-instrument", "uvicorn", "sre_agent.agent_runtime:app", "--host", "0.0.0.0", "--port", "8080"]

左右滑动查看完整示意

现有Agent只需添加一个FastAPI封装层（agent_runtime:app），即可与Amazon Bedrock AgentCore兼容。

同时，添加opentelemetry-instrument，以支持通过Amazon Bedrock AgentCore实现可观测性。

部署至AgentCore Runtime

使用deploy_agent_runtime.py脚本，可轻松将Agent部署至Amazon Bedrock AgentCore Runtime。

import boto3
# Create AgentCore clientclient = boto3.client('bedrock-agentcore', region_name=region)
# Environment variables for your agentenv_vars = {    'GATEWAY_ACCESS_TOKEN': gateway_access_token,    'LLM_PROVIDER': llm_provider,    'ANTHROPIC_API_KEY': anthropic_api_key  # if using Anthropic}
# Deploy container to AgentCore Runtimeresponse = client.create_agent_runtime(    agentRuntimeName=runtime_name,    agentRuntimeArtifact={        'containerConfiguration': {            'containerUri': container_uri  # Your ECR container URI        }    },    networkConfiguration={"networkMode": "PUBLIC"},    roleArn=role_arn,    environmentVariables=env_vars)
print(f"Agent Runtime ARN: {response['agentRuntimeArn']}")

左右滑动查看完整示意

Amazon Bedrock AgentCore会自动处理基础设施管理、弹性扩展以及会话管理相关工作。

调用已部署的Agent

使用invoke_agent_runtime.py脚本，调用已部署的Agent同样简单便捷。

# Prepare your query with user_id and session_id for memory personalizationpayload = json.dumps({    "input": {        "prompt": "API response times have degraded 3x in the last hour",        "user_id": "Alice",  # User for personalized investigation        "session_id": "investigation-20250127-123456"  # Session for context    }})
# Invoke the deployed agentresponse = agent_core_client.invoke_agent_runtime(    agentRuntimeArn=runtime_arn,    runtimeSessionId=session_id,    payload=payload,    qualifier="DEFAULT")
# Get the responseresponse_data = json.loads(response['response'].read())print(response_data)  # Full response includes output with agent's investigation

左右滑动查看完整示意

AgentCore Runtime关键优势

Amazon Bedrock AgentCore Runtime具备以下关键优势：

  • 零基础设施管理：无需配置服务器、负载均衡器，也无需手动处理扩缩容。

  • 内置会话隔离：每个会话均实现完全隔离。

  • Amazon IAM集成：无需自定义认证机制，即可实现安全的访问控制。

  • 自动扩缩容：支持从0扩展至数千个并发会话。

敬请参阅《部署指南》，了解包括容器构建与亚马逊云科技权限在内的完整部署流程。

《部署指南》

https://github.com/awslabs/amazon-bedrock-agentcore-samples/blob/main/02-use-cases/SRE-agent/docs/deployment-guide.md

应用实践案例

下面将结合真实排查案例，介绍SRE Agent如何处理常见的事故响应场景。

遇到生产环境问题时，用户可以用自然语言查询系统。该解决方案会借助Amazon Bedrock AgentCore Memory，根据用户设定的角色与偏好，提供个性化的排查支持。

export USER_ID=Alicesre-agent --prompt "API response times have degraded 3x in the last hour"

左右滑动查看完整示意

主管Agent会调取Alice的偏好设置（即详细的系统性分析风格），并针对其技术SRE的角色，量身定制一份排查方案。

Investigation Plan1. Use metrics_agent to analyze API performance metrics including response times, error rates, and resource utilization to identify the extent and pattern of slowdown2. Use logs_agent to examine application logs for errors related to slow API responses, focusing on database connection issues and memory errors3. Use kubernetes_agent to check pod status and resource constraints, especially for web-service and database pods, looking for CrashLoopBackOff states and missing ConfigMapsComplexity: SimpleAuto-execute: YesAgents involved: Metrics Agent, Logs Agent, Kubernetes Agent

左右滑动查看完整示意

各专业Agent会依据方案依次开展排查工作，各自运用其专业分析方法贡献见解。随后，该方案将整合这些排查结果，生成一份完整的执行摘要。

Executive SummaryKey Insights- Root Cause: Database service failure due to missing ConfigMap 'database-config' in production namespace, causing database pod to crash repeatedly- Impact: Severe performance degradation with API response times increased from 150ms to 5000ms (33x slower)- Severity: High - Database unavailability, memory exhaustion(100%), and CPU saturation(95%) causing 75% error rateNext Steps1. Immediate(< 1 hour): Create/update ConfigMap 'database-config' in production namespaceand restart database pod2. Short-term(< 24 hours):    - Fix permissions on '/var/lib/postgresql/data' directory   - Increase Java heap space for web-service to address OutOfMemoryErrors   - Optimize UserService.loadAllUsers method causing memory issues3. Long-term(< 1 week):    - Implement resource monitoring with alerts forCPU(>80%), memory(>90%)   - Optimize slow database queries, particularly "SELECT * FROM users WHERE status='active'"   - Scale up resources or implement autoscaling for web-serviceCritical Alerts- Database pod (database-pod-7b9c4d8f2a-x5m1q) in CrashLoopBackOff state- Web-service experiencing OutOfMemoryErrors in UserService.loadAllUsers(UserService.java:45)- Node-3 experiencing memory pressure (>85% usage)- Web-app-deployment showing readiness probe failures with 503 errorsTroubleshooting Steps1. Verify ConfigMap status: `kubectl get configmap database-config -n production`2. Check database pod logs: `kubectl logs database-pod-7b9c4d8f2a-x5m1q -n production`3. Create/update ConfigMap: `kubectl create configmap database-config --from-file=database.conf -n production`4. Fix data directory permissions: `kubectl exec database-pod-7b9c4d8f2a-x5m1q -n production -- chmod -R 700 /var/lib/postgresql/data`5. Restart database pod: `kubectl delete pod database-pod-7b9c4d8f2a-x5m1q -n production`

左右滑动查看完整示意

本次排查案例清晰展示了Amazon Bedrock AgentCore各核心组件如何协作：

  • AgentCore Gateway：通过MCP工具为基础设施API提供安全访问通道。

  • AgentCore Identity：负责处理入站与出站的身份认证工作。

  • AgentCore Runtime：托管具备自动扩展能力的多Agents解决方案。

  • AgentCore Memory：一方面为用户提供个性化体验，另一方面存储排查知识以供未来处理事故时调用。

  • AgentCore Observability：在Amazon CloudWatch中捕获详细指标与追踪信息，用于系统监控与故障排查。

SRE Agent充分展现了Agent协同调度能力：主管Agent会依据排查方案，将任务分配给各专业Agent。该解决方案的存储功能则确保每次排查都能积累知识，并根据用户角色与偏好提供个性化体验。

*图片源自亚马逊云科技官网

本次排查案例凸显了多项核心能力：

  • 多源关联：可将数据库配置问题与API性能下降关联起来。

  • 有序排查：各Agent会依据排查方案系统性推进工作，并实时同步最新进展。

  • 来源追溯：排查结果会明确标注具体使用的工具及数据源信息。

  • 可落地洞察：提供清晰的事件时间线，以及按优先级排序的恢复步骤。

  • 级联故障检测：可帮助呈现某一故障如何在系统中扩散传播的过程。

业务价值

已采用AI驱动的SRE助手的企业反馈，其核心运营指标得到显著改善：以往需要30至45分钟才能完成的初步排查，如今仅需5至10分钟，让SRE在开展深入分析前就能掌握完整背景信息。排查时间的大幅缩短，也将直接转化为更快的事故解决速度，进而减少业务中断时长。

该解决方案还优化了SRE与基础设施的交互方式：工程师无需在多个仪表盘和工具间切换操作，而是只需用自然语言提问，就能从相关数据源获取整合洞察。这不仅让团队能够在处理关键事故时保持专注，还能降低调查过程中的认知负荷。

或许最重要的是，该解决方案实现了团队内部的知识普及。所有团队成员都能使用统一的完整排查方法，既减少了对“隐性知识”的依赖，也减轻了相关人员工作负担。此外，该解决方案提供的标准化流程，可以确保无论团队成员是谁、处理何种类型事故，都能保持使用一致的排查方法，从而提升整体可靠性，同时降低遗漏关键证据的风险。

自动生成的排查报告为事后复盘提供了极具价值的文档资料，助力团队从每次事故中总结经验，并随时间推移不断积累凝结为组织知识。

此外，该解决方案还能充分利用企业已有的亚马逊云科技基础设施投入，与Amazon CloudWatch、Amazon Systems Manager及其他亚马逊云科技运维工具协作，共同构建统一的运维智能系统。

*图片源自亚马逊云科技官网

扩展解决方案

该解决方案采用模块化架构，用户可轻松根据特定需求进行扩展。

例如，用户可针对自身业务领域添加专业Agent：

  • 安全Agent：用于合规性检查与安全事件响应。

  • 数据库Agent：专门处理数据库故障排查与性能优化。

  • 网络Agent：负责网络连接检测与基础设施调试。

您也可将演示API替换为与实际业务系统的连接，例如：

  • Kubernetes集成：连接集群API，获取Pod状态、部署信息及事件数据。

  • 日志集成：与Amazon CloudWatch Logs等日志管理服务集成。

  • 指标监控：连接Amazon CloudWatch Metrics等监控服务。

  • 运维手册库：关联存储在Git代码库、知识库等的运维文档与操作手册。

清理

为避免后续产生费用，请使用清理脚本，删除演示过程中创建的需要付费的亚马逊云科技资源。

# Complete cleanup - deletes AWS resources and local files./scripts/cleanup.sh

左右滑动查看完整示意

该脚本会自动执行以下操作：

  • 终止后端服务器。

  • 删除网关及其目标资源。

  • 删除Amazon Bedrock AgentCore Memory资源。

  • 删除Amazon Bedrock AgentCore Runtime资源。

  • 删除生成的文件，包括网关URI、token、Agent ARN、存储ID等。

如需详细的清理操作说明，请参阅《清理操作指南》。

《清理操作指南》

https://github.com/awslabs/amazon-bedrock-agentcore-samples/blob/main/02-use-cases/SRE-agent/scripts/cleanup.sh

总结

SRE Agent充分展现了多Agents系统的价值：将事故响应从耗时费力的手动操作流程，转变为高效协作的排查过程，为SRE提供宝贵洞察，助力其快速解决问题。

通过将Amazon Bedrock AgentCore的企业级基础设施，与MCP中的标准化工具访问能力相结合，本例构建了一套可随基础设施演进和系统功能更新而灵活适配的底层框架。

完整的实现方案已发布至GitHub代码库，内含演示环境、配置指南及扩展示例等内容。建议您深入探索该解决方案，根据自身基础设施需求进行定制。

您可参考以下资源，着手构建您的专属SRE助手。

GitHub代码库：

https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/02-use-cases/SRE-agent

利用AI Agent实现应用任务自动化：

https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html

Amazon Bedrock AgentCore示例GitHub代码库：

https://github.com/awslabs/amazon-bedrock-agentcore-samples

MCP文档：

https://modelcontextprotocol.io/

LangGraph文档：

https://langchain-ai.github.io/langgraph/

新用户注册海外区域账户，可获得最高200美元服务抵扣金，覆盖Amazon Bedrock生成式AI相关服务。“免费计划”账户类型，确保零花费，安心试用。

五折认证，一次不过，免费重考，并享受官方备考服务。加入AWS AI/ML认证挑战，考取AWS AI认证为您的未来提供动力!

本篇作者

Amit Arora

亚马逊云科技人工智能与机器学习专家架构师，致力于帮助企业客户使用基于云的机器学习服务快速扩展创新成果。同时，Amit还是华盛顿特区乔治城大学数据科学与分析硕士课程的兼职讲师。

Dheeraj Oruganty

亚马逊云科技的交付顾问。Dheeraj热衷于构建具有创新性的生成式AI与机器学习解决方案，助力企业创造业务价值。他的专业领域涵盖Agentic AI评估、基准测试及Agent协同调度，并积极投身该领域的前沿研究，为技术发展贡献力量。他还拥有乔治城大学的数据科学硕士学位。

星标不迷路，开发更极速！

关注后记得星标「亚马逊云开发者」

听说，点完下面4个按钮

就不会碰到bug了！

点击阅读原文查看博客！获得更详细内容！

Logo
火山引擎开发者社区

火山引擎开发者社区是火山引擎打造的AI技术生态平台，聚焦Agent与大模型开发，提供豆包系列模型（图像/视频/视觉）、智能分析与会话工具，并配套评测集、动手实验室及行业案例库。社区通过技术沙龙、挑战赛等活动促进开发者成长，新用户可领50万Tokens权益，助力构建智能应用。

更多推荐

OBS Studio音频分离：人声与背景音乐分离全攻略

你是否曾在直播或录屏时遇到这样的困境：想要单独调整人声音量却影响了背景音乐，或是后期剪辑时无法消除环境噪音？OBS Studio（Open Broadcaster Software Studio，开放广播软件工作室）作为免费开源的音视频录制与直播工具，提供了强大的音频处理框架，通过合理配置滤镜链与外部工具组合，可实现专业级别的人声与背景音乐分离。本文将系统讲解3种分离方案，从基础声道分离到AI驱动

avatar 火山引擎开发者社区

lmstudio-python：简化LLM操作的强大Python SDK

lmstudio-python 是一款功能强大的 Python SDK，旨在帮助开发者轻松地使用大型语言模型（LLM）进行文本生成、对话系统搭建以及其他相关应用。通过简单易用的API，lmstudio-python 能够让用户快速集成 LLM 功能，无论是进行基础文本补全还是复杂的对话系统设计。## 项目技术分析lmstudio-python SDK 以 Python 为基础，提供了一个同

avatar 火山引擎开发者社区

OBS Studio AI增强：智能场景识别与自动优化全攻略

你是否曾在直播切换场景时手忙脚乱？是否因复杂的参数配置而错失最佳直播时机？OBS Studio作为开源直播软件的佼佼者，虽提供强大的自定义功能，但传统手动操作已难以满足专业创作者对效率和质量的双重需求。本文将系统介绍如何通过AI技术增强OBS Studio的核心能力，重点实现智能场景识别与自动参数优化，让你的直播制作流程效率提升300%。读完本文你将获得：- 基于OpenCV的实时场景分析插

avatar 火山引擎开发者社区