2026年4月22日，在Google Cloud Next将整个科技媒体的注意力吸引到拉斯维加斯时，AWS悄悄发布了一篇工程博客。

标题不够吸引眼球：《在几分钟内完成第一个可运行Agent：Amazon Bedrock AgentCore新功能发布》。

没有Sundar Pichai式的开场演讲，没有$2400亿积压订单的宏大叙事，只有技术细节和代码示例。但如果你在过去二十年里研究过AWS的平台策略，你会在这些技术细节里读到一个清晰的战略信号：

AWS正在系统性地将整个AI Agent开发工具链的中间层「战略性下沉」到自己的平台内部。

这是一场被工程博客包裹的平台战争。而战争的对象，是LangChain、LlamaIndex、CrewAI以及数以百计的AI基础设施创业公司。

一、3个API调用到底替代了什么

要理解这次发布的战略意义，首先需要理解AWS在替代什么。

在AgentCore新功能推出之前，一个典型的AI Agent从原型到生产，需要经历以下工作：

第一阶段：框架选择与集成（1-3天）

团队需要评估并选择框架：LangChain适合快速原型，但生产环境问题多；LlamaIndex擅长知识库场景，但复杂工作流较弱；CrewAI的多Agent协作直观，但企业级支持有限；AutoGen的对话模式独特，但与现有工具链整合困难。每种选择都意味着不同的学习曲线和后续维护成本。

第二阶段：编排层实现（2-5天）

无论选择哪个框架，团队仍然需要自己写Agent循环的核心逻辑：模型调用、工具选择、结果处理、错误恢复、上下文窗口管理。这部分代码是Agent的「神经系统」，也是最容易出现边界情况的地方。一个处理顺序不当的并发调用，可能让整个Agent在生产环境中以无法预测的方式失败。

第三阶段：基础设施接入（2-4天）

计算资源配置（选GPU还是CPU，实例大小）、代码沙箱隔离（防止Agent执行恶意代码）、身份认证管理（Agent需要调用哪些外部API，权限如何管控）、持久化存储（会话状态如何跨请求保存），每一项都需要独立的工程工作。

第四阶段：工具链连接（1-3天）

Agent通常需要访问数据库、内部API、外部服务。每一个连接都意味着：认证凭证的安全存储、访问权限的精细管控、调用失败的降级处理、速率限制的管理。对于工具数量较多的Agent，这部分工作的复杂度随工具数量非线性增长。

第五阶段：部署流程（1-2天）

开发环境的配置和生产环境不同，需要单独的CI/CD流程。测试Agent的行为比测试普通API困难得多，因为Agent的输出依赖于模型的非确定性。

AWS内部数据显示，大多数团队在运行第一个「真实」测试之前，平均花费数天甚至超过一周在这些基础设施工作上。

AgentCore的managed agent harness用3个API调用完整替代了第一阶段到第四阶段：

1. 声明Agent：定义模型、工具、指令
2. AgentCore自动构建harness：编排层、沙箱、身份、存储一并处理
3. 运行Agent：开始处理真实任务

修改模型变成了一个参数更改。增加工具变成了一行配置。A/B测试不同的Agent配置可以在几分钟内完成，而不需要重构代码。

VTEX工程副总裁Rodrigo Moreira公开表示：「以前，验证每个新的Agent想法都需要数天的编排代码和基础设施搭建，才能检验这个想法本身是否可行。AgentCore的harness功能改变了这一点：换一个模型、增加一个工具、优化Agent指令——现在都是配置变更，不再是重新构建。我们现在可以在几分钟内验证Agent想法，而不是几天。」

从工程角度，这是真实的生产力提升。

从战略角度，这是AWS最精典的剧本。

二、云厂商「下沉复杂度」的二十年历史

要真正理解AgentCore的战略意义，需要把它放进AWS二十年的发展历史里来看。

AWS的核心增长引擎，从来不是提供更贵的服务，而是一次又一次地识别开发者当前认为「必须自己构建」的东西，然后把它做成托管服务，放进自己的计费体系。

2006年：S3消灭了自建存储

S3出现之前，可扩展的对象存储需要企业自己设计分布式系统、管理硬件、处理故障和数据冗余。这是一个需要专业团队和持续投入的基础设施问题。S3之后，这变成了一个API调用。整个「分布式存储基础设施」行业，在接下来几年内基本消亡。

2009年：RDS消灭了自建数据库运维

