Agent Toolkit for AWS 实战:给你的 AI 编码 Agent 配一套生产级工具箱
上周让 AI Agent 帮我写一个 CloudFormation 模板,结果它生成的 YAML 引用了一个已经废弃半年的属性。改了三遍还是不对,token 烧了一大堆,活没干成。
这个问题的根源很简单——AI Agent 的训练数据是有时效的,它不知道 AWS 服务最近改了什么。而且没有约束的 Agent 就像一个什么都敢写的实习生,代码跑不跑得通全看运气。
亚马逊云科技刚发布的 Agent Toolkit for AWS 就是为了解决这个问题。说白了,它给 AI 编码 Agent 装上了"官方攻略本"——40 多个经过验证的技能、一个全托管的 MCP Server、还有打包好的插件,让 Agent 干活的时候有章可循。
这玩意儿是什么
Agent Toolkit for AWS 是一套生产就绪的工具集,三大件:
- Agent Skills — 40+ 个预置技能,覆盖 IaC、存储、分析、Serverless、容器、AI 服务
- AWS MCP Server(已 GA)— 全托管的 MCP 服务器,带 IAM 守卫和沙盒执行
- Agent Plugins — 一键安装包,目前有三个:Core、Data Analytics、Agents
它是 AWS Labs 上那堆 MCP servers/plugins/skills 的正式继任者。之前的东西不会下架,但后续会逐步迁移到 Toolkit 里统一维护。
免费用,只收你 Agent 实际消耗的 AWS 资源费。
为什么需要它
我之前用 AI Agent 构建 AWS 应用,踩过这几个坑:
坑一:知识过时。 Agent 不知道 S3 Express One Zone 是什么,也不知道 Bedrock 最新支持哪些模型。它会用旧的 API 参数,生成的代码编译都过不了。
坑二:没有最佳实践。 Agent 写出来的 CloudFormation 模板能跑,但安全组全开、没有加密、日志也没配。上线前要人肉 review 一大堆。
坑三:不好管。 Agent 调了哪些 AWS API?花了多少钱?出了问题怎么追溯?之前完全是黑盒。
Agent Toolkit 的解法:
- Skills 提供经过验证的、最新的操作流程,Agent 按流程走而不是自己瞎编
- MCP Server 提供 IAM 级别的权限控制,Agent 只能做你允许的操作
- CloudWatch + CloudTrail 全程可观测,每一步都有记录
快速上手
安装 Agent Plugin
最简单的方式是直接装插件。以 AWS Core 插件为例:
# 克隆 Agent Toolkit 仓库
git clone https://github.com/aws/agent-toolkit-for-aws.git
cd agent-toolkit-for-aws
# 查看可用插件
ls plugins/
# aws-core/ aws-data-analytics/ aws-agents/
# 安装 AWS Core 插件(包含 MCP Server + 核心 Skills)
cd plugins/aws-core
cat README.md
三个插件的定位:
| 插件 | 适用场景 | 包含技能 |
|---|---|---|
| AWS Core | 全栈应用开发 | CloudFormation、Lambda、S3、DynamoDB 等 |
| AWS Data Analytics | 数据分析和 BI | Glue、Athena、Redshift、数据管道 |
| AWS Agents | AI Agent 开发 | Bedrock AgentCore、模型调用、RAG |
配置 MCP Server
AWS MCP Server 是全托管的,你不需要自己跑服务器。配置方式:
{
"mcpServers": {
"aws": {
"command": "aws-mcp-server",
"args": ["--region", "us-east-1"],
"env": {
"AWS_PROFILE": "dev-account",
"AWS_MCP_GUARDRAILS": "true"
}
}
}
}
关键配置项:
# 设置 IAM 守卫——限制 Agent 只能操作特定服务
export AWS_MCP_ALLOWED_SERVICES="s3,lambda,dynamodb,cloudformation"
# 启用沙盒模式——Agent 生成的代码在隔离环境执行
export AWS_MCP_SANDBOX="enabled"
# 启用审计日志
export AWS_MCP_AUDIT_LOG="cloudtrail"
使用 Agent Skills
Skills 是核心。看一个实际例子——让 Agent 写一个 Serverless API:
# skills/serverless-api/skill.yaml
name: build-serverless-api
description: |
构建一个生产就绪的 Serverless REST API,
包含 API Gateway + Lambda + DynamoDB
steps:
- validate_requirements
- generate_sam_template
- configure_auth
- setup_monitoring
- deploy_and_test
best_practices:
- 使用 SAM 而非原始 CloudFormation
- Lambda 函数必须设置超时和内存限制
- DynamoDB 表必须启用按需计费或设置自动扩展
- API Gateway 必须配置 WAF 和限流
Agent 拿到这个 Skill 后,就不会再写出那种没有超时设置、没有错误处理的 Lambda 了。
实际调用流程
当你让 Agent "帮我搭一个用户注册 API" 时,整个流程是:
import boto3
import json
# 1. Agent 通过 MCP Server 检索相关 Skill
# 2. Skill 告诉 Agent 需要哪些资源和最佳实践
# 3. Agent 生成 SAM 模板
sam_template = """
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Globals:
Function:
Timeout: 30
MemorySize: 256
Runtime: python3.12
Tracing: Active
Environment:
Variables:
TABLE_NAME: !Ref UsersTable
Resources:
RegisterFunction:
Type: AWS::Serverless::Function
Properties:
Handler: app.handler
CodeUri: src/register/
Events:
Register:
Type: Api
Properties:
Path: /users
Method: post
Policies:
- DynamoDBCrudPolicy:
TableName: !Ref UsersTable
UsersTable:
Type: AWS::DynamoDB::Table
Properties:
BillingMode: PAY_PER_REQUEST
AttributeDefinitions:
- AttributeName: userId
AttributeType: S
KeySchema:
- AttributeName: userId
KeyType: HASH
PointInTimeRecoverySpecification:
PointInTimeRecoveryEnabled: true
SSESpecification:
SSEEnabled: true
"""
# 4. MCP Server 在沙盒中验证模板
# 5. 通过后部署到目标账户
注意几个细节——Skill 确保了:
- Function 有 Timeout 和 MemorySize(防止跑飞)
- 启用了 X-Ray Tracing(可观测)
- DynamoDB 开了 PITR 和加密(安全)
- 用了 PAY_PER_REQUEST(避免预置容量浪费)
这些都是 Skill 内置的最佳实践,Agent 不需要自己"想起来"。
IAM 守卫详解
这是我觉得最有价值的功能。之前 Agent 拿着 Admin 权限到处跑,心里总是慌的。
MCP Server 的 IAM 守卫机制:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AgentAllowedActions",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"lambda:CreateFunction",
"lambda:UpdateFunctionCode",
"cloudformation:CreateStack",
"cloudformation:DescribeStacks"
],
"Resource": "arn:aws:*:us-east-1:123456789012:*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": "us-east-1"
}
}
},
{
"Sid": "DenyDangerous",
"Effect": "Deny",
"Action": [
"iam:CreateUser",
"iam:AttachRolePolicy",
"ec2:RunInstances"
],
"Resource": "*"
}
]
}
这样即使 Agent "想"创建一个 EC2 实例或者修改 IAM 策略,MCP Server 也会直接拦截。所有被拦截的操作都会记录到 CloudTrail。
可观测性
每次 Agent 的操作都能在 CloudWatch 里看到:
# 查看 Agent 最近的操作日志
aws logs filter-log-events \
--log-group-name "/aws/mcp-server/agent-operations" \
--start-time $(date -d '1 hour ago' +%s)000 \
--filter-pattern '{ $.action = "cloudformation:CreateStack" }'
# 查看 token 消耗趋势
aws cloudwatch get-metric-statistics \
--namespace "AWS/AgentToolkit" \
--metric-name "TokensConsumed" \
--start-time 2026-05-25T00:00:00Z \
--end-time 2026-05-25T23:59:59Z \
--period 3600 \
--statistics Sum
当前限制
说几个需要注意的点:
- MCP Server 区域有限 — 目前只支持 us-east-1 和 eu-central-1(法兰克福)
- Skills 还在扩展中 — 当前 40+ 个,数据库、网络、IAM 相关的技能还在路上
- 需要 AWS 凭证 — Agent 运行环境必须配好 IAM 角色或 Access Key
跟之前 AWS Labs MCP 的区别
| 对比项 | AWS Labs(旧) | Agent Toolkit(新) |
|---|---|---|
| 维护方 | 社区/实验性 | AWS 官方产品团队 |
| Skills 验证 | 无保证 | 经过严格评估 |
| 安全控制 | 无 | IAM 守卫 + 沙盒 |
| 可观测 | 无 | CloudWatch + CloudTrail |
| 安装方式 | 单独配 | 插件一键装 |
简单说,之前是"能用",现在是"能上生产"。
我的判断
Agent Toolkit 解决了一个核心矛盾:AI Agent 需要自由度才能发挥创造力,但生产环境需要约束和可控。
它的思路是对的——不是限制 Agent 能做什么,而是告诉它正确的做法是什么,同时在底层兜底。这比事后 review Agent 生成的代码要高效得多。
40 个 Skills 只是起步,我估计半年内会覆盖大部分常见场景。对于已经在用 AI Agent 写 AWS 代码的团队来说,这个工具值得第一时间试。
相关链接:

浙公网安备 33010602011771号