企业级智能体平台：Google Vertex AI 与 AWS Bedrock 的架构与战略对比分析，以及构建通用 OpenAI 兼容 API 网关的技术指南

构建通用 OpenAI 兼容 API 网关的技术指南

第一部分：智能体人工智能格局的战略分析

范式转变：从生成式人工智能到智能体系统

大型语言模型 (LLM) 的出现催化了企业计算的根本性变革，将重点从数据处理转移到信息合成和内容生成。¹ 然而，尽管生成式人工智能应用的初始浪潮功能强大，但大多局限于被动的请求-响应模式。下一个进化飞跃是向智能体系统过渡——这些自主应用利用 LLM 的推理能力，主动追求目标、协调复杂任务并与环境交互。² 本报告对构建此类系统的两大领先企业平台——谷歌云的 Vertex AI Agent Builder 和亚马逊云服务 (AWS) 的 Bedrock Agents——进行了权威的架构和战略分析。

人工智能代理与简单的聊天机器人或生成式人工智能助手截然不同。聊天机器人遵循预定义的脚本或决策树，助手则响应用户的直接提示，而代理则拥有更高的自主性和能力。代理系统的核心特征包括：理解高层次目标、将其分解为一系列可执行步骤（规划）、通过与外部工具和数据源交互来执行这些步骤（工具使用），以及在长时间交互过程中保持上下文信息（记忆）。³ 这些系统旨在超越简单的回答问题，实现诸如规划行程、管理库存或自动化财务报告等目标。⁵

这种从被动响应模式向主动响应模式的转变代表了一种新的计算范式，而不仅仅是功能上的渐进式增强。它要求我们重新评估业务流程的设计和自动化方式。企业现在无需编写显式、僵化的工作流程，而是可以将复杂的多步骤目标委托给人工智能代理，这些代理能够跨不同的企业系统进行推理、适应和执行任务。⁶ 因此，成功实施智能体人工智能不仅是一项技术挑战，更是一项战略挑战，需要对支持这些功能的底层平台有深刻的理解。选择智能体平台是一项至关重要的长期决策，它将影响企业未来几年的创新和自动化能力。

两种理念的碰撞：谷歌的开放生态系统 vs. AWS 的集成市场

从最高层面来看，谷歌云和AWS代表了企业智能体AI未来发展的两种截然不同的理念。谷歌倡导开放、可互操作的生态系统，将Vertex AI定位为一个中心枢纽，能够协调各种智能体，而无需考虑其底层框架或供应商。相比之下，AWS则利用其在云市场的主导地位，提供深度集成的“封闭式”体验，使Bedrock成为其庞大现有客户群最便捷、最熟悉的选择。

谷歌的战略很大程度上基于推广开放标准，旨在构建一个异构的、多厂商的智能体生态系统。Agent2Agent (A2A) 协议的引入，被誉为“通用通信标准”，是这一战略的基石。⁸ 在超过 50 家合作伙伴的不断壮大的联盟支持下，A2A 被设计成一个用于智能体间通信的 API 层，使使用不同框架（例如谷歌自家的智能体开发工具包、LangGraph 或 Crew.ai）构建的智能体能够发现彼此的功能并协商交互。⁸ 这一愿景也延伸至数据和工具的连接，通过模型上下文协议 (MCP) 实现，该协议旨在标准化智能体访问企业系统的方式。⁸ 这使得谷歌不仅成为平台提供商，更成为潜在“智能体网络”的架构师，其价值源于网络效应和互操作性。

相反，AWS 针对 Bedrock Agents 的策略是将其深度原生集成到其庞大的云服务生态系统中。Bedrock 被定位为典型的“模型商城”，提供统一的 API 来访问来自亚马逊和领先第三方提供商的精选基础模型。⁹ 扩展代理功能的主要机制是通过“操作组”，而操作组通常使用 AWS Lambda 函数来实现。¹² 这种方法巧妙地利用了数百万 AWS 开发人员的现有技能，他们已经精通无服务器范式。通过将代理开发作为熟悉的基于 Lambda 的工作流程的自然延伸，AWS 显著降低了准入门槛，并促进了其生态系统内的快速采用。¹⁵

归根结底，选择这两个平台是对未来发展趋势的战略押注。选择谷歌意味着押注于一个开放互联的未来，在这个未来中，能够协调来自多个供应商的各种最佳代理程序将带来竞争优势。而选择AWS则意味着押注于一个未来，在这个未来中，深度集成的单一供应商堆栈所提供的性能、安全性和开发速度将超过开放互操作性带来的优势。

第二部分：深度解析：Google Cloud Vertex AI Agent Builder

平台架构：代理构建器、ADK 和代理引擎的三重组合

Google Cloud 的智能体 AI 解决方案是一个全面的多层平台，旨在支持智能体开发的整个生命周期，从无代码原型设计到高度可控的生产级部署。该架构由三个相互关联的主要组件构成：Vertex AI Agent Builder、Agent Development Kit (ADK) 和 Vertex AI Agent Engine。

• Vertex AI Agent Builder： 这是一套涵盖整个代理开发体验的综合工具和服务。⁷ 它作为创建、构建和编排生成式 AI 应用的中央控制台和管理平台。它将 Google 的基础模型（例如 Gemini）、用于数据构建的 Vertex AI Search 以及对话式 AI 技术（最初基于 Dialogflow）集成到一个统一的平台中。⁷ Agent Builder 旨在满足各种开发人员的专业水平，既提供无代码界面，也提供通往代码优先框架的途径。⁷

• Agent Development Kit (ADK)： ADK 是 Google 的代码优先的开源 Python 框架，用于构建复杂的单代理和多代理系统。⁸ 它旨在为开发人员提供对代理的思考、推理和协作方式的精确、细粒度控制。关键特性包括确定性防护机制、细粒度的编排控制，以及诸如双向音频和视频流等独特功能，以实现更人性化的交互。⁸ 该框架旨在提高效率，其目标是使用不到 100 行直观的 Python 代码构建可用于生产环境的代理。⁸ ADK 还拥抱更广泛的开源社区，明确支持集成和使用 LangChain、LangGraph 和 Crew.ai 等流行框架。⁸

• Vertex AI Agent Engine： 原名 Vertex AI Reasoning Engine，这是一个完全托管的无服务器运行时环境，旨在部署、管理和扩展生产环境中的 AI 代理。⁸ Agent Engine 抽象了基础设施管理的复杂性，使开发人员能够专注于代理功能，而不是运维开销。⁸ 它是一组模块化的服务，可以单独使用或组合使用，包括具有端到端管理的安全运行时、集成的质量和评估服务、用于对话上下文的持久内存库以及安全的代码执行沙箱。² 它与框架无关，能够部署使用 ADK、LangChain 或任何其他兼容框架构建的代理。8

这三个组件共同构成了一个完整的生态系统。开发人员可能会在代理构建器的“代理花园”中发现一个有用的工具，使用 ADK 为利用该工具的新代理编写核心逻辑，然后将该代理部署到代理引擎，以大规模地处理生产流量。¹⁷

开发者光谱：从无代码控制台到高代码框架

Vertex AI平台的一项关键优势在于其能够满足各种技术水平的开发者的需求，从没有编码经验的业务分析师到需要深度控制智能体行为的资深AI工程师，都能轻松上手。这得益于其结合了低代码API、无代码控制台和高代码开源框架。

对于希望快速构建对话代理的开发者而言，Vertex AI Agent Builder 提供了一个简化的无代码控制台体验。⁷ 该界面基于 Google Dialogflow 的强大基础架构构建，用户只需点击几下即可创建新代理。⁵ 一个实用的代码实验室教程演示了如何构建“旅行伙伴”代理，只需提供显示名称、定义目标，并通过内置模拟器与其交互即可。⁵ 这种无代码路径对于创建主要专注于信息检索和对话流程的客户、员工和知识代理尤为强大。¹⁹ 用户可以通过附加数据存储（例如来自 Cloud Storage 的文档）轻松地为这些代理提供知识库，从而为其提供知识库。⁵ 这种方法使 AI 代理的创建更加普及，能够快速构建原型并部署针对常见用例（例如 FAQ 机器人和订单管理系统）的解决方案。¹⁹