托管数据库出现之前，运行一个高可用PostgreSQL意味着：主从复制配置、自动故障转移、定期备份和恢复测试、版本升级管理、安全补丁应用。一个专职DBA的工作。RDS将这个工作「下沉」为一个月度账单上的服务项目。

2014年：Lambda消灭了服务器管理

Serverless出现之前，每一个微服务都需要自己的实例管理、自动扩缩容配置、负载均衡设置。Lambda将这些「下沉」，让开发者只写业务逻辑。

2016年：SageMaker开始消灭ML基础设施

机器学习训练和部署的基础设施：GPU集群管理、分布式训练编排、模型版本管理、A/B推理测试——AWS逐步将这些「下沉」到SageMaker平台。

现在，2026年，轮到了AI Agent编排基础设施。

每一次「下沉」的模式都相同：

  1. 识别一个开发者认为「必要复杂度」的领域
  2. 构建一个托管服务，将复杂度隐藏在API之后
  3. 定价低于企业自建的成本（考虑工程时间）
  4. 逐步建立迁移成本，使得从平台迁出的代价越来越高

AgentCore是这个剧本的最新篇章，不是第一章，也不会是最后一章。

三、被「下沉」的不只是复杂度，还有创业公司的商业模式

让我们直说一件AI圈很多人选择回避的事：AgentCore每一项新功能，都直接对应一个现有AI工具的核心价值主张。

managed agent harness的推出 → 威胁LangChain、LlamaIndex、CrewAI、AutoGen

这些框架的核心价值是「让构建Agent更简单」。当AgentCore可以在3个API调用内完成这件事，框架层的差异化价值立即被压缩。对于80%的标准Agent场景，你真的需要LangChain吗？

AgentCore CLI的推出 → 威胁LangSmith、Weights & Biases、MLflow的部署功能

统一的开发-部署-运维工作流，正是这些工具解决的核心问题。AWS将它内置，等于将这个价值主张「下沉」到了平台基础设施层。

预置coding agent skills → 威胁特定场景的垂直框架

为Claude Code、Kiro等编码Agent提供预置的最佳实践上下文，意味着AWS在特定垂直场景积累了平台级的护城河。独立框架如果想在这个场景上竞争，需要面对AWS的预置优势。

微VM隔离沙箱 → 直接威胁E2B、Modal等代码执行沙箱服务

安全的代码执行环境是一个专门的基础设施问题，过去催生了专门的创业公司。AgentCore将沙箱执行内置，这个独立市场的空间被大幅压缩。

会话状态持久化 → 竞争Mem0、Zep等记忆管理服务

Agent跨会话的记忆管理是下一个AI基础设施的核心竞争场景。AWS通过AgentCore内置了基础的状态持久化，同时上周还发布了与Amazon Neptune + Mem0的深度集成，显示了在企业级记忆管理上的全面布局。

这五项功能的组合，构成了一个对AI基础设施创业公司的「包围圈」。不是正面攻击，而是战略性地把它们赖以生存的市场一层一层地「下沉」到平台内部。

四、开源Strands Agents：一个值得分析的战略工具

AgentCore的managed harness底层，是AWS去年开源的Strands Agents框架。

这里有一个微妙但值得关注的战略点——尽管目前还无法确定性地下结论。

AWS说：「managed harness基于Strands Agents，当你需要更多控制时，可以切换到代码定义模式，底层仍然是Strands Agents，在AgentCore Runtime上运行。」

表面上，这是在提供灵活性：你可以从配置模式升级到代码模式，不需要更换底层平台。

但从迁移成本的角度，可以观察到一个值得警惕的分层结构：

配置模式（3步API）：Agent状态、工具调用历史、会话持久化都在AgentCore Runtime中。最简单，但对运行环境依赖最强。

代码模式（Strands Agents + AgentCore Runtime）：你有了对编排逻辑的完全控制，但你的Agent仍然依赖AgentCore的微VM、身份管理、持久化存储。迁移出去需要重建这些基础设施。

完全独立（自建一切）：完全可行，就像今天仍然可以不用S3自建分布式存储。但随着AgentCore平台能力的增强，这个选择的机会成本越来越高。

当然，要说这是「精心设计的锁定」还是言之过早——AWS可能真的只是在提供优秀的开发者体验，没有任何刻意的锁定意图。事实是，我们目前没有看到大量开发者因为锁定而抱怨AgentCore，也没有可靠的数据显示迁移成本有多高。

