Google Cloud FDE 实操手册：BigQuery × Vertex AI 落地的三道坎与一套方法论

这是「AI 观察室 · FDE 前线工程师」系列的第 5 篇。前四篇我们看了 OpenAI DeployCo、Palantir Foundry、FDE 薪酬报告、FDE vs Solutions Engineer 的边界。今天我们把镜头从硅谷搬到 Mountain View 以南——Google Cloud 自己的 FDE，到底是怎么把 BigQuery 和 Vertex AI 拼到客户机房里去的。

引子：当 BigQuery 不再只是数仓

五年前，「Google Cloud FDE」在多数人的认知里还约等于 Cloud Professional Services 的咨询顾问；他们的标配是笔记本电脑 + 一本厚厚的「Google Cloud Architecture Framework」白皮书 + 一个 BigQuery 试用项目。客户买 GCP 的动机也很朴素：要存数据、要跑 SQL、要换掉 Teradata。

2026 年的故事完全不同。BigQuery 已经不只是 SQL 引擎——它和 Vertex AI Model Garden、Gemini Enterprise Agent Platform 一起，被 Google 重写成一套「数据 + 模型 + Agent」三合一的落地底座。FDE 进客户现场的第一句话不再是「我们来给你跑 SQL」，而是「你们的数据在哪里、决策卡在哪一环、能不能容忍一个 RAG 的误差率」。这套方法论变了，对 FDE 的能力要求也变了。

本期深度文聚焦三件事：

1. Google Cloud FDE 现在到底驻场做什么——不是 PPT，是从 BigQuery 数据接入到 Vertex AI 端点部署的 5 个真实步骤；

2. 与 Palantir FDE 的方法论差异——为什么 GCP 的 FDE 更像「数据工程师 +」，而 Palantir 的 FDE 像「Foundry 的产品经理」；

3. 3 道坎与 1 套范式——数据治理、Agent 幻觉、ROI 度量，以及为什么 a16z 投的那批「Agent 基础设施公司」会反推 Google 的方法论演进。

一、核心现象：Google Cloud FDE 的工作面长什么样

1.1 「FDE」这个词在 Google 内部的两种含义

第一个含义是 Field Deployment Engineer，这是 Google 内部对驻场工程师的旧称，覆盖 Cloud 落地、GCP 项目交付、SRE 紧急介入等场景。HN 上 2020 年那条被吐槽的「contract with Google FDEs on-site」（comment id 23364940，作者 choppaface）反映的就是这一类角色——客户对他们的主要不满是「Googlers 不会听（Googlers just don't listen）」。

第二个含义是 Forward Deployed Engineer，这是 2023 年以后 Google Cloud 跟随 Palantir、Anthropic 重新启用的称谓，定位更高、责任更重。前一类负责「把东西装上去」，后一类负责「把客户业务跑出来」。两者的边界在 2026 年仍在融合，但 FDE 的核心方法论已经基本定型：用 Google Cloud 的全栈能力（BigQuery + Vertex AI + Gemini Agent Platform）接管客户的数据→模型→决策流水线，而不是只交付一个模型 API。

1.2 一个典型 FDE 项目的 5 步执行流

我们从 GitHub 上的 GoogleCloudPlatform/vertex-ai-samples 仓库（4,271 commits）和 GoogleCloudPlatform/generative-ai 仓库（2,135 commits）抽出一个 FDE 项目的高频路径：

┌────────────────────────────────────────────────────────────────────────┐
│  Google Cloud FDE 5-Step Delivery Methodology                          │
└────────────────────────────────────────────────────────────────────────┘

  [1] 数据发现 (Data Discovery)
       ↓  客户表结构盘点 + 行级权限 + PII 标记
  [2] BigQuery 数据接入 (Ingestion)
       ↓  BigQuery Transfer Service / BigLake / Omni
  [3] Vertex AI 建模 (Modeling)
       ↓  Model Garden (Gemini, Claude, Llama, Gemma) / AutoML
  [4] Agent 编排 (Orchestration)
       ↓  Gemini Enterprise Agent Platform / Agent Search / RAG Grounding
  [5] 业务上线 (Productionize)
       ↓  Model Registry + Endpoints + Cloud Monitoring

步骤 1 - 数据发现：FDE 进客户现场第一天通常不开工，先和客户的 CDO（Chief Data Officer）+ DPO（Data Protection Officer）开 3 次会议。FDE 需要回答的不是「你们有多少张表」，而是「哪些表在 GDPR 范围内」「哪些字段涉及商业秘密」「如果错用，会触发哪一条合规条款」。这一步的产出物是一份 Data Inventory——表名 × 字段 × 业务 owner × 风险等级。

