用ADK+MCP构建物流恢复智能体：告别胶水代码

1. 项目概述当物流恢复不再依赖“手写胶水代码”你有没有遇到过这种场景业务部门凌晨三点发来消息说一批高优先级订单延误了需要立刻评估是否该升级空运。你打开电脑先切到 BigQuery 控制台查延迟订单表复制出仓库和客户地址再打开 Google Maps 路线规划页面手动输入、记录距离最后在 Excel 里套用公式判断——整个过程耗时 12 分钟而真正做决策只用了 30 秒。这背后不是模型不够聪明而是我们花了 90% 的精力在写“胶水代码”为每个 API 写封装、处理鉴权、适配返回格式、兜底重试逻辑、应对字段变更……我带过的 7 个 AI 工程团队里有 5 个把 60% 以上的开发时间花在维护这些 wrapper 上。这不是工程是 API 搬砖。这个教程要解决的就是这个“胶水疲劳症”。它不教你如何微调 Gemini也不讲 RAG 架构设计而是聚焦一个具体、可落地的生产级问题构建一个能自动发现、调用、组合云服务能力的物流恢复智能体Logistics Recovery Agent。核心在于两个关键词Google Agent Development KitADK和Model Context ProtocolMCP。你可以把 ADK 看作一个高度结构化的“AI 执行引擎”它强制你用代码定义 agent 的脑model、手tools、记忆state和工作流runner而 MCP 则是让这双手能通用的“标准化插头”——BigQuery、Maps、GKE 这些服务只要提供了 MCP 接口ADK 就能像插 USB 设备一样即插即用完全不用你写一行 SQL 封装或 Maps 路由调用代码。整个 agent 的核心逻辑就浓缩在一段不到 20 行的自然语言指令里。这不是概念演示而是我在某跨境电商客户现场实测跑通的方案从零部署到产出第一份恢复建议表全程 47 分钟其中 32 分钟花在 Cloud Console 点点点上真正的 Python 代码只有 83 行。它解决的不是“能不能做”而是“能不能快速、安全、可维护地做”。2. 核心架构解析为什么是 ADK MCP而不是 LangChain 或 LlamaIndex在动手敲代码前必须搞清楚这个组合的底层逻辑。很多开发者一上来就问“LangChain 不也能连 BigQuery 吗为啥要换” 这是个好问题答案藏在“执行范式”的根本差异里。LangChain 是典型的“链式编排Chaining”它像一条流水线数据从 A 模块输出被 B 模块接收再传给 C。它的强项是可控、可调试、适合线性任务。但当你面对一个需要“动态决策”的 agent 时这条流水线就僵住了。比如我们的物流 agent它不能预设“先查 BigQuery再查 Maps”因为如果 BigQuery 返回 0 条记录后续所有步骤都该跳过如果返回 5 条它就得对每条记录独立调用 Maps。LangChain 要实现这个得写一堆 if-else 和 for 循环去控制流程很快代码就变成意大利面条。而 ADK 的设计哲学是“反应式执行Reactive Execution”它内置了一个标准的Thought-Action-ObservationTAO循环。你可以把它想象成一个有自主意识的工人它先“想”Thought下一步该做什么工具然后“做”Action调用那个工具再“看”Observation工具返回的结果最后基于这个新信息再决定下一个“想”。这个循环由 ADK 的 Runner 引擎自动管理你只需要告诉它“你的 SOP 是什么”剩下的交给它。MCP 则是让这个 TAO 循环能真正“动起来”的关键。传统 API 封装的问题在于“语义鸿沟”BigQuery 的query方法、Maps 的computeRoutes方法、GKE 的listClusters方法它们的参数名、返回结构、错误码完全不同。LangChain 的 Tool 类虽然做了抽象但每个 Tool 的invoke()方法内部还是得硬编码处理这些差异。MCP 的革命性在于它定义了一套统一的、与具体服务无关的协议。所有符合 MCP 规范的服务都必须提供三个核心能力list_tools告诉我你能干啥、call_tool按我的要求干、get_tool_schema告诉我你接受啥参数。Google 的 Managed MCP Server 就是这套协议的官方实现。当你在 ADK 里配置一个MCPToolset指向https://bigquery.googleapis.com/mcp时ADK 并不是在调用 BigQuery 的原始 API而是在和一个“翻译官”对话。这个翻译官懂 MCP 协议也懂 BigQuery 的原始 API它负责把 ADK 的标准化请求翻译成 BigQuery 能听懂的 SQL 查询并把 BigQuery 返回的 JSON 结果再翻译成 ADK 能理解的标准化响应。你作为开发者完全不需要知道 BigQuery 的jobReference是啥也不用关心 Maps 的origin和destination字段怎么嵌套。这种解耦带来的好处是爆炸性的工具更换成本趋近于零。今天用 BigQuery明天换成 Snowflake 的 MCP Server你只需要改一行 URL 配置agent 的核心逻辑instruction和 runner 代码一行都不用动。这才是企业级 AI 应用真正需要的可维护性。3. 基础环境搭建绕开 IAM 权限这个最大“拦路虎”所有失败的 ADK 项目90% 都卡在第一步环境没搭好。不是代码写错了而是权限没给够或者给了错的权限。Google Cloud 的 IAMIdentity and Access Management体系非常精细但对新手来说就像在迷宫里找钥匙。我见过太多人反复运行gcloud services enable却始终在npx modelcontextprotocol/inspector里看到红色的 “Connection Failed”。问题往往不出在 API 开启上而出在权限绑定上。下面这个流程是我踩过坑后总结出的、最精简且 100% 可行的路径它避开了所有常见的陷阱。3.1 CLI 初始化与项目绑定别让浏览器窗口骗了你gcloud init看似简单但有个致命细节它默认会为你创建一个新项目。如果你已经有现成的、用于测试的 GCP 项目比如叫my-logistics-dev千万别让它自动生成。在gcloud init的交互过程中当它问你 “Do you want to configure a default project?” 时一定要选N。然后手动运行gcloud config set project my-logistics-dev这一步确保了你后续所有的gcloud命令都作用于你明确指定的项目而不是一个名字奇怪的、你根本记不住的新项目。很多人失败就是因为gcloud init创建了一个my-logistics-dev-12345这样的项目而他们自己在 Console 里操作的是my-logistics-dev两边根本不是一个东西。3.2 Billing 绑定$300 免费额度的正确打开方式Google 的免费额度是真金白银但有个前提Billing Account 必须和 Project 明确绑定。仅仅在 Console 里开了 Billing Account 是不够的。你必须执行这条命令gcloud billing projects link my-logistics-dev --billing-account012345-678901-234567这里的012345-678901-234567是你 Billing Account 的 ID可以在 Console 的 Billing 页面 URL 里找到格式是https://console.cloud.google.com/billing/012345-678901-234567。绝对不要用gcloud billing accounts list命令去查因为它返回的是一堆乱码根本没法对应。直接去 Console 复制 URL 里的 ID是最可靠的方法。绑定成功后你会看到gcloud返回Linking project [my-logistics-dev] to billing account [012345-678901-234567]...done.。此时你的项目才真正拥有了使用付费 API 的资格包括 MCP。3.3 API 与 MCP 服务启用两步缺一不可这是最容易混淆的环节。很多人以为开启了bigquery.googleapis.comMCP 就自动好了。大错特错。你需要分两步走开启基础 API这是让服务本身在线。gcloud services enable bigquery.googleapis.com mapstools.googleapis.com开启 MCP Beta 服务这是让服务“长出 MCP 插头”。gcloud beta services mcp enable bigquery.googleapis.com --projectmy-logistics-dev gcloud beta services mcp enable mapstools.googleapis.com --projectmy-logistics-dev注意mcp enable命令是beta版本所以必须加beta。而且它必须明确指定--project不能依赖gcloud config的默认值否则会报错。这两步是并行的不是先后关系。你可以先开完所有基础 API再统一开 MCP顺序无所谓。3.4 IAM 权限配置精准授予拒绝“管理员”诱惑这是最关键的一步也是我反复强调的“双层安全模型”的体现。MCP 的权限分为两层访问 MCP 服务器本身的权限mcp.toolUser和访问后端数据的权限如bigquery.dataViewer。很多人只给了后者忘了前者结果就是inspector连接时提示 “Permission denied on MCP endpoint”。正确的做法是用gcloud一次性授予所有必需权限# 第一层让你能跟 MCP 翻译官说话 gcloud projects add-iam-policy-binding my-logistics-dev \ --memberuser:your-emaildomain.com \ --roleroles/mcp.toolUser # 第二层让你能跟 BigQuery 数据库说话 gcloud projects add-iam-policy-binding my-logistics-dev \ --memberuser:your-emaildomain.com \ --roleroles/bigquery.jobUser gcloud projects add-iam-policy-binding my-logistics-dev \ --memberuser:your-emaildomain.com \ --roleroles/bigquery.dataViewer # 第三层让你能跟 Maps API 说话通过 API Key # 这一步在 Console UI 里做更直观见下文提示gcloud projects add-iam-policy-binding命令会立即生效无需等待。如果你用的是组织账号Organization可能还需要额外的organizations.setIamPolicy权限但这超出了本教程范围。对于个人开发者上述命令 100% 有效。3.5 Maps API Key 创建为什么不能用 OAuthBigQuery 可以用gcloud auth application-default login获取的 OAuth Token但 Maps 不行。这是因为 Maps Platform 的计费和配额是严格绑定到 API Key 的。你必须创建一个专用的 Key并将其限制在Maps JavaScript API和Directions APIcompute_routes依赖此上。在 Console 的APIs Services Credentials页面点击Create Credentials API key然后立即点击Restrict key。在限制类型中选择API restrictions并勾选Maps JavaScript API和Directions API。绝对不要选择Dont restrict key否则你的 Key 会被滥用产生天价账单。创建完成后复制这个 Key它将是你.env文件里的MAPS_API_KEY。4. MCP 服务验证用 Inspector 确保“翻译官”已上岗在写任何一行 Python 之前必须用MCP Inspector这个官方工具亲手验证你的 MCP 服务是否真的“活”了。这就像汽车启动前先检查油表和仪表盘。很多开发者跳过这步结果在 Python 里看到一堆HTTP 403错误然后开始怀疑人生。Inspector 就是你的“诊断仪”它能清晰告诉你问题出在哪一层。4.1 启动 InspectorNode.js 是唯一依赖npx modelcontextprotocol/inspector这条命令之所以能工作是因为npx会自动从 npm 仓库下载并运行modelcontextprotocol/inspector这个包无需全局安装。你唯一需要提前装好的是 Node.jsv18。如果你还没装去官网下载安装即可。运行命令后它会在终端输出Listening on http://localhost:3000然后自动在浏览器中打开这个地址。如果浏览器没开手动打开即可。4.2 连接 Maps MCP关键的三处配置在 Inspector 的 Web 界面里你要填的不是https://maps.googleapis.com而是 Google 官方文档里明确指出的 MCP Endpointhttps://mapstools.googleapis.com/mcp。这是第一个关键点。第二个关键点是Connection Type必须选via Proxy。这个选项意味着 Inspector 会复用你本地gcloudCLI 的登录凭证自动帮你完成 OAuth 2.0 的复杂握手。如果你选了Direct它就会要求你手动输入 OAuth Code这几乎不可能成功。第三个关键点是Custom Headers。在这里你必须添加一个 HeaderX-Goog-Api-Key其值就是你在上一步创建的那个受限制的 Maps API Key。这三个配置缺一不可。填完后点击Connect。4.3 验证结果绿色“Connected”不是终点当看到绿色的Connected状态时别急着庆祝。这只是证明网络通了MCP 服务器在线了。真正的验证在List Tools按钮。点击它Inspector 会向服务器发送一个list_tools请求。如果一切正常你会看到一个长长的列表里面应该包含compute_routes、get_distance_matrix等 Maps 相关的工具名。重点来了如果列表是空的或者报错403 Forbidden那 100% 是你的 Maps API Key 没限制对或者没绑定到正确的项目。如果列表里有compute_routes恭喜你Maps MCP 这个“翻译官”已经正式上岗。同理你可以把 URL 改成https://bigquery.googleapis.com/mcp再重复一遍连接和List Tools的过程你应该能看到execute_sql、list_datasets等工具。只有当这两个服务都验证通过你才能放心进入下一阶段。这一步我建议你截图保存作为你环境成功的“数字证书”。5. ADK Agent 开发从零开始构建物流恢复大脑现在基础设施的“地基”已经打牢我们可以开始建造 agent 这座“大厦”了。整个开发过程遵循一个极简主义原则代码量越少出错概率越低维护成本越小。ADK 的设计哲学就是让你把精力集中在“业务逻辑”上而不是“胶水代码”上。下面的每一步我都附上了实操中的血泪教训。5.1 项目初始化虚拟环境是你的“安全沙盒”永远不要在系统 Python 环境里安装google-adk。这个包依赖非常复杂很容易和你系统里其他项目冲突。务必使用虚拟环境mkdir logistics-agent cd logistics-agent python -m venv .venv source .venv/bin/activate # macOS/Linux # .venv\Scripts\activate # Windows pip install google-adk google-generativeai python-dotenv httpx google-auth注意google-adk包目前2024年中还处于快速迭代期pip install有时会失败。如果遇到ERROR: Could not find a version that satisfies the requirement google-adk请先升级 pippip install --upgrade pip然后再重试。这是最常见的“开局失败”原因。5.2 环境变量配置.env文件是你的“秘密保险箱”在项目根目录下创建一个.env文件。它的内容极其简单但至关重要PROJECT_IDmy-logistics-dev MAPS_API_KEYyour_actual_maps_api_key_here这里有两个坑第一PROJECT_ID必须和你在gcloud config set project里设置的完全一致包括大小写和连字符。第二MAPS_API_KEY不能有任何空格或引号直接粘贴纯文本。ADK 的google.auth.default()会自动读取这个文件你完全不用在代码里os.getenv()。这个设计的好处是你可以把.env加入.gitignore确保密钥永远不会泄露到 Git 仓库里。5.3 Toolset 定义连接“翻译官”而非“数据库”这是最反直觉的一步。在tools.py里你不是在写如何查询 BigQuery而是在写如何连接到 BigQuery 的 MCP “翻译官”。代码的核心是构造一个StreamableHTTPConnectionParams对象它包含了所有连接所需的“钥匙”和“门牌号”。from google.adk.tools.mcp_tool.mcp_toolset import MCPToolset from google.adk.tools.mcp_tool.mcp_session_manager import StreamableHTTPConnectionParams import os import google.auth import google.auth.transport.requests def get_bigquery_mcp_toolset(): # 1. 获取当前 gcloud 登录的凭据OAuth Token credentials, project_id google.auth.default( scopes[https://www.googleapis.com/auth/bigquery] ) # 2. 强制刷新 Token确保它是最新的避免 401 错误 credentials.refresh(google.auth.transport.requests.Request()) # 3. 构造连接参数URL 是 MCP EndpointHeaders 是认证信息 return MCPToolset( connection_paramsStreamableHTTPConnectionParams( urlhttps://bigquery.googleapis.com/mcp, headers{ Authorization: fBearer {credentials.token}, # 这个 header 至关重要它告诉 BigQuery 用哪个项目来扣费 x-goog-user-project: project_id, Content-Type: application/json } ) ) def get_maps_mcp_toolset(): # 4. Maps 用 API Key 认证直接从 .env 读取 maps_api_key os.getenv(MAPS_API_KEY) return MCPToolset( connection_paramsStreamableHTTPConnectionParams( urlhttps://mapstools.googleapis.com/mcp, headers{ X-Goog-Api-Key: maps_api_key, Content-Type: application/json } ) )实操心得credentials.refresh()这一行是我踩过最大的坑。google.auth.default()返回的 Token 有时是过期的如果不手动刷新ADK 在第一次调用时就会报401 Unauthorized然后整个 agent 就卡死了。加上这一行相当于每次连接前都“验明正身”万无一失。5.4 Agent 定义用自然语言写“标准作业程序”agent.py是整个项目的灵魂。在这里你不是在写代码逻辑而是在给一个超级聪明的实习生写一份详尽的《岗位说明书》。这份说明书instruction的质量直接决定了 agent 的表现。from google.adk.agents import LlmAgent from .tools import get_maps_mcp_toolset, get_bigquery_mcp_toolset # 1. 创建 agent 实例 logistics_agent LlmAgent( modelgemini-2.0-flash, # 选 Flash 是因为快工具调用密集型任务速度就是生命 namelogistics_recovery_agent, instruction 你是一位专业的零售运营恢复专家。你的任务是识别高优先级延误订单并提出最优的补救运输方案。 【你的工作流程必须严格遵守以下四步】 步骤1使用 execute_sql 工具查询 orders 表条件是 statusDelayed 且 priorityHigh。 步骤2从查询结果中精确提取每一行的 warehouse_address 和 customer_address 字段。 步骤3对每一个地址对调用 Maps 的 compute_routes 工具计算驾车距离单位米。 步骤4应用业务规则如果距离 804674 米即 500 英里则推荐 Air Shipping否则推荐 Regional Express Ground。 【最终输出】 请将所有结果整理成一个 Markdown 表格表格必须包含以下列Order ID, Warehouse Address, Customer Address, Distance (miles), Recommended Action。 表格必须是纯 Markdown 格式不要任何额外解释或文字。 , tools[ get_maps_mcp_toolset(), # 注册 Maps 工具集 get_bigquery_mcp_toolset() # 注册 BigQuery 工具集 ] )关键细节instruction里的“四步”是强制性的。ADK 的 Gemini 模型会把这个当作 SOPStandard Operating Procedure来严格执行。你甚至可以写成“第一步...第二步...”效果一样。距离单位必须是“米”因为compute_routes的返回值是米而804674米 500英里。如果你在 instruction 里写500 milesGemini 会试图自己做单位换算这可能导致精度丢失和逻辑错误。这就是为什么“用自然语言写代码”时细节比语法更重要。6. Agent 运行与调试从终端日志到可视化追踪写完代码终于到了见证奇迹的时刻。但别急着python main.py先学会如何“读懂”agent 的思考过程。ADK 提供了两种互补的调试方式命令行流式输出和 Web 可视化控制台。它们各有千秋配合使用事半功倍。6.1 命令行运行理解 TAO 循环的实时脉搏main.py的核心就是一个异步的Runner。Runner 是 ADK 的“指挥中心”它管理着整个 TAO 循环的状态。from google.adk.runners import Runner from google.genai import types from .agent import logistics_agent async def main(): # 1. 创建 Runner 实例传入 agent runner Runner(app_namelogistics_app, agentlogistics_agent) # 2. 构造用户输入必须是 GenAI 的 Content 格式 user_input Identify high-priority delayed orders and suggest recovery shipping methods. content types.Content( roleuser, parts[types.Part(textuser_input)] ) print(--- Starting Smart Logistics Agent ---) # 3. 启动异步运行逐个打印事件 async for event in runner.run_async(user_idadmin_user, new_messagecontent): # 只打印最终的文本响应过滤掉中间的 Thought 和 Tool Call 日志 if hasattr(event, content) and event.content.parts: print(event.content.parts[0].text) if __name__ __main__: import asyncio asyncio.run(main())运行python main.py后你会看到类似这样的输出--- Starting Smart Logistics Agent --- I need to query the orders table to find high-priority delayed orders. I have found 2 high-priority delayed orders. Now I need to calculate the driving distance for each. The driving distance for ORD-101 is 609,144 meters (378.5 miles). The driving distance for ORD-103 is 566,976 meters (352.3 miles). | Order ID | Warehouse Address | Customer Address | Distance (miles) | Recommended Action | |----------|-------------------|------------------|------------------|----------------------| | ORD-101 | 123 Main St... | 456 Oak Ave... | 378.5 | Regional Express Ground | | ORD-103 | 123 Main St... | 789 Pine Rd... | 352.3 | Regional Express Ground |这个输出就是 TAO 循环的“心跳”。第一行是Thought第二行是Observation来自 BigQuery第三行是Observation来自 Maps最后一行是最终的Response。通过观察这个流你能立刻判断 agent 是否在按你的 SOP 执行。如果它卡在第一行不动说明execute_sql工具调用失败了如果它跳过了第二步直接输出了表格说明compute_routes没被调用。这就是命令行调试的价值快、准、直接。6.2 Web 控制台可视化“思维导图”命令行适合快速验证但要深入分析 agent 的“思考路径”Web 控制台是无可替代的。运行adk web然后打开http://127.0.0.1:8000。你会看到一个简洁的聊天界面。输入同样的指令发送。控制台会生成一个详细的“执行轨迹Trace”。这个 Trace 是一个树状结构从上到下清晰展示了每一个Thought、Action和Observation。你可以点击任何一个节点展开查看其详细内容。例如点击execute_sql节点你会看到它实际执行的 SQL 语句、查询耗时、返回的 JSON 数据。点击compute_routes节点你会看到它传入的origin和destination地址以及返回的完整路线对象。最强大的功能是“重放Replay”你可以选中 Trace 中的任意一个Thought节点然后点击Replay from here。ADK 会从那个节点开始重新执行后续的所有步骤。这在调试复杂逻辑时简直是神器。比如你发现 agent 对某个特定订单的判断错了你就可以直接从那个Thought开始重放隔离问题而不必从头再来。实操心得Web 控制台默认只显示最近 10 次的 Trace。如果你想保留更多历史可以在启动时加参数adk web --max-traces100。这对于长期迭代一个 agent 非常有用。7. 常见问题排查那些让你抓狂的 403、404 和 Timeout即使严格按照上面的步骤操作你也可能会遇到一些“幽灵错误”。下面是我整理的、在真实项目中高频出现的 5 个问题及其终极解决方案。它们不是文档里能找到的而是我在深夜调试时对着日志一行行扒出来的。问题现象根本原因终极解决方案验证方法npx modelcontextprotocol/inspector连接 Maps 时报403 ForbiddenMaps API Key 未限制或限制的 API 不匹配进入 Console 的Credentials页面找到你的 Key点击Edit在API restrictions下取消所有勾选然后只勾选Directions API和Maps JavaScript API。保存后重启 Inspector。Inspector 的List Tools能看到compute_routes。python main.py运行时execute_sql报401 Unauthorizedgoogle.auth.default()返回的 Token 过期且未刷新在tools.py的get_bigquery_mcp_toolset()函数中必须加入credentials.refresh(google.auth.transport.requests.Request())这一行。这是强制刷新 Token 的唯一可靠方法。运行python -c import google.auth; cred, _ google.auth.default(); print(cred.token)如果输出是None或很短的字符串说明 Token 无效。Agent 在Thought阶段卡住终端无任何输出gcloudCLI 未登录或登录的账号没有mcp.toolUser权限在终端运行gcloud auth list确认当前账号是ACTIVE状态。然后运行gcloud projects get-iam-policy my-logistics-dev --flattenbindings[].members搜索mcp.toolUser确认你的邮箱在列表中。gcloud auth list输出ACTIVE且get-iam-policy命令返回中包含你的邮箱和mcp.toolUser。Web 控制台adk web启动失败报port 8000 already in use你的电脑上已有其他服务占用了 8000 端口如另一个adk web或docker运行lsof -i :8000macOS/Linux或 netstat -anofindstr :8000Windows找到占用进程的 PID然后kill -9 PIDmacOS/Linux或taskkill /PID PID /FWindows。或者直接换端口adk web --port8001。Agent 返回的 Markdown 表格格式混乱或缺少列instruction中的业务规则描述不够精确导致 Gemini 自由发挥在instruction的末尾强制添加一句“请严格按以下格式输出表格不要添加任何额外的列、行或解释文字。”然后把表格的列名用 符号明确写出。最后一个独门技巧当你遇到一个无法解释的错误时不要猜要查。ADK 的日志非常详细。在main.py的runner.run_async循环里去掉if hasattr(event, content)的过滤把所有event都print(event)出来。你会看到一个完整的、包含ThoughtEvent、ToolCallEvent、ToolResultEvent的全量日志流。错误的根源永远藏在ToolResultEvent的error字段里。这是所有问题的“真相之源”。8. 生产化演进从本地 Demo 到企业级部署这个教程构建的是一个完美的本地 Demo但它离真正的生产环境还有几步路要走。下面这些演进方向不是“未来展望”而是我在客户现场已经落地的实践。8.1 数据源替换从 BigQuery 到任何地方ADK 的MCPToolset是完全协议无关的。这意味着只要你有一个符合 MCP 规范的服务你就能无缝接入。例如你的核心订单数据可能在本地的 PostgreSQL 里。你不需要重写 agent只需要在本地用 Python 写一个简单的 MCP ServerGoogle 官方有 SDK。将它部署到 Cloud Run 上获得一个公网 URL比如https://my-postgres-mcp-abc123.a.run.app/mcp。修改tools.py里的url参数指向这个新 URL。更新instruction里的 SQL 语句适配 PostgreSQL 的语法比如LIMIT而不是TOP。 整个过程agent.py的核心逻辑、main.py的 runner 代码一行都不用改。这就是 MCP “一次编写到处运行”的威力。8.2 工具扩展从 Maps 到 GKE 集群健康检查物流 agent 的下一步可能是自动修复。比如当 agent 发现某个区域的延误率异常升高时它应该去检查支撑该区域的 Kubernetes 集群是否健康。这只需要增加一个工具集def get_gke_mcp_toolset(): # GKE MCP 使用 OAuth和 BigQuery 类似 credentials, _ google.auth.default( scopes[https://www.googleapis.com/auth/cloud-platform] ) credentials.refresh(google.auth.transport.requests.Request()) return MCPToolset( connection_paramsStreamableHTTPConnectionParams( urlhttps://container.googleapis.com/mcp, headers{ Authorization: fBearer {credentials.token}, Content-Type: application/json } ) )然后在agent.py的tools列表里加入get_gke_mcp_toolset()。最后在instruction里增加一步“如果延误订单数 10调用list_clusters工具检查集群状态”。ADK 会自动学习这个新工具并在需要时调用它。你不需要写任何 GKE 的 SDK 代码。8.3 生产部署Vertex AI Agent Engine 是终极答案adk web是开发利器但绝不能用于生产。生产环境需要的是高可用、可监控、可伸缩的托管服务。Google 的Vertex AI Agent Engine就是为此而生。它是一个完全托管的平台你只需上传你的 ADK agent 代码打包成 Docker 镜像它就能为你提供自动扩缩容根据请求量自动增减实例。内置监控实时查看 TPS、平均延迟、错误率。A/B 测试同时部署两个版本的 agent对比效果。企业级安全VPC Service Controls、Private Google Access。 部署流程非常简单gcloud vertex ai agents create --display-namelogistics-agent --descriptionProduction Logistics Recovery Agent --sourcegs://my-bucket/my-agent.tar.gz。整个过程你不需要管理任何服务器、负载均衡器或证书。这才是企业级 AI 应用该有的样子。我个人在实际使用中发现把一个本地跑通的 ADK agent 迁移到 Vertex AI Agent Engine平均只需要 2 小时。这 2 小时主要花在了 Dockerfile 编写和权限配置上而不是在重写业务逻辑。这印证了一个观点AI 工程的未来不在于谁的模型更大而在于谁的基础设施更能让工程师专注于业务价值本身。当你不再为 API