夜雨聆风
AI Coding Agent 接云账号这件事，已经从“能不能连上”变成“敢不敢放权”。
以前很多人用本地 AWS 凭证加社区 MCP Server，让 Agent 帮忙查资源、写 CDK、改 Lambda。实验阶段挺爽，一旦靠近真实账号，问题就来了：它到底调用了什么 API？能不能删桶？有没有审计？出事后能不能把每一步翻出来？
AWS 这次推的 Agent Toolkit for AWS，真正有价值的地方就在这里。它不是又给 Agent 多接一个工具，而是把 MCP Server、Skills、Plugins、Rules files 放到一套受控工具箱里，让 Agent 进 AWS 前先过权限、审计和沙箱这几道闸。
如果你已经在用 Claude Code、Codex、Cursor、Kiro 这类工具写云上代码，这个方向值得盯紧。
Agent 终于拿到 AWS 钥匙了，但这次钥匙带了闸门
Agent Toolkit for AWS 的定位很直接：让 AI Coding Agent 帮你在 AWS 上构建、部署和管理应用。
听起来像老生常谈。关键差别在于，它不只提供“调用 AWS API 的能力”，还把权限边界、审计痕迹、文档检索、专家工作流和 IDE 插件一起塞进来。
仓库本身是 AWS 官方支持的开源项目，48 小时窗口内仍有更新；dev.to 上的 AWS 技术文章也在 6 月 12 日发布，围绕从旧 MCP Server 切到新工具箱的真实差异展开。热度不算纯新闻级别，但对开发者价值很实在。
它覆盖的不是一个点，而是一条链：
这套组合对个人开发者有用，对团队更关键。因为团队里最怕的不是 Agent 不会干活，而是它干完活没人知道它干了什么。
它不是又一个 MCP Server：真正的差异在“可控”
旧的社区 MCP Server 很适合试水。你给它凭证，它能替 Agent 查 AWS、调接口、读文档。
但试水和生产是两回事。
Agent 一旦能碰真实基础设施，就必须回答三个问题：
这才是它值得切换的核心：不是“工具更多”，而是“Agent 的动作终于能被治理”。
AWS MCP Server 提供 300+ AWS 服务的统一访问入口，也支持文档搜索、读取完整页面、区域可用性检查。这对 Agent 很重要，因为很多云上错误并不是模型不会写代码，而是它拿了过期文档、错用区域能力、或者把本地经验硬套到当前账号。
别只看连通性：CloudTrail 里这三个指纹才是保命线
Agent 能列出 S3 Bucket，只说明它连上了。
真正要看的是：这个调用在 CloudTrail 里有没有明确指纹。
通过 AWS MCP Server 发起的调用，会带上可识别的来源信息，比如：
这个细节非常关键。它让你能把“人类自己在终端执行的 AWS CLI 命令”和“Agent 通过 MCP 发起的调用”区分开。
没有这层区分，所有动作最后都混在同一个凭证或同一个终端历史里。真出了事，你只能猜：到底是人删的，脚本删的，还是 Agent 删的。
有了这层区分，审计才有意义。你可以按 MCP 来源过滤调用，查它访问过哪些服务，触发过哪些高危 API，是否绕过了预期区域，是否在非工作时间动过资源。
这也是我认为 Agent Toolkit 值得写的原因。它把“AI Agent 上生产”从一句口号，往工程治理上推了一步。
权限别再靠自觉：用 aws:CalledViaAWSMCP 把 Agent 关进围栏
最值得抄的设计，是 IAM 条件键。
AWS MCP Server 会给调用打上 aws:CalledViaAWSMCP 这类条件信号。你可以写 IAM 策略，让 Agent 和真人使用同一套账号时也走不同限制。
比如，禁止通过 MCP 发起删除 S3 Bucket：
这段策略的意思很直白：你本人可能有删桶权限，但 Agent 通过 MCP 调用时不行。
真要落地，我建议至少做三层：
别相信“Agent 应该不会乱来”。权限系统不是用来表达信任的，是用来承认人和模型都会出错的。
怎么接入：Claude Code、Codex、Cursor、Kiro 都能走
如果你用 Claude Code，可以从官方插件市场装：
如果要做 AWS 上的 AI Agent，还可以装：
如果你用 Codex，可以先添加插件市场：
然后在 Codex 里通过 /plugins 浏览并安装 aws-core。
Kiro 的 MCP 配置可以这样写：
这里有两个细节别漏。
第一，建议固定 mcp-proxy-for-aws 版本。Agent 工具链一旦进生产，依赖漂移就是供应链风险，不要让今天能跑的配置明天悄悄换行为。
第二，URL 里的区域是 MCP Server 所在区域，AWS_REGION 是你实际操作资源的区域。别把这两个混了。
如果要给 Agent 使用命名 Profile，可以追加：
接通后，不要直接让它改资源。先让 Agent 做只读验证，比如：
确认 CloudTrail 能看到 MCP 指纹，再逐步开放更具体的任务。
上线前清单：这 7 件事不做，别让 Agent 碰真实云账号
这类工具最容易被误用在“我先连上再说”。
不急。连上只是开始，真正要做的是把护栏补齐。
awslabs 本地 MCP Server | |
mcp-proxy-for-aws 版本 | |
这里还有一个容易忽略的成本问题：Agent 会很勤快。它可能为了确认一个资源状态反复查 API，也可能因为工具调用失败进入重试。权限、配额、账单告警应该一起上，不要只做“能不能用”的验证。
我的判断：MCP 接云账号，正在从玩具进入基础设施
MCP 最开始火的时候，很多人把它当“给 AI 接工具”的协议。
但接工具这件事越往后走，越不像插件问题，越像基础设施问题。尤其是接 AWS 这类云平台，真正的门槛不是把 API 暴露给 Agent，而是让它每一次动作都可控、可查、可停。
Agent Toolkit for AWS 的价值就在这里。
它没有让 Agent 变成万能 DevOps，也不会替你设计权限体系。但它至少把几个生产化问题摆到了台面上：IAM 条件键、CloudTrail 审计、CloudWatch 指标、远程沙箱、插件化安装、项目级规则。
这比“让 AI 帮我点云控制台”要重要得多。
如果你的团队已经开始让 Coding Agent 写 CDK、改 Lambda、查日志、排障，那下一步别再只问模型准不准。先问一个更工程化的问题：它拿到的钥匙，有没有闸门。
