用 Bedrock AgentCore Runtime 把自然语言变成 AWS CLI——AWS API MCP Server + Amazon Quick 实战

预计阅读时间：9 分钟

运维和开发最怕的不是命令难写，而是关键时刻要切工具。凌晨两点排查故障，你脑子里想的是"把那个 ECS 服务的任务数缩到 1"，手上却要先开终端、翻文档、拼 CLI 参数、确认 region——整个过程断断续续，注意力被工具切换撕碎。

Amazon Bedrock AgentCore Runtime 现在支持了 Model Context Protocol（MCP），配合 AWS API MCP Server 和 Amazon Quick，可以把这条链路压成一句话：你用自然语言描述意图，助手直接翻译成 AWS CLI 命令并执行。不需要换窗口，不需要背参数格式。

MCP 在 AWS 生态里到底干了什么

Model Context Protocol 是 Anthropic 推出的开放标准，核心思路很简单：让 LLM 能统一地调用外部工具。以前每接入一个 API 都要写一套适配代码；有了 MCP，工具端只要暴露一个标准接口，LLM 端就能自动发现并调用。

AWS API MCP Server 就是这样一个"工具端适配器"——它把 AWS 数百个服务的 API 按照 MCP 规范包装起来，让 LLM 不需要逐个硬编码调用逻辑，而是通过 MCP 协议动态获取可用操作列表、参数定义，再按需生成对应的 CLI 命令。

架构拆解：三个组件怎么串起来

整条链路的角色分工很清晰：

组件	角色
Amazon Quick	对话前端——用户在这里输入自然语言，看到结果
Bedrock AgentCore Runtime	编排引擎——托管 MCP 客户端，协调 LLM 与工具的交互
AWS API MCP Server	工具提供方——把 AWS API 以 MCP 标准暴露出来

流程是这样的：

用户在 Amazon Quick 里输入："帮我列出 us-east-1 里所有运行中的 EC2 实例"
Quick 把请求发给 AgentCore Runtime
Runtime 里的 Bedrock 模型识别出意图，通过 MCP 协议查询 AWS API MCP Server 支持哪些操作
MCP Server 返回 ec2:DescribeInstances 的参数定义
模型生成对应的 AWS CLI 命令，通过 MCP Server 执行（或返回命令供确认后执行）
结果回传到 Quick，用户看到实例列表

关键点在于：AgentCore Runtime 同时充当 MCP 客户端和 LLM 调用的宿主，你不需要自己写工具路由逻辑。

实战：搭建一个能对话操作 AWS 的助手

下面走一遍最小可跑的部署流程。假设你已经有 AWS 账号且开通了 Bedrock。

1. 安装并配置 AWS API MCP Server

AWS API MCP Server 目前以 npm 包形式发布，也可以用 Docker 运行。这里用 Docker 方式，避免本地 Node 环境问题：

# 拉取 MCP Server 镜像
docker pull public.ecr.aws/aws-api-mcp-server:latest

# 启动 MCP Server，挂载你的 AWS 凭证
docker run -d \
  --name aws-api-mcp \
  -p 3000:3000 \
  -e AWS_REGION=us-east-1 \
  -v ~/.aws:/home/app/.aws:ro \
  public.ecr.aws/aws-api-mcp-server:latest

假设说明：镜像地址和端口以 AWS 官方发布为准，实际部署时请参照 AWS API MCP Server 的最新文档确认。-v ~/.aws 挂载确保容器内能读取你的 AWS CLI 凭证配置。

启动后，MCP Server 在 http://localhost:3000 提供 SSE（Server-Sent Events）端点，这是 AgentCore Runtime 连接它的入口。

2. 在 AgentCore Runtime 中注册 MCP 工具

AgentCore Runtime 用 JSON 配置文件描述 MCP 连接。创建 agent-config.json：

