利用MCP、Bedrock Nova构建自主型AWS SRE Copilot，并实现人工审批流程。

大约一年来，业界一直专注于ChatOps：将大型语言模型集成到Slack或Telegram中，作为CI/CD流程的智能封装层。不过，聊天机器人仅仅是其可见的部分，真正的企业价值在于从被动的聊天机器人转向自主代理。基于Amazon Bedrock（Nova）、模型上下文协议（MCP）及AWS构建的自主站点可靠性工程（SRE）辅助工具展现了这一愿景。它不仅能触发流程，还能自主分析实时生产故障，获取指标与日志，找出根本原因并应用修复措施，所有操作都在有人监管的安全信任范围内进行。

托管方案：AWS DevOps Agent

在构建任何定制化解决方案之前，架构师应先确认AWS是否已提供类似功能。实际上AWS确实有相关产品。AWS在2025年的re:Invent大会上推出了DevOps Agent，将于2025年12月进入预览阶段，并在2026年3月全面上市。这是一个功能强大的多代理系统，旨在实现AWS环境中的自动故障响应。

它远远超越了像DevOps Guru这样的旧工具：

• 自动故障响应。一旦CloudWatch警报触发，该系统便会启动调查，通过整合遥测数据、日志、追踪信息、代码变更记录以及部署历史来定位根本原因，并制定缓解方案。
• 主动预防。它能够分析历史故障模式，为提升可观测性、基础设施性能以及流程效率提出改进建议。

发布就绪性审查。它在代码变更和部署流程进入生产环境之前对其进行审核。

多智能体设计。一个主协调器负责指挥专门的子智能体来执行日志分析、根本原因排查等任务，这与本次构建所采用的模式相同。

广泛的集成能力。Datadog、Dynatrace、New Relic、Splunk、PagerDuty、GitHub、GitLab、ServiceNow和Slack均可直接集成。

从理论上讲，它涵盖了SRE团队可能需要的所有功能。

为何要构建定制版本

问题在于访问权限。DevOps Agent仅随AWS Business+和Enterprise级别的支持计划一同提供，不向普通用户开放按需购买服务。使用Developer Support级别的机构、初创公司、独立团队，或是没有Enterprise支持而在客户账户中工作的顾问都无法使用它。

该托管服务适合那些已使用企业级支持、且遵循标准AWS架构模式的团队，因为AWS已经完成了大部分工作，同时具备广泛的集成能力。但对于AI架构师而言，更值得探讨的问题是：是否足够深入地理解这些模式，从而能够独立构建相关系统，并在托管产品无法覆盖的领域进行扩展。这个项目正是对此的体现。

核心问题：大规模工具的应用

像Amazon Nova这样的模型虽然理解分布式系统、AWS架构以及复杂的调试过程，但它们本质上仍只是“罐子里的大脑”——无法查看CloudWatch指标，也无法操作DynamoDB表。

以往，要让大型语言模型脱离传统工具运行，往往需要编写脆弱的定制代码：

1. 为该工具定义JSON架构。
2. 编写用于运行它的Python函数。
3. 将AWS凭证硬编码到代理程序的运行环境中。

这使智能体与基础设施紧密绑定，从而带来安全问题及维护瓶颈。

MCP的登场

由Anthropic推出的模型上下文协议正迅速成为行业标准，它很好地解决了这一问题。这是一种标准化协议，堪称AI领域的USB-C，能够将模型与外部数据源及工具相连。无需将AWS工具硬编码到智能体中，而是构建独立的MCP服务器。该服务器位于AWS环境中，并拥有必要的IAM角色，通过标准协议提供严格类型化、具有语义意义的工具。无论在何处运行的智能体都可以作为MCP客户端进行连接，因为它无需AWS凭证，只需向服务器请求执行相应工具即可。

自由选择模型

由于MCP并不关心另一端使用的是哪种模型，SRE智能体编排器可以根据需求选择合适的模型：

Amazon Nova  ─┐
Claude 3.5   ─┼──→  SRE Agent Orchestrator  ──→  MCP Server  ──→  AWS Cloud
OpenAI GPT-4o─┘          (agent.py)                (server.py)

要使用其他提供商的模型，只需修改一行代码即可。MCP服务器及其提供的所有安全AWS工具完全保持不变。

SRE智能助手的架构

1. 目标基础设施