步骤 2 - BigQuery 接入：这一步是 GCP 的舒适区。如果客户已经在 GCP 上跑业务，BigQuery Transfer Service + BigLake 可以让新数据源半天入仓；如果客户是混合云（数据在 AWS S3 或 Azure ADLS），FDE 会用 BigQuery Omni 直接做跨云查询，不需要搬运原始数据。bigquery-utils 仓库里有大量现成的连接器和 SQL 模板。

步骤 3 - Vertex AI 建模：FDE 不一定自己写模型。他们通常从 Model Garden 拉一个现成的基础模型——Gemini 处理多模态、Claude 处理长上下文、Llama / Gemma 跑开源需求——然后做 prompt engineering + function calling 适配。如果客户非要自训，FDE 会引导客户走 AutoML 或 custom training（用 ray_on_vertex_ai 做分布式）。

步骤 4 - Agent 编排：这是 2026 年新加的环节。Gemini Enterprise Agent Platform（仓库里新立的 Google-Cloud-AI/agent-platform）接管了上一代 Vertex AI Agent Builder 的能力，FDE 需要帮客户组装 Tools、Memory、Routing、Grounding 四个组件。generative-ai 仓库里 agents/、rag-grounding/、search/ 三个目录是 FDE 最常用的资源。

步骤 5 - 业务上线：FDE 不像传统 ML 工程师那样把模型扔进生产就完事。他们必须帮客户搭 Model Registry + Endpoints + Cloud Monitoring 的完整闭环，并写一份「为什么这个模型的这个版本应该上线的」审计文档。

1.3 FDE 一天的工作切片（来自 Levels.fyi 的薪酬分布旁证）

Levels.fyi 7/3 数据显示，Palantir 的 Forward Deployed Software Engineer 是单独列出来的子角色（与 Backend / Full-Stack / Production 并列），可见这是一个公认的细分职位。Google 内部没有公开子角色拆分，但根据多个 FDE 在 LinkedIn 上的描述，他们一天的时间分配大致是：40% 写代码（BigQuery SQL + Python + 一点 Java）+ 30% 客户沟通（视频会议 + Slack）+ 20% 架构设计（白板 + Confluence）+ 10% 内部知识沉淀（内部 wiki + blog post）。

注意这个 40%——这是 FDE 区别于 Solutions Architect 的核心指标。SA 通常写 PPT，FDE 必须能自己撸代码把客户的需求跑通。

二、技术/商业深度解析

2.1 BigQuery × Vertex AI 的「数据-模型」耦合范式

Google Cloud FDE 之所以偏爱 BigQuery + Vertex AI 这套组合，根因是 BigQuery 本身就是一个能跑 ML 的引擎。BigQuery ML 让客户用纯 SQL 完成特征工程 + 模型训练 + 在线预测，FDE 不用跳出 SQL 上下文就能交付一个最小可用模型。

这种「数据层和模型层共用一个 SQL 入口」的设计，让 FDE 在客户现场能做的迭代速度远超传统 MLOps 流程。一个典型迭代周期是：改 SQL → 跑 BigQuery ML → 看结果 → 调 prompt → 部署 Vertex AI Endpoint，全程不超过 2 小时。

2.2 Agent Platform 演进：从 Vertex AI Agent Builder 到 Gemini Enterprise Agent Platform

2025 年下半年到 2026 年上半年，Google Cloud 把 Vertex AI Agent Builder 升级为 Gemini Enterprise Agent Platform，这是一次不小的产品重组。FDE 的工作流也跟着变了——

| 阶段 | 工具 | FDE 聚焦 |

|---|---|---|

| 2024 - 2025 H1 | Vertex AI Agent Builder | Prompt 设计 + Function Calling |

| 2025 H2 | Vertex AI Agent Builder + RAG Engine | 加入向量检索 + Grounding |

| 2026 H1 | Gemini Enterprise Agent Platform | 多 Agent 协作 + Tool Routing + Memory |

新的 Agent Platform 仓库（Google-Cloud-AI/agent-platform）里 agents/、tools/、search/ 三个目录是 FDE 重点熟悉的资源。从 repo 结构看，Google 把 Agent 拆成了 5 大组件（Skills + Memory + Tools + Routing + Grounding），每个组件都有独立的 notebook 教程。这种拆解方式给 FDE 提供了「模块化替换」的便利——客户的旧 RAG 流程可以只换 Grounding 这一块，不影响其它环节。

2.3 与 Palantir FDE 的方法论对比

FDE 圈子里常被问到的问题：Google Cloud FDE 和 Palantir FDE 有什么本质区别？我们用一张表说清楚：

| 维度 | Google Cloud FDE | Palantir FDE |

|---|---|---|