{
  "agentName": "aws-ops-assistant",
  "modelId": "anthropic.claude-3-5-sonnet-20241022-v2:0",
  "mcpServers": [
    {
      "name": "aws-api",
      "transportType": "sse",
      "url": "http://localhost:3000/sse",
      "headers": {}
    }
  ],
  "instruction": "你是一个 AWS 运维助手。用户用自然语言描述需求时，你通过 MCP 工具查询 AWS API 并生成对应的 CLI 命令或直接执行操作。操作前先确认意图，涉及删除/终止类操作必须二次确认。"
}

instruction 字段是给 LLM 的系统提示，这里我加了安全约束：破坏性操作必须二次确认。这不是可选的装饰，是生产环境的底线。

3. 用 CLI 部署 AgentCore Runtime Agent

# 创建 Agent
aws bedrock-agentcore create-agent \
  --agent-name aws-ops-assistant \
  --agent-resource-role-arn arn:aws:iam::123456789012:role/AgentCoreRuntimeRole \
  --model-id anthropic.claude-3-5-sonnet-20241022-v2:0 \
  --region us-east-1

# 关联 MCP Server 配置
aws bedrock-agentcore create-agent-mcp-association \
  --agent-id <AGENT_ID> \
  --mcp-server-name aws-api \
  --transport-type sse \
  --url http://localhost:3000/sse \
  --region us-east-1

AgentCoreRuntimeRole 需要提前创建，赋予 Bedrock 调用权限和必要的 AWS 操作权限。权限范围应该遵循最小特权原则——只给助手需要操作的服务的读写权限，不要给 AdministratorAccess。

4. 在 Amazon Quick 中接入 Agent

Amazon Quick 作为对话前端，配置入口指向刚创建的 AgentCore Agent：

# 获取 Agent 的调用端点
aws bedrock-agentcore get-agent \
  --agent-id <AGENT_ID> \
  --region us-east-1 \
  --query 'agent.endpointUrl' \
  --output text

把返回的端点 URL 配到 Amazon Quick 的 Agent 连接设置里。具体配置界面在 Quick 的管理面板 → Integrations → Bedrock AgentCore，填入 Agent ID 和 Endpoint。

5. 试一轮对话

在 Amazon Quick 中输入：

"帮我查一下 us-east-1 有多少 RDS 实例还在运行"

助手会通过 MCP 调用 rds:DescribeDBInstances，返回类似：

us-east-1 当前有 3 个运行中的 RDS 实例：
- db-prod-main (mysql 8.0, db.r5.large)
- db-analytics (postgres 15, db.r5.xlarge)  
- db-cache-replica (mysql 8.0, db.t3.medium)

对应 CLI 命令：aws rds describe-db-instances --region us-east-1 --query 'DBInstances[?DBInstanceStatus==`available`]'

你拿到结果的同时也拿到了可复用的 CLI 命令——下次可以直接跑命令，不用再问助手。

安全边界与采纳建议

这套架构把自然语言变成了 AWS 操作的入口，便利性拉满，但风险也拉满了。几个必须做的事：

权限隔离。MCP Server 挂载的 AWS 凭证决定了助手能操作的范围。生产环境不要用个人开发者的 AK/SK，应该创建一个专用 IAM Role，用 IRSA（IAM Roles for Service Accounts）或 ECS Task Role 注入，权限只覆盖需要的服务和动作。

破坏性操作双确认。前面配置里的 instruction 已经要求二次确认，但这只是 LLM 层面的软约束。更硬的保障是在 MCP Server 层面加策略——对 terminate、delete、force-stop 类操作要求显式 confirm: true 参数，否则直接拒绝。

审计日志。AgentCore Runtime 和 MCP Server 的每次调用都应该落到 CloudTrail。定期检查日志，确认没有超出预期范围的操作。

渐进式上线。先从只读操作开始——查实例状态、看日志、列资源。确认稳定后再开放写操作，最后才放开删除类操作。不要一步到位给全部权限。

这套组合真正解决的问题是：把"想做什么"到"做完"之间的工具摩擦降到接近零。但零摩擦不代表零风险——便利性和控制力永远要一起调。