对于需要更高定制化和控制权的开发者，该平台提供了一条以代理开发工具包 (ADK) 及其与开源生态系统集成为核心的“高代码”路径。⁷ ADK 专为构建复杂的多代理系统而设计，在这些系统中，对推理、协作和工具使用的精确控制至关重要。⁸ 它提供确定性的防护措施和编排控制，使开发者能够精确定义代理的行为和交互方式。⁸ 考虑到许多开发者已经投入使用现有的开源工具，Google 确保了 ADK 与更广泛的代理构建器平台具有高度互操作性。开发者可以使用 LangChain、LangGraph、AG2 或 Crew.ai 等流行框架构建代理，并仍然可以利用 Vertex AI 代理引擎进行托管部署、扩展和监控。⁸ 这种灵活性使团队能够使用最符合自身偏好和现有技术栈的工具，同时还能受益于 Google Cloud 的企业级基础设施和 MLOps 功能。⁷

编排与推理：Gemini核心与多智能体协作

任何基于 Vertex AI 构建的智能体的核心推理能力都由 Google 的基础模型之一提供支持，主要来自 Gemini 系列。² 编排层随后指导智能体的推理过程，管理多步骤工作流程，并确定何时调用外部工具来收集信息或执行操作。² 这种强大的逻辑逻辑模型 (LLM) 和灵活的编排框架的结合，使智能体能够处理需要迭代问题解决的复杂多步骤任务。

为了加速开发，Vertex AI 提供了“Agent Garden”，这是一个精选的预构建端到端代理解决方案库，适用于特定的用例，以及可以集成到自定义代理中的单个工具。17 这使得开发人员可以从一个可用的示例开始并对其进行自定义，而不是从头开始构建所有内容。

该平台最具前瞻性的编排功能在于其多代理协作方式。一些平台采用带有中央“主管”的层级模型，而谷歌则通过 Agent2Agent (A2A) 协议率先采用了一种更加去中心化的点对点模型。⁸ 该协议旨在成为代理间通信的通用标准，使基于不同框架、由不同供应商构建并在不同环境中运行的代理能够无缝交互。⁸ A2A 的功能类似于代理的 API 层；代理可以发布自身功能，并协商如何与用户和其他代理交互，无论是通过文本、表单，甚至是双向音频/视频流。⁸ 这种架构将一组孤立的代理转变为一个协作的、动态的团队。

这种将代理间通信外部化和标准化的策略意义深远。它预示着未来企业自动化将不再由单一的整体式代理负责，而是由一个分布式专业代理网络来处理，这些代理可以动态发现和组合，以解决新出现的问题。虽然这种联邦模型的设计本质上比简单的层级模型更为复杂，但它具有更大的可扩展性、弹性和创新潜力，因为它可以利用来自不同供应商的更广泛的生态系统能力。

数据接地和工具集成：连接器的世界

智能体的效能与其获取和利用相关及时数据的能力直接相关。Vertex AI Agent Builder 提供了一套丰富且多功能的智能体构建工具，可将智能体与企业数据连接起来，并将其与外部工具和 API 集成。

将智能体与组织专有知识关联起来的主要机制是检索增强生成 (RAG)。Vertex AI Search 提供了一个完全托管的、支持 AI 的搜索和关联系统，可以轻松连接到智能体。⁷ 开发人员可以从各种来源（例如 Google Cloud Storage 中的非结构化文档或网站内容）创建数据存储，并将其附加到智能体。⁵ 智能体随后可以查询此知识库，以提供基于公司自身数据的准确、上下文相关的答案，从而显著减少虚假信息并提高响应的相关性。⁷

除了 RAG 之外，Vertex AI 还提供丰富的工具集成选项，使智能体能够与实时系统交互并执行操作。这些集成途径包括：

• 原生 Google Cloud 集成： 代理可以无缝连接到其他 Google Cloud 服务。一项关键集成是与 Google 的 API 管理平台 Apigee，使代理能够安全地发现和调用 Apigee API Hub 中管理的企业 API。⁸

• 预构建企业连接器： 通过应用集成，Vertex AI 提供 100 多个预构建的连接器，可连接到常用的企业应用，使代理无需编写自定义代码即可与 Salesforce、ServiceNow 和 SAP 等系统进行交互。⁸

• 自定义 API 集成： 对于定制或第三方 API，开发人员可以使用 YAML 文件中的 OpenAPI v3.0 规范定义工具。²² 代理构建器控制台允许开发人员粘贴此 YAML 定义以创建新工具，然后代理可以调用该工具。代理的指令已更新，以引用新工具，使其能够理解何时以及如何使用 API 来满足用户请求。²³

• **生态系统协议和框架：**该平台支持模型上下文协议 (MCP)，这是一种新兴的开放标准，用于将代理连接到各种数据源和工具的生态系统。⁸它还与 LangChain 等开源框架深度集成，允许开发人员在其 Vertex AI 代理中利用 LangChain 丰富的工具库。⁷

这种多管齐下的数据和工具集成方法确保开发人员拥有灵活而强大的选项集，可以将他们的代理连接到必要的企业系统，无论是通过托管连接器、自定义 API 定义还是开源库。

样板房参观：双子座系列及宽敞的样板花园

任何智能体的性能和能力从根本上取决于支撑其推理的底层基础模型。谷歌云的 Vertex AI 通过其模型花园提供对庞大且多样化模型组合的访问，其中最引人注目的是谷歌自主研发的先进 Gemini 系列模型。

谷歌第一方模型：

旗舰产品是 Gemini 系列模型，它们原生集成并针对 Vertex AI 平台进行了优化。其中包括 24 个模型：

• **Gemini 2.5 Pro：**谷歌最先进的推理模型，专为复杂、多轮、多模态理解而设计。²⁴

• **Gemini 2.5 Flash：**一款在价格和性能之间达到最佳平衡的优化模型，适用于各种任务。²⁴

• **Gemini 2.5 Flash-Lite：**该系列中最具性价比、速度最快的模型，专为高吞吐量应用而设计。²⁵

除了语言和推理之外，谷歌还提供了一系列强大的专有模型，用于处理其他模态，包括：

• **Imagen：**一系列高级模型，可根据文本提示生成和编辑高质量、工作室级别的图像。²⁴

• **Veo：**一系列模型，可根据文本和图像输入生成高质量视频。²⁴

• **Gemma：**一系列轻量级、最先进的开源模型，基于与 Gemini 相同的研究和技术，旨在高效执行。²⁴

模型花园中的第三方和开放模型：

Vertex AI 的模型花园是一个全面的模型库，其范围远远超出谷歌的专有产品，涵盖了众多合作伙伴和开源模型。²⁵ 这使开发者能够灵活地选择最适合其特定用例的模型，并避免在模型层被供应商锁定。该模型花园包括：

• 合作伙伴模型： 通过 API 管理访问来自领先 AI 公司的模型，例如 Anthropic 的 Claude 系列（包括 Opus、Sonnet 和 Haiku）以及 Mistral AI 的模型。²⁵

• 开放模型： 大量流行的开源模型，可部署在 Vertex AI 上并提供服务。这包括 Meta 的 Llama 模型（Llama 3、3.1、3.2、3.3、4）的各种版本、Qwen2、Microsoft 的 Phi-3 以及众多用于视觉、语音和嵌入的特定任务模型。²⁵

这种双管齐下的方法——既提供深度集成、尖端的专有模型，又提供全面开放的第三方和开源替代方案——是谷歌人工智能战略的核心原则。它为企业提供了最大的选择权和灵活性，使企业能够根据自身特定需求，在性能、成本和开放性之间取得平衡。

第三部分：深度解析：AWS Bedrock Agents

平台架构：基石代理和 AgentCore 基础架构

亚马逊的智能体人工智能解决方案围绕两大核心支柱构建：Amazon Bedrock Agents，一项用于构建和编排智能体的全托管服务；以及 Amazon Bedrock AgentCore，一套用于在企业级规模上部署和运行任何智能体应用程序的基础服务。这种架构旨在提供精简高效的高级构建体验，以及强大且与框架无关的运维基础架构。

• Amazon Bedrock Agents： 这是一项主要的、完全托管的服务，使开发人员能够构建可执行多步骤任务的生成式 AI 应用程序。⁶ 开发过程的核心是为代理提供一组定义其用途和角色的自然语言指令，通过“知识库”将其连接到企业数据，并通过“动作组”为其配备工具。⁶ 该服务利用所选基础模型的推理能力来解释用户请求，将其分解为一系列逻辑步骤，并协调使用其配置的工具和知识库来完成请求。⁶

• Amazon Bedrock AgentCore： AgentCore 被誉为加速代理从原型到生产的综合解决方案，它是一套模块化的基础服务，可以组合使用，也可以独立使用。²⁸ 至关重要的是，AgentCore 的设计与框架和模型无关，支持使用 CrewAI 和 LangGraph 等开源框架构建的代理，以及来自 Bedrock 内外的模型。²⁸ 这使得 AgentCore 成为…… AWS 上企业级智能 AI 的底层运营层。其主要组件包括 28 个：

