Vertex AI Agent Builder 是 Google Cloud 提供的全托管 Agent 构建与部署平台，2024 年 5 月正式 GA，2025 年 5 月随 Agent Engine 的推出完成能力扩展。它解决的核心问题是：开发一个生产级 AI 代理（Agent）不只是调用大模型，还要处理数据接入、检索增强（RAG）、工具调用、多代理编排、部署运维和可观测性——这些通常要自己拼装多套系统。Agent Builder 把这些整合进一个平台：先用开源框架 Agent Development Kit（ADK）在本地写代码、做调试，再一键部署到云端的 Agent Engine 托管运行时，获得任务调度、评估、日志追踪等生产能力。它并不是一个大模型服务，而是“Agent 的构建与托管平台”，默认配合 Gemini 系列模型使用，也支持 Claude 等第三方模型（通过 Google AI 的模型网关）。本篇从环境配置、控制台操作、ADK 代码开发、生产部署四个层面展开，最后给出选型对比与常见误区，帮助你在 Google Cloud 生态内快速落地 Agent 应用。
对 AI 从业者而言，掌握 Agent Builder 意味着同时拿到“代码优先的本地开发框架 + 生产级托管运行时”，这是目前云厂商中最完整的 Agent 生命周期管理方案之一，也是 Google Cloud 上做 Agent 落地的主流路径。
目录
速览卡是工具类内容的固定首屏模块：30 秒判断「这工具是什么、能不能商用、适不适合我」。
为什么需要 Vertex AI Agent Builder：Agent「后段工程」太重 → 全托管编排与部署
直接调用大模型 API 构建助手，只能完成“输入-输出”的单轮对话，无法访问企业数据、无法调用外部工具、无法在多次推理中保持状态。要做一个能查库存、能改订单、能回答政策的客服 Agent，必须自己解决检索增强（RAG：把企业文档检索结果拼进提示词，让模型基于事实回答）、函数调用（Function Calling：让模型决定调用哪个 API）、代理循环（Agent Loop：计划-行动-观察的多次迭代）以及长期记忆——这些模块各自都要设计、调试和运维，工作量远大于模型本身。
Agent Builder 的解法是把这些能力平台化。它提供数据存储（Data Store）接入企业文档，自动完成分块、向量化和检索；提供扩展（Extensions）和函数调用能力，预置连接 Google 服务与第三方 API；提供 ADK 开源框架在本地编写和调试代理逻辑；最终通过 Agent Engine 一键部署到云端，自动获得负载均衡、定时任务（Cron）、执行轨迹追踪和评估能力。与 LangChain 等纯开源框架相比，Agent Builder 的差异在于“开发与运维一体”：本地写好代码，云端直接接管部署、扩展和监控，不需要自己搭 Kubernetes。
安装与环境配置：4 步就绪
第一步，准备 Google Cloud 项目。Agent Builder 是 GCP 托管服务，所有操作都发生在某个项目中。需要先有一个项目，并确保该账号有 roles/aiplatform.user 和 roles/discoveryengine.editor 等权限。
第二步，安装并认证 gcloud CLI。gcloud 是 GCP 的命令行工具，用于启用 API、管理资源。认证时执行 gcloud auth login 完成浏览器登录，再用 gcloud auth application-default login 生成本地开发用的应用默认凭证——这是本地 Python SDK 访问云资源的前提。
第三步，安装 Python SDK 和 ADK 框架。google-cloud-aiplatform 是 Vertex AI 的官方 Python 客户端，google-adk 是代理开发框架本体。执行环境中要求 Python 3.10 以上。
第四步，启用项目中的相关 API。aiplatform.googleapis.com 对应 Vertex AI 服务，discoveryengine.googleapis.com 对应数据检索（Discovery Engine）服务，两个都必须启用，否则控制台操作会报“API 未启用”。
# 1. 认证并设置项目gcloud auth logingcloud config set project YOUR_PROJECT_IDgcloud auth application-default login # 2. 启用 Agent Builder 依赖的 APIgcloud services enable aiplatform.googleapis.com discoveryengine.googleapis.com # 3. 安装 Python SDK 与 ADK 框架pip install --upgrade google-cloud-aiplatform google-adk # 4. 验证安装python -c "import google.cloud.aiplatform, google.adk; print('Vertex AI SDK OK')"
快速上手：30 分钟跑通第一个客服 Agent
推荐路径是“控制台建数据源 + ADK 写代理逻辑”两步走：先在控制台配置企业知识库，让代理有东西可查；再用 ADK 在本地定义代理行为和工具，最后在对话面板中测试。整个过程无需自己搭检索服务。
1. 登录 Google Cloud 控制台，在顶部搜索栏输入 "Agent Builder" 并进入产品页面。
2. 点击“创建”按钮，选择“代理构建”（Agent building）类型，填写代理名称，选择所在区域和默认模型（如 gemini-2.0-flash，菜单中会列出可用模型）。
3. 在代理详情页找到“数据存储”（Data store）模块，点击创建数据存储，选择数据来源——可以上传本地文件、指向 Google Cloud Storage 路径，或填写公开网站 URL，系统会自动完成抓取、分块和向量化。
4. 在“扩展”（Extensions）模块添加需要的工具，例如搜索、计算、自定义 API 连接器；或者在代码中用函数调用（Function Calling）声明工具。
5. 在控制台右侧的对话面板输入真实问题测试，观察代理是否正确检索并回答；回答下方会展示引用的数据来源，便于核对。
6. 测试通过后，点击“发布”按钮选择部署方式，指向 Agent Engine 即可完成托管部署。
以下是一个最小可运行的 ADK 代理示例，定义了“查询天气”的函数调用，在本地即可启动调试：
本地调试通过后，用 gcloud CLI 或控制台上传代理目录到 Agent Engine，即可获得生产级托管运行。
# agent.py — 最小 ADK 代理from google.adk.agents import Agentfrom google.adk.models import Gemini def get_weather(city: str) -> str: """返回指定城市当前天气（演示函数）""" # 在实际项目中，这里替换为真实天气 API 调用 return f"{city} 当前 22°C，晴。" weather_agent = Agent( name="weather_agent", model=Gemini(model_name="gemini-2.0-flash"), description="查询天气的助手", instruction="你是天气助手，使用 get_weather 工具回答用户问题。", tools=[get_weather],) # 在终端执行 `adk web` 启动本地调试界面，即可与该代理对话
核心能力详解：4 大支柱
支柱一：Agentic RAG 与数据存储。Agent Builder 的检索增强不是“一次性把文档拼进提示词”，而是让代理自主决定何时检索、检索什么、检索几次。数据存储（Data Store）负责把企业知识库接入、分块和建立索引，搜索引擎支持语义检索与关键词混合检索。代理在推理过程中可多次调用检索工具，先查用户意图、再查具体条目，甚至跨多个数据源汇总结果——这就是“代理式检索增强”（Agentic RAG）与传统 RAG 的本质区别。
支柱二：代码优先的 ADK 编排框架。ADK（Agent Development Kit）是 Google 开源的 Python 代理框架，核心特性包括：基于 TypedSchema 的参数严格类型校验，编译期即可发现参数错误；支持顺序式、并行式、层级式三种多代理架构——层级式通过 transfer_to_agent 实现前台客服代理把工单转给后台专员代理；内置人工介入（Human-in-the-loop）机制，可在关键步骤暂停等待审批；自带评估工具包（Evals），可编写自动化评测用例验证代理行为。ADK 与 Agent Builder 共享同一套运行时，写好的代理可直接部署上云。
支柱三：函数调用与扩展生态。代理要落地必须能触达真实业务系统。Agent Builder 提供两层工具接入：一是函数调用（Function Calling），在 ADK 代码中用 Python 函数声明工具签名，模型自动决定调用时机和参数；二是扩展（Extensions），通过 OpenAPI 规范连接第三方 API 和 Google 企业服务，无需写代码即可把 Salesforce、Jira、BigQuery 等变成代理可调用的工具。扩展在控制台可视化配置，适合非深度开发场景。
支柱四：Agent Engine 托管运行时。Agent Engine 是 2025 年推出的代理生产运行环境，解决“代码写完怎么上线”的问题。它接管了部署、扩缩容和流量管理，内置定时任务（Cron）调度代理周期执行，内置执行轨迹（Traces）记录每一轮推理的工具调用与中间结果，内置评估框架对比不同版本代理的回答质量，支持灰度发布回滚。兼容 ADK、LangChain、LlamaIndex 构建的代理，意味着已有 LangChain 项目的团队也可以将代理迁入获得托管能力，而不必重写代码。
生产部署与监控：从上线到运维
部署方式一：Agent Engine 托管部署（推荐）。将 ADK 代理项目上传至 Agent Engine，平台自动处理容器化、负载均衡与高可用。部署后可在控制台创建定时任务（Cron），例如每天早上 8 点让代理自动汇总前一日销售数据并推送至钉钉或 Slack，无需自建调度器。评估功能支持对同一代理的多个版本运行同一组测试用例，对比回答质量后决定是否推送新版本，并将流量按比例灰度切换。
部署方式二：自管容器部署。如果 Agent 需要与现有微服务架构深度耦合，可将 ADK 代理打包为 Docker 镜像部署到 Cloud Run 或 GKE。此方式需要自己处理扩缩容、监控告警和版本管理，适合对运行时环境有特殊要求（如特定 CUDA 版本、私有网络）的场景。选择此路径时，ADK 的本地开发能力依然适用，只是把“部署目标”从 Agent Engine 换成了自己的容器服务。
可观测性。Agent Engine 部署的代理自动向 Cloud Logging 输出运行日志，每条日志包含会话 ID、代理版本和工具调用记录；Cloud Trace 可查看单次请求在模型调用、检索、工具调用三个环节的耗时分布，用于定位“慢在哪一步”；Cloud Monitoring 提供请求量、错误率、延迟等指标。生产建议：开启会话级日志留存以便事后审计，配置基于错误率的告警规则，并对检索召回率做周期性的离线评测，防止数据更新导致回答质量回退。
<p class="para-label">避坑清单：</p>
<ul class="dash-list"><li>区域先行：Agent Builder 和 Agent Engine 并非所有 GCP 区域可用，创建前在官方文档确认目标区域支持情况（如 us-central1、europe-west4），避免后期迁移成本。</li><li>IAM 权限默认最小化：代理能读取的数据范围由服务账号权限决定，权限过宽会直接导致数据越权访问，建议为代理创建专用服务账号并仅授予所需数据源的读取权限。</li><li>数据存储按量计费：文档写入 Data Store 后会产生索引存储费用，删除代理不会自动删除数据存储，需手动清理，否则持续产生账单。</li><li>ADK 与运行时版本对齐：本地 ADK 版本过旧可能导致上传 Agent Engine 时功能不兼容，部署前确认 google-adk 的版本号与 Agent Engine 支持版本一致。</li></ul>
| 维度 | Vertex AI Agent Builder | LangChain / LangGraph | Amazon Bedrock AgentCore | Azure AI Foundry Agent Service |
|---|---|---|---|---|
| 定位 | Google Cloud 全托管 Agent 平台 | 开源 LLM 应用编排框架 | AWS 全托管多代理运行时 | Azure 全托管代理服务 |
| 编排范式 | ADK 代码优先 + 控制台低代码混合 | Chain/Graph 状态机，代码自由度高 | 控制台建 Agent + SDK 管理运行时 | 云工作流 + 托管智能体运行时 |
| 类型约束 | ADK TypedSchema 运行时校验 | LangGraph 状态图 + Pydantic | Python 参数定义 + 运行时校验 | JSON Schema 入参定义 |
| 学习曲线 | 中等（需 GCP 基础） | 陡峭（生态碎片化，片断多） | 中等（需 AWS 知识） | 中等（需 Azure 知识） |
| 生态集成 | 深度集成 BigQuery、Cloud Run、Firestore 等 | 数千第三方工具集成，云无关 | 深度集成 AWS 服务与 Lambda | 深度集成 Microsoft 365 与 Azure 服务 |
| 生产部署 | Agent Engine 全托管，含调度与评估 | 自行部署容器或接入云托管的 Agent 服务 | Bedrock 全托管多代理运行时 | Azure 全托管，含监控与治理 |
| License | 平台闭源 SaaS；ADK 开源 Apache 2.0 | MIT 开源 | 闭源 SaaS | 闭源 SaaS |
| 适合谁 | Google Cloud 用户、追求托管运维的团队 | 重自由度、需跨云移植的团队 | AWS 用户、多代理规模化的团队 | Microsoft 生态企业、需求合规治理的团队 |
选型建议：已有的云厂商绑定是首要决策因素——在 Google Cloud 上就选 Agent Builder，在 AWS/Azure 上则分别选 AgentCore 和 Agent Service，可获得最顺滑的托管体验。若团队需要跨云移植或高度自定义编排逻辑，LangChain/LangGraph 仍是最灵活的选择，但要接受自行承担部署运维成本。多代理规模化和内置评估能力是 Agent Engine 的差异化优势，对生产级多代理场景优先考虑。
版本迭代
Agent Builder 的演进主线是从“检索 + 对话”走向“完整 Agent 生命周期管理”。2023 年以 Vertex AI Search/Conversation 起步，2024 年 5 月整合为 Agent Builder GA，同年 12 月开源 ADK 框架，2025 年 5 月推出 Agent Engine 托管运行时，产品重心转向代码优先开发与生产运维一体化。（截至训练数据，Agent Engine 已进入 GA 阶段，可能已有更新版本）
| 版本 | 时间 | 变化 | 提升 |
|---|---|---|---|
| Vertex AI Search / Conversation（Preview） | 2023-11 | 生成式搜索与对话服务 | 提供企业数据接入、语义检索与多轮对话，Agentic RAG 雏形 |
| Vertex AI Agent Builder（GA） | 2024-05 | Agent Builder 正式一般可用 | 统一控制台，新增 Agent 库、函数调用（Function Calling）、扩展（Extensions），支持数据存储接入 |
| Agent Development Kit（ADK）开源 | 2024-12 | 开源 Python 代理开发框架 | Apache 2.0 协议，TypedSchema 类型约束、多代理架构、人工介入机制，与 Agent Builder 部署打通 |
| Vertex AI Agent Engine（发布） | 2025-05 | 全托管 Agent 运行时上线 | 内置定时任务（Cron）、执行轨迹追踪、自动化评估，兼容 ADK、LangChain、LlamaIndex 代理 |
版本演进揭示了两条主线：一是开发方式从控制台拖拽转向代码优先（ADK），让复杂代理逻辑可版本化管理、可本地调试；二是部署方式从用户自管容器转向 Agent Engine 全托管，把调度、评估、可观测性内建进平台。对选型的影响是：新项目应直接采用 “ADK 本地开发 + Agent Engine 托管部署”的组合，而不是从控制台拖拽开始；已有 LangChain 代理的团队也能平迁到 Agent Engine 获得托管能力，无需重写。
AI 应用场景
场景一：企业知识库问答（Agentic RAG）
阶段：RAG 管道构建 / 文档智能
解决的问题：传统做法需要自建文档解析、向量化、检索、重排整条链路，且一次检索往往召回不准。Agent Builder 的数据存储自动完成数据接入与索引，代理可自主决定多轮检索策略——先定位部门，再查具体制度条文，并引用来源回答，显著降低搭建成本。
具体案例：某企业内部支持团队将上千份 HR 与 IT 政策文档接入数据存储，员工通过对话入口直接提问。相比人工翻查文档，平均响应时间从小时级降至分钟级，且每条回答附有文档来源，可追溯、可审计，减少了支持工单量。
场景二：多代理售后工单自动化
阶段：Agent 编排 / 多代理协作
解决的问题：售后服务涉及意向确认、订单查询、退款审批多个环节，单代理难以覆盖全部职责。ADK 的层级式多代理架构让前台代理负责接待与意图判断，通过 transfer_to_agent 将复杂工单转交后台退款代理，退款代理在审批节点暂停等待人工介入。
具体案例：某电商售后团队将退款申请流程交给多代理处理。前台代理完成用户身份与订单核实，后台代理检查退货条件并生成退款建议单，超过设定金额时自动暂停转人工审批。整体处理时长较原先人工流转明显缩短，人工只需处理异常单。
场景三：定时数据分析与报告推送
阶段：Agent 编排 / 生产部署
解决的问题：周期性报表依赖人工从数据库取数、汇总、生成日报，重复且耗时。Agent Engine 的定时任务（Cron）调度能力让代理按设定时间自动运行，连接 BigQuery 等数据源生成分析结果并推送至协作平台。
具体案例：某运营团队配置了一个每日早间运行的代理，自动查询前一日核心业务指标、对比目标完成率并生成简短文字简报，推送到团队群。原先分析师每天花费约一小时完成的重复工作被压缩到几乎为零，分析师的精力转向深度分析。
常见误区
误区「Agent Builder 就是一个调用 Gemini 的接口，我直接用它生成回答就行，和用 Vertex AI 的模型端点没什么区别。」
正解Agent Builder 是 Agent 构建与托管平台，不是单纯的模型调用入口。它的价值在于检索、工具调用、编排和部署这一整条链路的托管：数据存储负责让代理“有据可查”，ADK 负责让代理“有逻辑可循”，Agent Engine 负责让代理“稳定上线”。只用它来调模型，等于买了整个平台却只用了其中 5% 的能力。
为何常见：Agent Builder 的界面以对话演示为入口，初次使用者容易把它和模型聊天界面混淆，忽略了后台的数据接入和编排配置。
误区「ADK 是 Google 开源的一个玩具框架，Agent Builder 才是正式产品，两者选一个用就行。」
正解两者是开发与部署的先后关系：ADK 负责本地编写、调试和测试代理，Agent Builder 的 Agent Engine 负责云端托管部署。ADK 的 Agent 定义可直接上传到 Agent Engine 运行，统一运行时意味着本地行为与线上行为一致。正确用法是“本地用 ADK 写，云端用 Agent Engine 跑”，而不是二选一。
为何常见：两套产品名称不同（一个是 GitHub 开源仓库，一个是云控制台入口），且 ADK 以正式版持续迭代，容易被误认为是独立竞品。
误区「Agent Builder 不是有可视化界面吗？我不用写代码，拖拖拽拽就能做出生产级 Agent。」
正解控制台适合快速验证数据接入效果和配置扩展，但生产级代理的复杂逻辑（多代理流转、条件分支、人工介入、自定义评估）都需要通过 ADK 代码实现。控制台配置的数据存储和扩展可以在 ADK 代码中引用，但编排逻辑本身是代码。Google 的官方推荐路径是代码优先（Code-first），控制台是辅助层而非替代层。
为何常见：产品名含 “Builder“ 且控制台确实提供低代码入口，给初学者的第一印象是可完全可视化操作，官方文档中的代码示例又加剧了”需要编程”的认知反差。
误区「代理配好了就行，它能搜到企业数据是平台的能力，我不用管权限。」
正解Agent 能检索到什么数据，完全取决于运行时服务账号和调用者身份被授予的权限。如果给代理的服务账号配置了过宽的角色（如对存储桶授予全部读写），代理可能检索或泄露超出业务范围的数据。正确的做法是为每个代理创建最小权限的服务账号，按需授予数据源读取权限，并在生产环境开启审计日志。
为何常见：控制台演示环境下权限已被预先配置好，用户直接体验“开箱即用”，就忽略了真正上线时需要显式配置身份与权限这一环。
误区「RAG 不就是把相关文档检索出来拼到提示词里让模型读吗？Agent Builder 也就是自动做了这件事。」
正解传统 RAG 是“一次检索，固定注入”，而 Agentic RAG 是代理在推理过程中自主决定检索时机与次数：先判断需要什么信息、执行检索、根据结果决定是继续检索还是调用工具还是直接回答。Agent Builder 的数据存储支持这种多轮检索，代理可以用一个问题引导出多个检索动作并综合多源信息，回答质量和复杂问题处理能力都高于单次注入。
为何常见：“检索 + 拼提示词”是大多数 RAG 教程的基本形态，初学者容易把 Agentic RAG 理解为同一件事的自动化，忽略了“自主决策检索策略”这一核心差异。
面试题
Q1. Vertex AI Agent Builder 的核心定位是什么？
- A.大模型训练平台
- B.全托管 Agent 构建平台← 正确答案
- C.向量数据库托管服务
- D.前端应用托管服务
答案：B。Agent Builder 的核心定位是 Agent 的构建与托管平台，覆盖数据接入、检索、工具调用、编排和部署全链路。它不是训练平台（A），不是数据库服务（C），也不负责前端托管（D）。选项 B 准确描述了它的本质。
Q2. Agent Development Kit（ADK）采用的开源协议是？
- A.MIT 协议
- B.GPL-3.0 协议
- C.Apache 2.0 协议← 正确答案
- D.BSD-3-Clause 协议
答案：C。ADK 以 Apache 2.0 协议开源，允许商业使用、修改和再分发，是宽松型开源协议。MIT 和 BSD 也属于宽松协议但不是 ADK 采用的；GPL-3.0 具有强传染性，与 ADK 的实际协议不符。
Q3. 将 ADK 构建的代理部署到 Google Cloud 生产环境的推荐方式是？
- A.部署到 Agent Engine 托管← 正确答案
- B.部署到 Firestore 数据库
- C.发布到 Docker Hub 镜像
- D.部署到 Cloud Pub/Sub 队列
答案：A。Agent Engine 是 ADK 代理的官方托管部署目标，提供调度、评估与可观测能力。Firestore 是数据库、Docker Hub 是镜像仓库、Pub/Sub 是消息队列，均非代理运行环境，无法执行代理逻辑。
Q4. 传统 RAG 与 Agentic RAG 在检索行为上的关键区别是什么？
- A.传统 RAG 不使用向量检索
- B.代理可自主多次检索并调用工具，传统 RAG 通常一次检索固定注入← 正确答案
- C.Agentic RAG 不使用大模型生成回答
- D.传统 RAG 无法生成文本回复
答案：B。Agentic RAG 的核心是代理在推理循环中自主决定检索时机和次数，并可结合工具调用综合多源信息；传统 RAG 是一次检索后把结果拼入提示词。A、C、D 都与实际技术实现不符。
Q5. Agent Engine 为生产环境提供的内置能力不包括哪项？
- A.定时任务调度（Cron）
- B.执行轨迹追踪（Traces）
- C.自动化评估与灰度发布
- D.大模型参数微调训练← 正确答案
答案：D。Agent Engine 提供调度、追踪、评估和灰度能力，是代理的托管运行时。模型微调属于 Vertex AI 训练服务的范畴，不由 Agent Engine 承担。其余三项均为 Agent Engine 的文档明确记载能力。
Q6. ADK 中 TypedSchema 机制解决的核心问题是什么？
- A.加快模型推理速度
- B.对工具参数进行类型约束校验← 正确答案
- C.自动压缩上下文窗口
- D.减少 token 计费成本
答案：B。TypedSchema 对工具函数的入参和返回值做严格的运行时类型校验，在开发期即可发现参数类型错误，避免模型产生非法工具调用。它不涉及推理速度（A）、上下文压缩（C）或成本优化（D）。
Q7. ADK 支持的多代理架构模式包括哪些？
- A.顺序式（Sequential）← 正确答案
- B.并行式（Parallel）← 正确答案
- C.层级式（Hierarchical）← 正确答案
- D.递归式（Recursive）
答案：ABC。官方文档明确的多代理架构为顺序式、并行式和层级式三种。层级式通过 transfer_to_agent 实现代理间任务转交。递归式不是 ADK 支持的官方架构模式，故不选。
Q8. Agent Builder 中接入企业数据的正确途径有哪些？
- A.创建数据存储并上传本地文件← 正确答案
- B.指向 Cloud Storage 路径接入← 正确答案
- C.配置公开网站 URL 抓取← 正确答案
- D.直接在对话面板粘贴全文
答案：ABC。数据存储（Data Store）的官方数据源包括本地文件上传、Cloud Storage 和网站 URL 抓取。在对话面板粘贴全文只是单次对话内容，不会建立可复用的检索索引，不属于数据接入方式。
Q9. 关于 ADK 与 Agent Engine 的关系，正确的说法是？
- A.ADK 是本地开发框架，Agent Engine 是全托管运行时← 正确答案
- B.ADK 构建的代理可直接部署到 Agent Engine 运行← 正确答案
- C.Agent Engine 与 ADK 相互独立，需要自行做适配
- D.Agent Engine 只支持 LangChain 代理部署运行
答案：AB。ADK 与 Agent Engine 共享统一运行时，本地写的代理可直接上传部署，A、B 正确。C 错误在于两者是配套关系无需额外适配；D 错误在于 Agent Engine 同时支持 ADK、LangChain 和 LlamaIndex 的代理。
Q10. 某代理需要“每日定时生成报表并推送”，以下哪种方案最符合架构最佳实践？
- A.在代理代码中写死时间判断逻辑
- B.使用 Agent Engine 的 Cron 定时任务调度代理← 正确答案
- C.由用户在每天固定时间手动点击运行
- D.在 Firestore 设置定时触发器运行代码
答案：B。Agent Engine 内置 Cron 调度，是官方推荐的定时触发方案，与托管运行、监控和计费体系打通。写死在代码中无法动态管理（A），手动运行不具可扩展性（C），Firestore 的触发器面向数据库文档变更而非定时任务（D）。