云厂商做 Plugin 不做 Agent：AWS Agent Toolkit 的定位逻辑

来源: aws/agent-toolkit-for-aws — https://github.com/aws/agent-toolkit-for-aws
语言: TypeScript | 今日 Stars: 11 | 协议: Apache 2.0
一句话: AWS 不做自己的 agent，而是给所有 agent 提供 AWS 的 plugin——5 个插件覆盖 core/agents/data/devsecops/startup

一个反常识的选择

2026 年，所有云厂商都在做自己的 AI agent。Google 有 Gemini CLI，Microsoft 有 Copilot，阿里有通义灵码。AWS 做了一个反常识的选择：不做自己的 agent，给所有 agent 做 plugin。

Agent Toolkit for AWS 不是"AWS 的 Claude Code"。它是"让 Claude Code、Codex、Cursor、Devin、Kiro 都能安全操作 AWS 的插件包"。

这个选择反常识在哪里？云厂商的护城河是锁定——你用了 AWS 的 agent，就更可能用 AWS 的服务。做 plugin 看起来是在"给别人做嫁衣"。

但仔细想，这是更聪明的锁定。Agent 的生命周期短——今天 Claude Code 强，明天可能 Codex 强。如果 AWS 做自己的 agent，赌的是"AWS 的 agent 能赢"。如果 AWS 做 plugin，赌的是"不管哪个 agent 赢，都要操作 AWS"。

后者是稳赢的赌注。

5 个插件的分层

Agent Toolkit 不是一个大插件，是 5 个分层插件：

1. aws-core — 服务选择、CDK/CloudFormation、serverless、容器、存储、可观测性、计费、SDK 用法、部署
2. aws-agents — 在 AWS 上构建 AI agent（Bedrock + AgentCore）
3. aws-data-analytics — 数据湖、分析、ETL（S3 Tables、Glue、Athena）
4. aws-agents-for-devsecops — 安全调查、代码审查、UAT、漏洞扫描、渗透测试
5. aws-startup-advisor — 创业架构、成本、安全、AWS Activate 指导，以及从 Azure/GCP/Heroku/OpenAI/Gemini 迁移到 AWS

这个分层有一个逻辑：不是按 AWS 服务分，是按用户场景分。

传统 AWS 文档按服务分（S3 怎么用、Lambda 怎么用）。Agent Toolkit 按场景分（你要部署？用 aws-core。你要做数据分析？用 aws-data-analytics。你要做安全审查？用 aws-agents-for-devsecops）。

这个转变很重要。按服务分是"给你工具箱"，按场景分是"给你工作流"。Agent 不需要知道"我要用 S3 + Lambda + API Gateway"，agent 需要知道"我要部署一个 serverless API"——然后 plugin 帮它选服务。

Guardrails 而非 Freedom

Agent Toolkit 的 README 里反复出现一个词：guardrails（护栏）。

不是"给 agent 操作 AWS 的自由"，是"给 agent 操作 AWS 的边界"。

这个定位和 AWS 的企业客户需求一致。企业不敢让 AI agent 自由操作生产环境——一个幻觉可能导致 agent 删掉一个 S3 bucket 或改掉 IAM 策略。Agent Toolkit 的 guardrails 做的是：

• 限制 agent 能操作的服务范围
• 限制 agent 能执行的操作级别（只读 vs 写入）
• 提供最佳实践的"知识库"让 agent 不需要猜

这和之前讨论过的 ECC AgentShield 的"Agent 配置层安全"概念互补——AgentShield 检测配置漏洞，Agent Toolkit 从源头提供安全配置。

"从 Azure/GCP/Heroku/OpenAI/Gemini 迁移到 AWS"

aws-startup-advisor 插件里有一个特别的功能：迁移指导。不只是"AWS 怎么用"，是"你现在的 Azure/GCP/Heroku/OpenAI/Gemini 栈怎么搬到 AWS"。

这个功能暴露了 Agent Toolkit 的真实定位：它不是中性工具，它是 AWS 的获客渠道。