为了让智能助手有东西可修复，会使用Terraform部署一个标准的无服务器微服务：在Lambda函数前端设置API网关，该函数负责向DynamoDB表写入数据。人为设置的缺陷在于该表的读取容量单元和写入容量单元各仅为1，因此在任何实际负载下，此API都会抛出ProvisionedThroughputExceededException错误。

2. MCP服务器

一个Python FastMCP服务器充当操作接口，提供四种SRE功能：

• describe_architecture功能可查找所有带有应用标签的AWS资源（ARN）。

query_cloudwatch_metrics用于获取诸如ThrottledRequests之类的时间序列数据。

query_cloudwatch_logs会执行CloudWatch Logs Insights查询以定位堆栈跟踪信息。

remediate_dynamodb_capacity是一种会修改数据的工具，用于提升表格的容量。

信任边界是人类介入的位置。只读工具完全自主运行，因此模型可以随意使用它们来进行调查。而修复工具则要求必须有人类介入才能继续操作。在调用AWS API之前，它会暂停并请求终端中的操作员给出[y/N]确认，同时显示模型的处理理由。DevOps Guru和Amazon Q都无法提供这种由组织自身规则设定的、可审计的状态变更操作检查点。

3. 自主代理

该智能体是一个小型 Python 脚本，通过 boto3 与 Amazon Bedrock Converse API 进行交互，选用 Amazon Nova 模型系列是因为其功能强大且成本较低。它运行一个自动的 while 循环：

1. 它接收类似“用户反馈 Payment API 出现超时问题，需要修复”的提示。
2. 它向 MCP 服务器查询可用的工具。
3. 它将 MCP 工具的架构直接转换为 Bedrock Converse 格式。
4. 它开始进行分析：查找 Payment API 相关资源，检查其指标，然后读取日志。
5. 它通过 MCP 调用相应工具，将结果反馈给 Bedrock，并持续处理直到找到解决方案并触发修复工具。

循环的实际运行过程

当被要求查明为何演示 API 会返回 429 和 500 错误码时，该智能体会按以下步骤进行处理：

1. 它会调用describe_architecture来获取Lambda函数和DynamoDB表的ARN。
2. 接着它会对该表调用query_cloudwatch_metrics，查看ProvisionedThroughputExceededRequests的数值，发现其出现了大幅上升。
3. 为确认情况，它会进一步对Lambda函数调用query_cloudwatch_logs，解析JSON日志后确认存在ProvisionedThroughputExceededException异常。
4. 最终判断出容量不足，于是调用remediate_dynamodb_capacity，请求分配50个RCU和50个WCU。

此时MCP服务器会拦截该请求并提示操作人员处理：

=======================================================
⚠️ URGENT: AGENT REQUESTING PERMISSION TO MODIFY INFRASTRUCTURE
=======================================================
Action: Scale DynamoDB Table 'sre-copilot-payments-dev'
New Capacity: Read=50, Write=50
Agent's Reason: The table is experiencing severe throttling (ProvisionedThroughputExceededException). Scaling up to mitigate the incident.
=======================================================
Approve this change? [y/N]: y

同一代理还以Streamlit聊天应用的形式运行，展示拟议的解决方案及审批流程。一旦人工完成审批，容量就会得到更新，事件也随之解决。

该架构的优势

通过MCP将“大脑”（Amazon Nova及Bedrock）与“双手”（AWS API）分离，带来了管理型AWS工具无法比拟的灵活性：

• LLM的可移植性。只需修改一次配置，即可将Nova替换为Claude或GPT-4o。
• 安全性。原始凭证永远不会传递到LLM运行时。
• 安全性。所有操作变更都必须经过可自定义的人工审批流程。
• 可扩展性。无论是PagerDuty、Datadog API查询还是ServiceNow工单检查，只需一个@mcp.tool()函数即可实现。

自主性。该代理可自由探索只读的遥测数据，因此能够发现DevOps Guru这类模式匹配工具会忽略的异常问题。

云运维似乎正从束缚团队的单一管理型服务，转向由团队自行构建、拥有并持续改进的、可组合的、与模型无关且可审计的代理。这是一种适合投入实际应用的模式，而不仅仅是演示而已。

供参考，MCP规范发布在modelcontextprotocol.io上，AWS Labs也提供了开源的参考MCP服务器。