| 核心产品 | BigQuery + Vertex AI + Gemini Agent Platform | Foundry + AIP + Ontology |

| 客户决策点 | 用 GCP 全栈替换或补充现有架构 | 接受 Palantir 的数据本体（Ontology）抽象 |

| 数据哲学 | 「数据在哪，模型在哪」（BigQuery Omni 支持跨云） | 「数据先搬进 Foundry，再讨论模型」 |

| FDE 角色定位 | 数据工程师 + AI 工程师的 hybrid | 数据产品经理 + 解决方案架构师的 hybrid |

| 代码占比 | ~40% | ~20%（更多时间在配置 Ontology） |

| 驻场周期 | 3-6 个月 | 6-18 个月（Foundry 部署周期长） |

| 典型客户 | 互联网、零售、媒体、电信 | 政府、金融、国防、医疗 |

| 薪酬对标 | Customer Success 中位数 $403K / Solution Architect $331K（Levels.fyi 6/16 数据） | Forward Deployed Software Engineer 子类未单列中位数；Software Engineer $250K |

数据来源：Levels.fyi 6/16/2026 与 7/3/2026 数据。值得注意，Palantir 的「Forward Deployed Software Engineer」是 Levels.fyi 单独列出的子类，Google 内部尚未对外披露 FDE 单独的薪酬中位数。

2.4 FDE 的三道坎与一套范式

和任何工程角色一样，Google Cloud FDE 在客户现场也会遇到重复出现的「坎」。我们归纳出三道最常见的：

第一道坎：数据治理 vs 模型迭代速度的拉扯。客户的数据治理团队要求每张新表都走数据血缘 + PII 标记 + 合规审批，而模型团队要求 2 周迭代一次。FDE 必须站在中间翻译——把治理要求拆成「表级权限」+「行级策略」+「模型输入清洗」三件独立的事，分别跟两方对齐。bigquery-utils 仓库里的 row_access_policies 和 column_data_masking 是这类对话的常用工具。

第二道坎：Agent 幻觉 + 业务容错的边界。客户业务团队最常问 FDE 的问题是「Agent 说错了怎么办」。FDE 不能简单回答「加个 fallback」，必须给出三层防护——Grounding（用 RAG 把答案锚定到客户数据）+ Guardrails（用 Gemini 的安全过滤拦截违规输出）+ Human-in-the-loop（关键决策留人工确认）。这三层在 Gemini Enterprise Agent Platform 里都有现成组件，但客户业务团队往往不愿意付后两层的人工成本，FDE 需要用实际案例证明 ROI。

第三道坎：ROI 度量。这是最难的一道坎。客户 CFO 会问「这套 Vertex AI + Agent Platform 投了 $500K，到底赚回来多少」。FDE 拿不出传统 SaaS 那种「节省 X 人天」的干净数字，因为 Agent 改造的是流程而非替代人力。FDE 必须在项目启动前就和 CFO 约定好度量框架——通常是 「决策响应时间下降百分比 × 该决策的年发生频次 × 该决策的单次业务价值」——这个公式不是 Google 独有的，但 Google Cloud 的 BigQuery 提供了现成的度量模板。

2.5 a16z 投资视角下的 Agent 基础设施如何反推 FDE 角色

a16z 2025 年以来投了一大批 Agent 基础设施公司——LangChain、LlamaIndex、Sierra、Fixie、Letta、Inkeep 等。这些公司的共同点是「让 Agent 更容易构建、部署、观测」。它们的存在反过来推高了 Google Cloud FDE 的能力要求：FDE 不能只会调 Vertex AI API，还要懂 Agent 编排的底层原理（tool calling protocol / memory architecture / evaluation pipeline），否则和客户的工程团队对话会出现断层。

FDE 圈子里有一句玩笑话：「2024 年的 FDE 拼 SQL，2026 年的 FDE 拼 Agent。」这句话不无道理——Agent 是模型之上的运行时抽象，FDE 必须熟悉它的生命周期管理。

三、关键点总结