但历史的规律确实值得参考：开源框架作为云厂商托管服务的基础层，是一个被反复验证的模式。Kubernetes开源之后，GKE/EKS/AKS成为大多数企业的首选——开发者保留了「可以跑在任何地方」的理论自由，同时实际上越来越依赖云厂商的托管服务。Strands Agents是否会走相同的路，目前还是一个开放性问题，但值得开发者在架构决策时思考。

Strands Agents的开源，让AWS可以诚实地说「我们是开放的，你可以随时离开」。从目前情况看，这个说法是真实的。问题在于，随着平台能力的增强，「随时离开的权利」和「离开的经济理性」是两件不同的事。

五、独立框架的存活路径

这不是在预言LangChain或LlamaIndex的死亡。但它们需要认真回答一个问题：当AWS能提供「3步API部署生产级Agent」时，你的差异化价值在哪里？

目前来看，有三条可能存活的路径，以及一条正在关闭的路径：

路径一（正在关闭）：「让Agent开发更简单」

这曾经是LangChain的核心价值主张。但当AgentCore在这个维度上的投入远超独立框架的资源，这条路径的竞争空间越来越小。这不是说不能做，而是很难赢。

路径二（仍然有效）：「复杂场景的精确控制」

LangGraph走的方向：图式工作流、精确的状态机控制、复杂的多Agent协调逻辑。这比AgentCore的声明式配置灵活得多，适合需要精确控制的复杂场景。

实际案例来看，金融行业的一些量化研究团队使用LangGraph构建的Agent工作流，需要在数百个节点之间精确控制执行顺序和条件分支——这种粒度的控制，AgentCore的当前版本无法满足。药物研发公司的分子筛选Agent，同样需要极其精确的工作流状态机，任何简化都可能导致错误结果。

这条路径确实有效，但它的市场规模是有限的。云厂商的托管服务，天然面向「足够好」的标准场景优化；超出标准化范围的特殊需求，才是独立框架的真正机会。

从行业观察来看，这类「需要精确控制」的复杂场景，通常是金融量化、药物研发、航空航天等对决策可追溯性有严格要求的垂直领域。这些场景虽然不是市场的多数，却往往是愿意为专业工具付最高费用的客户。市场规模虽有限，但商业价值不低。

路径三（有潜力）：「多云中立性和迁移保护」

这是一个有真实基础的企业需求，特别是对于监管严格行业的大型企业——金融、医疗、政府。在这些领域，数据主权要求和监管合规框架往往明确限制了对单一云供应商的过度依赖；欧盟的GDPR和美国的金融监管法规，都有明确的数据驻留和可审计性要求，这使得「只跑在一个云上」成为一个合规障碍。

对于这类企业，「AgentCore只在AWS上运行」不是一个可接受的选项，无论它有多方便。能够提供「在AWS/Azure/GCP上运行相同Agent代码，相同的监控和迁移工具」的框架，满足了一个AWS自己结构性无法满足的需求。这是差异化的真实来源，不是假设的需求。

路径四（高潜力）：「垂直场景深度集成」

通用基础设施是云厂商的主场。但针对特定垂直场景的深度整合：

  • 法律AI的工作流（合规追踪、引用验证、监管报告）
  • 医疗AI的安全框架（HIPAA合规、临床决策审计）
  • 金融AI的风控集成（实时风险评估、交易合规检查）

这些场景的「必要复杂度」，AWS不会轻易下沉，因为它们需要深入的垂直领域知识，而不只是通用技术能力。

六、企业开发者的三道选择题

对于正在做架构决策的企业开发者，AgentCore的发布提出了三个值得仔细思考的问题：

问题一：你的Agent场景在AWS的「标准化」范围内吗？

如果你的需求是：标准的工具调用型Agent、单一模型提供商（Claude或Bedrock上的其他模型）、相对可预测的工作流，AgentCore的3步API可能真的是最高效的选择。

如果你的需求是：复杂的多Agent协调、跨不同AI提供商的混合调用、高度定制的编排逻辑，你可能需要在AgentCore之外寻找方案，或者接受AgentCore的代码模式并承担相应的平台绑定。

问题二：你对AWS的依赖度已经有多高？

如果你的主要基础设施已经在AWS（S3、RDS、Lambda、SageMaker），增加AgentCore只是扩展了已有的依赖，迁移风险的边际增量可控。

如果你在有意识地保持多云或云中立，AgentCore的深度集成可能需要谨慎评估。

问题三：你的Agent是战术工具还是战略资产？

