AWS 的 Agentic 战略：让最好用的 AI Agent 建立在 AWS 之上

8 月 18 日，AWS 宣布 Amazon Bedrock AgentCore Payments 正式可用，这代表的是，AWS 开始让 AI Agent 在执行任务时可以自己付款。 过去一年，AWS 围绕 Agent 连续推出了 Runtime、Long-Term Memory、Identity、Gateway、Policy 和 Observability。它们分别在解决 Agent 如何运行、如何保留记忆、以什么身份访问外部服务、可以调用哪些工具，以及整个执行过程如何被限制和追踪。现在，Payments 补上了付款这一环。 2025 年，AWS 在纽约峰会的一次公开分享中提到： Making AWS the best place to build the world’s most useful AI agents. 也就是，让最好用的 AI Agent 建立在 AWS 之上。 AWS 想做的并不是一个最聪明的 Agent，而是一个可以承接不同模型、框架和 Agent 的基础平台。Agent 需要运行、记忆、身份和工具，也需要支付。AWS 要做的，是把这些模型之外的能力一层层补齐。 所以，我们可以带着这个目标来看 AgentCore Payments 到底在做什么。 AgentCore Payments：为 AI Agent 打通支付 简单来说，它把付款变成了 Agent 执行任务时可以调用的一项能力。 比如，一个研究 Agent 正在帮公司做市场调查。它找到了一份付费数据，或者一个按次收费的 API。过去走到这里，任务通常会停下来：人需要注册账号、绑定支付方式、购买套餐，再把 API key 配给 Agent。现在，这笔付款可以直接发生在 Agent 的任务流程里。 开发者会先为 Agent 设定一个 payment session，规定它在多长时间内可以付款、单笔最多花多少、总预算是多少，并连接 Coinbase 或 Stripe Privy 提供的钱包。 当 Agent 调用一个收费服务时，对方会返回价格和付款要求。AgentCore Payments 先检查这笔支出是否符合预先设定的权限和预算，再调用外部钱包完成付款。付款成功以后，Agent 带着支付证明重新请求服务，对方验证后交付数据或结果。 所以，AgentCore Payments 并不是给 Agent 一张可以随便刷的卡。钱仍然放在外部钱包里，预算和权限仍然由人或企业设定。AgentCore Payments 做的，是把支付判断、钱包调用和支付记录接进 Agent 的执行过程。 *图片来源：AWS AgentCore Payments GA 公告* 这张图可以从上往下看。 最上面是 Agent，以及它需要访问的收费 API、内容和数据。Agent 可以通过 AgentCore Gateway 或 Browser 找到这些服务，但只要服务要求付款，原来的任务流程就会多出一次支付判断。 中间的 Payment Manager 负责处理这次付款。左边的 Payment orchestration 连接钱包并处理支付，右边的 Payment guardrail 检查授权和支出上限。也就是说，Agent 可以提出付款请求，但不能自己决定预算，也不能绕过预先设置的限制。 再往下是实际提供资金的钱包和执行付款的协议。目前支持 Coinbase 和 Stripe Privy 钱包，以及 x402 和 MPP 两种机器支付协议。钱包负责签名和出钱，协议负责让 Agent 与收费服务用机器可以理解的方式交换价格、付款要求和支付证明。 最底下的 Identity 与 Observability 分别处理身份和记录。Identity 保管钱包连接需要的凭证，Agent 看不到原始密钥；Observability 则记录支付是否成功、花了多少、由哪个 Agent 和 payment session 发起，方便企业后续检查。 当前产品主要服务付费 API、MCP 工具和数字内容。旅行预订、实体商品购买、退款、欺诈和争议处理要复杂得多，AWS 也没有证明这些场景已经形成规模。产品正式可用，并不代表 Agent Commerce 已经成熟。 AWS 想做的，是 Agent 背后的基础平台 这样一家云公司，为什么要做 Agent 支付？ 今天做出一个 Agent demo 已经不算困难。选一个模型，写一段 system prompt，接几个工具，再加一个循环，Agent 就能搜索、推理和执行任务。 真正难的地方通常在 demo 之后出现：Agent 跑在哪里，如何保存状态和记忆，以谁的身份访问外部服务，可以调用哪些工具，哪些动作必须拒绝，任务失败后如何恢复，每次决定又如何被追踪。 这些问题不决定 Agent 在演示中是否聪明，却决定企业敢不敢让它真正行动。 AWS 对 Agent 的理解，正在从“模型加工具”转向一种完整的生产工作负载。 在传统云计算里，一个 workload 从来不只是一段应用代码。它还包括计算、存储、网络、数据库、身份、权限、监控、安全和账单。企业可以更换上层应用，但一旦这些运行关系沉入云平台，迁移就会变得困难。 Agent 也是一样。 模型负责推理，却不会自动解决隔离、状态、身份、工具接入、策略执行、审计和支付。Agent 越自治，这些模型之外的能力越重要。 AgentCore 的产品矩阵看起来很复杂，其实都围绕这些生产问题展开：Runtime 负责运行和隔离，Memory 保存状态与记忆，Identity 管理身份和凭证，Gateway 连接工具，Policy 限制 Agent 可以做什么，Observability 记录它做过什么。现在，Payments 又把预算和付款接了进来。 AgentCore Harness 又把这些能力组装到了一起。开发者定义模型、工具和指令，AWS 负责提供记忆、身份、隔离环境和运行监控。需要更多自定义时，团队仍然可以自己编写编排逻辑，但底层使用的仍是同一套 AgentCore 能力。 这正是 AWS 最熟悉的产品方法：把开发团队反复搭建的基础设施抽象出来，变成可调用、可组合、按使用量付费的云服务。 二十年前，AWS 没有发明服务器、数据库和存储需求，它只是把这些能力重新组织成云。 今天，它正在对 Agent 重做一次。 模型可以换，但 Agent 背后的系统会留下 AWS 这套战略里它并没有要求开发者只能使用自己的模型和框架。 AgentCore 支持不同的开源框架，也允许开发者使用 Amazon Bedrock 之外的模型。AWS 还在接入 MCP、A2A 和 x402 等开放协议，而不是要求所有组件都使用 AWS 的私有接口。 这看起来很开放。但对 AWS 来说，模型和框架越容易变化，它越有理由把竞争位置往下移。 今天领先的模型，半年后未必仍然领先，Agent 框架也会快速迭代。如果平台把全部价值押在一个模型或框架上，它就必须持续承担上层技术变化的风险。 但企业的身份、网络、工具目录、权限策略、运行日志、采购关系和账单不会以同样速度变化，这些能力一旦围绕 AgentCore 建立起来，就比模型更难迁移。 所以，AWS 对模型和框架保持开放，并不意味着它没有平台野心。开放接口让更多模型、工具和 Agent 进入 AWS；身份、权限、工具、日志和账单，则让企业的运行关系逐渐沉淀在 AWS。 模型可以换，但 Agent 背后的系统不会轻易更换。 从开发者入口，到企业预算和 Agent 支付 如果只有 AgentCore，AWS 仍然只是一个基础设施供应商。现在，它正在把开发、运行、分发、采购和具体应用串成一条更完整的商业路径。 Strands 是开发者入口，用开源 SDK 降低 Agent 的开发门槛。Harness 和 Runtime 承接生产运行，让简单和复杂的 Agent 都能使用同一套底层能力。 Marketplace 则把第三方 Agent、工具、MCP 服务和专业服务接入企业采购。企业可以通过已有 AWS 账户购买，统一管理许可、付款和用户访问；部分产品还能直接运行在 AgentCore Runtime，或通过 Gateway 被 Agent 调用。 这一步的重要性不只是多了一个“Agent 应用商店”。 企业采用 Agent 的阻力从来不只有技术。谁来签合同，软件能否进入已有预算，法务和安全如何审核，许可如何分配，费用如何统一结算，都会决定一个产品能不能真正卖进去。 AWS Marketplace 已经拥有这套采购网络。AgentCore 则把采购进来的工具接到运行环境和权限体系中。 于是，一条路径逐渐形成： Strands 获取开发者，Harness 与 Runtime 承接生产，AgentCore 管理身份、工具和权限，Marketplace 连接第三方供给与企业采购。 AWS 不只是为 Agent 提供服务器。它开始组织 Agent 的供给、运行环境、分发和企业预算。 Payments 又把这条路径往前推进了一步。过去，AgentCore 管理 Agent 在哪里运行、记住什么、以谁的身份调用哪些工具。现在，AWS 也开始处理 Agent 能不能花钱、一次能花多少，以及付款以后留下什么记录。 从 Agentic Payment 的角度看，支付从来不只是最后的资金结算。更难的问题是：Agent 凭什么花钱、可以付给谁、出了问题谁负责，以及整条交易能否被解释和审计。 AWS 正在把这些问题变成云平台能力。 如果未来 API、模型、数据和数字服务更多采用按次付费，AWS 管理的就不只是 Agent 的计算流和工具流，也包括一部分资金流。 AWS 已经做出了可以使用的产品，但市场是否愿意大规模采用、企业会不会把支付权限交给 Agent，以及退款和责任问题如何处理，都还没有答案。 “开放”与“锁定”可以同时发生 AWS 的产品矩阵完整，不等于开发者体验一定领先。企业是否采用 AgentCore，还取决于调试体验、成本透明度以及与现有系统的整合难度。Payments 已经可以正式使用，也不代表企业会立即把大规模支付权限交给 Agent。 另一方面，AWS 一边开放模型、框架和协议，一边让身份、权限、Memory、工具目录、日志、采购和支付逐渐沉淀在自己的平台上。开放降低了进入门槛，企业在 AWS 上建立的系统越完整，迁移成本也会越高。 这就是开放和锁定为什么可以同时发生。 云计算时代，AWS 没有决定企业最终运行什么软件，但它成为大量软件背后的计算、存储、网络、身份和安全基础设施。 Agent 时代，它正在尝试复制同一个位置：不要求自己拥有最强模型，也不要求所有 Agent 都由 AWS 开发，但希望越来越多 Agent 运行在 AWS 上，通过 AWS 连接工具，由 AWS 管理身份、权限和账单，并在预算范围内完成交易。 所以，AWS 真正下注的不是某一个 Agent 产品。 它下注的是： Agent 越自治，背后的运行、权限、成本与责任系统就越重要。 如果这个判断成立，Agentic AI 的重要赢家未必只有拥有最聪明模型的公司，也可能包括那家让不同模型、框架和 Agent 都能运行、调用工具、被企业采购，并且在授权范围内完成交易的云平台。 AWS 想占据的，就是这个位置。