• 🎯 Google Cloud FDE 在 2026 年的核心定位：用 BigQuery + Vertex AI + Gemini Agent Platform 全栈能力接管客户的数据→模型→决策流水线，而非仅交付模型 API。
• 🛰️ 典型交付路径：数据发现 → BigQuery 接入 → Vertex AI 建模 → Agent 编排 → 业务上线，5 步闭环，每步都有 GCP 官方 repo（bigquery-utils / vertex-ai-samples / generative-ai / agent-platform）作为工具支撑。
• 🧬 与 Palantir FDE 的本质差异：GCP FDE 像「数据工程师 +」（40% 代码），Palantir FDE 像「数据产品经理 +」（20% 代码）；客户决策点不同决定了方法论不同。
• 🚧 三道坎：数据治理 vs 迭代速度、Agent 幻觉 vs 业务容错、ROI 度量公式。每道坎都需要 FDE 同时具备技术深度和业务沟通能力。
• 📈 趋势预判：a16z 投的 Agent 基础设施公司（LangChain / LlamaIndex / Sierra 等）反推 FDE 角色升级——从「调 API 的工程师」升级为「懂 Agent 编排的解决方案架构师」。
• 💰 薪酬对标：Google Customer Success 中位数 $403K、Solution Architect $331K（Levels.fyi 6/16 数据）；Palantir Forward Deployed Software Engineer 在 Levels.fyi 单独列子类但未披露中位数，仅 Software Engineer 子类 $250K（Levels.fyi 7/3 数据）。
• 🗂️ 官方资源地图：GoogleCloudPlatform org 下 1,491 个 repo（截至 2026-07-03），FDE 高频使用 4 个：python-docs-samples（8.1k stars）/ vertex-ai-samples / generative-ai / bigquery-utils。

四、行业影响与未来展望

Google Cloud FDE 角色的扩张，本质上是 GCP 从「卖资源」转向「卖落地方法论」 的结果。当 BigQuery 和 Vertex AI 已经成为云厂商的标配时，差异化的不再是「能不能跑」，而是「能不能在客户业务里跑出价值」。

未来 12 个月值得聚焦的方向：

1. Agent 模板化——Google Cloud 已经在 agent-platform repo 里提供 Skills 目录，本质是把 FDE 的最佳实践沉淀成可复用的 Agent 模板。客户不再从零搭 Agent，而是从模板改。

2. FDE 与 Sales 的边界融合——随着 Agent 模板化，FDE 不再是「Sales 接单后进场实施」，而是「Sales 在谈单时就已经带着 Agent 模板进场演示」。

3. 跨云 FDE 出现——BigQuery Omni 让 GCP FDE 能直接查 AWS S3 和 Azure ADLS 的数据，跨云 FDE 的市场需求在 2026 H2 预计会显著上升。

值得注意的是，2020 年 HN 那条被吐槽的「Googlers just don't listen」（comment id 23364940）至今仍是 Google Cloud FDE 的软肋之一。Agent Platform 解决了技术交付的一致性，但没有解决 FDE 与客户业务团队的「倾听能力」问题——这是组织层面的挑战，不是技术能直接解的。

五、结语

Google Cloud FDE 这个角色的进化，是观察「AI 落地方法论」的最佳窗口之一。它不像 OpenAI DeployCo 那样高调，不像 Palantir 那样神秘，也不像 Anthropic Applied AI 那样纯 API——它是「在客户机房里，用 BigQuery 和 Vertex AI 一行行把业务跑出来」的一群人。

下期我们将走进金融和医疗行业，看看 FDE 在 HIPAA / SOC 2 / GDPR 的合规铁墙下，如何用同样的方法论撬开被监管的客户。如果你想看到 FDE 在某家具体客户的真实项目复盘，或者想看 FDE 与 Solutions Engineer / PM / Sales 的协作矩阵，留言告诉我具体方向。

参考资料

官方文档

• Google Cloud 客户案例中心 - 持续更新
• GoogleCloudPlatform/vertex-ai-samples (GitHub) - 4,271 commits，2026-07 活跃
• GoogleCloudPlatform/generative-ai (GitHub) - 2,135 commits，Gemini Enterprise Agent Platform 配套
• Google-Cloud-AI/agent-platform (GitHub) - 新一代 Agent 模板库

开源项目

• GoogleCloudPlatform 组织主页 - 1,491 个 repo，21k followers
• GoogleCloudPlatform/python-docs-samples (GitHub) - 8.1k stars，多语言 samples
• GoogleCloudPlatform/bigquery-utils (GitHub) - BigQuery 数据治理工具集

行业报道

• HN Algolia: "google cloud FDE" 搜索 - 11,131 hits，2020 年 choppaface 评论为代表性客户吐槽
• a16z: New Tech Stack 系列 - Agent 基础设施投资视角

社区讨论

• HN: Fuchsia overview thread (23364172) - 含 Google Cloud FDE 客户实战反馈
• HN: choppaface 评论 (23364940) - 「contract with Google FDEs on-site」真实客户视角

对比基准

• Levels.fyi: Google 薪酬 - 2026-06-16 更新，Customer Success 中位数 $403K
• Levels.fyi: Palantir 薪酬 - 2026-07-03 更新，Forward Deployed Software Engineer 子类已单独列出

本文由 AI 生成。内容基于公开资料整理，可能存在事实偏差，引用链接请以原始来源为准。