Loading...
Loading...
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 想占据的，就是这个位置。
当Amazon Bedrock遇见XRPL：生成式AI如何重塑区块链运维范式区块链基础设施的演进正迎来一个关键转折点。亚马逊AWS与Ripple围绕Bedrock平台的合作探讨，表面上是一次技术评估，实则揭示了更深层的产业变革——价值万亿美元的云服务市场，开始系统性地将最前沿的生成式AI能力注入主流公链的运维核心。这不再是简单的工具升级，而是整个运维哲学的根本性迁移。
传统区块链运维如同精密钟表匠的作坊，依赖工程师对日志瀑布流的人工解读，性能调优基于经验传承的隐性知识，故障诊断接近于艺术般的直觉判断。当XRPL承载起国家级支付网络与CBDC试点的关键任务时，这种手工业模式已触及瓶颈。AWS带来的Bedrock平台，预示着从手工作坊向AI驱动的全自动化指挥中心的范式跃迁。
来源：Medium_Manishankar Jaiswal
XRPL运维的现代困境：在规模化与复杂性间挣扎
XRP Ledger的运维团队正面临典型的“成功者的诅咒”。随着企业级支付流与跨境结算量的指数增长，网络复杂度呈现非线性攀升。当前的监控体系建立在多层规则引擎与阈值告警之上，这套系统在应对已知模式时表现稳健，却在面对新型异常时显得力不从心。
日志分析的维度爆炸成为首要难题。单个验证器节点每日产生的日志数据涵盖网络层、共识层、应用层数十个维度的信息流。传统监控工具依赖预先定义的规则模板，当出现前所未见的性能退化模式或隐蔽的安全威胁时，系统如同在黑暗房间中寻找特定形状的积木。去年一次由跨链桥状态同步异常引发的级联延迟事件中，工程师团队花费整整72小时才定位到根本原因——一个在特定网络拓扑下才会触发的边缘案例。
异常检测的滞后性同样困扰着运维团队。现有系统基于静态阈值触发告警，这意味着问题必须发展到足够严重的程度才会被系统感知。更为棘手的是“缓慢漂移”现象：网络延迟每周增加1-2%，连续数周后整体性能已显著劣化，但没有任何单日数据会突破告警阈值。这种渐变式退化往往在影响用户体验后才会被人工发现。
人力成本构成不可忽视的瓶颈。Ripple的全球运维团队不得不配置专项岗位，负责将技术指标翻译为商业可理解的洞察。资深工程师近半工作时间消耗在编写故障分析报告、向合作伙伴解释性能波动原因、将命令行输出转化为管理仪表盘。这种知识转换的损耗与延迟，在关键时刻可能影响关键决策的时效性。
Bedrock的介入：从规则匹配到语义理解的代际跨越
生成式AI的引入正在重构运维技术栈的基础假设。传统AI运维工具建立在监督学习范式之上，需要大量标注的“正常”与“异常”样本来训练分类器。Amazon Bedrock搭载的大语言模型带来了根本性变革——这些模型具备对系统日志、性能指标、技术文档的深层语义理解能力，能够建立跨数据源的上下文关联。
一个测试场景展示了这种能力演进。当某个区域的验证器节点出现间歇性共识延迟时，传统监控系统可能仅报告“网络延迟超过阈值”。接入Bedrock的智能运维平台则能够自主构建事件全景：首先关联AWS内部状态数据，发现该区域云网络存在背景流量波动；接着扫描版本管理系统，识别出该区域主要运营商近期升级了客户端软件；继而分析开发者社区讨论，发现有关特定负载模式下内存管理的潜在问题；最终生成综合分析：“高置信度指向v2.1.0客户端与区域网络栈的兼容性问题，建议临时回滚至v2.0.8版本并密切观察24小时”。
这种上下文感知能力将平均故障诊断时间从传统的手工排查所需的小时级，压缩至AI辅助下的分钟级。更重要的是，系统开始识别那些从未被明确编程检测的异常模式——通过理解日志的语义内容而非仅仅匹配关键词，模型能够发现人类工程师尚未归纳的问题类别。
来源：CoinGape
预测性运维：构建区块链的数字孪生
Bedrock平台的真正颠覆性潜力体现在预测能力维度。通过整合历史性能数据、实时网络拓扑、交易模式特征以及外部数据源（包括加密货币市场波动、全球网络状况、甚至监管动态），AI模型能够构建XRPL生态的“数字孪生”——一个能够模拟各种压力场景的虚拟网络副本。
容量规划正经历方法论革命。当系统预测某国央行数字货币试点将于下月启动公开测试时，AI引擎可以提前生成部署建议：“目标区域需新增3个验证器节点，优化跨区域路由策略，预期流量增长120%的情况下保持确认时间在3秒以内。”这种前瞻性规划将资源调配从被动响应转变为主动设计。
安全态势获得前所未有的感知深度。通过分析链上交易模式的微观变化，并与全球威胁情报库进行实时关联，系统能够发出早期预警：“检测到与已知攻击模板相似度达68%的交易序列聚类，建议提升相关账户监控等级，检查智能合约交互模式。”这种预测性安全使防护窗口从攻击发生后的应急响应，提前到攻击准备阶段的早期干预。
自然语言交互彻底重构了人机协作界面。运维工程师现在可以使用对话式查询替代复杂的查询语句编写：“对比亚太区与欧洲区过去一周的交易成功率差异，列出前三个影响因素。”“如果我们将验证器硬件配置升级到最新一代，预估对能源消耗和吞吐量的影响比例。”这种交互方式不仅降低了专业知识门槛，更关键的是促进了业务目标与技术指标的深度融合。
技术实现路径：在理想架构与现实约束间平衡
将生成式AI深度集成至区块链运维体系面临多重技术挑战。首要问题是数据管道的重构——XRPL节点产生的原始日志需要经过清洗、标准化、语义标注，才能转化为大语言模型可高效处理的知识图谱。这个过程必须平衡数据丰富度与处理延迟，实时性要求高的监控场景可能需要流式处理管道，而深度分析任务则可以容忍分钟级的延迟。
模型的专业化微调构成核心工程挑战。通用的基础模型虽然具备广泛的知识，但缺乏区块链运维领域的专业术语理解与问题解决模式。这需要构建高质量的训练数据集：包含历史故障案例及其解决方案、性能优化最佳实践、安全事件响应记录。更为复杂的是持续学习机制的设计——当系统遇到新型异常并成功诊断后，如何在不引发模型退化的情况下，将新知识安全地融入现有模型体系。
可解释性成为信任建立的关键瓶颈。AI系统可能给出准确的诊断建议，但如果无法提供清晰的推理链条，人类工程师很难在关键时刻完全信赖机器判断。这催生了新型可视化界面的需求：不仅展示结论，更要展示数据关联路径、置信度分布、备选解释的权衡比较。当系统建议“重启某组验证器节点”时，工程师需要理解这个建议是基于网络分区的检测，还是基于内存泄露的模式识别。
成本效益的精细测算决定规模化可行性。生成式AI推理的计算开销显著高于传统规则引擎，特别是在处理高频率日志流时。这需要在架构层面设计智能采样策略——对大多数常规流量进行轻量级分析，仅对异常信号区域启动深度推理。边缘计算与云端协同的分层架构可能成为标准范式：节点本地的轻量模型执行初步过滤，可疑事件上报至区域处理中心，复杂场景最终交由中央AI引擎进行全局分析。
生态影响：重新定义区块链基础设施的竞争维度
AWS Bedrock与XRPL的集成实验正在释放强烈的行业信号。区块链基础设施的竞争焦点，正从单纯的吞吐量数字和手续费价格，扩展到智能化运维能力与生态服务深度。验证器运营商将面临新的分化：那些能够早期接入AI增强工具链的服务商，可能形成明显的运营效率优势，从而吸引更多委托质押与商业合作。
开发者体验迎来升级窗口。当底层网络的健康状况变得高度透明且可预测时，应用层开发者可以基于更稳定的预期构建产品。智能合约可以集成网络状态查询，在检测到潜在拥堵时动态调整手续费策略；DeFi协议可以在预测到网络升级维护窗口时，暂时调低杠杆率限制。这种深度的链下与链上协同，将催生新一代的适应性应用。
行业标准面临演化压力。当前区块链监控领域缺乏统一的数据格式、指标定义和接口规范。主流云厂商的深度介入可能加速事实标准的形成——正如AWS在传统IT领域定义的CloudWatch标准那样。开源社区需要警惕过度依赖单一厂商技术栈的风险，同时把握机会推动开放标准的建立，确保生态的多样性与互操作性。
监管科技找到新的结合点。对于日益受到监管关注的公链网络，AI增强的监控能力提供了前所未有的透明度工具。合规团队可以实时追踪大额资金流动模式，自动生成反洗钱可疑活动报告，甚至模拟监管政策变化对网络行为的影响。这种能力可能改变监管机构与区块链网络的互动模式，从被动审查转向主动协同的风险管理。
运维智能化的漫长革命
亚马逊Bedrock与XRPL的探索仅仅揭开了序幕。生成式AI在区块链运维领域的应用，本质上是将人类数十年积累的系统管理经验，编码为可扩展、可传承、可进化的数字智能体。这场变革不会一蹴而就——技术可行性需要与运营可靠性反复磨合，创新速度必须与系统稳定性谨慎平衡。
真正的挑战或许不在技术层面，而在于组织与文化的适应。运维团队需要从警报响应者转变为AI训练师，从故障消防员转变为系统架构师。管理决策需要学会在AI建议与人类直觉间找到最佳平衡点，在自动化效率与可控性之间划定清晰边界。
未来三年的发展路径将定义整个十年的行业格局。那些成功将AI深度融入运维DNA的区块链网络，可能形成显著的生态优势——更低的运营中断风险、更快的异常响应速度、更优的资源利用效率。而这场竞赛的胜出者，或许将重新定义什么叫做“企业级区块链基础设施”。
当最后一台需要人工持续监控的验证器节点控制台关闭时，我们迎来的不仅是运维效率的量变提升，更是区块链网络作为自主进化的数字有机体的质变开端。这条路始于今日的技术评估，通向的是智能合约与智能基础设施完全融合的未来图景。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 想占据的，就是这个位置。