当 agent 帮你分析"你的 Azure Functions 部署怎么迁移到 AWS Lambda"时，agent 已经在引导你走向 AWS 了。这不是"帮你用云"，是"帮你换云"。

Agent 时代的新战场在这里：谁能在 agent 的决策链里植入自己的偏好。AWS 通过 plugin 把"AWS 是默认选择"植入 agent 的知识库。用户问"我该怎么部署"，agent 会优先推荐 AWS 的方案——因为 plugin 里就是这么写的。

Plugin 作为分发渠道

传统云厂商的分发渠道是：文档、SDK、控制台。Agent 时代的分发渠道是：plugin。

区别在于决策者变了。传统模式下，开发者读文档、选服务、写代码。Agent 模式下，agent 读 plugin、选服务、写代码。开发者从"决策者"变成"审批者"——agent 给方案，开发者点确认。

这意味着 plugin 的质量直接影响 agent 的推荐。如果 AWS 的 plugin 写得比 Azure 的好，agent 在面对"部署 serverless 应用"时会优先推荐 AWS 的方案——因为 AWS 的 plugin 给了更清晰的路径。

Plugin 不是"给开发者用的工具"，是"给 agent 用的知识库"。写作对象变了，写法也要变。Agent Toolkit 的 README 写得像给 agent 看的指令——"安装这个 plugin，然后你可以做 X、Y、Z"。不是给人看的教程，是给 agent 看的能力清单。

11 Stars 的意义

Agent Toolkit 今天只有 11 stars。和同批次的 impeccable（733）、cindy（471）比，看起来很弱。

但 stars 不是这里正确的指标。Agent Toolkit 的价值不在 GitHub 上的关注度，在于"有多少 agent 装了它"。Claude Code 的官方 marketplace 里 aws-core 是默认推荐的 plugin——这意味着每个用 Claude Code 的开发者都可能装它。

分发渠道变了。GitHub stars 衡量的是"开发者社区关注度"，marketplace 安装量衡量的是"agent 实际使用率"。后者才是 agent 时代的真正指标。

一个更深的问题

Agent Toolkit 引出一个更深的问题：当云厂商通过 plugin 影响 agent 的决策，谁来审计 plugin 的中立性？

如果 aws-startup-advisor 说"从 Azure 迁移到 AWS"，Azure 会不会出一个"从 AWS 迁移到 Azure"的 plugin？如果两个都装了，agent 听谁的？

这和搜索引擎时代的"SEO 战争"类似——厂商通过优化自己的内容来影响搜索结果。Agent 时代的"plugin 战争"是厂商通过优化自己的 plugin 来影响 agent 推荐。

区别在于：搜索引擎的算法是黑盒，agent 的决策过程至少在理论上可审计。如果 agent 推荐了 AWS，你可以问"为什么推荐 AWS"——agent 会告诉你"因为 aws-core plugin 里说 Lambda 适合 serverless"。

但前提是 agent 的决策过程是透明的。如果 plugin 的知识被内化到 agent 的 context 里，用户可能看不到"这个推荐来自 AWS 的 plugin"。

收尾

Agent Toolkit for AWS 看起来是一个不起眼的工具——11 stars，5 个 plugin，一个 README。但它代表了一个重要的趋势：云厂商从"做 agent"转向"做 agent 的知识来源"。

这不是 AWS 一家的选择。Google、Microsoft、阿里都会跟进。未来的竞争不是"谁的 agent 更强"，是"谁的 plugin 装得更多"。Agent 是消费端，plugin 是供给侧。云厂商争的是供给侧的份额。

对开发者来说，这意味着一个新技能：审计 plugin 的中立性。你的 agent 推荐的方案，是真正最优解，还是某个云厂商的 plugin 说了算？这个问题在 agent 之前不存在——因为是你自己在读文档做决策。agent 之后，这个问题变得至关重要。

Agent Toolkit for AWS 是这个新战场的早期样本。11 stars 不重要，重要的是它定义了"云厂商在 agent 时代怎么玩"的范式。