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 想占据的，就是这个位置。
AxBlade 將於 AWS Summit 香港期間舉辦「From Agentic AI to Physical AI」Side Event香港，2026 年 6 月 18 日 —— AxBlade 將於 6 月 18 日 AWS Summit Hong Kong 期間，舉辦一場邀請制閉門活動「From Agentic AI to Physical AI」。活動將邀請約 150 位創辦人、工程師、合規負責人及投資人，聚焦一個正在被業界迴避的問題：當 AI 從生成文字走向物理世界執行動作，驗證、追溯與問責的基礎設施已明顯滯後於能力的躍升。
什麼是 Physical AI？為何問責問題比想像中更迫切？
所謂 Physical AI，是指不只在螢幕上生成文字或圖像，而是能在現實世界執行實體動作的人工智能系統——涵蓋工廠機械臂、自動駕駛車輛、手術輔助機器人等場景。這些系統一旦出錯，責任歸屬的複雜程度遠超傳統軟件故障。
今日的 AI 競爭重心已經轉移。問題不再是某個模型能否通過某項基準測試，而是自主系統能否被部署進工廠、車輛或醫院，同時不製造無法追責的風險。
以下三個真實可能發生的場景，清楚說明問題所在：
凌晨三點，AI 交易機器人執行了一筆未獲授權的槓桿訂單；斷網災區環境下，手術機器人完成了一次切割動作；生產線上，人形機器人做出接觸決策導致工人受傷。這三個場景指向同一種制度性失敗——沒有可信記錄能夠證明「誰」在何時做出了「什麼」決策，也沒有任何證據能夠驗證該決策是否在既定的授權邊界之內。
現有審計工具為何無法解決這個問題？
現有的審計工具，設計初衷是為人類操作的軟件系統服務，無法還原自主 AI 代理的完整決策鏈。這並非工具的技術限制，而是根本的架構問題。
更深層的挑戰在於：任何依賴單一公司服務器的問責系統，都會繼承該公司本身的利益與風險。日誌可能因系統故障而丟失，可能因版本更新而被改寫，也可能在法律壓力下消失。當保險公司、監管機構與機器人製造商就同一事故各執一詞，沒有任何一方有足夠的理由信任對方的服務器記錄作為中立裁決依據。
AxBlade 嘗試以公鏈形態回應這一問題：一個開放、無需許可的執行環境，其中的行為證明以密碼學終局性（cryptographic finality）作為錨定，而非依賴任何組織層面的承諾或自我申報。
關於本次活動：這是一場工作會議，不是發布會
AxBlade 對本次活動的定位，是工作會議（Working Session），而非產品發布會、代幣活動或泛談「AI 將改變一切」的舞台。
議程設計的核心目的，是讓已在生產環境中部署自主系統的從業者，能夠展示並討論真實的技術選型與商業決策——包括部署時遇到的實際問題、合規層面的未解難題，以及基礎設施建設的優先順序判斷。
預期出席機構涵蓋 AWS、NVIDIA、Y Combinator、Crypto.com、Roche 及 Pfizer 等，代表雲端基礎設施、機器人技術、醫療及機構金融等多個領域。參與名額設有上限，採申請審核制。
活動議程
13:30–14:30 嘉賓簽到 & 歡迎咖啡
14:30–15:00 AxBlade 主題演講：協議現況、測試網即時數據與 Physical AI 存證基準
15:00–15:30 AWS 主題演講：面向可驗證 AI 執行的雲端基礎設施
15:30–17:00 三場專題討論：AI 基礎設施融資趨勢、真實世界部署、從 Demo 到規模化生產
17:00–18:00 定向交流 / Demo 角：PoB 即時驗證、機器人邊緣存證、EU AI Act 合規映射
18:00–21:30 閉門私享晚宴（僅限邀請）
AxBlade 在做什麼？
AxBlade 並不製造 AI 模型。該項目構建的，是位於模型層與應用層之間的可溯源層（Accountability Layer）——透過鏈上身份識別（DID）、行為存證（PoB，即 Proof of Behavior）、決策溯源（PoD，即 Proof of Decision）與零知識證明，讓自主 AI 系統的行為能夠被獨立審計與追責。
這一基礎設施需要一種特定的形態：公鏈，而非私有數據庫。只有當帳本是無需許可、以密碼學保護的，才能為多方之間的爭議提供中立的裁決基礎。
AxBlade 的設計目標是：高吞吐行為存證、以太坊級終局性、以 AI 治理為核心建構的 Layer 2 公鏈——而非以金融投機為導向的基礎設施。每一份行為證明都發布在鏈上，每一項聲明均可由任何第三方獨立驗證，無需信任 AxBlade 或 AI 運營方本身。
如何申請參與？
本次活動為邀請制或審核制，剩餘少量名額對以下人士開放申請：在受監管或物理環境中部署 AI 的技術創辦人、負責 AI 治理的企業決策者，以及關注基礎設施賽道的投資人。
申請參與：https://luma.com/9byrohqe
關於 AxBlade
AxBlade 是一條專為 AI 問責而構建的 Layer 2 公鏈。透過鏈上身份、行為存證（PoB）、決策溯源（PoD）與零知識驗證，AxBlade 為自主 AI 系統提供可驗證、可審計、可追責的信任基礎設施，覆蓋從數字代理到物理機器人的全場景。
活動資訊
日期：2026 年 6 月 18 日（週三）
時間：13:30–21:30（香港時間）
地點：香港灣仔 Kennedy Road 15 號 21F
形式：AWS Summit Hong Kong 期間邀請制閉門活動
科技巨头财报解读：天量资本支出、AI需求与泡沫之争撰文：Bobby Li，Techub News
2026 年 5 月，谷歌、亚马逊、Meta和微软四大科技巨头在90分钟内相继发布了创纪录的季度财报，引发了市场对AI热潮是真实增长还是巨大泡沫的激烈讨论。Limitless Podcast的主播Ejaaz和Josh对此进行了深度剖析。本文基于他们的对话，梳理了财报中的关键数据、巨头们的战略布局，以及对AI行业未来的核心判断。
一、 创纪录的财报：是泡沫还是黄金时代？
“我们是否处于AI泡沫中？”这是当前市场最核心的疑问。Ejaaz开篇即指出，过去批评者认为的“AI泡沫”和“过度支出”，被最新财报数据“完全证伪”。以谷歌为例，其每股收益超出预期94%，这并非笔误。其云业务收入同比增长约50%，积压的算力订单价值高达近5000亿美元。即使是此前被认为在AI竞赛中落后的Meta，其广告业务也因AI实现了大规模收入增长。
然而，Josh提出了一个更细微的观点：“我们是否处于泡沫中？答案很可能是明确的‘是的’。但关键在于这个泡沫有多大？很可能比许多人想象的要小得多。而剩下的跑道还有多长？我认为比人们预期的要长得多。”分歧的焦点在于对“泡沫”的定义和当前数据的解读。
财报的核心矛盾点在于：一方面，巨头们正在投入史无前例的资本支出（CapEx）。谷歌为下一个财年提供的资本支出指引高达1800亿至1900亿美元。Josh形容这是一个“愚蠢的、疯狂的数字”。作为对比，谷歌单季度的收入（1100亿美元）就已超过可口可乐的年收入。更惊人的是，谷歌CEO Sundar Pichai（桑达尔·皮查伊）在财报电话会上表示，2027年的资本支出将比今年（已是创纪录水平）显著增加。这预示着未来几年投入强度只增不减。
另一方面，这些投入正在产生实实在在的、超预期的利润。Ejaaz强调，关键要看利润率的扩张。谷歌和亚马逊的云业务利润率平均扩大了约50%。这意味着，提供AI芯片和云服务让它们获得了更高的边际利润。Josh补充道，定价弹性也很高，即便提价，客户仍会买单。
Ejaaz总结了一个关键观察：这些公司的总营收增长可观，但并非“惊人”。真正“惊人”的是利润率的大幅扩张。这回答了关于AI需求的核心质疑：企业是否愿意为AI基础设施付费？财报显示，需求不仅存在，而且旺盛到连谷歌这样的超大规模云提供商都“在近期受到算力限制”，其云收入本可以更高，如果能满足需求的话。Ejaaz指出，积压的4620亿美元订单是已锁定的订单，而非预测，这强有力地证明了市场需求是真实且迫切的。
二、 资金流向：从科技巨头到核心基础设施
天量的资本支出将流向何处？Josh指出，这是一个资金“下渗”的过程。当亚马逊、谷歌等公司将现金用于建设数据中心时，钱流向了产业链的上下游：它们需要外壳、能源、芯片。
一个生动的例子是能源公司Bloom Energy，其股价在一年内上涨了1400%，仅昨日就因强劲的财报上涨了24%。著名投资者利昂·库珀曼（Leopold）在其最新的13F文件中显示，对Bloom Energy的持仓从8.75亿美元增至27亿美元。这显示了资本支出如何惠及基础设施供应商。
另一个例子是存储公司SanDisk（闪迪）。Josh提到，如果两年前投资SanDisk，回报高达30倍。原因在于，所有四家巨头的财报都提到，内存是严重的供应瓶颈，相关成本正在上升，而公司们正在吸收这些成本。Meta或亚马逊仅因这些商品成本上涨就增加了250亿美元的资本支出。
Ejaaz和Josh都认为，这种资金从巨型科技公司“向下”流入核心基础设施的“倒置”现象，是近期市场一个未被充分定价的变化。传统上，这些科技巨头吸收了大量自由现金流；现在，它们正在将其花出去，而这些钱正在其他领域创造新的增长点。
关于“泡沫论”的一个重要反驳点是公司的财务状况。Ejaaz强调：“根据定义，AI泡沫意味着这些公司的资产负债表杠杆率很高。而我们2026 年 5 月讨论的公司——谷歌、亚马逊、Meta和微软——都没有加杠杆。”他指出，尽管亚马逊已承诺将其94%的自由现金流用于AI基础设施投资，这是一种非常激进的策略，但它们目前并未陷入债务融资的境地。只要这些投资能持续产生高于成本的回报，这种支出就是可持续的。
三、 不只是基础设施：AI如何赋能传统业务
除了云基础设施，AI也在直接改造和提升科技公司的传统核心业务，Meta是一个典型案例。
长期以来，Meta在广告领域一直与谷歌竞争，而谷歌凭借其“互联网门户”的地位在搜索广告领域占据主导。然而，在过去的一个季度，情况发生了变化。Meta开始整合AI，特别是其收购的Manus（尽管该交易近期被中国否决）等新技术，实现了更高的AI搜索转化率。其每股收益超出预期53%，收入同比增长33%。Ejaaz指出，搜索引擎优化（SEO）是一个价值数十亿美元的庞大业务，而Meta正在开创这方面的AI版本。
这一案例与谷歌类似：此前人们担心AI会侵蚀谷歌的搜索收入，但其搜索业务反而增长了20%。这表明，AI不仅通过基础设施（云）赚钱，也通过渗透到每一个产品类别并使其更赚钱。
Josh提出了一个有趣的市场现象：尽管Meta财报数据强劲，其股价当日却下跌了9%。他认为这可能是因为广告业务相比算力更具波动性。云业务有长期合同和回头客，而广告业务则可能因竞争对手（如谷歌）推出更好的AI搜索优化系统而在下一季度发生变化。但Ejaaz认为，市场对Meta的恐惧可能过度了，人们仍将其视为社交媒体公司，而非广告业务巨头。
Josh提醒观众，需要重新认识这些公司：人们日常接触的是它们的消费者层面（如亚马逊购物App、Instagram），但其背后支撑的、规模远大于此的企业级业务（如AWS、广告平台）才是真正的增长引擎。
四、 竞争格局：微软的挑战与未来的变数
微软的财报表现同样强劲，但其股价当日表现却是四大巨头中跌幅第二大的。其云业务Azure增长了40%，利润丰厚。问题出在对比和预期上。
Ejaaz分析道，AWS和谷歌云的表现“碾压”了Azure。虽然微软的百分比增长不错，但在与另外两家巨头同台竞技时，投资者可能更倾向于选择亚马逊和谷歌。此外，微软将2026日历年度的资本支出指引上调至1900亿美元（比先前预估高出25%），这个数字超过了希腊的GDP，也超过了波音、洛克希德·马丁和通用汽车的年度资本支出总和。如此巨大的支出规模也让部分投资者感到困惑和担忧。
Ejaaz还指出了微软在AI产品层面的一个潜在弱点：缺乏清晰的AI领军人物。他提到，微软AI团队的负责人Mustafa Suleyman（穆斯塔法·苏莱曼）似乎并未交付出市场预期的产品。尽管微软是OpenAI的早期投资者和重要合作伙伴，拥有先发优势，但其Copilot产品在企业客户中的采用率并不理想。客户反而直接要求使用Claude或ChatGPT。微软的回应是推出由Claude和ChatGPT支持的“Microsoft Features”。然而，随着微软与OpenAI的独家云服务协议2026 年 5 月破裂，未来当相关知识产权在几年后到期时，微软将面临挑战。Ejaaz认为，市场可能正在预演这种“看跌”情况，从而选择了更安全的谷歌或亚马逊。
Josh总结道，只要用户在AI工具和服务中发现的增量价值大于成本，这个循环就能持续。一旦这个链条停止，当模型变得“愚钝”或用例耗尽时，问题就会出现。“但我们还没有到达那一步，”Josh表示，“所以我感到乐观。”
五、 行业动态：从AI代理到音乐生成
除了财报，对话还涉及了几项重要的AI行业动态，进一步佐证了技术的演进和商业模式的创新。
1. Anthropic的“Project Deal”实验：Anthropic团队进行了一项为期一周的实验，创建了一个仅由AI代理（Claude）自主运行的内部 classifieds 市场（类似Craigslist）。人类不能发布商品、撰写描述或议价，一切由AI代理完成。实验最终产生了4000美元的交易额，参与者反馈积极。Josh指出，这类“智能体”工作流将消耗巨量的Token，从另一个侧面推动了底层算力需求的增长。
2. Cursor发布AI Agent Harness：Cursor2026 年 5 月发布了其AI Agent Harness（AI智能体套件）的API。Ejaaz承认自己此前低估了Cursor，认为它只是一个没有护城河的“AI包装器”。但事实证明，这种能够针对特定用例精细调教、设置开发环境、集成API的“套件”，其价值已与模型本身等同。Sam Altman（萨姆·奥尔特曼）2026 年 5 月也表达了类似观点。Cursor通过将其套件作为API开放并收费，瞬间建立了自己的商业壁垒。值得注意的是，Elon Musk（埃隆·马斯克）的xAI已获得了收购Cursor的期权。
3. Eleven Labs的音乐生成平台与创作者经济：音频AI领域的领先公司Eleven Labs推出了音乐生成平台，并宣布已通过其“声音库”向创作者支付了1100万美元。Ejaaz认为，这个平台的意义在于它正面回应了艺术家对AI的担忧——AI窃取IP且不给予回报。该平台提供了一种透明、可追溯的方式，让声音IP所有者能够从其声音被使用的AI生成音乐中获利，即使音乐并非由他们自己创作。这为创作者经济开辟了新的可能性。
4. Claude新增创意软件连接器：Claude发布了连接Blender、Adobe Creative Cloud、Ableton、Canva、SketchUp等创意软件的新系列连接器。Josh尝试后发现，虽然功能强大，但目前处理速度较慢，且在复杂任务（如包含上万个零件的3D渲染）中存在出错风险，但仍是值得关注的技术进展。
5. 亚马逊的“AI播客”功能（一个反面案例？）：亚马逊在其电商平台上测试了一项新功能：为商品页面生成一个由两位AI主持人讨论该产品的播客，并支持用户实时提问。Ejaaz和Josh对此都感到困惑甚至有些“厌恶”，认为这可能是“有史以来最糟糕的AI产品”。它更多地证明了AI生成内容的成本已降至极低，以至于亚马逊可以“免费”尝试，但并非所有东西都需要AI化或变成播客。
六、 结论：泡沫尚未到来，但需关注关键指标
回到最初的问题：我们是否处于AI泡沫中？Ejaaz的结论是：目前还没有。他认为，只有当这些公司开始大量负债、市盈率（P/E Ratio）飙升时，泡沫才会出现。未来，当SpaceX、OpenAI等公司上市，资本从现有巨头中被抽走时，情况可能发生变化，但目前尚未到达那个阶段。
Josh从估值角度提供了支持：目前这些核心业务的定价并不高。Meta的市盈率为16倍，微软为25倍。相比之下，互联网泡沫巅峰时期，微软的市盈率曾达73倍，思科超过200倍，雅虎甚至超过800倍。当前这些公司并未过度借贷，也没有超出承受能力的支出，它们只是将客户那里赚取的收入再投资以扩大业务。
最终，这场讨论揭示了一个清晰的图景：AI相关的利润正在大幅增长，主要来自基础设施和利润率的扩张，尤其是云业务。只要投入算力的每一美元对客户而言仍有价值，只要像Claude和ChatGPT这样的产品不仅被普通消费者，更被每年创造数十亿美元收入的高价值企业深度嵌入其业务流程并发现深层价值，那么这场由AI驱动的资本盛宴和增长故事就仍有继续的空间。方向目前是积极的，但市场参与者需要密切关注资本支出、债务水平、市盈率以及最终用户价值创造等关键指标的变化。代理治理，超越监管成为企业AI竞争力…Boomi与AWS扩大合作随着企业在现场引入“智能体AI”的速度加快，智能体治理正成为一项必要条件，而非可选项。曾几何时，只有部分企业关注的控制与管理系统，如今正被评价为决定AI投资回报率的核心基础设施。
将业务扩展至AI编排平台的Boomi，被视为较早读懂并应对这一趋势的企业。Boomi全球战略项目总管兼欧洲、中东及非洲首席技术官安·玛雅在Boomi World 2026活动上表示：“我们去年推出了‘智能体控制塔’，非常早地进入了治理市场。当时还有人问为什么需要这样的功能，但现在，每个人都要求一定程度的治理。”
Boomi与AWS合作，应对多云时代
Boomi与亚马逊云科技（AWS）的合作，展现了在智能体AI扩散的形势下，单一企业难以提供所有解决方案的现实。这是因为企业系统正扩展到混合与多云环境，智能体治理也必须能够覆盖多种基础设施。
AWS首席客户经理妮可·布拉德利解释说，通过将Amazon Bedrock与Boomi的智能体控制塔相连接，可以支持企业从中央层面管理智能体。她表示：“必须能够在客户所处的环境中直接响应和支持。对于AWS无法直接覆盖的多云或混合领域，Boomi可以介入并提供支持，这种伙伴关系拓宽了客户支持的范围。”
数据主权需求扩大……在自有防火墙内运行AI
Boomi强调的优势在于其“控制优先”的理念。据公司方面称，其云原生运行时环境的设计使其即使在客户内部防火墙内，也能进行数据交易和转换。这一结构在过去集成服务方面表现出色，如今正扩展为在“主权环境”内运行领域专用语言模型和AI智能体的基础。
玛雅特别透露，针对数据主权需求强烈的金融领域，公司正在英国建设欧洲平台实例。此举被解读为同时满足欧洲与北美金融机构监管要求的动向。
他表示：“组织中最有价值的终究是数据，而正是这些数据构筑了企业的竞争护城河。现在，这些数据正散落各处。”他补充道，“让客户能够在其自有VPN或防火墙内直接运行小型语言模型或领域专用语言模型，是Boomi的方向。新一代运行时环境使之成为可能，并且很快将能在该环境中运行智能体。”
非开发人员也能构建智能体……控制由中央进行
这一战略也体现在近期发布的“Boomi Connect”上。该产品不仅支持开发人员，也支持业务人员创建和连接智能体，同时其设计确保认证信息和访问权限由中央统一管理。
核心在于“以治理为前提的扩散”。与过去云引入初期所谓的“影子IT”虽带来快速创新但导致控制缺失的副作用不同，如今企业需要在速度、安全性和责任性之间取得平衡。
玛雅表示：“要释放AI潜力并用AI激活数据，终究需要思考如何进行控制。未来，AI将更广泛地开放使用，但与此同时必须能够对其进行掌控。”
AI竞争力的标准，从性能转向运营体系
此次Boomi与AWS释放出的信号表明，AI竞争的标准正从单纯的模型性能转向实际运营体系。在企业级AI市场，除了使用多么强大的模型之外，管理其在何处运行、由谁访问、连接哪些数据的能力正变得同样重要。
最终，智能体治理已超越“监管应对”的层面，成为决定企业AI扩展速度与投资效率的关键因素。随着智能体AI渗透到企业运营的方方面面，率先构建可控架构的企业，很可能将占据领先优势。
TP AI注意事项
本文基于TokenPost.ai语言模型进行摘要。正文主要内容可能被省略或与事实不符。AWS与WNBA结成“数据同盟”…以实时AI指标改变转播与应用程序体验AWS与美国女子职业篮球联赛WNBA携手，超越了单纯的赞助，结成了“数据同盟”。其构想是通过实时分析联赛的比赛数据，并将其融入转播、应用程序和网站，从而同时增加粉丝流入和停留时间。
AWS与WNBA签署多年合同
近日，WNBA宣布选择亚马逊网络服务（AWS）作为其官方云及云AI合作伙伴。通过此次合作，AWS也加入了WNBA的最高级别战略赞助集团“ChangeMakers Collective”。这是AWS首次与女子职业体育联盟建立正式合作伙伴关系，因此意义重大。
核心是“WNBA Inside the Game”平台。该系统实时接收球员位置追踪数据和比赛事件数据，将其处理成基于AI的指标，然后提供给WNBA的应用程序、官方网站以及直播画面。新引入的诸如“WNBA Gravtiy”和“WNBA Shot Difficulty”等指标，将负责展示至今难以量化的无球跑动、防守专注度以及实际投篮难度。
将“看不见”的比赛转化为“故事”的结构
此次合作的核心并不仅仅在于增加统计数据。WNBA的目标是“可解释的乐趣”。其判断是，如果能让球迷直观地理解那些仅凭数据无法了解的球员影响力，那么比赛的沉浸感也将随之提高。
例如，引力指标展示了明星球员即使未持球也能吸引多少防守。投篮难度模型则揭示了同样是两分球或三分球，在何种情况下尝试的难度有多大。这不仅提供了超越简单得分数据的背景信息，也有助于解释特定阵容为何能有效运转。
利用AWS的云基础架构，WNBA无需另行组建大规模数据工程团队，即可快速测试新的可视化、统计包和定制化信息流功能。对于赛季相对较短，且扩大全球粉丝群至关重要的联赛特性而言，这种“灵活性”被视为一大优势。
NBA验证过的“数据飞轮”……扩展至WNBA
AWS此前已在NBA支持类似的分析平台。NBA一直积极将利用追踪数据得出的高级指标和实时分析内容应用于转播和数字平台。通过此次合作，WNBA也站上了同样的技术基础之上，从而为缩小联赛间的“产品体验差距”奠定了基础。
这具有超越单纯技术转移的意义。因为NBA已验证过的实时对位可视化、富含背景信息的精彩集锦、个性化记录信息流等功能，可以更快地应用于WNBA。最终，从球迷的角度来看，无论联赛规模大小，他们都将获得更现代、更丰富的观赛体验。
扩大观众群的关键在于“转化率”而非“知名度”
分析人士认为，WNBA的课题并不仅仅在于告知联赛的存在。更重要的是将那些已经有关注但并未持续观看的潜在粉丝，转化为定期观众。在这一点上，数据可以成为强有力的工具。
首先，直播质量可能会发生变化。如果在转播中同时展示实时指标、引力热图、阵容效率、投篮质量趋势等，将提高对比赛的理解度。即使是未打开应用程序的普通观众，也能仅通过转播接触到差异化的信息，这可能会增加他们的停留时间。
数字体验的个性化也值得期待。随着球迷经常观看哪位球员、点击哪些指标等数据的积累，就有可能提供诸如以喜爱球员为中心的仪表盘、特定纪录达成时的通知、基于观看模式的比赛推荐等服务。这意味着联赛有可能在比赛之外的时间也能与球迷建立联系。
社交媒体的扩展性也很强。在短视频中添加AI分析，或者以卡片形式呈现能让人一眼看出“这个场景为何重要”的内容，都具有很高的分享性。特别是年轻粉丝群体已经在社交平台上消费体育内容，因此对WNBA而言，数据可以成为一个内容生产工具。
不仅仅是赞助，而是强化“产品竞争力”
WNBA与NBA的关注度差距一直受到历史、营销预算、转播权规模等结构性因素的影响。不过，在近期的体育市场中，基于技术的观赛体验也正成为一个重要变量。如果一个联盟提供精密的数据和互动功能，而另一个联盟却不能，那么球迷实际感受到的差距可能会比实际的竞技水平差距更大。
在这一点上，与AWS的合作是WNBA得以比独自建设技术基础设施要快得多地提升竞争力的一张牌。熟悉NBA分析内容的球迷很可能也会自然而然地接受WNBA的专属指标，从长远来看，串联起两个联盟的故事讲述也会变得更加容易。
WNBA与AWS的此次合作伙伴关系，可以看作是对“数据创造参与，参与创造粉丝”这一假设的正式实验。这不仅停留在添加赞助商标志的层面，更是一次试图改变联赛消费方式的尝试，因此正受到市场关注。如果WNBA能以此平台为基础，加速在转播、个性化、社交扩展方面的发展，那么第30个赛季之后，它有可能开启新的增长局面。
TP AI注意事项
使用基于TokenPost.ai的语言模型对文章进行了摘要。可能遗漏了正文的主要内容或与事实存在差异。AWS，AI编码工具‘Kiro’大幅改版…通过需求验证与并行执行减少开发瓶颈亚马逊云服务（Amazon Web Services, AWS）大幅增强了AI软件开发工具“Kiro”的功能。此举旨在减少设计阶段与实际代码执行之间产生的“瓶颈”，同时预先过滤实现错误，从而共同提升开发速度与质量。
AWS于13日宣布，将为Kiro新增“并行任务执行”、“快速计划”和“需求分析引擎”等功能。此次更新均从即日起陆续应用。其核心在于，当开发者输入功能规格时，能够将原本不必要顺序处理的任务同时执行，并在编写代码前，先对模糊的需求条件进行验证。
AWS的产品经理安基特·夏尔马与首席工程师理查德·斯雷克尔德通过博客解释称，Kiro专注于“基于规格的开发”。这是一种先精细打磨规格说明，再实现代码的方式，有利于提升最终成果的质量。然而，这也意味着审批流程和审查步骤增多，对于重视快速开发的组织而言，可能成为速度降低的因素。
实际上，以往的Kiro在接收到包含10个任务的功能规格时，即使有6个任务彼此无依赖关系，也往往不会一次性处理，而是倾向于按顺序执行。即使是那些写入不同端点、不同文件且不共享状态的任务，也会被串行处理，从而导致时间增加。相反，即使需求看起来简短简单，实际上也可能包含许多隐藏前提和模糊之处，存在实现方向偏离的风险。
需求分析引擎
本次引入的“需求分析引擎”是旨在减少这类问题的装置。该引擎使用一个三阶段“神经符号”管道。首先，大型语言模型（LLM）将用户的模糊需求重新整理为可测试的标准，并将其转换为形式逻辑。随后，一个名为“SMT求解器”的自动推理引擎会从数学上验证是否存在逻辑冲突。
这种方式不同于单纯预测下一个单词的普通LLM。例如，如果一份文档要求完全删除数据，而另一条规则要求进行可恢复的删除，SMT求解器会将其判定为无法同时满足的“数学矛盾”。Kiro会以开发者易于理解的语句展示此类冲突，并快速指出需要修改的位置。
并行任务执行与快速计划
“并行任务执行”功能也直接关系到实际效率的提升。Kiro通过分析项目依赖关系图，筛选出不共享状态、端点和文件的任务，然后在隔离的环境中同时运行它们。AWS表示，通过此方式，大型规格的处理时间可以从超过1小时缩短至至少15分钟的水平。
“快速计划”是一种针对范围和约束已经明确的功能开发而设的“高速模式”。它不再像以往那样持续请求分步审批，而是在初期一次性提出必要的确认问题，然后一次性生成整个技术栈。当开发者已经清楚知道要构建什么时，它能提供更快速的流程。
意义与前景
此次更新在自主型AI智能体的实用性方面也值得关注。迄今为止，许多AI编码工具仅限于按指令实现内容，而无法根据常识指出设计本身存在的问题，这构成了其局限性。AWS计划通过为Kiro增加数学验证流程，来减少这种“幻觉”和非理性结果，从而使编码智能体能够超越简单的生成器，进化为真正的工程辅助工具。
最终，这次改版表明，AI编码工具市场的竞争正从单纯的代码生成转向“准确性”和“可验证性”。在提升开发速度的同时，初期捕捉需求冲突的能力变得愈发重要，Kiro的新功能在企业级软件开发现场能发挥多大效果，值得关注。
TP AI 注意事项
使用基于 TokenPost.ai 的语言模型对文章进行了摘要。可能与原文的主要内容有出入或存在事实差异。Coinbase，因AWS故障暂停交易数小时……基础设施风险再次凸显Coinbase (COIN) 因亚马逊网络服务 (AWS) 故障导致交易中断数小时，再次引发可靠性争议。在业绩不佳和重组的背景下，“核心基础设施风险”凸显。
Coinbase 于当地时间8日表示，由于位于美国弗吉尼亚州的 AWS 东部区域出现多个可用区故障，导致其网络和移动端全网交易无法进行。该公司解释称，“受影响的 AWS 服务温度升高导致了服务中断。” 故障期间，市场切换为“仅可取消订单”模式，此后交易功能已恢复。
Coinbase 通过 X（原推特）表示，“主要问题已解决”，并称“待 AWS 事后报告公布后，将进行进一步调查。” 内部检查结果显示，初期众多服务中检测到“高错误率”，工程师已将原因确定为 AWS 基础设施故障。该公司补充道，“系统设计虽能承受单一可用区故障，但此次故障影响了多个区域，导致核心交易服务长时间中断。”
故障争议不断……可靠性面临考验
此次事件再次引发了人们对 Coinbase 以往在市场急剧动荡时期反复出现故障的历史回顾。2020年，当比特币（BTC）价格在30分钟内从9500美元暴跌约10%至8100美元时，曾发生访问故障；而在一周前，价格飙升15%的区间也出现了类似问题。相比之下，同期 Kraken 等其它交易所维持正常运营。
软件工程师 Gergely Orosz 指出，“在 CEO 最近表示非开发部门也将参与生产代码部署后不久，就出现了长达数小时的交易中断，这‘呈现的画面’非常糟糕。”
业绩不佳、裁员连番打击……利空叠加下风险凸显
故障发生时，正值 Coinbase 财务和运营压力增大的时期。该公司公布了低于预期的2026年第一季度业绩，每股净亏损1.49美元，与市场预期的盈利0.27美元相去甚远；营收为141亿美元，低于预期的152亿美元。财报公布后，其股价在盘后交易中下跌超过5%。
此前，该公司于5日宣布裁员660人，约占员工总数的14%。CEO Brian Armstrong 将原因归结为“市场低迷”和“AI 环境变化”这两大压力。
分析认为，此次故障揭示了 Coinbase 在依赖外部云架构下，面对“多重故障”的脆弱性。在交易所核心收入来源——交易活动放缓之际，若基础设施稳定性也受到动摇，投资者信心的恢复可能会更加缓慢。
文章摘要 by TokenPost.ai
🔎 市场解读
AWS 多可用区故障导致 Coinbase 交易中断，使“云依赖风险”成为现实。
这不仅仅是技术问题，更是与交易所信誉直接相关的结构性弱点再度凸显。
叠加业绩不佳、裁员等利空，市场情绪可能进一步受挫。
💡 策略要点
投资中心化交易所时，需审视其基础设施分布水平及故障应对历史。
从股价角度看，短期风险加大，但从长期看，基础设施是否改善是关键变量。
与竞争对手交易所的稳定性比较，可能成为未来用户迁移的考量标准。
📘 术语解析
可用区 (AZ): 云中物理隔离的数据中心单元，用于隔离故障。
取消专用模式: 一种紧急运营模式，仅允许取消现有订单，禁止下达新订单。
云依赖风险: 特定云服务故障可能导致整体服务中断的结构性风险。
💡 常见问题解答 (FAQ)
Q.
此次 Coinbase 交易中断的核心原因是什么？
AWS 美国东部区域的多个可用区因温度升高发生故障，导致 Coinbase 的核心交易系统停滞。并非单一故障，而是多区域同时出现问题，是造成长时间中断的主要原因。
Q.
此类故障对投资者有何影响？
交易停止可能导致投资者无法在理想时机进行买卖，从而产生损失，并直接影响对交易所的信任。特别是在波动性较大的市场中，此类故障会构成更大的风险。
Q.
未来能否减少此类问题？
可以，但需要结构性改进。需要加强多云策略或基础设施分布式设计，降低对单一服务的依赖度是关键。投资者有必要将此类技术应对措施作为主要的判断依据。
TP AI 注意事项
使用基于 TokenPost.ai 的语言模型进行文章摘要。主要文本内容可能被省略或与事实不符。AWS故障导致Coinbase瘫痪……比特币交易也陷入停滞Coinbase（$COIN）因亚马逊网络服务（AWS）故障，其核心交易系统受到影响。用户遭遇图表停更、订单失败等问题，据报道，比特币（BTC）交易也一度无法正常进行。
据外媒13日（当地时间）报道，本次问题源于美国弗吉尼亚州北部AWS数据中心的过程问题。Coinbase表示，其在美国东部区域'US-EAST-1'和可用区'use1-az4'的服务受到影响。部分用户在桌面和移动端应用中经历了'性能下降'，价格更新延迟和订单未成交的情况也接连出现。
加密货币交易员Luke Cannon声称，在故障期间，Coinbase上超过1小时没有比特币交易。他指出，与币安和Hyperliquid等其他交易所相比，Coinbase的报价明显偏高，且大量订单未能执行。Coinbase强调资金是安全的，并解释称已先将交易切换为'仅取消'模式，之后将逐步恢复交易。
据悉，本次故障也影响了KAITO、SENT、TOSHI、AKT、ANIME、ZK、KERNEL、BARD等部分资产。这是自2025年10月以来，Coinbase第二次遭遇与AWS相关的服务中断。
时机也很不凑巧。Coinbase在前一天公布的第一季度财报中录得每股1.49美元的净亏损，营收为14.1亿美元，低于市场预期的约15.2亿美元。业绩不及预期后，其股价在盘后交易中下跌约4%。
Coinbase正计划通过拓展稳定币、代币化实物资产和金融服务业务，转型为'交易一切的交易所'。但有分析认为，在业绩不佳之后又遭遇大规模系统故障，其恢复信任的挑战变得更加艰巨。
业界认为，尽管此次事件源于特定AWS区域的问题，但这再次凸显了大型交易所对基础设施的依赖程度有多深。接连发生的故障与业绩恶化叠加，预计Coinbase的运营稳定性和扩张战略短期内将面临更严格的审视。
文章摘要 by TokenPost.ai
🔎 市场解读
AWS数据中心故障导致Coinbase交易中断，再次凸显中心化交易所的基础设施风险
对特定云区域的依赖度较高，可能导致整个服务瘫痪
紧随业绩不佳之后发生，对投资者信心和股价的负面影响扩大
💡 策略要点
需要分散使用交易所（拥有多个平台账户）进行风险管理
在重大事件/波动区间，基础设施稳定性是关键的选择标准
越是依赖云服务的企业，越需要检查其故障历史及响应速度
考虑中心化交易所（CEX）与去中心化交易所（DEX）的角色分散策略
📘 术语解释
AWS：亚马逊的云计算服务，全球企业用作服务器基础设施
区域：AWS数据中心所在的物理区域单位
可用区（AZ）：区域内独立的数据库中心组，用于分散故障
仅取消模式：仅允许取消现有订单，禁止新下单的受限状态
💡 常见问题解答（FAQ）
Q.
为什么AWS故障会影响Coinbase的全部交易？
Coinbase并非基于自有服务器运行，而是建立在AWS云基础设施之上。因此，当特定区域出现故障时，订单处理、价格数据、图表等核心系统可能同时受到影响。
Q.
这次故障对投资者的资产造成风险了吗？
Coinbase表示用户资产是安全的。但是，由于交易延迟和订单失败，可能会产生无法在期望价格进行买卖的'机会损失'。
Q.
在这种情况下，投资者应该如何应对？
相比仅依赖一家交易所，同时使用多家交易所更为安全。此外，在市场急剧变化时，选择使用限价单、风险管理策略以及基础设施稳定性高的平台很重要。
TP AI 提示
本文摘要基于TokenPost.ai的语言模型生成。主要内文可能被省略或与事实不符。AWS 发布 AI 代理“直接支付”功能…支持稳定币与法定货币AWS公开了人工智能(AI)代理可直接支付的功能。随着企业级AI能够自行购买数据订阅或软件使用权限，这标志着‘代理经济’已进入实际服务阶段。
公开AI代理直接支付的功能
亚马逊云服务(AWS)8日宣布，在其AI代理开发服务‘Amazon Bedrock AgentCore’中以预览形式添加了支付功能。该功能支持企业创建的AI代理直接购买付费数据、软件订阅以及各类在线服务使用权限。
据AWS介绍，其应用范围广泛。例如，金融分析AI代理可以购买证券交易所数据集的访问权限，编码辅助代理可以自动支付基于云的开发工具使用费。AWS计划未来将功能扩展至更接近实体商品（如机票）的购买。
基于x402的支付……支持稳定币和法定货币
此次支付功能基于名为‘x402’的技术运行。x402是Coinbase开发的技术，利用网络通信协议HTTP状态代码体系。普通用户熟悉的HTTP状态代码如页面未找到时显示的‘404’错误。
当AI代理访问应用了x402的付费服务时，该服务会返回‘402’状态代码，其中包含支付方式和访问权限购买流程。代理按照指引完成支付后，会收到购买凭证信息，之后重新加载页面即可访问付费内容。
资金执行通过数字钱包实现。目前AWS正与Coinbase及Stripe旗下的Privy合作。AI代理可以使用稳定币或法定货币进行支付。AWS似乎并未突出特定区块链资产，而是聚焦于企业环境中可直接使用的支付基础设施。
提供支出限额和追踪功能
对于企业而言，AI代理自主支付意味着控制机制至关重要。Bedrock AgentCore允许为每个单独会话设置支出限额，并通过内置的观测功能追踪哪个代理在何时使用了多少金额。
AWS计划未来逐步扩展支付功能，包括支持x402之外的其他协议。这显示出AI代理正从简单的响应工具进化为执行实际业务的‘交易主体’。
Coinbase基础设施增长与战略负责人Brian Foster表示：“很快，执行交易的AI代理数量将超过人类，它们需要为互联网设计的货币。”
与美国U.S. Bancorp签署大型云合同
AWS当天还发布了金融领域扩张的消息。其与美国金融公司U.S. Bancorp签署了大规模云合同，AWS将其描述为‘最大、最全面的银行现代化项目之一’。
在纽约证券交易所上市的U.S. Bancorp计划将数百个内部工作负载迁移至AWS，其中包括支付处理系统、资产管理与平台以及企业金融相关业务。同时，该公司将利用AWS的AI服务实现客户支持工作的自动化。
此次发布的意义在于，AWS不仅作为AI基础设施提供者，还致力于构建AI能够实际花钱并完成任务的执行环境。特别是涵盖稳定币和法定货币的支付结构，被视为在企业AI市场中可能加速普及的因素。
TP AI注意事项
本文基于TokenPost.ai语言模型进行摘要。正文主要内容可能被省略或与事实不符。AWS "AI原生转型，关键不在技术而在组织重新设计"……云与治理是必要条件各企业正在加速向“AI原生”转型，但诊断显示，实际上比技术引入本身更困难的问题是改变人员、工作方式和组织结构。云转型和数据治理如今已不再是可选项，而是作为可信赖的AI原生战略的“必要条件”而浮现。
亚马逊云服务(AWS) AI原生事务总管莎拉·库珀在Atlassian团队活动上接受采访时表示，AI正在改变从产品规划到客户回应的企业运营整体。他表示：“如果没有灵活的云环境、全球连接性、安全性和数据隐私，就无法在AI时代以足够快的速度行动。”
此番言论是在解释AWS与Atlassian如何支持企业AI原生转型的背景下发表的。两家公司正在云基础设施、安全性和协作体系整体上合作，帮助企业迁移至大规模AI驱动的运营模式。特别是Atlassian正在包括Jira在内的自身平台整体上扩大应用“智能体型AI”，而AWS则提供支撑这一应用的基础设施和治理体系。
库珀指出，与过去的平台转型相比，此次AI原生转型的速度和影响力要大得多。他强调，传统上被认为变化缓慢的公用事业、汽车、医疗保健和生命科学领域，如今也正转变为快速行动的行业。他解释说，随着关税变化和气候风险等难以预测的变量增多，即使是习惯于长期规划和大规模资本支出的企业，也面临着对更灵活业务结构的需求。
这种变化最终导致了IT架构的重组。这意味着，企业要将AI融入整体业务，不能仅仅停留在添加模型的程度，还需要一个能够确保数据安全流动、部门间自然协作的基础设施。这也正是为何有分析认为，AI原生战略更接近于重新设计企业级运营模式，而非单纯的技术项目。
安全与数据主权被视为企业引入AI时最敏感的议题。库珀强调，驱动Atlassian产品内AI功能的Amazon Bedrock不会将客户数据用于训练。他表示：“客户数据不会成为模型的一部分，使用哪些数据的控制权也掌握在客户手中。”
此外，AWS长期构建的企业级安全功能、防护栏、治理结构和可视性也被作为优势提出。库珀提及全球13个可用区，并解释道，对于需要满足各国数据主权和监管要求的大企业而言，这种基础设施的深度成为重要的判断标准。
市场上，随着生成式AI竞争日趋激烈，人们正关注实际胜负手可能并非模型性能，而是在于能否将AI稳定融入企业运营的执行力。此次AWS与Atlassian的声明再次表明，AI原生转型的核心并非“使用最新AI”，而是改变组织整体能够承受并适应这种变化的结构。
最终，AI原生转型并非技术引入项目，而更像是改变企业体质的长周期课题。只有云就绪度、数据治理、安全体系和协作文化齐备，企业才不致在AI时代的速度战中落后——这一分析正日益获得认同。
TP AI 注意事项
使用基于TokenPost.ai的语言模型对文章进行了摘要。正文主要内容可能被遗漏或与事实不符。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 想占据的，就是这个位置。