• 运行时： 一个安全、无服务器的基础架构，用于部署和扩展动态代理工作负载，具有完整的会话隔离功能，并支持长达 8 小时的异步任务。

• 网关： 一项服务，可将现有 API 转换为代理就绪的工具，且只需编写少量代码。

• 内存： 一项托管服务，用于管理短期和长期内存，以在交互过程中维护对话上下文。

• 身份： 一项安全的身份和访问管理服务，供代理访问 AWS 资源和第三方工具。

• 可观测性： 一项全面的监控解决方案，可提供代理行为的运行可见性，并与 OpenTelemetry 兼容。

这种双架构使 AWS 能够满足不同的需求。开发人员可以使用托管的 Bedrock Agents 服务，获得快速、集成化的开发体验。同时，使用开源工具构建更复杂或定制化代理系统的企业可以利用 AgentCore 的各项服务，以安全、企业级的方式应对部署、扩展、内存管理和可观测性等棘手的运维挑战。²⁸

开发者体验：Lambda 函数作为行动引擎

在 AWS Bedrock 上创建功能强大的代理的开发者体验，旨在自然地扩展现有的 AWS 无服务器开发模式。AWS 没有要求开发者从头开始学习新的、特定于代理的框架，而是将代理操作的实现集中在 AWS Lambda 上，这项服务对于其生态系统中的数百万开发者来说都非常熟悉。

向基岩版代理添加功能的核心工作流程包括三个主要步骤 13：

• 定义操作： 开发人员定义代理可以执行的任务。这些任务被组织成“操作组”，每个操作组包含相关的功能。³²

• 指定 API： 对于每个操作组，开发人员提供一个 OpenAPI 模式（JSON 或 YAML 格式）。该模式充当契约，描述了 API 端点、参数以及对代理底层基础模型的预期响应。这使得模型能够推断何时以及如何调用函数来完成用户的请求。¹³

• 在 Lambda 中实现逻辑： 操作的实际业务逻辑以代码形式编写在 AWS Lambda 函数中。¹² 当代理决定调用某个工具时，它会触发此 Lambda 函数，并传递 OpenAPI 模式中定义的必要参数。然后，Lambda 函数执行任务（可能涉及查询数据库、调用其他 API 或与任何其他 AWS 服务交互），并将结果返回给代理。¹³

这种以 Lambda 为中心的策略是一项强有力的战略选择。它显著降低了庞大的 AWS 现有开发者社区的入门门槛。他们可以利用自己现有的 Python 或 Node.js 等语言技能、对 Lambda 控制台和部署模式的熟悉程度，以及将 Lambda 与其他 AWS 服务集成的专业知识。教程和快速入门指南都一致地演示了这种模式：在 Bedrock 控制台中创建一个代理，使用 OpenAPI 规范定义一个操作组，然后使用控制台的“快速创建”功能生成一个存根 Lambda 函数，开发者随后用自己的自定义代码填充该函数。¹²

通过将成熟的无服务器工作流作为代理操作的“引擎”，AWS 为其客户构建代理应用程序提供了一条务实高效的途径。这种做法优先考虑在现有 AWS 生态系统中快速采用和集成，而不是引入一种全新的、可能具有颠覆性的开发框架。

编排与推理：主管代理和 ReAct 框架

在 Amazon Bedrock Agents 中，编排是指系统解释用户请求并协调使用其可用工具和知识库以生成最终响应的过程。此过程由所选基础模型 (FM) 的推理能力驱动，该模型充当代理的“大脑”。⁶

当用户与 Bedrock Agent 交互时，功能模块 (FM) 会分析提示和 Agent 的指令。然后，它会制定一个计划，将复杂的任务分解成一系列逻辑步骤。⁶ 默认情况下，Bedrock Agent 采用一种称为 ReAct（Reason and Action，推理与行动）的编排策略。³³ 在此框架中，Agent 会迭代执行一个“思考-行动-观察”循环。它首先……

智能体首先对当前状态及其下一步需要执行的操作进行推理，然后执行相应的操作（例如调用工具或查询知识库），最后观察该操作的结果。这一观察结果会为下一轮推理提供信息，从而使智能体能够逐步找到解决方案。³³ 开发人员可以使用跟踪信息查看逐步推理过程，以便了解和调试智能体的行为。³⁴

对于需要多个专业代理协调的更复杂的工作流程，Bedrock 支持分层多代理协作模型⁶。在这种模式下，“主管代理”负责监督整个流程。主管代理接收初始用户请求，将其分解为子任务，并将每个子任务委派给相应的专业代理。这种模块化设计使得每个代理都可以是特定领域的专家（例如，“数据库分析代理”和“临床证据研究代理”），从而确保复杂业务流程的精确性和可靠性⁶。

虽然 ReAct 是默认方案，但 AWS 为开发人员提供了对编排逻辑的强大控制权。为了实现更精细的控制，开发人员可以使用高级提示模板来自定义 Bedrock 在 ReAct 流程的每个阶段（预处理、编排和后处理）使用的提示。³⁶ 为了获得最终的控制权，开发人员可以完全绕过内置的编排，并在 Lambda 函数中实现自己的自定义编排逻辑。这使他们能够完全掌控代理如何做出决策、何时调用工具以及如何生成最终响应，从而实现高度专业化或专有的编排策略。³³

数据基础架构和工具集成：知识库和原生 AWS 服务

将代理连接到可靠的数据源和功能工具对于构建企业级应用程序至关重要。Amazon Bedrock 为此提供了两种主要机制：用于托管检索增强生成 (RAG) 的知识库，以及通过操作组与更广泛的 AWS 服务生态系统进行深度原生集成。

RAG知识库：

Amazon Bedrock 的知识库是一项完全托管的功能，可简化 RAG 应用程序的构建过程。³⁸ 它允许开发人员安全地将基础模型连接到公司内部数据源，从而使用相关、最新的信息增强模型的响应，并降低出现错误信息的可能性。⁶ 该过程包括将知识库指向数据源（通常是 Amazon S3 中的位置），并选择嵌入模型（例如 Amazon Titan Embeddings）。¹⁴ 然后，Bedrock 会处理整个数据摄取管道：它会自动将源文档拆分成块，将其转换为向量嵌入，并将其存储在向量数据库中。³⁸ 配置完成后，可以将代理与一个或多个知识库关联。当用户提出问题时，代理可以自动查询相关的知识库以检索上下文并生成基于事实的准确响应。³² 对于更高级的用例，开发人员可以使用操作组以编程方式调用知识库。

检索或检索和生成 API，允许自定义检索逻辑，例如基于元数据进行过滤。40

原生 AWS 服务集成：

Bedrock Agents 的最大优势在于其与庞大的 AWS 服务生态系统的无缝集成。由于代理工具的核心逻辑是在 AWS Lambda 函数中实现的，因此代理可以与 Lambda 函数能够调用的几乎任何其他 AWS 服务或外部 API 进行交互。¹⁴ 详细的架构示例展示了代理如何协调跨多个服务的工作流：从 Amazon DynamoDB 获取数据、检查 Amazon S3 中的文件、将密钥存储在 AWS Secrets Manager 中，以及通过 Amazon Simple Email Service (SES) 发送通知。¹⁴ 这种原生集成对于已投资于 AWS 生态系统的企业而言是一项重要的加速器。它使他们能够轻松地将现有的云基础设施和业务逻辑“代理化”，从而将静态数据存储和服务转换为自动化智能系统的动态组件。

模特资源：精选“模特商城”

Amazon Bedrock 的基础模型访问策略是充当“模型商城”或统一门户，提供来自亚马逊和领先的第三方人工智能公司的各种精选高性能模型。⁹ 这种方法为企业提供了灵活性和选择权，使他们能够根据性能、成本和其他特性为特定任务选择最佳模型，同时通过单一且一致的 AWS API 进行交互。¹⁵ 这简化了采购、安全和集成，因为开发人员无需为每个模型提供商管理单独的合同或 API 集成。¹⁶

亚马逊自营机型：

AWS 提供自己的一系列基础架构模型，这些模型与 Bedrock 服务深度集成：

• 亚马逊 Titan： 这是亚马逊的旗舰机型系列，其中包括 42 款：

• Titan 文本模型（例如 Express、Lite、Premier）：一系列文本生成模型，专为摘要、文案撰写和开放式问答等各种任务而设计。

• Titan 图像生成器：一种根据文本提示创建图像的模型。

