亚马逊AWS官方博客
基于 CoT 协调多 MCP Tool — 智能运维 Redshift
![]() |
Amazon Redshift 是一种在云端运行的全托管、PB 级数据仓库服务。它为企业提供了强大的数据分析能力,能够处理海量数据并提供快速的查询性能。作为 AWS 数据分析生态系统的核心组件,Amazon Redshift 通过列式存储、并行处理和高效的数据压缩算法,使组织能够以经济实惠的方式从其数据中获取洞察。
Amazon Q Developer 是亚马逊云科技推出的一款生成式 AI 助手,加速整个软件开发生命周期的构建,从设计、开发、测试和运维,到执行软件升级。Amazon Q Developer 中的 Q Developer CLI 是一个在命令行中运行的智能 AI 助手。Amazon Q Developer CLI 通过集成模型上下文协议(Model Context Protocol,简称 MCP)进一步拓展了其功能边界。MCP 允许 Amazon Q Developer CLI 与各种外部工具和服务无缝连接,使其能力得到显著增强。
在《基于 Amazon Q Developer+Remote MCP 访问 Amazon Redshift》中已经介绍了如何通过 Amazon API Gateway 与 AWS Lambda 实现 Remote MCP,并集成至 Amazon Q Developer CLI ,实现了 “Agent+ Remote MCP” 的模式。但是在实际使用过程中发现, Agent 规划出的任务清单(to-do list)、调用 MCP Tool 的方式,不总是符合用户的预期,尤其是在 MCP Tools 较多时还会出现过于发散的情况。
本文将使用 Amazon Q Developer CLI 集成多个 MCP Tool,优化 Amazon Redshift 的日常运维场景效率,如性能优化、排查问题与巡检等。并使用思维链(Chain of Thought),针对用户场景中的一些常见问题,定制 Agent 的处理思路,协调多 MCP Tool 按用户预期完成工作。
一、解决方案概述
下图展示了方案的整体架构,基于 Amazon API Gateway+AWS Lambda 实现了三个 MCP Server。
- CoT MCP Server:在 Amazon S3 上以 Markdown 格式存储了一些常见问题的处理思路,然后通过 CoT MCP Server 做了一个简易的 RAG ,让 LLM 推理返回一个任务清单(to-do list),并在 Amazon DynamoDB 中创建一个 session 记录任务清单(to-do list)。Amazon Q Developer CLI 会按照这个任务清单(to-do list)来执行任务。之所以是使用 S3,而不是使用 Amazon Q Developer CLI 本地的 Context,是为了方便在不同用户的 Amazon Q Developer CLI 上进行共享。
- Redshift MCP Server:让 Amazon Q Developer CLI 可以生成 SQL 并执行 SQL 。
- Monitor MCP Server:调用 Amazon CloudWatch API 查询 Amazon Redshift 的监控指标。尽管 Amazon Q Developer CLI 可以通过 AWS_CLI Tool 来查询 Amazon CloudWatch 指标,但本场景中存在一些定制化的需求,所以单独开发实现了一个 MCP Server 来查询 Amazon CloudWatch 指标。
![]() |
本方案中实现 3 个 MCP Server 共计 8 个 MCP Tool ,如下图所示。重点是 CoT MCP Server,提供了 plan_task 与 check_list 两个 tool。
- 当 Amazon Q Developer CLI 开始处理 Redshift 相关的问题时,根据 plan_task 提示词的设计,会自动触发 plan_task 的调用,生成任务清单(to-do list)。
- 然后 Amazon Q Developer CLI 会按照任务清单(to-do list)去执行任务,调用其它 MCP Tool。
- 最后会根据 check_list 的提示词设计,自动触发 check_list 的调用,并根据 session id 从 Amazon DynamoDB 中获取此前生成的任务清单(to-do list),然后检查此前规划的任务清单(to-do list)是否完成。若发现有未完成项,则会触发继续执行。
![]() |
二、解决方案实施
针对上面介绍的解决方案,可参考如下步骤进行实施与部署。大部分的操作,都通过 SAM CLI 进行自动化部署。
1. 前提准备
准备一台 Amazon Linux 2023 的 EC2,设置 AWS Credentials(AWS CLI Configure 或者 EC2 IAM Role),并安装以下环境:
- Make
- AWS SAM CLI (AWS Serverless Application Model Command Line Interface)
- Docker
参考如下脚本:
下载解决方案所使用的代码:
代码的整体目录结构如下所示:
2. 配置环境变量
在实施解决方案之前,需要先修改配置文件,修改环境变量。
配置文件中的主要参数如下:
- AWS Configuration:
PROFILE
:AWS CLI Profile 名称,若对 Amazon EC2 配置了 IAM Role,则可以忽略此选项BUCKET
:存储部署文件(如 Layer 的 zip 包)的 S3 桶REGION
:部署 Amazon API Gateway+AWS Lambda 的 AWS region
- MCP Dependencies:
P_DESCRIPTION
:MCP package version(默认值: “mcp==1.8.0″)O_LAYER_ARN
:AWS Lambda Layer 的 ARN,需要在完成“make layer”命令后命令,获取 ARN,并更新该参数,再执行后续命令
- API Gateway and Lambda Configuration:
P_API_STAGE
:Amazon API Gateway 的部署阶段名称 (默认值:dev)P_FN_MEMORY
:AWS Lambda 的内存大小 (默认值:128 MB)P_FN_TIMEOUT
:AWS Lambda 的超时时间(默认值:30 秒)
3. 构建 Lambda Layer
MCP Server 中的 python 代码会依赖一些第三方库,需要提前构建一个 AWS Lambda Layer ,整个过程通过如下脚本自动完成。
部署完成后,可以获取到 Lambda Layer 的 ARN,如下图所示。
![]() |
基于该 ARN,更新“etc/environment.sh”中的 O_LAYER_ARN
参数。
4. 构建 Amazon API Gateway+AWS Lambda
接下来,执行如下 Make 命令,通过 AWS SAM CLI 进行 Amazon API Gateway+AWS Lambda 的自动化创建。
执行完成后,可以获取到 Amazon API Gateway 的访问地址,如下图所示。
![]() |
同时,可以在亚马逊云科技 Console 中,看到已经创建好的 Amazon API Gateway 与 AWS Lambda,如下二图所示。
![]() |
![]() |
5. 配置 AWS Lambda
在通过自动化手段创建了 Amazon API Gateway 后,还需要手动微调一些 AWS Lambda 配置。
Lambda 函数:mcp-redshift
修改 Lambda 函数 mcp-redshift 的环境变量配置,设置 Amazon Redshift 的访问信息 (host、 port 、 database 、 user 、 password)。这里为了方便演示,直接在环境变量中配置 user 与 password,但在生产环境中,建议修改 AWS Lambda 函数代码,通过 AWS Secrets Manager 来获取 Amazon Redshift 集群用户名与密码。AWS Secrets Manager 配置步骤,请参考链接。
![]() |
同时,为了让 AWS Lambda 通过 VPC 内网访问 Amazon Redshift 集群,需要启用 AWS Lambda 的 VPC 设置,如下图所示,设置 VPC,子网与安全组。此外,还需要在 Amazon Redshift 集群的安全组中设置入站规则,放行来自该 AWS Lambda 安全组的访问。
![]() |
![]() |
Lambda 函数:mcp-monitor
针对 Lambda 函数 mcp-monitor,需要配置一下 Amazon Redshift 的集群名称,用于调用 Amazon CloudWatch API 查询 Amazon Redshift 集群的监控数据,如下图所示。
![]() |
Lambda 函数:mcp-cot
Lambda 函数 mcp-cot,本质上是一个极简化的、没有向量数据库的 RAG 知识库,知识库文件存在 Amazon S3 上,然后通过 LLM 的一次推理完成召回与结果输出。这里需要配置一下知识库 Markdown 文件的 S3 桶名与 Key,还需要设置一下 CoT Mcp Server 自身需要访问 Amazon Bedrock 的 Region 信息 ,如下图所示。
![]() |
6. 配置 API 密钥
为了考虑 Remote MCP 的访问安全,还需要配置 Amazon API Gateway 的认证授权。Amazon API Gateway 支持多种方式的认证授权,这里为演示方便,使用 API 密钥 来认证。
首先,在 Amazon API Gateway 中创建“使用计划”,然后在使用计划中关联 API 的“部署阶段”与对应的 API 密钥,如下二图所示。
![]() |
![]() |
然后还需要针对 API 中的每个方法,设置“需要 API 密钥”为是。
![]() |
至此,整套方案就部署好。
7. 使用 Amazon Q Developer CLI 进行测试
首先,配置一个用于演示的 Markdown 文档,记录几种常见问题的处理思路,如下图所示。将该文档上至 S3 对应目录下(请参考 Lambda 函数 mcp-cot 的环境变量配置)。
![]() |
在执行 Amazon Q Developer CLI 的客户端,编辑“.amazonq/mcp.json”文件,配置如下信息。其中的“https://xxxx.execute-api.ap-southeast-1.amazonaws.com/dev”来自于此前步骤中执行“make apigw”的结果输出。
接下来,我们通过“q”命令进入 Q Developer CLI ,再输入“巡检 Redshift 集群”,Q Developer CLI 就会按照设计调用 MCP Tool 。
- 先调用 plan_task,生成任务清单(to-do list)
- 根据任务清单(to-do list),调用其它 MCP Tool
- 最后调用 check_list,检查任务清单(to-do list)是否都已完成
![]() |
8. 使用 Strands SDK 进行测试
如果有实际场景中,需要对 Agent 进一步的定制,比如上下文管理的定制实现,以及 Multi-Agent 等需求,可以使用 Strands SDK 集成上述 MCP Server 中的 Tool,实现更灵活的场景,如下图所示。详细代码可以参考代码目录 mcp_cli 下的代码文件。
![]() |
三、总结&综述
本文详细介绍了一种基于 Amazon Q Developer CLI+Remote MCP+Amazon Redshift 的智能化运维解决方案,提升性能优化、错误排查与集群巡检等 Amazon Redshift 常见运维场景的效率。方案中基于思维链(Chain of Thought, CoT)协调多个模型上下文协议(Model Context Protocol, MCP),让 Amazon Q Developer CLI 按照预期完成工作,有效解决了单纯“Agent+Remote MCP”模式中 Agent 任务规划不符合用户预期的问题。 最后,本文基于 SAM CLI 提供了一键部署的脚本,用于自动化创建 API Gateway+Lambda,并配套了详细的配置说明。
*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营,具体信息以中国区域官网为准。
参考文档
- Strands SDK Quick Start
- 基于 Q Developer+Remote MCP 访问 Redshift
- How to Use SAM CLI
- Model Context Protocol
- 使用 Amazon Lambda 快速部署 Streamable HTTP Github MCP Server
- Using Amazon Q Developer on the command line