北京
晚上十一点，你让 AI 搭档帮你写一段基础设施代码。它自信地给出一个 AWS 服务名，编了个 ARN，指了一个你根本没用的区域，还“贴心”地补上 DynamoDB 表名和一套完整的部署步骤。你心想：这玩意儿还真没听说过，去翻翻文档——结果发现全是幻觉。AI 编造了一个不存在的 Lambda 调用、一套不存在的资源，还一脸真诚地问你“要不要看看你账户当前配置来核实命名”。
你当然想让它看到真实环境。于是你做了大多数人都干过的事：把一条访问密钥贴进 .env 文件，让 AI“就看一眼”真实的资源名。代码跑通了，问题解决了，只是——你忘了删掉那个 .env。一次不小心的提交，密钥进了 Git 历史，告警炸锅，风险四伏。更要命的是，这个获得了真实权限的 AI 助手，可能在某一刻过于积极，删错了 CloudFormation 堆栈，或者一天之内悄悄烧掉四十美元账单，甚至更多。
AWS 显然看到了这个痛点，也给出了解决方案——而且一给就是两个，名字还极其相似：Knowledge MCP 和 managed AWS MCP Server。很多人第一反应是困惑：到底该用哪个？它们各自的场景是什么？现在 AWS 已经有了倾向性推荐，你不需要再陷入抉择瘫痪。这篇文章就是一份冷靜的拆解地图：两个方案的定位、各自消灭的代价、以及究竟怎么安全接入 Claude Code、Claude 桌面应用甚至 Kiro，全程不再需要往 .env 里贴凭证。
先看两个阵营的基础立场。
一方认为，AI 在编码时的最大问题是缺乏上下文，会凭空编造资源名，所以需要一个能随时查询账户知识库的中间层——这正是 Knowledge MCP 要解决的问题，它像一个实时的“账户维基”，让 AI 知道你到底有哪些表、哪个区域在用、资源名是啥。
另一方则认为，光有知识不够，AI 还要能安全地执行操作，但又不能把全量密钥扔给前端。managed AWS MCP Server 走的是 OAuth 授权路径，用一种受控的链接方式让 AI 替你去调 API，密钥永远不会出现在代码里。
在 2026 年 7 月更新后，连接流程已经转向直接 OAuth，不再需要你在客户端和环境变量间手动搬运密钥。也就是说，不论是 Claude Code 接入、还是 Claude 桌面应用甚至第三方客户端 Kiro，都可以通过标准授权步骤完成配置。整个过程就像授权一个 OAuth 应用访问你的 AWS 账户，AI 看到的只是最小权限的临时凭证，而你的长期密钥始终留在 AWS 那一侧。
IAM 策略的设计在这里扮演关键角色。你可以限定 AI 能访问哪些服务、哪些操作，甚至细化到只读某些 DynamoDB 表、只看特定区域的资源。这种粒度给了你刹车：AI 可以读取真实配置来避免幻觉，却无法顺手删库跑路，账单也不会在你睡着时悄悄炸裂。
那么，哪个方案更值得选？
如果你只是想让 AI 停止编造 ARN，需要它准确引用已有的 S3 桶名、Lambda 函数名、Step Functions 等，Knowledge MCP 作为只读知识库已经够用，而且接入轻量。
但 AWS 现在更推荐 managed AWS MCP Server 这一条路径，因为它把“看”和“做”的边界用权限策略管理起来，不再需要维护两套 MCP 服务。把知识查询也纳入 OAuth 通道后，AI 不再凭空捏造，也不用接触原始凭证。一个统一的受控通道，同时解决幻觉和泄露问题。
将来如果你遇到 MCP 连接流程与本文不一致的情况，记得去 AWS 官方文档看一眼。这组工具迭代很快，我在 2026 年 6 月写下这份指南，7 月就因为连接方式切换为直接 OAuth 而更新过一次。保持让密钥远离代码仓库的原则，比紧跟哪一个具体界面更重要。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