• Titan 嵌入模型（文本和多模态）：旨在将文本和图像转换为数值表示的模型，用于语义搜索和推荐等任务。

• Amazon Nova： 一个较新的模型系列，包括 Nova Pro，它定位为高性能多模态模型。⁴²

第三方供应商模式：

Bedrock 的一项关键价值主张是其丰富的模型库，这些模型来自其他领先的 AI 公司。这使得客户无需离开安全的 AWS 环境即可访问最先进的模型。Bedrock 上提供的第三方提供商及其旗舰模型包括 42 个：

• **Anthropic：**完整的Claude模型套件，包括功能强大的Claude 3系列（Opus、Sonnet、Haiku）以及更新的Claude 3.5模型。

• **AI21 Labs：**用于多语言文本生成的Jurassic-2系列（Ultra、Mid）以及更新的Jamba模型。

• **Cohere：**用于文本生成和聊天功能的Command模型，以及用于多语言语义搜索的Embed模型。

• **Meta：**Llama系列开源模型，包括Llama 3以及更新的Llama 3.1和3.2版本。

• **Mistral AI：**一系列热门模型，包括Mistral Large、Mistral Small和Mixtral 8x7B。

• **Stability AI：**用于高保真图像生成的Stable Diffusion系列模型（包括SDXL 1.0和SD3）。

• 其他提供商： Bedrock 还包含来自 DeepSeek、Luma AI、OpenAI、TwelveLabs 和 Writer AI 等提供商的模型。42

这种精心策划的多供应商方案使企业能够确保其人工智能战略面向未来。随着更新、更强大的模型不断涌现，企业可以通过 Bedrock API 轻松评估和集成这些模型，而无需对现有应用程序进行重大架构重构。²⁹

第四部分：直接对比和决策框架

核心能力对比分析

在 Google Vertex AI Agent Builder 和 AWS Bedrock Agents 之间做出选择，需要在不同的架构理念、开发者体验和生态系统策略之间进行权衡。虽然这两个平台都提供了一套用于构建企业级 AI 代理的全面工具，但它们在编排、工具集成和多代理协作等关键方面的做法却截然不同。下表对它们的核心功能进行了战略性的并排比较，以阐明这些差异并为决策过程提供参考。

功能/特性 Google Vertex AI Agent Builder AWS Bedrock Agents 核心理念 开放生态系统与互操作性： 专注于开放标准（A2A、MCP），以创建一个联合的多供应商代理网络。8 集成市场与 AWS 原生体验： 利用 AWS 服务的深度集成，为现有客户提供无缝体验。14 主要抽象 代理开发工具包 (ADK)： 一个代码优先的开源 Python 框架，用于精确控制代理的推理和行为。8 动作组（Lambda 函数）： 通过以无服务器 Lambda 函数形式实现的 OpenAPI 模式定义代理功能，扩展了熟悉的开发范式。12 运行时环境 Vertex AI Agent Engine： 一个完全托管的无服务器运行时，用于部署和扩展使用 ADK 或其他开源框架构建的代理。8 Amazon Bedrock AgentCore： 一套基础服务（运行时、内存、可观测性），用于运行任何代理应用程序规模.28多智能体模型点对点（通过 A2A 协议）：一种去中心化模型，其中不同的智能体发现并协商交互，从而实现协作网络。8层级式（主管智能体）：一种集中式模型，其中主管智能体分解任务并将其委派给专门的下级智能体。6数据接地（RAG）顶点 AI 搜索：一个完全托管的、支持 AI 的搜索平台，作为智能体的主要接地系统。7Amazon Bedrock 知识库：一项完全托管的 RAG 服务，可自动执行从 S3 数据源的数据摄取和向量化管道。6API/工具集成Apigee 和连接器：与 Apigee 集成以进行企业级 API 管理，并通过应用程序集成提供 100 多个预构建连接器。8API 网关和 Lambda 集成：主要依赖 Lambda 函数与任何 AWS 服务或外部 API 集成，通常由 Amazon API 网关作为前端。14开源一致性深度集成：强大的，对使用 LangChain、LangGraph 和 Crew.ai 等框架进行构建提供一流的支持，这些框架可以部署在 Agent Engine 上。8框架无关运行时： AgentCore 旨在部署和运行使用任何框架构建的代理，但原生 Bedrock Agents 服务与特定操作系统库的关联性较低。28安全模型****GCP IAM 和 VPC 服务控制： 利用 Google Cloud 成熟的安全机制进行访问控制并创建安全的网络边界。21AWS IAM 和 VPC 端点： 利用全面的 AWS 身份和访问管理框架以及 VPC 端点实现安全、私密的连接。14

基础模式访问：两个目录的故事

选择基础模型是构建人工智能代理时最关键的决策之一，因为它直接影响推理质量、性能、成本和专业能力。Vertex AI 和 Bedrock 都提供丰富的模型选择，但它们的模型库构成和战略重点却截然不同。Vertex AI 的优势在于其先进且深度集成的专有模型（Gemini）以及庞大的第三方和开源模型库。Bedrock 的独特之处在于其独家提供某些热门第三方模型（尤其是完整的 Anthropic Claude 系列模型）以及精心挑选的“最佳”模型库。

模型提供商 模型系列/名称 Vertex AI 可用 Bedrock 可用 备注 Google Gemini（2.5 Pro、2.5 Flash 等） 是 否 旗舰级专有模型，与 Vertex AI 工具深度集成。 24 Imagen、Veo、Gemma 是 否 用于图像、视频和开放式轻量级应用程序的先进模型。 24 Amazon Titan（文本、图像、嵌入） 否 是 Amazon 用于通用任务的专有模型系列。 42 Nova（Pro 等） 否 是 Amazon 较新的高性能多模态模型系列。 42 Anthropic Claude（3、3.5、Opus、Sonnet、Haiku） 是（部分模型） 是（全系列） Bedrock 提供对备受追捧的 Claude 模型系列最全面、最新的访问权限。 25 Meta Llama（3、3.1、3.2、4） 是（广泛）是（选择模型）两个平台都提供流行的 Llama 模型；Vertex AI 的模型花园通常拥有更丰富的开源方案。25Mistral AIMistral Large、Small、Mixtral是是由于需求量大，在两个平台上都广泛可用。25CohereCommand、Embed否是Bedrock 的重要合作伙伴，为企业用例提供强大的模型。42AI21 LabsJurassic、Jamba否是Bedrock 平台的另一个基础合作伙伴。11Stability AIStable Diffusion（SDXL、SD3）是（方案）是（托管）Bedrock 提供托管端点；Vertex AI 提供开源部署方案。25其他开放模型Phi-3、Qwen2 等是（广泛）是（市场）Vertex AI 的模型花园为各种开放模型提供更广泛、更集成的体验。25

评估与监控：从原型到量产

确保人工智能代理的质量、可靠性和性能是 MLOps 面临的一项关键挑战。谷歌和 AWS 都在快速提升这方面的能力，但它们采取的理念截然不同。谷歌正在构建一个紧密集成、平台原生的评估套件，其中包含专门用于评估代理行为的指标。相比之下，AWS 则强调一种开放的、基于标准的可观测性方法，旨在与更广泛的企业监控工具生态系统集成。

Google Vertex AI：

Vertex AI 平台上的智能体评估以 Gen AI 评估服务为核心。⁴⁸ 该服务旨在评估智能体的整个决策过程，而不仅仅是其最终输出。它引入了一系列“轨迹评估指标”，用于分析智能体为找到解决方案而采取的一系列行动。这些指标包括⁴⁸：

• **完全匹配、顺序匹配和任意顺序匹配：**用于评估智能体是否按正确的顺序执行了正确的操作。

• **精确率和召回率：**用于衡量智能体操作相对于参考解决方案的准确性和完整性。

• **单工具使用：**用于验证特定关键工具是否被正确使用。

评估任务在 Vertex AI Experiments 中作为运行进行跟踪，提供了一种集中且可复现的方法来比较代理、模型或提示的不同版本。⁴⁸ 对于生产监控，Vertex AI Agent Engine 与以下系统原生集成：

Google Cloud Monitoring。它会自动收集并可视化内置指标，例如请求计数和延迟。开发者还可以创建自定义的、基于日志的指标，或通过 API 或 PromQL 以编程方式查询性能数据，从而进行更高级的分析和告警。⁵⁰

AWS Bedrock：

AWS 的方法更加模块化，也更注重生态系统。为了在开发过程中调试和理解代理的行为，AWS 提供了跟踪信息，使开发人员能够在编排的每个阶段检查代理的逐步推理过程。³⁴ 对于正式评估，重点在于使用开源框架和方法。AWS 提供了关于如何使用诸如 之类的框架的示例和指南。