对于战术性的内部工具（自动化重复任务、提升团队效率），AgentCore的开发速度优势远大于锁定风险。

对于战略性的核心产品（AI Agent是你的差异化竞争力所在），平台依赖的风险需要更认真地评估——不是因为AWS不可靠，而是因为战略资产的命运不能完全交给第三方平台决定。

七、一个更大的视角：AI工具链的第二波整合

把视角拉远，我们正在经历AI工具链历史上的第二波整合。

第一波整合（2022-2024）发生在模型访问层

大量独立的推理服务、微调平台、提示工程工具，在OpenAI/Anthropic API能力持续提升的过程中逐渐被边缘化。当模型提供商直接提供Fine-tuning API、Function Calling、Assistant API时，在它们之上搭建简化层的创业公司开始失去存在价值。

结果：大量早期AI工具公司消亡或转型，少数成功转向更高层的价值（可观测性、评估、垂直应用）。

第二波整合（2025-2026+）正在发生在Agent基础设施层

AgentCore代表的，正是这第二波整合的加速信号。编排框架、沙箱执行、记忆管理、部署工具，正在被云厂商系统性地「下沉」到平台层。

这和第一波整合有相同的规律：一旦某个「必要复杂度」被充分抽象，做这个抽象层的独立公司就失去了最重要的生存理由。

第三波整合的迹象正在出现，但时间轴不确定

要说第三波整合「将在哪里发生」并不公平，因为预测总是包含误差。但当前已经可以观察到一些信号，值得密切追踪：

向量数据库方向：AWS在2025年持续增强OpenSearch Service的向量搜索能力，并将其与Bedrock深度集成；Azure的AI Search已经把向量检索和LLM工作流无缝打通。Pinecone、Weaviate等独立向量数据库仍然保持增长，但它们的关键增长指标（新客户获取率）是否能抵御云厂商内置功能的侵蚀，是2026-2027年最值得观察的数据之一。

评估和可观测性方向：Weights & Biases、LangSmith在LLMOps领域建立了护城河，但AWS的CloudWatch、Bedrock内置的模型评估功能也在持续演进。目前这个方向云厂商还没有发起决定性的竞争，但如果未来某一天AWS在控制台里提供一键式的Agent评估报告，这个市场的格局可能发生转变。

提示管理和实验层：这一波整合在2023-2024年已经基本完成。大量早期的提示工程工具已经销声匿迹，用户回归到了直接使用各模型提供商的API和官方工具。这是最近的一个可参照案例。

这些信号说明，下沉的方向是清晰的，但时间框架取决于云厂商的执行速度和独立工具的差异化能力。最保守的估计是：某种形式的整合将在2026-2028年继续发生，但具体哪个细分市场会先被整合，还需要持续观察。

八、那条AWS没有宣传的发布

在发布managed agent harness的同一周，AWS还有另一条相关发布更少引起关注：Spring AI AgentCore SDK。

这个开源SDK将AgentCore能力引入Spring AI框架，面向全球估计1500万企业Java开发者。

这条发布的信号意义超过了它本身的技术内容。AWS不只是在吸引「AI原生」的Python开发者——它在进行一场更大规模的企业开发者迁移，将Java生态中的企业AI开发，同样纳入AgentCore的版图。

1500万Java企业开发者，是一个比所有Python AI框架用户加起来更大的群体。如果其中5%开始用AgentCore，这将是AI基础设施历史上最大规模的平台采用事件之一。

这是AWS在做的事情的真实规模。不是替代LangChain（它可能也会做到），而是系统性地建立下一个十年AI开发的标准平台。

结语：一个历史性的时刻，在一篇被低估的博客里

当所有人的眼睛盯着Google Cloud Next的大舞台时，AWS用一篇工程博客安静地宣示了AI基础设施战争的下一个章节。

3个API调用，不是终点，而是起点。

它起点的背后是这样一条逻辑链：简化部署 → 更多开发者采用 → 更多Agent运行在AgentCore Runtime上 → 更多企业业务依赖AWS AI基础设施 → 更高的迁移成本 → 更稳固的平台护城河。

这是AWS过去二十年每次发布新托管服务时运行的同一条逻辑链。

历史告诉我们：它有效。每一次都有效。

对于开发者和创业公司，理解这条逻辑链，不是为了恐慌，而是为了做出更清醒的选择：你的价值究竟在哪一层？当这一层被下沉，你的下一步是什么？

