亚马逊、微软和谷歌在企业智能体架构上趋于一致
内容提要
三大云厂商（亚马逊、微软、谷歌）均推出企业级智能体平台，核心架构趋同，但缺乏统一标准，导致智能体难以跨云迁移。文章类比PaaS发展，指出智能体平台需类似Cloud Foundry的开放契约，涵盖运行时、记忆、工具网关等组件，并强调治理、打包和状态可移植性。目前开源项目尚未解决此问题，未来中立平台或成关键。
延伸解读
架构趋同背后的锁定风险
三大云厂商的智能体平台在组件上高度一致，但身份、遥测和部署都绑定在单一云内，导致智能体难以跨云迁移。文章指出，这种垂直整合是厂商的理性选择，因为集成是利润所在，但后果由客户承担。企业在选型时需警惕被单一云锁定，应优先考虑可移植性。
智能体平台需要PaaS式契约
文章类比PaaS发展，指出智能体平台缺乏类似Cloud Foundry的开放契约。Cloud Foundry通过应用契约实现了可移植性，而当前智能体平台在运行时、记忆、工具网关等组件上各自为政，缺乏统一标准。未来需要中立平台定义智能体生命周期管理，才能让企业摆脱云厂商的束缚。
智能体与Web应用的本质差异
智能体行为具有概率性，相同输入可能产生不同工具调用；其权限错误可能造成真实世界影响；模型更新或工具描述变化会改变行为。因此，智能体平台需要可丢弃的执行工作器和持久、可检查、可移植的状态。文章强调，不能简单将智能体视为带模型的Web应用，否则在生产中会失败。
开源协议与生命周期平台的差距
MCP、A2A、OpenTelemetry等协议已存在，但协议不等于生命周期平台。Linux基金会下的Agentic AI Foundation虽汇聚了MCP、goose、AGENTS.md等项目，但未解决智能体版本控制、环境提升和回滚等问题。企业评估平台时，应关注治理、打包和状态可移植性，目前尚无开源项目能同时满足这三点。
Q&A
亚马逊、微软和谷歌的企业智能体平台在架构上有哪些共同点？
三大云厂商的企业智能体平台都采用了相似的核心架构，包括运行时、内存、工具网关、身份、可观测性和治理等组件，尽管名称可能不同。例如，亚马逊的AgentCore、微软的Foundry Agent Service和谷歌的Gemini Enterprise Agent Platform都提供这些基础组件。
为什么说企业智能体目前难以跨云迁移？
因为智能体的会话状态、追踪日志和身份都绑定在单一云提供商的托管服务中，缺乏统一的开放契约。如果企业想将智能体从一个云迁移到另一个云，需要重建整个组装，就像PaaS出现之前应用部署的困境。
Cloud Foundry和Heroku在PaaS发展中的作用是什么？它们对智能体平台有何启示？
Cloud Foundry和Heroku通过定义应用契约，将虚拟机、负载均衡器、消息队列等底层资源统一起来，使开发者可以专注于应用而非基础设施。它们证明了开放契约和可移植性的价值，为智能体平台提供了借鉴：智能体平台也需要类似Cloud Foundry的开放契约，涵盖运行时、记忆、工具网关等组件，以实现可移植性。
智能体平台与传统的Web应用平台相比，有哪些关键差异？
智能体行为是概率性的，相同输入可能产生不同工具调用；智能体以委托的用户权限行动，权限错误可能导致真实世界副作用；智能体的依赖（如模型更新或工具描述变化）可能改变其行为，而无需代码部署。因此，智能体平台需要可丢弃的执行工作节点和持久、可检查、可移植的智能体状态。
目前有哪些开源项目或标准在推动智能体互操作性？它们是否解决了智能体生命周期管理问题？
目前有MCP（模型上下文协议）标准化工具访问，A2A（代理间通信）用于智能体间发现和通信，OpenTelemetry正在定义GenAI约定，OCI镜像作为打包方案。Linux基金会也成立了Agentic AI Foundation，但协议不等于生命周期平台，它们没有解决智能体的版本控制、环境提升和回滚等问题。
企业在评估智能体平台时，应该关注哪三个关键问题？
企业应关注三个问题：治理（项目是否由中立基金会控制）、打包（同一智能体工件能否在不同云上运行而无需重写）、状态（记忆能否导出）。目前没有开源项目能同时满足这三个条件。
为什么说智能体平台的控制平面定义权很重要？
因为控制平面的定义者不仅决定部署方式，还定义了智能体的本质、包含哪些组件以及平台团队可以替换哪些部分。这类似于Kubernetes定义了pod、deployment和service等抽象，影响了整个行业对运行软件的看法。