RAGA 和诸如 LLM 作为评判员 之类的技术可用于评估智能体在 RAG 和文本到 SQL 等任务上的表现，衡量忠实度、答案相关性和上下文回忆等指标。35

对于生产监控，战略解决方案是Amazon Bedrock AgentCore Observability。²⁸ 该服务旨在为任何代理应用程序提供全面的端到端可追溯性，无论该应用程序托管在 AgentCore Runtime 上还是客户自己的基础架构上。该服务的一个关键特性是其标准化。

OpenTelemetry 是一个开源的可观测性框架。52 这确保了代理生成的遥测数据（跟踪、指标、日志）与各种现有的企业监控工具兼容，包括 Amazon CloudWatch 和 Datadog 等第三方解决方案。52 这种开放的方法允许组织将代理监控集成到其现有的统一可观测性仪表板中。

这种差异反映了各个平台更广泛的理念。谷歌在其自身生态系统中提供了一套功能强大、专用且深度集成的套件，用于评估代理质量。而AWS则提供了一个灵活的、基于开放标准的可观测性解决方案，旨在接入客户现有的、可能包含多个供应商的监控堆栈。

定价模型和总拥有成本 (TCO)

分析代理平台的定价十分复杂，因为总成本是由多种底层服务构成，而非像“代理编排”那样仅包含一项费用。虽然两个平台都采用按需付费模式，但具体组成部分和定价指标有所不同。

Vertex AI Agent Builder 定价：

在 Vertex AI 上运行代理的成本是其所使用服务成本的总和。Vertex AI 的定价页面显示，成本按组件细分。⁵⁴ 主要成本驱动因素包括：

• **模型使用费：**这通常是成本中占比最大的部分。对于像 Gemini 这样的生成模型，定价基于输入（提示）和输出（响应）中的字符或标记数量。例如，文本生成起价为每 1000 个字符 0.0001 美元。²⁷

• **代理引擎运行时：**虽然代理引擎运行时的具体定价尚未公布，但它是一项托管服务，费用将与执行代理逻辑和处理请求所消耗的计算资源相关。

• 相关服务：使用其他 Vertex AI 服务将产生额外费用。这包括用于 RAG 的 Vertex AI 搜索、用于使用连接器的应用程序集成以及用于托管数据存储的云存储。

Vertex AI 提供使用量有限的免费套餐，以便用户免费进行实验。¹⁹

亚马逊基岩定价代理：

同样，Bedrock Agent 的成本是其各部分成本的总和。Bedrock 的官方定价页面详细列出了模型推理的成本，但并未提供单独的 Agent 编排服务定价表。⁵⁵ 主要成本组成部分包括：

• 模型推理： Bedrock 提供多种推理定价模型，具有很大的灵活性 55:

• 按需付费： 输入和输出令牌均按令牌付费，非常适合工作负载变化较大或难以预测的情况。

• 批量处理： 针对特定型号，批量处理价格比按需付费优惠很多（例如，低 50%），适用于大型异步作业。

• 预置吞吐量： 客户按固定小时费率购买“模型单元”，通常需要签订 1 个月或 6 个月的合约。此模式专为需要保证吞吐量的大型、稳定工作负载而设计，按小时计费（例如，Claude Instant 的价格为 44 美元/小时，无需合约）。

• **动作组执行（Lambda）：**每次代理调用工具时，都会触发一个 AWS Lambda 函数。费用将包含基于调用次数和执行持续时间的标准 Lambda 定价。

• **数据处理和存储：**使用知识库进行 RAG 会产生存储在 S3 中的数据费用以及用于存储嵌入向量的向量数据库费用。

计算任一平台上的智能体应用程序的总拥有成本 (TCO) 都需要仔细分析预期工作负载。这包括估算平均用户交互次数、交互的复杂性（决定每次交互的模型调用次数和工具调用次数）、基础模型的选择以及 RAG 处理的数据量。

第五部分：技术指南：构建与 OpenAI 兼容的 API 网关

理由：模型抽象的战略必要性

尽管像 Vertex AI 和 Bedrock 这样的云平台为构建 AI 代理提供了强大而集成的环境，但基础模型格局的快速演变带来了一个重大的战略风险：供应商锁定。今天最先进的模型明天可能就会被取代，而与特定供应商 API 紧密耦合的应用程序难以且成本高昂地进行适配。构建定制的、与 OpenAI 兼容的 API 网关是一种复杂而有效的策略，可以降低这种风险，并构建面向未来、具有弹性的 AI 基础设施。

OpenAI v1/chat/completions API 已成为与基于聊天的 LLM 交互的事实行业标准。许多开发者都熟悉其结构，并且围绕它构建了一个庞大的工具和库生态系统，包括官方 SDK。⁵⁶ 通过构建一个网关，将此标准接口暴露给内部应用程序，同时将请求路由到各种后端模型提供商，企业可以实现以下几个关键战略目标：

• **模型抽象和厂商中立性：**其主要优势在于能够通过网关进行简单的配置更改，在不同的模型提供商（例如 OpenAI、Google（通过其与 OpenAI 兼容的 Gemini API 端点）、Anthropic 或任何其他提供商）之间无缝切换，而无需在每个客户端应用程序中重写代码。⁵⁸这使得组织能够始终针对特定任务使用性能最佳或最具成本效益的模型。

• **集中式治理和安全：**API 网关为所有 LLM 访问提供单一控制点。所有后端提供商的 API 密钥都可以安全地存储在网关环境中（例如，使用密钥管理服务），并且永远不会暴露给客户端应用程序或单个开发人员，从而大幅降低密钥泄露的风险。⁶⁰网关可以对所有 LLM 流量强制执行统一的安全策略、身份验证和授权。

• **统一的可观测性、成本控制和优化：**通过将所有请求路由到中心点，网关可以实现全面、标准化的日志记录和监控。这提供了一个统一的仪表盘，用于跟踪所有型号和提供商的使用情况、性能（延迟、错误率）和成本。⁶⁰ 诸如速率限制、相同请求的缓存以及智能路由（例如，将简单查询发送到更便宜的型号，将复杂查询发送到更强大的型号）等高级功能可以集中实现，以优化性能并控制支出。⁵⁹

投资通用API网关就是投资架构灵活性。它将应用层与快速变化的模型层解耦，使组织能够适应变化并进行创新，而不受单一供应商选择的限制。

架构蓝图：托管服务与自托管解决方案

实现与 OpenAI 兼容的 API 网关有多种架构模式，每种模式在成本、控制和实现复杂性方面各有优劣。具体选择哪种架构取决于组织现有的基础设施、技术专长和具体需求。

• **第三方托管式AI网关：**越来越多的供应商提供AI网关托管服务。这些平台开箱即用，提供与OpenAI兼容的端点，并处理路由、身份验证和可观测性等复杂问题。

• 示例： Vercel AI Gateway 58 和 Cloudflare AI Gateway 59

• 优点： 上市速度最快，运营成本最低，并且通常包含缓存、速率限制和统一计费等高级功能。

• 缺点： 引入了对第三方软件的依赖，自定义逻辑的灵活性可能较低，并且会将敏感数据路由到供应商的基础设施。

• 云原生 API 网关： 这种方法利用云提供商现有的 API 管理服务来构建网关。这些服务提供强大的工具，用于定义 API、管理流量、保护端点以及转换请求和响应。

• 示例： Azure API Management 60、Amazon API Gateway、Google Cloud API Gateway。

• 优点： 利用现有的云基础设施和安全集成（例如 IAM），具有高度可扩展性和可靠性，并提供强大的策略引擎用于请求转换和控制。

• 缺点： 配置可能比专用的 AI 网关服务更复杂、成本更高。需要具备特定云提供商 API 管理平台的专业知识。

• 开源自托管网关： 为了获得最大的控制权和灵活性，组织可以在自己的基础设施上部署开源网关解决方案（例如，在 Kubernetes 集群或虚拟机上）。

• 示例： BadgerHobbs/OpenAI-API-Gateway（一个轻量级的基于 NGINX 的代理）⁶¹ 和

Portkey-AI/gateway（一个功能更丰富的基于 Node.js 的解决方案）⁶³

• 优点： 完全掌控代码、基础设施和数据路径。无第三方依赖，并可根据所需逻辑进行定制。可能是规模化应用中最具成本效益的解决方案。

• 缺点： 运维负担最重，因为组织需要负责网关基础设施的部署、扩展、维护和安全。

