企业将AI代理从实验推向生产的浪潮中，一个核心问题日益凸显：我们该如何管理它们？Google和亚马逊AWS给出了截然不同的答案，揭示了AI技术栈正在发生的深刻分裂——Google选择在系统层进行代理管理，而AWS则将控制权设置在执行层。

两大阵营的最新动作

Google发布了新版Gemini Enterprise，将其企业AI代理产品——Gemini Enterprise Platform和Gemini Enterprise Application——统一到一个框架下。公司实际上将Vertex AI重新品牌为Gemini Enterprise Platform，虽然强调除了名称变更和新功能外，它在根本上仍是同一界面。

Google的高级产品总监Maryam Gholami表示：“我们希望为公司提供一个平台和入口，让他们能够访问Google提供的所有AI系统和工具。Gemini Enterprise Application构建在Gemini Enterprise Agent Platform之上，安全和治理工具都作为Gemini Enterprise Application订阅的一部分免费提供。”

与此同时，AWS为Bedrock AgentCore添加了新的托管代理引擎。AWS在新闻稿中表示，该引擎“用基于配置的起点取代了前期构建，由Strands Agents（AWS的开源代理框架）提供支持”。用户定义代理的功能、使用的模型和调用的工具，AgentCore负责将所有内容整合在一起运行。

状态漂移：AI代理的新故障模式

从短时任务到长时间运行的自主代理的转变，迫使业界重新思考AI系统的行为方式。随着代理持续运行，它们会积累状态——记忆、响应和不断演变的上下文。随着时间推移，这些状态会变得过时。数据源发生变化，工具可能返回相互矛盾的响应，但代理却越来越容易受到不一致性的影响，变得不那么可靠。

代理的可靠性变成了一个系统性问题，管理这种漂移可能需要的不仅仅是更快的执行速度——它可能需要可见性和控制力。这也正是Gemini Enterprise和AgentCore等平台试图解决的核心痛点。

速度优先 vs 治理优先

AWS以及在某种程度上Anthropic和OpenAI的方法优化的是更快的部署速度。Claude Managed Agents抽象了大量启动代理的后端工作，Agents SDK现在包含沙箱支持和现成的引擎。这些方法旨在降低代理上线的门槛。

Google则提供了集中式控制面板来管理身份、执行策略和监控长时间运行的行为。这种方法借鉴了Kubernetes风格的控制平面理念，将代理视为需要编排、监控和治理的“工作负载”。

正如一位行业观察者所指出的：“代理引擎与运行时的问题常被视为自建与购买之争，但本质上是一个风险管理问题。如果你的代理不影响核心收入流，使用第三方运行时是可以接受的。但对于更关键的业务流程，自建和控制将是唯一选择。”

AI技术栈的分层演化

日益清晰的是，AI技术栈正在分离成不同的层次，各自解决不同的问题。AWS以及在某种程度上Anthropic和OpenAI优化的是快速部署，让团队能够实验并发现代理的能力边界。Google则提供集中式控制，增加了一层信任保障。

企业很可能两者都需要。快速迭代让团队能够实验和发现代理的潜力，而集中式控制则增加了信任层。企业需要确保自己不会被锁定在纯粹为单一代理执行方式设计的系统中。

未来的走向

这场架构之争远未尘埃落定。随着AI代理从短暂的实验性任务助手演变为工作流中长期运行的实体，管理复杂性只会继续增加。无论最终哪种架构胜出，有一点是确定的：AI代理的管理已经从“可有可无”变成了“必不可少”。

对于企业技术决策者而言，当前最重要的考量不是选择哪家供应商，而是明确自身的风险承受能力、治理需求和长期技术路线图。在这个快速演进的领域，保持架构的灵活性和可迁移性可能比押注任何单一平台都更为明智。