Vertex AI

为什么选择 Vertex AI？

Vertex AI 并非 Cursor 风格的编辑器、VS Code 插件或终端编程 Agent。它的核心价值体现在原型阶段之后——当团队需要将模型、提示词、嵌入、微调任务、端点、评估和运维控制转化为一个可重复的生产系统时。

对于开发工具决策者来说，Vertex AI 的定位是 AI 应用背后的基础设施层。团队可能仍在使用 Cursor、GitHub Copilot、Gemini Code Assist 或 Claude Code 来编写代码，但会使用 Vertex AI 来托管或调用模型、运行推理、评估输出、管理 RAG 工作流，并将 AI 行为与 Google Cloud 的权限和计费系统连接。

由于 Google 正在将 Vertex AI 的功能整合至 Gemini Enterprise Agent Platform（Gemini 企业级智能体平台）品牌下，名称可能会让人混淆。考虑到搜索需求和开发者的认知，本页面保留了 “Vertex AI” 这一名称，并在正文中说明当前的平台命名。

核心工作流程

实际的 Vertex AI 工作流通常始于模型选择，而非编辑器配置。开发者从 Google、合作伙伴或开源模型库中选择模型，然后在控制台或 SDK 中测试提示词或 API 调用。一旦模型表现符合预期，工作流将进入评估、接地（Grounding）、检索、部署、监控和成本控制阶段。

对于生成式 AI 应用，闭环通常如下：设计提示词、通过 RAG 或工具调用（Tool Use）关联上下文、评估输出、添加安全和治理控制、通过应用后端部署，随后监控延迟、质量和开销。对于传统的机器学习团队，闭环则可能涉及数据集、训练任务、模型注册表、批处理预测、在线端点和模型监控。

这使得 Vertex AI 比起 API 优先的产品显得更“重”，但也更适合作为大型云架构的一部分。最佳实践是将 Vertex AI 视为后端能力，而不是日常编写代码的场所。

适用场景

Vertex AI 适合构建需要单个模型端点以外功能的 AI 产品的团队。例如：基于公司文档的内部 Copilot、具有检索和升级逻辑的客户服务助手、AI 搜索体验、多模态分析流、预测性机器学习服务，以及需要托管运行环境、记忆和可观测性的 Agent 系统。

当现有技术栈已在 Google Cloud 上运行时，Vertex AI 的优势尤为明显。BigQuery 数据、Cloud Storage 资源、Cloud Run 服务、IAM 权限、审计日志和计费控制都可以纳入同一个运营模型。这种集成是选择 Vertex AI 而非简单的独立模型 API 的最强理由。

在代码相关场景中，Vertex AI 通常是间接发挥作用。它可以驱动代码生成、代码分析、文档生成或内部开发者 Agent，但它本身不是开发者写代码的界面。想要代码补全、内联对话、仓库编辑或 PR 辅助的团队，应该将其与 IDE 工具配合使用，而不是指望 Vertex AI 取代它们。

竞品对比

与 Amazon Bedrock 相比：Vertex AI 是以 Google Cloud 为中心的团队的自然选择，特别是那些使用 Gemini、BigQuery 和 Google 原生部署模式的团队。而 Bedrock 对于已经在 IAM、Lambda、SageMaker 和 AWS 网络环境中标准化的 AWS 优先组织更具吸引力。

与 Azure AI Foundry 相比：Vertex AI 的竞争定位是全栈云 AI 平台，而非局限于模型 API。Azure 可能对 Microsoft 365、GitHub、Windows 和企业级微软环境更有吸引力，而 Vertex AI 在 Google Cloud 原生数据和应用栈方面更强。

与 OpenAI API 平台相比：Vertex AI 拥有更广的云运维覆盖面。OpenAI 在模型驱动的产品开发中上手更快，而当模型访问、数据治理、部署、评估和云架构必须共存于一个受管环境时，Vertex AI 会更具竞争力。

与 Cursor、Windsurf 或 Zed AI 等 AI IDE 相比：Vertex AI 解决的是技术栈中不同层级的问题。这些 IDE 旨在改进开发者编写和编辑代码的方式，而 Vertex AI 则是帮助团队在生产环境中运行 AI 能力。

最佳配置建议

对于小型实验，建议从独立的 Google Cloud 项目开始，设置严格的预算提醒和最少的 IAM 权限。这可以保持测试环境隔离，若实验放弃也易于清理资源。

对于生产环境，应按项目或文件夹分隔环境，为每个应用定义服务账号，尽早添加配额和预算控制，并为资源打上标签以便追溯团队或产品的用量。此外，团队应根据内部政策决定提示词、请求/响应日志、评估数据和嵌入是否可以被存储、导出或审查。

良好的架构通常将应用逻辑保留在 Vertex AI 之外，通过后端服务调用 Vertex AI。该后端可以处理身份验证、缓存、速率限制、提示词版本管理、安全检查和兜底逻辑，从而避免将云端凭据或平台复杂性直接暴露给前端应用。

迁移建议

从简单 API 提供商迁移过来的团队需要做好应对更多配置工作的准备。除了管理 API 密钥外，还需要配置 Google Cloud 项目、计费、IAM、启用相关的 API、选择区域、设置服务账号、配额，以及可能的 VPC 或合规性配置。

从旧版 Vertex AI 迁移的团队应将旧术语映射到新的 Agent Platform 命名。Vertex AI Studio、Model Garden、RAG Engine、Agent Engine、Vector Search、端点和评估功能在当前的 Google Cloud 文档中可能出现在更新后的标签下。

最稳妥的迁移方式是逐个迁移工作负载。先从非核心的推理路径开始，在所选模型上复现行为，测量延迟和成本，在替换现有的生产路径前，先增加评估和监控环节。