最佳选择取决于组织的优先事项。初创公司可能为了速度而选择托管服务，而拥有成熟云运维团队的大型企业则可能选择云原生或自托管解决方案，以便更好地控制并与其现有的安全和可观测性堆栈集成。

核心实施步骤：实用指南

构建定制的、自托管的或云原生的、兼容 OpenAI 的 API 网关涉及几个关键的实施步骤。以下指南概述了创建功能齐全且安全的网关所需的核心架构组件。

• **端点设计与兼容性：**网关必须公开一个符合 OpenAI API 规范的 RESTful 端点。其中最关键的端点是 /v1/chat/completions。56 网关应接受发送到此端点的 HTTP POST 请求，请求体为符合 OpenAI ChatCompletion 请求模式的 JSON 格式。这确保任何旨在与 OpenAI 配合使用的客户端应用程序或 SDK 都只需进行少量修改即可指向网关的 URL。57

• **身份验证与密钥管理：**一个强大的双层身份验证系统对于安全性至关重要。

• **客户端到网关的身份验证：**网关应定义自己的 API 密钥集 (GATEWAY_API_KEY)。客户端应用程序必须在每次请求中，在 Authorization: Bearer <GATEWAY_API_KEY> HTTP 标头中提供这些密钥之一。网关负责验证此密钥。⁶¹

• **网关到提供商的身份验证：**网关必须安全地存储其支持的所有后端模型提供商（例如 OpenAI、Google、Anthropic）的 API 密钥。这些密钥应存储在安全的密钥存储库中，例如 AWS Secrets Manager、Google Secret Manager 或 HashiCorp Vault。它们绝不能硬编码到网关的应用程序代码中。⁶⁰

• **动态路由逻辑：**网关的核心功能是将传入请求路由到正确的后端提供商。此逻辑通常由客户端 JSON 请求体中的模型参数驱动。⁵⁸

• 网关应解析请求体以提取模型字符串（例如，“model”:“anthropic/claude-3-haiku”或“model”:“google/gemini-2.5-pro”）。

• 然后，它应使用配置映射或路由表查找相应的后端提供商的基本 URL（例如，https://api.anthropic.com/v1 或 https://generativelanguage.googleapis.com/v1beta/openai/）以及包含相应 API 密钥的密钥名称。

• 网关构建新的上游请求，并使用提供商的密钥设置正确的 Host 和 Authorization 标头。

• 请求和响应转换： 虽然现在许多提供商都提供与 OpenAI 兼容的 API 端点（例如，可以通过修改 base_url 64 使用 OpenAI Python 库直接调用 Google 的 Gemini API），但网关必须能够处理使用不同 API 架构的提供商。如果后端提供商使用原生且不兼容的 API，网关必须执行转换，将传入的 OpenAI 格式请求中的字段映射到提供商所需的格式，然后将提供商的响应转换回标准的 OpenAI ChatCompletion 格式，最后将其返回给客户端。

• 流式传输支持： 为了支持实时逐个令牌的响应，网关必须能够处理服务器发送事件 (SSE)。当客户端请求流式传输（“stream”: true）时，网关必须在接收来自后端提供商的流式响应期间保持与客户端的连接。然后，它必须将这些事件转发给客户端，并确保它们按照 OpenAI 规范正确格式化：每个事件都应该是一行，以 data: 开头，后跟一个 JSON 对象，并且流必须以最后一个 data: 结尾。58

卓越运营：安全性、性能和可观测性

将 API 网关部署到生产环境中需要注重安全性、性能和可观测性方面的卓越运营，以确保其可靠性、可扩展性和可信度。

安全：

对于处理敏感数据和 API 凭证的组件而言，安全性是首要考虑因素。

• 密钥管理： 如前所述，所有后端 API 密钥必须存储在专用的加密密钥管理服务中。网关的运行时环境应被授予 IAM 权限，以便在运行时检索这些密钥，并遵循最小权限原则。⁶²

• 网络加固： 网关应部署在安全的网络环境中，例如虚拟私有云 (VPC)。应通过防火墙或安全组控制对网关的访问；如果网关连接到同一云中的后端服务，则应使用私有端点（例如 AWS PrivateLink）以避免通过公共互联网。⁶⁰

• 身份验证和授权： 网关应强制所有客户端进行强身份验证。除了简单的 API 密钥外，它还可以与企业身份提供商 (IdP) 集成，使用 OAuth 2.0 和 OIDC 等协议来验证来自已认证用户的 JWT，从而提供更精细的访问控制。⁶²

表现：

网关是每个 LLM 请求的关键路径上的一个新组件，因此其性能至关重要。

• **可扩展性：**网关的基础设施必须能够处理预期的峰值请求量。使用自动扩展的虚拟机组或部署在 Kubernetes 等无服务器或容器编排平台上至关重要，以确保网关不会成为瓶颈。⁶⁰

• **缓存：**对于重复查询量大的用例（例如，常见的客户支持问题），实施缓存层可以显著降低延迟和成本。网关可以缓存相同提示的响应，并设置可配置的生存时间 (TTL)，直接提供缓存的响应，而无需对后端 LLM 进行冗余调用。⁵⁹

• **延迟：**网关应部署在地理位置上靠近其主要用户和后端模型端点，以最大限度地减少网络延迟。虽然模型推理时间通常是主要因素，但在交互式应用程序中，每一毫秒的网络开销都至关重要。⁶⁰

可观测性：

该网关的一个主要优势是集中式可观测性。

• **集中式日志记录：**网关应记录每个请求和响应的详细信息。这些信息应包括客户端标识符、请求的模型、输入和输出令牌计数、网关内的处理时间（openai-processing-ms）、唯一的请求 ID（x-request-id）以及最终状态码。这种结构化的日志记录提供了全面的审计跟踪，对于调试和成本分析至关重要。⁵⁶

• **监控和告警：**应使用 Prometheus 等工具或云提供商的监控服务持续监控关键性能指标 (KPI)，例如请求速率、错误率（例如 HTTP 5xx 错误）和延迟（例如 p95 和 p99）。应配置告警，以便在出现任何异常或性能下降时通知运维团队。

通过解决这些运维方面的考量，企业可以将自定义 API 网关从简单的代理转变为强大、安全且高性能的核心 AI 基础设施。

第六部分：综合分析与战略建议

决策矩阵：为您的企业选择合适的平台

在 Google Cloud Vertex AI Agent Builder 和 AWS Bedrock Agents 之间进行选择是一项重要的架构决策，会对企业的 AI 战略、开发者生态系统和运营模式产生深远的长期影响。这两个平台各有千秋，没有绝对的优劣之分；最佳选择取决于组织的具体优先级、现有技术栈以及对智能体 AI 的战略愿景。以下框架可为决策提供指导。

如果您符合以下条件，请选择 Google Cloud Vertex AI Agent Builder：

• 您的战略优先考虑开放、可互操作的生态系统。 如果您设想未来企业能够利用来自多个供应商和开源项目的多样化专业代理网络，那么谷歌对 A2A 协议等开放标准的投入使其成为更具前瞻性的选择。

• 您需要 Gemini 模型的先进推理和多模态功能。 对于那些需要突破复杂推理、编码和多模态理解界限的应用场景，直接且优化地访问最新的 Gemini 2.5 Pro 和 Flash 模型是一项极具吸引力的优势。

• 您的开发团队倾向于采用 Python 式的、代码优先的开发体验，并希望获得最大程度的控制权。 代理开发工具包 (ADK) 专为希望对代理行为、推理循环和编排进行精细控制的开发人员而设计，它提供了一个强大的框架，用于构建高度定制化和复杂的代理。

• 您计划大量利用开源智能体 AI 生态系统。 Vertex AI 对 LangChain 和 LangGraph 等框架的一流支持，使团队能够使用熟悉的工具，同时受益于受管理的企业级部署环境。

如果符合以下条件，请选择 AWS Bedrock Agents：

• 您已深度投入 AWS 生态系统。 如果您的数据、应用程序和开发人员的专业知识已围绕 AWS 构建，Bedrock Agents 可提供最无缝、最集成的途径，帮助您构建代理功能，并充分利用现有的 IAM 角色、VPC 以及 Lambda 和 S3 等服务。

• 您的开发团队精通无服务器/Lambda 范式。 以 Lambda 函数为核心执行引擎的动作组模型，可为现有 AWS 开发人员提供极快的上手速度，最大限度地降低学习难度，并加快产品上市速度。

• 您需要访问特定的高性能第三方模型。 Bedrock 的“模型商城”提供对 Anthropic (Claude) 和 Cohere 等主要提供商的全套模型的全面、托管式访问，这对于某些用例至关重要。

