Azure 和 Google 在争谁的模型更多。AWS 在做一件不一样的事。
2026 年 5 月 6 日，AWS 悄悄上线了 github.com/aws/agent-toolkit-for-aws。
不是 awslabs，是 aws。一个字母的差距——AWS 在说：这是正式产品，不是实验室项目。
然后 AWS 做了一件竞争对手都还没做的事：给 AI agent 写"操作手册"，写完还拿去测了。
先说结论，再讲逻辑
结论是：AWS 在认真解决一个其他云厂商远没做足的问题：“agent 怎么可靠地操作云服务”
Azure 的 Microsoft Foundry 有 1,900+ 个模型，覆盖 OpenAI、Anthropic、Meta、xAI、Mistral 等主流厂商，服务全球大量企业；Google 的 Gemini Enterprise Agent Platform 有 Agent Development Kit（ADK）、Model Evaluation……两家比的都是"平台多宽"。
AWS 这次比的是另一件事：agent 在我的平台上成功率是多少。
这两个思路的分歧，比看上去大得多。
问题出在哪里
过去两年，开发者拿着 AI agent 构建 AWS 应用，踩了三类坑：
第一坑，模型知识过期。 AWS 几乎每周都在发布新服务、新 API。大模型的训练数据有截止日期——agent 信心满满地调用一个已经被废弃的 API，或者压根不知道某个新服务的存在。
第二坑，多服务工作流容错差。 让 agent 部署一个"Lambda + API Gateway + DynamoDB"的应用，它单独认识每个服务，但串联起来容易出错。这里面有大量 AWS 特有的最佳实践和配置顺序，通用大模型没有被专门训练过。
第三坑，企业没法上生产。 agent 调用 AWS API，没有审计日志，没有权限粒度控制，出了事没法追溯。大量公司卡在"POC 很好用但不敢上线"的阶段。
三个坑，Azure 和 Google 给的答案是"换个更强的模型"。
AWS 这次的答案不一样。
AWS 的解法：三件套
Agent Toolkit for AWS 是三件东西的组合：Skills + AWS MCP Server + Plugins。
第一件：Skills（操作手册）
这是核心。
Skills 不是 API 文档，是"经过验证的操作流程"。
举个例子：agent 要用 CloudFormation 部署 serverless API。不给 Skills 的时候，agent 凭通用知识拼 YAML，大概率在某个配置项上卡壳或走弯路。有了 Skill，agent 直接调取手册：
- 模板用什么结构
- 哪几个参数是 AWS 最佳实践要求必配的
- 这一步前要先做什么、这一步后要检查什么
但关键不是"有手册"，是"手册经过了测试"。
AWS 官方说，每个 Skill 都经过了"严格评估（rigorously evaluated）"，确保能帮 agent 更准确、更可靠地完成任务。
这里的机制值得细看：AWS 评估的不是文档写得对不对，而是"agent 用了这个 Skill 之后，完成任务的准确率和可靠性有没有提升"。这是一个以输出结果为标准的评估，不是以文档质量为标准。
跟竞品比一下就清楚了：
- Azure AI Foundry：有 quick start templates，是可定制的代码起点，解决的是"怎么写代码"，不是"agent 在这个工作流里完成任务的成功率"
- Google ADK：有 evaluation 工具，评估的是通用 agent 执行轨迹（execution trajectory），而 AWS Skills 评估的是特定 AWS 服务操作场景下的任务完成率——两者粒度和场景针对性都不同
AWS 的 Skills，是目前云厂商中少见的、专门针对特定云服务操作场景、以任务完成率为标准评估过的官方产品。首发 40+，覆盖 IaC、存储、数据分析、Serverless、容器、AI 服务，且承诺持续扩展。
第二件：AWS MCP Server（企业级安全层）
MCP（Model Context Protocol）是 Anthropic 提出的工具调用协议，现已成为行业标准。AWS MCP Server 是 AWS 官方托管的 MCP 服务器，agent 通过它调用任意 AWS 服务。
但这个 MCP Server 的重点不在"能调用"，在"怎么控制"：
- IAM 权限控制：精确到具体 API 操作，agent 只能做被授权的事
- IAM 条件键：区分"agent 发起的操作"和"人工发起的操作"——出了问题，一眼看出是谁干的
- CloudTrail 审计日志：所有 agent 操作完整记录，不可篡改，可追溯
- CloudWatch 可观测性：实时监控 agent 行为
- 零凭证暴露：agent 不接触 AWS 密钥
这个能力组合，才是企业敢把 agent 推上生产的底线条件。
第三件：Plugins（一键安装包）
Plugins 是把 MCP Server 配置 + 相关 Skills 打包成一键安装的组合。
发布时三个：
- AWS Core：全栈应用开发
- AWS Data Analytics：数据管道和查询
- AWS Agents：用 Amazon Bedrock AgentCore 构建生产级 agent
（仓库后续持续新增，如 aws-agents-for-devsecops 等，查 GitHub 获取最新列表。）
怎么用
支持 Claude Code、Codex、Cursor、Kiro，但安装方式有区别：
Claude Code / Codex / Cursor：Plugin 一键安装。
| |
| |
Kiro 及其他 agent：需手动配置 MCP Server，再加载 Skills：
| |
Kiro 用户别照着 Plugin 命令抄——按 GitHub README 的 Kiro/Other 章节单独走。
这场仗，AWS 在打什么
AWS 不是在争"最好的 AI 平台"，它在争"agent 工作最顺畅的地方"。
Azure 和 Google 的逻辑是：我给你更多模型、更强算力、更宽平台，你在上面自由发挥。
AWS 的逻辑反过来：我知道开发者在我这儿具体要干什么——部署 Lambda、配 CloudFormation、跑 Bedrock——我就把这些操作的最佳路径提前写好、测好，让 agent 直接调。
这两个逻辑有一个根本性的分歧：
Azure/Google 在优化"agent 的能力上限"；AWS 在优化"agent 的任务成功率"。
对企业 IT 决策者来说，后者才是更直接的生产需求。没有人关心 agent 在 benchmark 上得了多少分，他们关心的是：这个 agent 上线之后，出错的概率是多少，出了错能不能追责。
AWS 这套工具，每一件都在回答这两个问题：
- Skills → 降低出错概率
- IAM + CloudTrail → 出了错有完整的追责链路
这是 AWS 30 年企业基础设施 DNA 的延伸，只不过这次延伸到了 agent 层。
代价是什么
免费——只需为 agent 实际调用的 AWS 资源付费。
AWS MCP Server 目前开放两个区域：US East（N. Virginia）和 Europe（Frankfurt）。
Skills 和 Plugins 在 GitHub 开源，Apache 2.0 协议。
最后
Azure 和 Google 在造航母。
AWS 在帮你的 agent 把活干完、不出错、出了错能追查。
AI agent 的下半场，比的不再是谁的模型多。
比的是谁的 agent 敢上生产。
GitHub：github.com/aws/agent-toolkit-for-aws 官方文档：docs.aws.amazon.com/agent-toolkit/latest/userguide/quick-start.html