亚马逊、微软和谷歌在企业智能体架构上趋于一致
内容提要
三大云厂商（亚马逊、微软、谷歌）均推出企业级智能体平台，核心架构趋同，但缺乏统一标准，导致锁定风险。文章类比PaaS演进，指出智能体平台需定义可移植契约，涵盖运行时、记忆、工具网关等组件。开源项目尚未解决治理、打包和状态问题，呼吁建立中立、云无关的智能体生命周期平台，以恢复企业议价能力。
延伸解读
架构趋同背后的锁定风险
三大云厂商的智能体平台在组件上高度相似，但每个组件都深度绑定各自云生态。例如，会话状态、遥测和身份都依赖单一供应商，导致跨云迁移需要重建整个系统。这种趋同并非巧合，而是云厂商追求垂直整合以获取利润的自然结果。企业需警惕，选择平台时不仅要看功能，更要评估其可移植性，否则将重蹈PaaS时代被锁定的覆辙。
从PaaS演进看智能体平台
文章类比PaaS发展，指出智能体平台正处在类似2011-2016年的转折点。Cloud Foundry和Heroku通过应用契约统一了部署，而智能体生态尚无等价契约。当前各平台虽提供运行时、记忆、工具网关等组件，但缺乏统一标准，导致企业难以在不同云间迁移。借鉴PaaS经验，智能体平台需要定义可移植的契约，涵盖代码、指令、工具依赖、记忆和权限等，才能实现真正的可移植性。
开源协议与生命周期平台的差距
尽管MCP、A2A和OpenTelemetry等协议已标准化了工具访问、代理间通信和可观测性，但它们并未解决智能体的版本控制、环境提升和回滚等生命周期问题。Linux基金会虽汇聚了这些协议，但缺乏一个中立的生命周期平台来整合它们。企业评估平台时，应关注治理、打包和状态这三个关键问题，而目前尚无开源项目能完全满足，这为中立平台的出现留下了空间。
Q&A
亚马逊、微软和谷歌的企业智能体平台在架构上有哪些共同点？
三大云厂商的企业智能体平台都采用了相似的核心架构，包括运行时、记忆、工具网关、身份、可观测性和治理等组件，尽管名称略有不同。例如，亚马逊的AgentCore、微软的Foundry和谷歌的Gemini Enterprise Agent Platform都提供这些功能。
为什么说企业智能体平台缺乏统一标准会导致锁定风险？
因为每个平台都集成了身份、遥测和部署等组件，使得智能体的运行环境与特定云厂商绑定。如果企业想迁移智能体到其他云，需要重建整个组装，这类似于PaaS出现前的困境，导致企业议价能力下降。
文章如何类比PaaS演进来说明智能体平台的发展？
文章将智能体平台的演进类比为PaaS的演进：在2011-2016年间，开发者需要手动组装虚拟机、负载均衡器等组件，而Cloud Foundry和Heroku通过应用契约统一了这些组件，使开发者专注于应用而非基础设施。智能体生态目前也处于类似阶段，但缺乏统一的契约。
企业智能体平台需要定义哪些可移植契约？
可移植契约应涵盖运行时、记忆、工具网关、身份、可观测性和治理等组件，并确保代码、指令、工具依赖、记忆契约、权限和评估套件作为一个整体可版本化、可测试、可移动。
开源项目在智能体生命周期管理方面存在哪些不足？
开源项目尚未解决治理、打包和状态问题。例如，MCP、A2A和OpenTelemetry等协议标准化了工具访问、代理间通信和可观测性，但缺乏对智能体版本控制、环境提升和回滚的支持，也没有提供跨云的可移植打包和可导出的状态存储。
企业评估智能体平台时应关注哪三个关键问题？
企业应关注三个问题：治理（项目是否由中立基金会控制）、打包（同一智能体工件能否在不同云上运行而无需重写）和状态（记忆能否存储在企业可导出的位置）。目前没有开源项目能同时满足这三点。
为什么说智能体不是简单的“带模型的Web应用”？
因为智能体行为是概率性的，相同输入可能产生不同工具调用；智能体以委托的用户权限行动，权限错误可能导致现实世界影响；智能体的依赖（如模型更新或工具描述变化）可能改变其行为，而无需代码部署。这些特性要求平台支持可丢弃的执行工作器和持久、可检查、可移植的状态。
文章提到的“云无关的智能体生命周期平台”有什么意义？
这样的平台可以恢复企业的议价能力，使企业能够在不被特定云厂商锁定的情况下部署和管理智能体。它基于Linux基金会已有的协议（如MCP、A2A）构建，提供统一的治理、打包和状态管理，从而促进生态系统的增长。