• 您更倾向于采用完全托管、控制台驱动的关键组件方法。 Bedrock 的知识库等服务可以抽象化设置 RAG 管道的复杂性，为将代理连接到企业数据提供简化的、托管的体验。

未来展望：企业智能体人工智能的发展轨迹

智能体人工智能领域正以前所未有的速度发展，而这些平台目前的状况仅仅是某一时刻的缩影。展望未来，谷歌和AWS的战略走向表明，它们的发展路径将继续分化。

谷歌对A2A和MCP等开放协议的重视，表明其长远愿景是成为全球异构AI代理网络的编排和通信平台。如果这一愿景得以实现，Vertex AI不仅能成为一个开发平台，还能成为一个中央清算中心或“代理操作系统”，类似于Kubernetes如何成为容器编排的标准。Vertex AI的未来发展方向很可能包括与开源社区更深入的整合、扩展A2A合作伙伴生态系统，以及引入更复杂的工具来管理去中心化的协作代理工作流程。

与此同时，AWS 很可能继续推行其深度集成和卓越运营的战略。推出与框架无关的运行时环境 AgentCore 是一项重大举措，表明 AWS 的目标是成为运行任何代理应用程序的最佳平台，无论其构建方式如何。Bedrock 的未来发展方向很可能包括：扩展其“模型库”，纳入更多提供商；在 AgentCore 中提供更多托管服务（例如高级内存和身份解决方案）；以及与其数据、分析和安全服务实现更紧密的集成。这将进一步巩固其作为现有企业客户最便捷、最安全、最具可扩展性的平台的价值主张。

最终建议：混合型韧性策略

鉴于智能体人工智能的战略重要性以及底层技术的快速且不可预测的演进，对于大型企业而言，最具韧性和面向未来的策略是混合策略。这种策略需要在选择一个主要平台的同时，投资于抽象层以降低风险并保持灵活性。

• 选择主要智能体开发平台： 使用上方的决策矩阵，选择 Vertex AI 或 Bedrock 作为智能体开发和部署的主要平台。此选择应基于对组织当前技术环境、战略目标和开发人员技能的客观评估。确定主要平台有助于组织构建深厚的专业知识，并充分利用其集成工具链的强大功能，以支持大多数智能体项目。

• 构建并实现通用的、兼容 OpenAI 的 API 网关： 同时，组织应投入资源构建或采用通用 API 网关，详情请参阅本报告第五部分。该网关应成为所有需要使用生成式 AI 模型功能的内部应用程序的单一标准化入口点。

这种双管齐下的方法兼具两者的优势。企业可以通过标准化使用一个主要的智能体平台，快速高效地推进业务发展，并受益于其深度集成和托管服务。同时，API 网关扮演着战略性的“断路器”角色，将应用程序逻辑与所选平台的特定模型端点解耦。这一关键的抽象层确保企业永远不会完全被单一供应商的模型生态系统所束缚。如果其他平台上出现了更优秀的新模型，或者出于价格或性能方面的考虑需要进行变更，则可以在网关后透明地完成切换，而无需耗费大量成本和时间重写每个应用程序。这种混合策略使企业能够在当下充分利用智能体 AI 的强大功能，同时保持架构的灵活性，以适应未来的创新。

参考文献

• 把握人工智能的智能优势 - 麦肯锡，访问日期：2025 年 9 月 28 日，https://www.mckinsey.com/capabilities/quantumblack/our-insights/seizing-the-agentic-ai-advantage

• Vertex AI 智能体引擎 - Google Cloud - Medium，访问日期：2025 年 9 月 28 日，https://medium.com/google-cloud/ai-agents-8eb2b6edea9b

• 什么是人工智能智能体？定义、示例和类型 | Google Cloud，访问日期：2025 年 9 月 28 日，https://cloud.google.com/discover/what-are-ai-agents

• LLM 代理编排：使用 LangChain 和 Granite 的分步指南 - IBM，访问日期：2025 年 9 月 28 日，https://www.ibm.com/think/tutorials/llm-agent-orchestration-with-langchain-and-granite

• 使用 Vertex AI Agent Builder 构建 AI 代理 - Google Codelabs，访问日期：2025 年 9 月 28 日，https://codelabs.developers.google.com/devsite/codelabs/building-ai-agents-vertexai

• AI 代理 - Amazon Bedrock - AWS，访问日期：2025 年 9 月 28 日，https://aws.amazon.com/bedrock/agents/

• Vertex AI Agent Builder - Google Cloud Skills Boost，访问日期：2025 年 9 月 28 日，https://www.cloudskillsboost.google/course_templates/1162/documents/532073

• Vertex AI Agent Builder | Google Cloud，访问日期：2025 年 9 月 28 日，https://cloud.google.com/products/agent-builder

• Azure AI Foundry vs AWS Bedrock vs Google Vertex AI：2025 年指南 - GoPenAI，访问日期：2025 年 9 月 28 日，https://blog.gopenai.com/azure-ai-foundry-vs-aws-bedrock-vs-google-vertex-ai-the-2025-guide-25a69c1d19b1

• 2025 年 Amazon Bedrock 与 Vertex AI 对比 - Slashdot，访问日期：2025 年 9 月 28 日，https://slashdot.org/software/comparison/Amazon-Bedrock-vs-Vertex-AI/

• Amazon Bedrock：选择基础模型 - AWS，访问日期：2025 年 9 月 28 日https://aws.amazon.com/awstv/watch/c872f1ef288/

• Amazon Bedrock Agents 教程 - AWS，访问日期：2025 年 9 月 28 日，https://aws.amazon.com/awstv/watch/0453c416302/

• build-on-aws/amazon-bedrock-agents-quickstart - GitHub，访问日期：2025 年 9 月 28 日，https://github.com/build-on-aws/amazon-bedrock-agents-quickstart

• 使用 Amazon Bedrock Agents 协调无缝的业务系统集成 - AWS，访问日期：2025 年 9 月 28 日， https://aws.amazon.com/blogs/machine-learning/orchestrate-seamless-business-systems-integrations-using-amazon-bedrock-agents/

• 在提供基础模型访问方面，Amazon Bedrock 与其他云产品（例如 Microsoft Azure 的 OpenAI 服务或 Google Vertex AI）相比如何？ - Milvus，访问日期：2025 年 9 月 28 日，https://milvus.io/ai-quick-reference/how-does-amazon-bedrock-compare-to-other-cloud-offerings-such-as-microsoft-azures-openai-service-or-google-vertex-ai-in-providing-foundation-model-access

• 在提供基础模型访问方面，Amazon Bedrock 与其他云产品（例如 Microsoft Azure 的 OpenAI 服务或 Google Vertex AI）相比如何？ - Zilliz，访问日期：2025 年 9 月 28 日，https://zilliz.com/ai-faq/how-does-amazon-bedrock-compare-to-other-cloud-offerings-such-as-microsoft-azures-openai-service-or-google-vertex-ai-in-providing-foundation-model-access

• Vertex AI Agent Builder 概述 - Google Cloud，访问日期：2025 年 9 月 28 日，https://cloud.google.com/vertex-ai/generative-ai/docs/agent-builder/overview

• Vertex AI Agent Engine 概述 - Google Cloud，访问日期：2025 年 9 月 28 日，https://cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/overview

• Google Vertex AI 教程：如何构建 AI 代理 - Voiceflow，访问日期：2025 年 9 月 28 日，https://www.voiceflow.com/blog/vertex-ai

• 分步指南：使用 Vertex AI Agent Builder 构建 AI 代理 - 代理 - Google 开发者论坛，访问日期：2025 年 9 月 28 日，https://discuss.google.dev/t/step-by-step-guide-building-ai-agents-with-vertex-ai-agent-builder/265524

• Vertex AI Agent Builder API：快速概述 - SmythOS，访问日期：2025 年 9 月 28 日，https://smythos.com/developers/agent-integrations/vertex-ai-agent-builder-api-overview/

• 如何将外部数据源集成到 Vertex AI Agent Builder 中 - Premier Cloud，访问日期：2025 年 9 月 28 日2025 年，https://premiercloud.com/blog/how-to-integrate-external-data-sources-into-vertex-ai-agent-builder/

• 将外部数据源集成到 Vertex AI Agent Builder 中 | 作者：Aryan Irani | Google Cloud，访问日期：2025 年 9 月 28 日，https://medium.com/google-cloud/integrate-external-data-sources-into-vertex-ai-agent-builder-b542b657d1ef