这些问题，比3个API调用本身，更值得思考。

附录：AgentCore生态的完整拼图

要全面理解这次发布，值得把AgentCore的完整功能矩阵梳理清楚。

计算与执行层：微VM隔离沙箱为每个Agent提供独立的执行环境，防止Agent之间的代码互相干扰，也防止恶意工具调用污染宿主环境。这个能力过去需要企业自己配置容器隔离策略。

状态管理层：会话状态持久化到专属的持久化文件系统，Agent可以暂停任务然后从中断点恢复——这使得需要人工审批的「人在环路」场景变得切实可行，而不需要为此单独设计状态管理方案。

工具与安全层：AgentCore内置的身份和访问管理，让Agent可以安全地调用外部API，而不需要开发者单独管理和存储API密钥。这直接降低了Agent系统中最常见的安全风险之一：凭证泄露。

开发者工具层：AgentCore CLI统一了开发-测试-部署的全流程，使得在本地开发的Agent可以一键部署到生产环境，不需要为不同环境维护不同的配置。

框架兼容层：AgentCore明确支持LangGraph、LlamaIndex、CrewAI、Strands Agents等主流框架——这是一个重要的信号。AWS没有要求开发者放弃已有的框架，而是为它们提供了一个更好的运行平台。这是一个「平台包容框架」的策略，比「平台替代框架」更聪明，也更难对抗。

以上这五层能力的组合，构成了一个完整的Agent开发和运行平台。没有任何一层是颠覆性的技术创新，但它们的组合，填补了现有开发工具链中几乎所有的空白——而这些空白，正是大量AI基础设施创业公司赖以生存的市场空间。

这就是为什么这次发布值得认真对待，不是因为它技术上有多革命性，而是因为它战略上有多周全。

九、一个数学题

让我们做一道简单的数学题，结果可能比你想象的更令人不安。

假设你的团队正在构建AI Agent，每年总工程成本是$100万。

场景A（自建）：30%的工程时间用在基础设施（框架、编排、部署、监控）= $30万/年的「基础设施税」。这些工作不产生业务价值，但你必须付出。

场景B（AgentCore）：基础设施成本降到10%工程时间 = $10万/年。AgentCore服务费假设$8万/年。总支出$18万，节省$12万。

在这道数学题里，AgentCore赢了。

但这道题还有第二面：

今天的$12万节省，是用未来迁移成本的上限未知来交换的。

当你两年后决定「我们不想再用AWS了」，这时候的迁移成本是多少？没有人知道。它取决于AWS届时提供了多少你已经在依赖的差异化功能，取决于你的Agent数量和复杂度，取决于当时还有没有可靠的替代方案。

这不是一道有标准答案的题。对于多数初创公司，今天的$12万节省的价值，显然大于那个遥远的、不确定的迁移成本。合理选择。

但对于把Agent作为核心战略资产的公司，这道数学题需要加一个参数：如果五年后你必须迁出，你愿意付多少？ 如果这个数字比你今天节省的钱多，就需要提前做好架构上的「迁移友好」设计，而不是等到那天才发现问题。

AWS赌的是：大多数人不会算到这一步，或者算到了也觉得无所谓。

历史证明，AWS这个赌注，每次都赢了。

参考资料：

  • AWS官方博客：《Get to your first working agent in minutes: Announcing new features in Amazon Bedrock AgentCore》(2026-04-22) — https://aws.amazon.com/blogs/machine-learning/get-to-your-first-working-agent-in-minutes-announcing-new-features-in-amazon-bedrock-agentcore/
  • GitHub: aws/agentcore-cli (2026-04-22) — https://github.com/aws/agentcore-cli
  • AWS官方：《Spring AI AgentCore SDK发布》(2026-04-22) — https://aws.amazon.com/blogs/machine-learning/category/artificial-intelligence/amazon-machine-learning/amazon-bedrock/
  • AWS官方：《Company-wise memory in Amazon Bedrock with Amazon Neptune and Mem0》(2026-04-22) — https://aws.amazon.com/blogs/machine-learning/company-wise-memory-in-amazon-bedrock-with-amazon-neptune-and-mem0/
  • VTEX官方引用：Rodrigo Moreira, VP of Engineering (来源：AWS官方博客)
  • Ars Technica：《Anthropic gets $5B investment from Amazon》(2026-04-21) — https://arstechnica.com/ai/2026/04/anthropic-gets-5b-investment-from-amazon-will-use-it-to-buy-amazon-chips/