在过去的一两年里，类似的“AI 魔法”在无数个科技展会上演。人们敲击几下键盘，或者输入一段自然语言，机器就能迅速吐出一段代码、一幅画作，甚至一个看似能自主思考的对话机器人。对于坐在台下的数千名开发者来说，这样的场景并不陌生。在各种黑客马拉松和社区论坛里，只要写几段 Prompt，挂载两三个外部搜索工具，拼凑几行 Python 脚本，一个简单的 Agent（智能体）Demo 很快就能在本地跑起来。
但当会场广播响起，Google Cloud GCP 与 SRE 总裁 Brad Calder 走上台时，话题迅速从炫酷的视觉秀切入到了冷硬的现实工程里。
前一天的主题演讲，Google Cloud 花了大量时间向企业高管们解释，为什么今天的大公司需要一套企业级的智能体平台。而到了第二天的 Developer Keynote，聚光灯终于打在了真正要徒手把这些系统建出来的开发者身上。
当一个在本地跑得通的 Agent Demo，试图接入拥有上万并发用户的生产环境时，开发者面对的不再是“模型聪不聪明”的问题。他们需要处理状态的丢失、工具调用的超时、API 密钥的泄露、长文本带来的 Token 爆炸，以及多个智能体在复杂任务中像无头苍蝇一样相互干扰的窘境。
Google Cloud 给开发者们准备了一张巨大的架构图。
从 Agent Development Kit (ADK) 到模型上下文协议（MCP），从 Agent Runtime 到 Agent Registry，再到负责观测的 Agent Observability 和负责底线安全的 Agent Gateway。
这张图里的每一个模块，都在指向同一个现实：当应用架构开始从函数、微服务、API，慢慢演变成一组会协作、会沉淀记忆、甚至会自我修复的智能体网络时，开发者每天面对的底层环境变了。
不再是拘泥于 AI 写代码有多快，而是把过去开发者需要自己东拼西凑、甚至无从下手的那一大块 Agent 运行基础设施，直接作为平台的默认能力端了出来。
▶ 16 分钟音频带开发者朋友们听完 Google Cloud Next 大会全程！
一场关于物理世界复杂约束的压力测试
Google Cloud 技术布道师团队 Emma Twersky 和 Richard Seroter 站在台上，调出了他们正在构建的模拟应用。屏幕上，拉斯维加斯的 3D 天际线被点亮，成百上千个代表跑者的光点在赛道上移动，甚至连旁边街道上缓慢行驶的模拟车流都清晰可见。
这个工程量绝不只是在地图上画一条线。路线的长度必须精确到 42.195 公里（或者 26 英里 385 码）；封锁某些路段会对整个城市的交通网产生连锁反应；必须考虑紧急救援路线的重新规划；沿途需要根据补给策略精准投放医疗帐篷、补水站，甚至是 500 个移动厕所；更棘手的是，系统还要应对非确定性的变量，比如历史数据显示，78% 的跑者会在马拉松的后半程掉速，这些微观行为的聚集，会对宏观环境产生什么影响？
把这样一个充满物理世界真实约束的任务交给系统，实际上是在进行一场压力测试。它把 Agent 从单一的“文本生成器”或“聊天助手”，逼到了必须进行复杂逻辑推演、空间计算和环境仿真的角落里。
开发者 Mofi Rahman 走上台，他的任务是构建这套系统里最基础的一个部件：Planner Agent（规划师智能体）。
如果按照传统的开发路径，Mofi 需要先仔细阅读 Google Maps 的 API 文档，处理繁琐的 OAuth 认证，编写请求经纬度数据的封装函数，再把获取到的数据喂给语言模型。但这次，他在 Agent Designer 中走了一条完全不同的路。
他打开了智能体设计器，给这个规划师智能体输入了一段关于马拉松规划的系统指令。接着，他需要让这个 Agent 具备地理空间计算的能力。Mofi 并没有写任何 API 对接代码，而是直接将智能体连接到了 Google Maps 的 MCP 服务器。
在这个新架构下，所有的 Google Cloud 服务都已经默认支持 MCP。这意味着平台已经在底层建立好了安全的通信隧道和标准化的工具定义。Mofi 只需要在代码里加几行配置，Agent 就立刻拥有了直接调取拉斯维加斯地标数据的能力。
随后，Mofi 引入了“技能（Skills）”的概念。一个技能包含 YAML 格式的元数据和 Markdown 格式的主体，元数据决定了 Agent 在什么上下文中才需要加载这项技能。他给 Planner 挂载了三个技能：一个地图技能，让它能选择性地调用 Google Maps；一个 GIS（地理信息系统）技能，允许 Agent 执行预置的 Python 脚本来处理 GeoJSON 数据，从而计算出一条起点和终点都合理的路线；最后是一个赛事总监技能。
这个“赛事总监技能”的来源尤其值得注意。Mofi 直接导入了一份真实世界里赛事策划委员会用来检查路线的文档。借助 Gemini，这份原本供人类阅读的历史经验文档，被无缝转化成了 Agent 可以直接执行的判断逻辑。
几分钟后，Mofi 将这个配置好的 Planner 部署到了 Agent Runtime 上。在 Emma 的模拟界面里，一条规划好的紫色路线在拉斯维加斯大道的地图上渲染了出来。此时的 Planner，已经不再是一个单纯的大语言模型，而是一个被 ADK（智能体开发套件）、地图工具和专业领域常识武装起来的模块化工程单元。
在传统的软件开发中，开发者习惯于编写一条从头跑到尾的线性逻辑，通过一层层的 if/else 和函数调用来校验结果。如果在单一的 Agent 里塞入所有的任务——既要画路线，又要评估对社区的影响，还要计算长度，最后还要模拟交通，这个 Agent 的上下文很快就会崩溃，它会陷入严重的“幻觉”，甚至忘记自己最初的任务是什么。
Casey West 和 Ivan Nardini 接过了演示的接力棒。他们的做法是，把这个庞大的任务拆解，构建一个由多个智能体组成的团队。
他们在原有的 Planner 之外，又引入了两个全新的角色：Evaluator（评估师）和 Simulator（模拟器）。
Evaluator 被设计成一个独立的子智能体。它的工作极其纯粹：不参与任何路线的生成，只负责拿一把标尺，对 Planner 产出的路线进行严苛的打分。
它使用一个独立的模型，拥有非常有限且聚焦的上下文，只盯着几个关键指标看——路线长度是不是分毫不差的 42.195 公里？社区影响如何？是否符合最初的 Prompt 要求？每一次 Planner 试图生成新计划，都必须像调用外部工具一样，把结果发给 Evaluator 进行校验。
Simulator 则负责另一个维度的任务。它接收获批的路线，配置环境变量，然后利用 Gemini Deep Research 学习到的现实世界人类跑步行为模式，在沙盒里生成成千上万个独立的跑者 Agent 会话，监控可能出现的交通拥堵，再把模拟结果反馈给 Planner。
这三个各自独立的 Agent，又是怎么在一个系统里配合起来的？
Ivan Nardini 在屏幕上调出了 Agent Registry（智能体注册表）。在多智能体系统中，如果还是靠开发者去硬编码写死 A 怎么调用 B，系统就会变得极其脆弱。Agent Registry 扮演了整个智能体网络的“DNS 解析中心”。
当 Planner 和 Simulator 被部署到 Agent Runtime 时，它们会自动在这个注册表里登记。每个 Agent 都会对外暴露一张 Agent Card（智能体卡片），这张卡片就是一份能力清单，告诉网络里的其他成员“我会做什么”。当 Planner 需要进行跑者模拟时，它不需要知道 Simulator 具体的 IP 地址或 API 接口，它只需要通过通用的 A2A（Agent-to-Agent）协议，在注册表中“发现”具备模拟能力的 Agent，并自动建立对话。
这种设计将系统内部的耦合度降到了最低。开发者从一个“写死每一行逻辑的实现者”，变成了“定义能力边界并让系统自行运转的编排者”。
随后，Casey 抛出了另一个前端开发领域的痛点。既然 Evaluator 已经给路线打出了详细的分数，这些多维度的数据该怎么展示给用户？如果按照以往的流程，前端工程师需要加班加点去写各种图表组件，对接评估数据接口，做一个定制化的 Dashboard。
但在台上的演示中，当评估完成后，UI 界面是直接在地图旁边“长”出来的。
Casey 展示了背后的秘密：一项名为 A2UI（Agent-to-User Interface）的开放标准。开发者只是在系统里提供了一个单样本（One-shot）的 UI 示例，告诉 Gemini 当前应用使用的通用设计语言规范。
当 Agent 拿到评估结果后，它没有吐出一大段干瘪的文本分析，而是直接理解了数据结构，动态调用了对应的图表和信息流组件，在地图引擎之上，为自己精确渲染出了一个交互式的评估结果面板。
前端组件被降维成了 Agent 可以调用的“词汇”。系统的输出边界，从纯数据层直接延展到了交互层。
当多个 Agent 能够相互协作后，系统面临的下一个巨大挑战是状态管理。
如果把 Agent 比作员工，过去我们使用大模型的方式，就像是在面对一个每次对话都会失忆的金鱼。为了让它了解当前的任务进展，开发者只能把之前发生的几十轮对话记录、长篇大论的背景资料，一股脑地全部塞进当前请求的 Prompt 里。这种做法不仅极其昂贵，而且随着上下文越来越臃肿，模型提取关键信息的能力会呈断崖式下降。
技术布道师 Lucia Subatin 和 Jack Wotherspoon 走上台，打开了 Antigravity IDE。他们的任务是解决 Planner 的“失忆症”。
Jack 敲下了不到 20 行代码，在 ADK 中为 Planner 引入了 Agent Platform Sessions（智能体平台会话）类。这几行代码改变了系统的工作方式：Agent 的运行不再是彼此孤立的请求响应，平台开始在底层维护一个时间轴，Agent 能够随着时间的推移保持状态，并在当前会话中根据需要修改上下文。
紧接着，他们把 Agent 挂载到了全托管的 Memory Bank（记忆库）服务上。这个服务比单纯保存聊天记录要深得多。当一次马拉松路线规划完成后，记忆服务会自动分析整个过程，提取出真正有价值的经验（比如某个路口的限流教训），并把它们作为结构化的“长期记忆”存储下来。
当下次遇到类似的任务时，Planner 就能从 Memory Bank 中精准召回这些经验。在随后的演示中，系统重新运行了一次模拟，屏幕上显示，引入记忆机制后的 Planner 生成了一条与之前截然不同的彩色新路线，因为它回想起了之前一次失败模拟中暴露的交通堵塞点。
除了让 Agent 拥有时间维度的记忆，Lucia 还展示了如何把物理世界里的“地方志”装进 Agent 的脑子里。
拉斯维加斯市有一套繁杂的地方性法规，这些文件格式各异，以非结构化的形式散落在各个系统里。Lucia 没有手动去整理这些数据，而是向系统里的 Data Engineering Agent（数据工程智能体）发送了一个 Prompt，要求它创建一条数据流水线。
这个专注于数据工程的 Agent 迅速响应，利用 Lightning Engine for Apache Spark，拉起了处理任务。它读取每一份地方法规文档，调用 Document AI 对文本进行语义级别的智能分块（Chunking），然后将这些数据块直接写入到 AlloyDB 数据库的表中。
在这里，Lucia 揭示了一个极大降低开发者心智负担的细节：他们完全没有编写任何生成文本向量（Embeddings）的代码。AlloyDB 内置了自动嵌入功能，只要数据存进来，数据库就会根据指定的模型自动在后台计算并生成向量表示。
Lucia 在控制台里进行了一次语义搜索测试。她输入了“在拉斯维加斯大道举办比赛的限制规定”。系统在向量空间中迅速检索，返回了一条极其冷门但关键的法规：拉斯维加斯公共道路上不允许出现骆驼。
随着控制台里传出一声骆驼的叫声，台下爆发出一阵笑声。
但这背后的工程意义十分严肃。Lucia 通过扩展一个官方技能，将连接 AlloyDB 的检索工具添加给了 Planner。这就构成了一个完整的 RAG（检索增强生成）闭环。Planner 从此不再仅仅依赖于基础模型里那些泛泛而谈的常识，它真正具备了对当前任务所处环境的具体、精准的地方性知识。
就在系统似乎已经完美运转时，Richard Seroter 在台上接管了控制权。他点击了运行按钮，试图加载一个包含更多参数的复杂模拟。
突然，刺耳的警报声响彻全场。屏幕上的进度条卡死，系统崩溃了。
“事情是这样的，Richard，这不是你的错。” Emma 在一旁打趣道，“众所周知，当我们开始引入大语言模型时，系统往往会以意想不到的新方式崩溃。”
这并不是一个为了节目效果而设计的意外，而是多智能体系统在生产环境中极易遭遇的真实梦魇。当无数个 Agent 在后台互相抛出请求，频繁调用外部工具，动态更新上下文时，一旦某个环节断裂，传统的单步调试和日志搜索将彻底失去作用。你面对的不是一行报 NullPointerException 的代码，而是一张混乱的调用网。
资深开发者布道师 Megan O'Keefe 上台接手了这个局面。她没有打开庞杂的系统日志去 grep 关键字，而是直接进入了 Agent Observability（智能体可观测性）控制台。
大屏幕上展示出了一张清晰的 Trace（链路追踪）视图。这就像是对 Agent 运行过程的 X 光透视。视图显示，Simulator 在崩溃前成功调用了多个工具，但在最后一次尝试向模型发送推理请求时，连接突然中断了。
面对底层的报错，Megan 点击了错误日志旁边的一个按钮：“启动 Cloud Assist 调查”。
Gemini Cloud Assist 是 Google Cloud 嵌在云端的一个 AI 助手智能体。在一分钟的调查后，它不仅拉取了日志，还跨越了基础设施层，查明了真相：Simulator 的崩溃并非逻辑 Bug，而是因为随着模拟的深入，它积累的历史上下文和工具调用记录过于庞大，最终在组装 Payload 时，超出了 Gemini API 100 万个上下文 Token 的硬性限制。
更令人惊叹的是排障的后半段。Megan 切回到 Antigravity IDE 中，她的开发环境通过 MCP 已经和 Cloud Assist 连通。她直接在 IDE 里问：“恢复关于 Simulator 的调查。agent.py 里面哪里出错了？”
Cloud Assist 带着刚才的诊断结果，一头扎进了 Megan 本地的源码里。它很快给出了详尽的解释：在 ADK 中，有一个名为 Event Compaction（事件压缩）的功能，它的作用是让 Agent 定期调用模型对自己的工作流进行总结，从而把几万字的对话压缩成几百字的精要，腾出 Token 空间。
Cloud Assist 指出，Megan 虽然开启了这个功能，但配置的压缩频率太低了，导致在面对马拉松模拟这种高频密集调用时，上下文还没来得及压缩，就已经撑爆了内存。
紧接着，Cloud Assist 在 IDE 里直接弹出了一个代码 Diff（差异对比）视图。它建议在 agent.py 的 Event Compaction 配置块中，新增一个 token_threshold 参数，强制系统在达到特定阈值时立刻触发压缩。
Megan 审阅了这段代码，点击了批准。代码被直接提交到了版本控制系统，触发了背后的 CI/CD 流水线。几分钟后，修补好 Token 漏洞的 Simulator 重新部署到了 Agent Runtime。同样的复杂模拟再次运行，这一次，系统在后台稳稳地处理着庞大的上下文，再也没有出现崩溃。
这段长达十几分钟的排障演示，彻底打破了传统运维工程师的工作流。当 Bug 隐藏在提示词、Token 限制和多智能体级联调用之中时，排障的第一步不再是看代码，而是让平台的诊断 Agent 去和出问题的业务 Agent 对话。诊断不仅给出了根因，甚至直接把带修复参数的代码推送到了开发者的面前。
Agent 的能力边界仅仅停留在改改 agent.py 的应用逻辑上吗？
在马拉松模拟重新跑通后，系统规模进一步扩大。随着内部测试中跑者数量扩展到数千名，新的问题浮出水面：代表跑者的系统组件响应变得极其迟缓，跑者们在地图上几乎停滞不前。
如果说上一次崩溃是应用层的逻辑问题，那么这一次，是底层的物理基础设施扛不住了。
集团产品经理 Bobby Allen 站到了大屏幕前。他调出 Cloud Assist 的预先调查报告。报告显示，问题出在存储层，当前使用的 GCS Fuse 存储在加载跑者模型时遭遇了 I/O 瓶颈，无法满足系统瞬间拉起海量并发容器的速度需求。
Bobby 打开了 IDE。屏幕上显示的是当前跑者服务在 Cloud Run 上的部署清单（Manifest）。他没有去查阅 Kubernetes 的部署文档，也没有去手动编写 YAML 文件。他在提示词框里输入了一段话：“将此 Cloud Run 服务转换为 GKE 上的等效服务，并在同一集群中托管一个 Gemma 4 模型。”
Cloud Assist 于是开始扮演一个全栈平台工程师的角色。它不仅将 Cloud Run 的服务定义准确翻译成了 Google Kubernetes Engine (GKE) 的部署清单，还自动识别了在 GKE 上运行推理服务的最佳实践，为新增的 Gemma 4 模型配置了正确的 vLLM 参数和扩缩容策略。同时，针对之前调查出的存储瓶颈，Cloud Assist 在生成的清单中，自动将挂载的存储底座从 GCS Fuse 替换成了专为高性能计算设计的 Lustre 并行文件系统。
十几分钟后，控制台显示架构迁移完成。跑者服务已经稳定运行在 GKE 集群中，而同集群的 Gemma 4 推理服务器也顺利拉起。在马拉松模拟器里，地图上的光点不仅恢复了流畅的移动，当鼠标悬停在某个跑者身上时，甚至能通过 Gemma 4 模型，看到根据当前心率和配速推演出的跑者“内心独白”。
“我用我的声音，告诉 AI 去部署 AI。”Bobby 看着流畅运行的新系统说道。
Agent 的角色不再仅仅是业务流里的一个节点，它开始跨越应用层，深入到基础设施的骨架里，根据性能指标和运行环境的变化，重构底层资源。
在真实的商业世界里，任何大型项目的落地都离不开跨部门的协作。除了路线规划，还有海量的物资采购、现场娱乐安排等琐碎的后勤工作。这些工作往往由不具备编程能力的业务团队，通过冗长的文档和表格来推进。
过去，这两个群体生活在平行的技术世界里。
开发者在 IDE 里写 Python，业务人员在办公软件里填表格。
Google Cloud 数据与分析开发者布道负责人 Jason Davenport 和产品管理高级总监 Ines Envid 走上台，演示了平台如何将这两个世界缝合在一起。
Jason 登录了 Gemini Enterprise 应用端。这个面向企业用户的产品，内置了一个极简的 Agent Designer（智能体设计器）。他没有编写任何代码，只是在对话框里输入了一段提示词，要求系统创建一个精通赛事采购的专家团队。
Gemini Enterprise 在一分钟内自动生成了一个包含主调度智能体和多个子领域专家智能体的“供应链系统”。为了让这个新团队了解背景，Ines 并没有去配置什么数据连接器，而是直接把那份记录了马拉松后勤需求的 Google Drive 文档链接，作为一个变量粘贴到了智能体的上下文中。
接下来发生了整场 Keynote 中最具协作隐喻的一幕。
Jason 回到了之前高代码开发者用 Python 写出来的“Planner Agent（规划师）”的对话界面。他改变了对话焦点，@ 了刚刚用无代码方式生成的“Supply Chain Agent（供应链）”，要求它们共同制定一份包含后勤物资放置点的最终计划。
很快，屏幕上输出了一份详尽的方案。规划师提供的地理路线节点上，被精准地叠加了供应链智能体根据文档推算出的补水站、香蕉发放点，以及最重要的——移动厕所的位置。
这两个智能体是如何跨越代码壁垒对话的？答案还是 Agent Registry。
无论是 Mofi 在 IDE 里一行行敲出来的、挂载了复杂 MCP 工具和 Spark 数据流水线的高代码 Agent，还是 Jason 在网页端用一段自然语言催生出来的无代码 Agent，在部署的那一刻，它们都会被平台一视同仁地注册进同一个底层的目录树里。
在底层的网络拓扑中，没有高代码和无代码之分，只有各自暴露的能力接口（Agent Card）。这种设计打破了组织内部的技术孤岛，业务团队随时可以捏出一个轻量级的 Agent，并将它无缝接入到核心工程团队构建的复杂网络中。
独家解读：Google Cloud 所理解的驾驭工程
从连接外部世界的 MCP 标准，到管理系统状态的 Sessions 和 Memory Bank；从打破单点瓶颈的 Agent Registry，到让系统具备自查自纠能力的 Cloud Assist；再到守住底线安全的 Agent Gateway。Google Cloud 在这块巨大的画布上，几乎填满了生产级多智能体系统所需的所有基础设施拼图。
它没有去过度渲染单个模型在某项跑分测试中又提升了几个百分点，而是直面了那个最粗糙、最棘手，也最让开发者头疼的现实问题：当 AI 从一个聊天的玩具，变成真正介入企业运转和物理世界模拟的复杂系统时，它到底该怎么平稳地跑下去。
以下是 CSDN 高级副总裁、奇点智能研究院院长李建忠对这场 Keynote 的深度解读：
Google Cloud 在押注一件事：Cloud Native 的工程范式会转变为 Agent Native 的工程范式，这个 Agent Native 工程范式的核心其实就是当下热议的 Harness Engineering（驾驭工程）。
对 Google Cloud 而言，这包括一系列产品工具和工程方法：Agent Platform Sessions 和 Memory Bank 带来的上下文和记忆管理；Agent Gateway，Agent Registry，A2A Orchestration 等带来的工具与编排能力；以及 Agent Simulation 带来的模拟，Gemini Cloud Assist 带来的调试，Agent Observability 带来的可观测性等。
通过这一系列 Agent 家族产品，Google Cloud 完整实现了 Harness Engineering 需要的知道、行动、反馈三部曲。从 Google Cloud 的开发者视角来看，Harness Engineering 不再是一个概念框架，而是一套正在被产品化的工程实践。
这场 Keynote 宣告了一个明确的信号：手写胶水代码、硬编码 API 对接、在 Prompt 里强塞历史记录的“小作坊时代”即将过去。当系统里的计算单元从一行行静态的指令，变成了能够自主决策、协同工作的 Agent 时，开发者手中的工具、工作的边界，以及思考系统架构的方式，都必须迎来一次彻底的重构。
而现在，通往这种全新工程范式的底座和脚手架，已经被搭建起来了。剩下的，就是看全世界的开发者们，能在其上建起怎样的大厦。
粤ICP备14082021号
免费POC，
零成本试错