• Google 模型 | Vertex AI 上的生成式 AI，访问日期：2025 年 9 月 28 日，https://cloud.google.com/vertex-ai/generative-ai/docs/models

• Model Garden 支持的模型 | Vertex AI 上的生成式 AI……，访问日期：2025 年 9 月 28 日，https://cloud.google.com/vertex-ai/generative-ai/docs/model-garden/available-models

• 模型 - Google DeepMind，访问日期：2025 年 9 月 28 日，https://deepmind.google/models/

• Vertex AI 平台 | Google Cloud，访问日期：2025 年 9 月 28 日，https://cloud.google.com/vertex-ai

• Amazon Bedrock AgentCore（预览版）- AWS，访问日期：2025 年 9 月 28 日，https://aws.amazon.com/bedrock/agentcore/

• 使用 Foundation 模型构建生成式 AI 应用程序 – Amazon Bedrock - AWS，访问日期：2025 年 9 月 28 日，https://aws.amazon.com/bedrock/

• 使用 AWS SDK 创建 Amazon Bedrock Agent 的代码示例，访问日期：2025 年 9 月 28 日，https://docs.aws.amazon.com/bedrock/latest/userguide/service_code_examples_bedrock-agent.html

• 步骤 2：创建 Amazon Bedrock Agent，访问日期：2025 年 9 月 28 日https://docs.aws.amazon.com/bedrock/latest/userguide/agent-tutorial-step2.html

• 在 Amazon Bedrock 中向代理添加操作组，访问日期：2025 年 9 月 28 日，https://docs.aws.amazon.com/bedrock/latest/userguide/agents-action-add.html

• Bedrock Agent 的工作原理 | AWS re:Post，访问日期：2025 年 9 月 28 日，https://repost.aws/questions/QUt4ankTG8Tl-3hs3V3uYTCg/working-of-the-bedrock-agent

• 使用 CloudWatch Metrics 监控 Amazon Bedrock Agent，访问日期：2025 年 9 月 28 日，https://docs.aws.amazon.com/bedrock/latest/userguide/monitoring-agents-cw-metrics.html

• 使用 Ragas 和 LLM 作为评判标准评估 Amazon Bedrock Agent |人工智能，访问日期：2025 年 9 月 28 日，https://aws.amazon.com/blogs/machine-learning/evaluate-amazon-bedrock-agents-with-ragas-and-llm-as-a-judge/

• Amazon Bedrock Agent 的工作原理，访问日期：2025 年 9 月 28 日，https://docs.aws.amazon.com/bedrock/latest/userguide/agents-how.html

• 使用自定义编排自定义 Amazon Bedrock Agent 的行为，访问日期：2025 年 9 月 28 日，https://docs.aws.amazon.com/bedrock/latest/userguide/agents-custom-orchestration.html

• Amazon Bedrock 的代理和知识库 |作者：Felix Fd - Medium，访问日期：2025 年 9 月 28 日，https://medium.com/@felix.fd/agents-and-knowledge-bases-for-amazon-bedrock-91c897ae526a

• AWS Bedrock — 探索代理、知识库和 RAG | 作者：Kapil Raina | Medium，访问日期：2025 年 9 月 28 日，https://kapil-raina.medium.com/aws-bedrock-exploring-agents-knowledge-base-rag-bd2856c80d2f

• 我们能否创建一个带有操作组的代理来对知识库执行自定义检索？如果不能，我们能否在 OpenSearch 上实现，或者使用它们中的任何一个定义自定义 RAG 流程？ AWS re:Post，访问日期：2025 年 9 月 28 日，https://repost.aws/questions/QUTF30Oc8nTP6KbMV-XWLqbg/can-we-create-an-agent-with-an-action-group-to-perform-custom-retrievals-on-a-kb-if-not-can-we-do-it-on-opensearch-or-define-a-custom-rag-flow-using-either-of-them

• 具有知识库元数据搜索功能的 Bedrock Agent | AWS re:Post，访问日期：2025 年 9 月 28 日，https://repost.aws/questions/QUbOIXPEWrQBuXlRckN3xs1Q/bedrock-agent-with-knowledgebase-metadata-search

• Amazon Bedrock 基础模型信息，访问日期：2025 年 9 月 28 日，https://docs.aws.amazon.com/bedrock/latest/userguide/foundation-models-reference.html

• Amazon Bedrock 支持的基础模型，访问日期：2025 年 9 月 28 日，https://docs.aws.amazon.com/bedrock/latest/userguide/models-supported.html

• 截至 2024 年的 Amazon Bedrock 模型 - 综合模型目录分析 | hidekazu-konishi.com，访问日期：2025 年 9 月 28 日，https://hidekazu-konishi.com/entry/amazon_bedrock_models_as_of_2024.html

• AWS Bedrock 基础模型 - SageCollab，访问日期：2025 年 9 月 28 日，https://sagecollab.com/aws-bedrock-foundation-models/

• 在 AWS Bedrock 中应该选择哪些基础模型？ - Economize Cloud，访问日期：2025 年 9 月 28 日，https://www.economize.cloud/blog/aws-bedrock-foundation-models-list/

• 使用 Vertex AI Agent Builder 构建 AI 代理 - Ema，访问日期：2025 年 9 月 28 日，https://www.ema.co/additional-blogs/addition-blogs/vertex-ai-agent-builder-guide

• 使用 Vertex Gen AI 评估服务评估您的 AI 代理 | Google Cloud 博客，访问日期：2025 年 9 月 28 日，https://cloud.google.com/blog/products/ai-machine-learning/introducing-agent-evaluation-in-vertex-ai-gen-ai-evaluation-service

• 如何使用 Vertex AI 评估您的 Gen AI 模型 - YouTube，访问日期：2025 年 9 月 28 日，https://www.youtube.com/watch?v=4w_uXjGl5Tk

• 监控代理 | Vertex AI 上的生成式 AI - Google Cloud，访问日期：2025 年 9 月 28 日，https://cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/manage/monitoring

• Vertex AI Agent Builder：无缝构建和部署 AI Agent - SmythOS，访问日期：2025 年 9 月 28 日，https://smythos.com/developers/agent-integrations/vertex-ai-agent-builder/

• 使用 Amazon Bedrock AgentCore Observability 构建可信赖的 AI Agent - AWS，访问日期：2025 年 9 月 28 日，https://aws.amazon.com/blogs/machine-learning/build-trustworthy-ai-agents-with-amazon-bedrock-agentcore-observability/

• 使用 Datadog LLM 监控在 Amazon Bedrock 上构建的 Agent可观测性，访问日期：2025 年 9 月 28 日，https://www.datadoghq.com/blog/llm-observability-bedrock-agents/

• 定价 | Vertex AI | Google Cloud，访问日期：2025 年 9 月 28 日，https://cloud.google.com/vertex-ai/pricing

• 定价 - AWS，访问日期：2025 年 9 月 28 日，https://aws.amazon.com/bedrock/pricing/

• API 参考 - OpenAI 平台，访问日期：2025 年 9 月 28 日，https://platform.openai.com/docs/api-reference/introduction

• API 参考 - OpenAI 平台，访问日期：2025 年 9 月 28 日，https://platform.openai.com/docs/api-reference

• OpenAI 兼容 API - Vercel，访问日期：2025 年 9 月 28 日，https://vercel.com/docs/ai-gateway/openai-compat

• 统一 API （OpenAI 兼容性）· Cloudflare AI Gateway 文档，访问日期：2025 年 9 月 28 日，https://developers.cloudflare.com/ai-gateway/usage/chat-completion/

• 通过网关访问 Azure OpenAI 和其他语言模型 - Microsoft Learn，访问日期：2025 年 9 月 28 日，https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/azure-openai-gateway-guide

• BadgerHobbs/OpenAI-API-Gateway：开源网关... - GitHub，访问日期：2025 年 9 月 28 日，https://github.com/BadgerHobbs/OpenAI-API-Gateway

• 通过网关为 Azure OpenAI 服务提供自定义身份验证 - Azure 架构中心 | Microsoft Learn，访问日期：2025 年 9 月 28 日，https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/azure-openai-gateway-custom-authentication

• Portkey-AI/gateway：速度极快的 AI 网关，集成防护机制。通过一个快速友好的 API 即可连接到 200 多个 LLM 和 50 多个 AI 防护机制。- GitHub，访问日期：2025 年 9 月 28 日，https://github.com/Portkey-AI/gateway

• OpenAI 兼容性 | Gemini API - Google AI for Developers，访问日期：2025 年 9 月 28 日，https://ai.google.dev/gemini-api/docs/openai