Annie Wang 直播｜Graph Engineering：用图工作流约束 Agent

核心论点

单靠「一个 Agent + 巨型 Prompt」做复杂任务（马拉松策略、客服退款、盖房子设计）看起来自信，但无法可靠取数、测试与信任。修复方式不是更好的 Prompt，而是结构：把工作拆成图上的节点与边——这就是 Graph Engineering（在 Prompt / Context / Loop Engineering 之上的下一层）。

原则（口述）：Predictable work goes in functions; reasoning goes in the model. 生产系统里，需要固定顺序与确定性路由的地方，不要把决策完全交给非确定性模型。

结构化总结

框架

• 工程分层（口述）：Prompt Engineering（对模型说什么）→ Context Engineering（模型周围放什么）→ Loop Engineering（plan–act–check 循环）→ Graph Engineering（多块工作用节点与边连成图）。
• 节点可以是：普通函数、带工具的 Agent、纯 Agent、甚至整段子工作流。

• 三种基础形状：
  • Fan-out / Join：互不依赖的取数并行跑，在 Join 汇合（口述称 join 像 synthesizer，按节点名打包输出）。
  • Router：在多条策略中选一。开放集合、自由文本 → LM router；封闭集合、信号在数据里 → 确定性 router（更省、更稳）。
  • Sequential：A→B→C 固定顺序，避免「只靠 Prompt 指望模型按序执行」。

  

  

  

• 动态 Fan-out：并行分支数量在运行时才知道（如深度研究）时，用代码在 runtime 决定图形状（提及 ADK2）。
• 本场 Lab 语境：五周系列中「单 Agent → 本周 Workflow → 下周 Human-in-the-loop / 持久状态」；工具为 Google Agent Development Kit（ADK，开源、可本地观测与调试）。示例从「race day / 马拉松」概念图，落到「团队盖房子 / 客服退款」工作流练习。

争议 / 取舍

• 灵活 vs 可控：单 Agent 开放式很强，但生产退款等场景不能只靠模型「按你希望的顺序」执行；图带来顺序保证，代价是灵活性下降。
• LM router vs 确定性 router：前者能分类自由文本但费 token、可能误读；后者适合封闭规则，更可靠、更便宜。
• 固定图 vs 动态图：流程已知用预绘 Fan-out；分支数未知用动态 Fan-out / 开放式编排。
• ASR 注意：全程几乎为英语；专有词偶发听写错误（fan-out / Vertex / Gemini / blueprint 等），正文已对高频误听标〔存疑〕，勿当原话金句引用。

可执行要点

1. 先画业务图：哪些步骤必须固定顺序（查订单 → 查政策 → 人工审批 → 退款），哪些可并行且互不依赖。
2. 把可预测步骤写成函数节点；只把需要推理的步骤留给模型节点——并统计「整条图实际几次 LM 调用」。
3. 封闭条件用确定性 router；开放自然语言分类才用 LM router。
4. 用 ADK Web（或同类）可视化边与节点输出做调试，而不是只在最终 App 上排错。
5. 分支数量依赖输入时，设计动态 Fan-out，而不是硬编码固定并行度。
6. 本地跑通：配置 .env（项目 ID、区域、API/Vertex 等）；系列下一讲预告为 Human-in-the-loop 与状态管理。

分章逐字稿

英文 ASR 转中文，非官方译稿。以下为 faster-whisper small 自动听写后再译，已按章节分组并保留时间戳便于跳读。非庭审级逐字记录；口语重复、口误与 ASR 错误保留或标〔存疑〕。原片约 85.5 分钟，源语言为英语。

00:00 · 开场：Graph Engineering 是什么

00:00 Graph Engineering（图工程）是什么、怎么搭、以及什么时候该用。嘿，我是 Annie。上期视频我们讨论了为什么 Loop Engineering 会失败，以及为什么你该考虑 Graph Engineering。今天，我们用真正能跑起来的代码来定义 Graph Engineering。

首先，什么是 Graph Engineering？你可以把它理解成：为系统创建一张图工作流。图里面，节点可以是 Agent，也可以是其他确定性函数。我们一起用 Google Agent Development Kit 2（ADK）来搭一个，帮你更好理解。例子就用这一条：race day（比赛日）。

一名跑者马上要跑马拉松，他们想要一个 Agent 只回答一个问题：这场比赛我该怎么跑？你现在看到的是第一次尝试：一个 Agent，一份巨型 Prompt。它什么都承诺：拉天气、分析赛道、检查体能、做出比赛策略。整套工作流都写在 Prompt 里。

看我跑一下会发生什么。看这个答案，它非常自信，也非常具体。但有一个问题：它没有天气 API，也没有赛道数据。所以那些数字全是编的，它在幻觉。这就是病症。

当每一步都活在一次模型调用里〔存疑：leaves→lives〕，什么都取不到、测不了、也信不过。所以修复方式不是更好的 Prompt，而是结构。Graph Engineering 就卡在这里。我们先学 Prompt Engineering：对模型说什么；再学 Context Engineering：在模型周围放什么。

然后是 Loop Engineering：让 Agent 在循环里 plan、act、check。Graph Engineering 是下一层：多块工作用线连在一起。块是节点，线是边。我们用 Graph Engineering 的思路来解这个马拉松问题。先搭能解决问题的最小图。我们想先取比赛日状态条件，

再据此给出策略。所以有两个节点。节点一是普通 Python 函数：取比赛日条件，不调模型，没有成本。

节点二是 Agent：读这些条件，写出建议。让人意外的是：函数和 Agent 出现在同一份列表、同一套连线上。看边：start → fetch → advice，整段编排就是这样。现在跑一下。函数取数，零次 LM 成本。

Agent 推理〔存疑：risen→reasoned〕，一次 LM 成本。真实数据进，真实建议出。有一条原则，你们大概已经有了：可预测的工作放进函数，推理留给模型。接下来迭代到下一个形状。这里有三个概念：Fan-out、Join 和 Router。我的比赛策略需要三个输入。

天气、赛道和体能。它们互不依赖，为什么不并行一起跑？从 start 画出三条边。首先是 Fan-out 模式：并行进程。三次取数同时出发、同时处理。在 ADK2 里，你还可以做动态 Fan-out。

03:12 如果你有并行进程，但不知道同时会跑几个。我们可以用动态工作流在 runtime 生成图的形状，这就是动态 Fan-out。回到马拉松例子。输入都拿到之后，它们在 Join 节点汇合。这是第二个概念。

它像智能体系统里的 synthesizer（合成器）。它等三条分支里最慢的那个，再把输出打成一个以节点名为 key 的字典。这里你不用写 merger，也不用写 aggregator Agent。Join 节点在图里就能工作。最后一个概念：Router 模式。

这也是大家很容易跑起来的形状。这种情况下我们有热天、冷天、普通天〔存疑：how day / code day〕三种策略。三个专家 Agent，需要挑一个。Router 怎么定义、怎么选策略？选项一：LM router。让模型做分类。能用，但费 token，

而且可能误读，因为 AI 是非确定性的〔存疑：原文 can't misread，语义应为 can misread〕。选项二：确定性 router。在图里放一个带固定规则和条件的确定性 router 节点。热指向热天策略，普通指向普通策略，冷指向冷天策略〔存疑：heart / code〕。怎么选？比方说，如果是自由文本请求，

用户随便打字，if 语句读不到信号，那是开放集合，LM router 最合适。集合封闭、信号就在数据里时，if 语句那种确定性 router 更赢。我们刚才的例子用确定性 router，因为它更可靠，

也更便宜。好，图工作流里三个概念讲完了：Fan-out〔存疑：Find out〕、Join 和 Router。来数成本。三次并行取数、一次 Join、一个策略师。仍然正好一次 LM 调用，因为只有策略师 Agent 需要 LM。其他节点都是确定性逻辑，

不需要任何 LM 调用。我们看到了图工作流的例子，但有时你根本不需要图。下面几个问题帮你判断要不要用图。第一：输入到来之前，你能把工作流画出来吗？能，就画，用图工作流。第二：如果图的形状本身

取决于输入呢？比如深度研究场景，你不知道图到底长什么样。你可以用 ADK2 做动态工作流，由代码在 runtime 决定图的形状。好，今天的图工作流 / Graph Engineering 就到这里。告诉我你怎么搭自己的工作流，

别忘了在评论区分享经验。非常感谢观看，下期见。Bye。

06:04 大家好。欢迎来到 Agent 101 直播的第二周〔存疑：second vehicle〕。我是 Annie。我是 Tilda。见到大家很高兴。在评论里告诉我们你从哪里来。来看看。

那个，嗯，你好。Una Lamman〔存疑：人名听写〕。我读得对吗？Hi，Christina。

Annie，上周我们讲了什么？对，上周大家讲的是怎么搭你的第一个 Agent。你会召唤〔存疑：summer→summon〕你的第一个 familiar（使魔）。不知道你们还记不记得。

对对，我有一只小狐狸 familiar，超可爱。我还给它加了额外的、嗯，衣柜小装饰，挺好玩。不过上周没来也没关系，今天可以从零开始。如果好奇上周，随时看回放，自己把 lab 做一遍。

所以，对。今天我们要讲 workflows。

因为单 Agent 不够。你想要一支 Agent 团队，也想为系统搭工作流。我们很快就会展开。

我很想往下挖。抱歉。没事。Tilda，现在轮到你了，我把你的幻灯片钉上。Hi，我先自我介绍。我是 Tilda，帮大家用 Google Cloud 来构建。很高兴见到你们。我会在聊天区帮忙。有问题就打在那里，

我们会尽量回答。还有几位同学也在以同样方式帮忙。下一页。来看看聊天区还有谁。有 Christina。Christina 是工程经理，有多年经验，在这个领域很专，聊天区也特别给力。

她之前也打过招呼。还有 Logan。Logan 有十多年工程经验，在 AI 领域也很懂。他也是我的同事，同样在聊天区支援。

08:00 · 系列路线图与问答暖场

08:07 接下来是 Xiang Jie。Xiang Jie 是在开发和推动、为 Google Agent Development Kit 做工作流的人。

他是 ADK（Agent Development Kit）的核心成员，也就是我们今天讲的这个框架。很高兴他也在直播聊天区支援。

接下来是我。Annie，目前也在帮开发者搭 AI Agent，Google Cloud Tech YouTube 频道上也有一些内容，可以去看看。

好。这就是我们的五周系列，这五周的路线图。

我看评论，流好像有问题。我们确定在向所有人广播吗？

什么意思？有人问今天是不是延迟了，我看频道只看到预览画面。所以。

09:04 我这边应该没问题，Christina 是什么意思？是真的延迟了吗？

嗯，先等一下，哦，好。Christina 说：如果你在看直播但画面没出来，需要刷新页面。

哦，明白了。好，谢谢帮忙看聊天。回到路线图：我们有五周系列。五周结束时，你会学到搭建 AI Agent 需要的一切。

上周我们讲搭单个 Agent，那是用 Google Agent Development Kit 做 AI Agent 的基础。本周是 workflow：系统里东西变多了，怎么编排。下周是怎么管 Human-in-the-loop，怎么管状态控制，

在多 Agent 系统、在工作流里。再下一周是 Agent 记忆：长期记忆、较短记忆、结构化记忆，还有短记忆。

会很好玩。我听说上周 Tilda 最爱的是 live，对吧？对，Voice Agent、Live Agent 现在超热，我特别想学怎么搭一个，等不及了。不过记忆和后面的题目听起来也很兴奋，我也想继续学。

走吧。评论里还有人说 we love Christina。对，大家都爱 Christina，她很棒。还有人问怎么领 credits。我很快会把 credit 链接钉到聊天。说到这个，幻灯片上就有。正在看的各位也可以去这个链接，输入 agent101-EP2-credit。

这是给你们的免费 Google Cloud credit。抱歉，我刚丢到聊天了，点那个链接。非常重要：必须用个人 Gmail 账号领取，不要用公司 Gmail，也不要用公司 Google 账号，否则不生效。对。

对，就像 Christina 说的，请不要用那些（公司）Gmail 账号。下一个是今天的 lab。今天的 lab，你知道，像〔存疑：Celastic / lab 名〕，你生成了自己的 familiar，对吧？这周是：如果它们组队，给你盖一座房子呢？你想盖房子，怎么盖？

这周就是这个。希望你们喜欢这个体验。谢谢 Tilda 在聊天里 tag 我们。你们先玩着，我开始启动今天的 lab 材料。谢谢 Tilda 帮我们介绍这一切，一会儿见。Bye。谢谢。

好。Daniel 找到链接了，太好了。你们自己去兑换 credit 的时候，我快速介绍一下今天的议程。

12:00 · 为何单 Agent 不够：盖房子隐喻

12:08 首先讲为什么单 Agent 不够，我们为什么要谈 workflow。第二部分是 workflow 入门。最近你可能听过一个热词，比如 Graph Engineering。这个 workflow 和 Graph Engineering 关系很重。

我们不会只停在入门。你会从基础学起：工作流里的节点是什么，一直到进阶特性——动态工作流，如何实时生成工作流、让它动态起来。最后用一些 Q&A 收尾。这就是今天的议程。

希望你们已经兴奋了。今天要做的应用，屏幕上能看到：有人想盖一座家，然后你会有一支「使魔」团队〔存疑：team of the media→familiars〕，按你生成的工作流来做。你可以在应用上看到这条工作流的模拟。

你还可以用不同类型的团队做出不同的房子。这就是今天的主题。进入正题。你想盖房子，想用单个 Agent 来做，对吧？今天新来的同学，先快速回顾，避免掉队。

上周和这周，我们都用 Google 的 Agent Development Kit（ADK）来搭 Agent 和工作流。为什么是 ADK、Google Agent Development Kit？ADK 是开源免费框架，适配各类模型，排障、可观测性、本地测试都方便，也容易得到支持，

而且 Google Cloud 对部署和可观测性支持得很好。所以它是很灵活的框架：你不仅能搭 Agent，今天我们还要介绍怎么用 Google Agent Development Kit 搭工作流。

我们马上进入。上周讲的是用 ADK 搭单个 Agent。单个 Agent 里，模型是大脑，负责推理、替你做决定。然后你有一个工具箱，里面有很多工具。

想象你要盖房子。你想要一份蓝图，提出需求：我想盖这样的房子，这些是要求。模型，比如用 Gemini 模型〔存疑：Germanic model〕，或者你用 Google Agent Development Kit 时也可以用别的模型。模型会决定：

好，我该用哪个工具？在我们的用例里，模型会按指令走：你要盖房子，先做步骤 A，再 B，再 C。模型跟着指令推理：我选哪个工具？它可能会选天气工具，

15:13 去看天气怎么样，好让房子设计适配天气。拿到结果后继续推理：下一步我可能要用某某模型〔存疑：none of model〕生成蓝图，然后用另一个图像生成工具。

所以模型负责推理、选工具、拿工具返回，再决定再用同一个工具还是换一个。最后如果你觉得结果不错，模型会把非结构化结果转成结构化结果，用人类语言回答，

好让你这个人能理解模型输出。这是快速回顾。如果你想用单个 Agent 设计房子：怎么盖、怎么出蓝图——

澄清一下，你并不是真的在生成一座房子。我们生成的是图像、设计和计划。这就是「用单个 Agent 来做」的语境。这种场景下，可以有一个带多工具的 Agent，工具箱里那些就是它能用的工具。所以你

可以有工具去查库存、查店里有没有足够的木头盖房子；也可以查天气；再用图像生成来画。然后这里有一些指令。模型要按这些指令选工具，去生成

这份计划，以及房子设计的图像。这当然能工作。这就是上周讲的，也是如今所有 Agent 系统的基础，大家都在谈 Agent。但如果你总是靠 Agent 做推理，可能会有控制问题。你看

这个：如果多次跑这个 Agent，而指令里只是简单说：先 A，再 B，再 C——你告诉 Agent：先用勘察工具做 survey，再做 brief，再看木头、查库存，

再画房子。如果你只在 Prompt 里写下你想要的顺序，然后指望 Agent 按这个顺序选不同工具来解题——有可能成功，因为模型够聪明就会跟着推理、选工具、再执行。

18:00 · 生产系统要可控：退款工作流动机

18:15 按顺序执行。这是 AI、Agent 系统漂亮的一面，也是危险的一面：你不知道、也无法控制 AI 怎么做决定，因为 AI 是非确定性的。第二轮、第三轮它可能跳过某步，或以你无法控制的不同顺序跑。

如果你只是单纯靠模型做决定，那就不是确定性编程。这就是如今生产系统的问题。如果你要做生产系统，比如客服 Agent，靠它给每个客户做退款。想象你靠

Agent 来做，只告诉它：我希望整段客户退款按这个顺序，然后指望它——但你信不过，因为 Agent 是非确定性的。我怎么既用上生成式 AI 的好处：它给我生成计划、生成

图像，又给系统加上控制，让它按我真正想要的顺序做事？一个我能上线的可靠系统。两边怎么兼得？

所以我们要引入 workflow 这个概念。有了工作流，你就能给系统加结构。你不仅不用丢掉生成式 AI 的能力——还能生成内容——也可以给系统加上结构。于是系统有确定性顺序、确定性过程。你现在看到的，

就是今天 lab 要搭的图、要搭的工作流。再想想客服例子：如果客户要退货退款，我希望系统先查这笔购买信息，然后系统再

查这个客户的信息。再查退款流程，看这笔退款是否有效。然后也许送到主管那里，做人审（Human-in-the-loop）批准或不批准。最后按退款流程，可能退回原支付，或给信用额度。

或者按退款流程做别的。如果你先忘掉「工作流」这个词，你只是想搭一个系统、解决那个问题。而你解题时，脑子里已经有流程：先做这个，再做那个，再做这项检查。所以自然地，当你

21:05 解题时，脑子里已经有过程、有解法、有顺序。工作流做的事，就是把你解题的方式、业务逻辑、业务流程抽象出来，画成一张图。然后用我们的 Agent Development Kit（ADK）实现这个顺序、实现这张图；你也可以用别的方式实现。

但今天我们教你用 Google ADK 来做——当然你也可以用别的 Agent 框架。搭工作流的核心是：把你解题的方式抽象成结构化顺序、确定性顺序、确定性流。你画出这张图，

那就是你解题的方式。再用我们的框架实现这张图。这基本上就是今天说的 workflow。回到这张图：这就是我想用来出盖房计划、或生成蓝图的工作流。这只是我脑子里已经有的顺序。

我要在今天的 lab 里一步步介绍、实现它。这就是今天的目标。我们用这个例子理解不同结构、不同工作流模式：包括顺序模式、并行 Fan-out〔存疑：find out〕、动态 Fan-out 与 Fan-in〔存疑：finding〕，以及一些动态的

递归工作流。我们会继续展开这个例子，帮你理解什么是 workflow、怎么用 Google ADK 搭。我知道讲了很多。我切到 lab 屏幕，带你们走一遍怎么搭环境，再一步步创建工作流。

我来分享屏幕——屏幕共享在哪？先停止共享。分享这个。我的屏幕呢？应该在这。好。你现在看到的就是今天的 lab。看看有没有 lab 链接。谢谢 Tilda 放了 lab 链接。Tilda 或 Christina，

如果能把 lab 链接和 credit 链接一起丢到聊天，会很有帮助。继续。我们有这个 lab，也有免费 credit。领 credit 只需点 claim。这是我现在的测试账号。你需要扫二维码验证你是人。我扫一下。

24:13 这份 credit 只在今天上午有效。你们来参加 lab 很幸运——哦，看直播的各位，不要替我扫这个二维码，谢谢。好，我领到 credits 了。可以打开账单账户，基本上就是在给我创建免费额度。下一步开始做这个 lab 的 setup。所以这个

lab 我放在 Google Cloud Shell 环境里。当然你也可以在本地做，用本地 VS Code 或任何你喜欢的环境。我们用 Google Cloud Shell，是为了有受控环境：依赖都装好、版本一致。但你也可以在本地做这个 lab。

所以我要 clone 这个。但先打开 Cloud Shell：点右上角按钮激活 Cloud Shell。

授权。好。把链接贴到这里。现在我在 clone 仓库。下一步我想——等一下，我好像漏了一步，需要先设置项目。这一步会给你创建新项目，并把项目绑定到它创建的账单账户。它会创建一个以 agent valley 为前缀的新项目〔存疑：agent value〕，然后绑定项目。

帮你绑定账单账户。现在你有一个带免费额度的 Google Cloud 项目〔存疑：visa free credit〕。下一步做 setup。我要安装并指向 Vertex AI〔存疑：what has AI〕，这次用 Vertex AI。location 设 global，配置我的 .env 文件〔存疑：.inv〕，跑 setup 脚本。

Setup 脚本是为了确保都配置好，尤其是打开一些权限。我来跑。哦，Shaya 问：我刚进来，有人告诉我今天学什么吗？我们今天学 workflow。随时可以看回放。聊天里有 lab 链接，

你可以去看你现在看到的这个 lab。这是动手 lab。这是刚进来的同学的 credit。对，如果你看到这个箭头，说明 setup 还要一点时间。你只需再跑一次，

27:14 确保权限配好。好，这次通了。我再跑 preflight，确认一切按预期工作。好，都配好了。第一步：在工作流里创建第一个节点。就像开头说的，今天 lab 讲

workflow。工作流会从单个节点开始，再到更复杂的模式，从单张图到动态流。我们先回到幻灯片，把工作流理解得更清楚，再更好理解今天要写的代码。对，这就是今天的工作流。

28:00 · Lab：节点、边与顺序结构

28:09 今天我们按这张工作流来设计和做 lab。开始创建工作流——工作流用的就是图上的节点和边，对吧？图就是节点加边。系统里的节点是什么？如果你用 Google Agent Development Kit 做今天的工作流，

每一个节点可以是函数，可以是带工具的 Agent，可以只是 Agent，甚至整段工作流也可以是一个节点。你看到的每个节点，可以是 Agent 节点、函数节点，也可以是「工作流作为节点」。所以你可以做确定性工作流，而每一个

节点可以是你觉得合理的任何东西。这回到一开始怎么解你的业务问题：你脑子里要有解题方式，把每个阶段抽象出来。然后想：这一阶段能不能用确定性逻辑做，

还是要靠生成式 AI 能力，还是要靠 Agent。那是你的决定。但本质上每个节点可以是其中任何一种，再把它们拼成看起来像这样的工作流。接下来有不同的跑法。在进入下一个之前，先创建我们的第一个节点。然后我们

看看它在系统里长什么样，以及怎么用简单节点搭简单工作流，来架构解题、架构决策。我分享一下怎么搭。分享这边屏幕。好。从单个节点开始。我们已经说了，工作流

30:21 从单个节点开始，对吧？可以是函数节点或 Agent。我复制这段贴到聊天。我们现在在跑 ADK Web。ADK Web 让你快速和正在创建的 Agent 系统交互：可以对话，可以轻松测试。上次来过的同学

已经玩过 ADK Web。新来的同学，这是你实验、聊天测试、跟刚创建的 Agent 说话的时间。看看长什么样？好，这就是我们正在看的 Web UI。

我们可以直接跟这个 Agent 说话。左上角自动选中了今天创建的 Agent。我们在聊：我想做一个下午能看书的地方。你可以看到我们刚创建的单个节点。这个单节点是 survey（勘察）节点〔存疑：serving node〕。

你可以看到，我们还有这个单节点上的状态控制。这个单节点在代码里长什么样？我们看一下，更好理解

代码里有什么。这样你就明白它如何映射到你刚创建的工作流。你刚创建的是一个做勘察的单节点。看看它长什么样。看这个 Agent 节点，我们可以用 Cloud Shell Editor 打开文件。如果你在本地环境做，

直接打开文件就行，不需要 Cloud Shell Editor。我开一个新标签，打开 Cloud Shell Editor。好，它没打开正确的文件。

我自己打开，因为第一次开 Cloud Shell Editor 要加载一会儿。第一次用 Google Cloud Shell 环境的同学可能注意到：它看起来很像 VS Code，但跑在你自己的 VM 上。用起来相当——

就像 VS Code 的克隆。看这个 agent.py 文件，这里是我们今天创建的全部工作流、全部节点。在 root agent 这里，这就是我们正在看的根 Agent。目前它只有一个 survey 节点。看看它长什么样。这些是整份东西

33:15 你后面会加的——那些注释是稍后才要加的。一开始你只有 survey 节点。基本上就是创建工作流，然后只把 survey 节点放在这里。看看我们创建的 survey 节点。现在它只是一个没有工具的简单 Agent。

它用模型当大脑，跟着这条指令。这里做状态控制：用名字作为 key 控制输出状态，value 是这次的输出。所以你只是在系统里放了一个单独的 Agent 节点。这正是你在工作流里构造单个节点的方式。

在代码里创建工作流，就是创建一份 workflow，再把东西放到边上，一起画出这张图。第一个例子是单个 Agent 作为节点。但前面说过，你可以放函数节点。函数节点是确定性逻辑。你也可以放 Agent 节点，

可以放带工具的 Agent。甚至可以把整段另一个工作流作为工作流的一部分。所以你有这种嵌套工作流〔存疑：nascent〕。你可以把这些都当作节点放进去，构造出图。跑这个工作流时，它就会按你构造的整张图走。这是单个 Agent 作为一个

节点的例子。如果我们让系统更复杂呢？怎么继续构造？这些又是什么意思？我们会在幻灯片和后面的 lab 结构里讲到。整个 lab 是从 ADK Web 开始，直接和我们的 Agent 节点交互。而这个 Agent 也是我们

整个系统的后端。从第二步起你会看到这条工作流——我想是第三步——整条工作流会出现在 Web App 上。基本上你构造的任何工作流都会显示在这里，但它们用的是同一个 Agent 后端。这就是今天 workshop lab 的整体架构和结构。如果你想

玩一下，可以改工作流内容，然后在 ADK Web 上看到不同可视化，稍后也能在这个 App 上看到不同可视化。我回到幻灯片，看还有没有问题。谢谢 Tyler 和 Christina 帮我回答一些问题。我分享幻灯片。好，你们看到，

36:22 这就是确定性工作流。现在你有了单个节点。下一步是什么？怎么继续？今天的 lab 会讲：可以用这种方式写代码，把它们连成顺序；也可以在写代码时做成 Fan-out 和 Join〔存疑：final and join〕这种格式。我们还会讲

怎么写这个 Router：在代码里做像这样的映射字典。我们很快会讲到。今天先为整条工作流创建一个 survey 节点。下一步，我希望你们把 survey 节点和 blueprint 节点〔存疑：footprint nodes〕连起来，就像这里。我们看第一个基本

概念：顺序。顺序基本上就是：在工作流里你要先做 A，再 B，再 C，把它们连在一起。ADK 工作流的好处是，因为每个节点可以是函数节点或 Agent 节点，所以你可以把 Agent 和函数

节点，甚至工作流节点，按这个固定顺序连在一起。回到最初的话题：你本可以用单个 Agent 解题，把全部指令放进 Prompt，让 Agent 按 Prompt 做事。但有了工作流，如果你确保有这个固定顺序，

你在创建这张图。它一定会从左到右跑。不会跳步，也不会倒着跑。这就是你在给系统加结构、加控制。每一步都容易测试、容易加可观测性。你可以轻松改顺序，以便更好地

38:00 · 顺序 / Fan-out·Join / Router

38:20 优化业务方案。这就是加结构的好处。我们用工作流来解这个问题。就像前面说的，你可以连 Agent 和 Agent，也可以连 Agent 和函数，也可以把两段函数代码连在一起。这就是 lab 的第二步：

我们要把两个 Agent 节点连在一起，让它们按顺序跑〔存疑：wrong→run〕。这很重要，因为这是固定顺序。但缺点是灵活性更低。如果你不确定、问题很开放、你不确定确切顺序，你不能只把决策委托给 Agent / LLM〔存疑：agent LAM〕。

39:05 那就不必做顺序。但如果你确定，比如说，做

退款流程〔存疑：refounding〕，必须先查产品信息，再查退款政策。这是你必须做的。你要确保这是确定性结构、确定性顺序。那时你就可以构图、在图里把它们连上，搭出这条工作流。

这是第二个基础。我们很快进 lab。但我想先讲工作流的下一块：Fan-out 和 Join。什么是 Fan-out 和 Join？基本上，做完这一步后，你希望有并行过程一起做事以省时间。这个例子里，我们想有不同过程：一个处理

我们的测算，计算器只是做一些确定性逻辑来计算。我还想有库存逻辑，检查库存、确保盖房子的料够。然后查天气，想想基于天气该做什么。基于这种并行，我做

Fan-out 处理，同时做这些事来省时间。如果一个一个做，会更久。做这些过程时它们并不互相依赖，是独立过程，可以同时做。我想省时间，所以要并行。我不想

按顺序做，也不想用别的方式。漂亮的是：这里每个并行处理可以是一次工具调用，可以是简单逻辑，也可以只是一次判断。所以可以是 Agent 节点，它们都可以并行跑。然后我们有 Join 节点〔存疑：joint node〕等所有东西完成。

有了 Join 节点，我们可以等所有东西完成，好让下一步用 aggregator 或 synthesizer 把其他结果一起继续处理。

这就是今天 lab 说的 Fan-out 模式〔存疑：fan out mode〕。今天 lab 里我们有这个 Fan-out 模式〔存疑：final mode〕：已经知道 ground、stock、weather 是三条要 Fan-out〔存疑：find out〕的过程，然后再 Join。这发生在你已经有既定计划的时候：你把它们画出来，然后

它们并行跑。你搭这条工作流，就是为了看它们并行。那如果一开始你不知道会有多少条并行呢？ADK（Agent Development Kit）里还有一个东西叫 parallel worker。这个 parallel worker 可以根据你的输入数量拉起并行进程。

42:06 如果你有四个输入，它可以拉起四个进程；五个就拉起五个。

但用这种 parallel worker 时，它们拉起的是同一种节点〔存疑：note→node〕。所以你可以用它给厨房、浴室、阁楼、不同地方做设计，但它们都是设计节点，同一类节点，可以按同一类型一起做。

好。往下之前我先停一下，回到我的 Cloud Shell〔存疑：collab〕实现目前这些。parallel worker 今天的 lab 不会覆盖，只是想介绍一下，知道有这回事就好。不会做到这个 lab 里，但我可以分享一些资料。

如果你想多了解怎么用并行工作流，稍后我们还会讲动态 Fan-out 之类。但在跳进这些进阶概念之前，先回到代码和我们的 App，看看：如果你已经知道并行过程、想 Join 它们，再想

构造工作流，长什么样。看看现在的 lab。我先暂停视频，回到 lab。好。回到 lab：我们刚做完第一步，创建单个节点〔存疑：note〕。下一步是构造边。我再到 Cloud Shell Editor，

或 Cloud Shell 终端里输入 cloud shell edit，打开这个。然后我取消注释这段 blueprint〔存疑：on comment→uncomment〕。取消注释后，我就有 survey 和 blueprint，把它们构造在一起。然后我再取消注释这个。然后我

重启 ADK lab。好，我刷新。然后用同一个问题问 ADK lab。我开一个新 session。在 session 这里可以看到这是刚才问的上一次，但现在我改了代码，想问新问题。因为我在 survey 后面加了新的 blueprint。

对。所以我有 survey 节点和 blueprint 节点，它们按顺序跑。你会看到它先做勘察处理，然后状态里有 south terrace〔存疑〕，再进入 blueprint 过程。

45:08 blueprint 过程，你也可以到代码里看，我们想怎么

检查蓝图。它们会按这条指令走，尝试检查蓝图。接下来，这两块连在一起之后，我想看看 Web App 里长什么样。Web App 依赖这条工作流作为后端。我去看看

Web App。我可能要开一个新标签，但要在同一个项目下开。我要确保项目是我们今天创建的那个：在项目选择器里选今天的项目。然后跑这条

start 命令，拉起今天 lab 的 Web App。这个 Web lab 是你可视化「如何创建这个家」的地方。看看。有没有问题？哦，Eric 在问动态分支，或者极端情况怎么处理〔存疑：great cases→edge cases〕。好，谢谢 Christina 回答。我们很快也会多讲

动态流。回到这边，我们刚讲到这个 App。

我想第一个链接是 Agent Valley。对，今天是五周 lab 里的这些。上周是第一个 lab。如果好奇第一个 lab，我们会把信息发到邮件里。这是第二个 lab，我们在盖房子。我们在连起来。现在你创建的只有两段工作流。

你可以输入任何你在想的东西，看到这就是你创建的第一版工作流。下一步是我们说的 Fan-out：我们想要 Fan-out 处理。要做 Fan-out，还是在 Agent 代码里，我要取消注释这一段〔存疑：on common→uncomment〕。取消注释之后，基本上，

你会看到：我们想让 ground、stock、weather 并行跑，然后 Join 结果。再往后，在 render 和 expect 里，我会继续聚合结果，继续做这里的逻辑。对。这就是我们如何构造工作流，如何在已经知道数量时创建 Fan-out 和 Join。

48:11 如果我们还不知道并行有多少，我们会在并行工作流和动态工作流那里讲。但这个例子是：我们已经知道这些东西并行跑，我们要 Join，然后继续。所以在这里，

我打开编辑器。在最底部，我取消注释这段处理。对。这样这三件事并行跑并 Join。如果你好奇它们各自长什么样，也可以看：这是带工具的 Agent。我记得 ground 其实不是 ground，它只是一次计算。

按我的记忆。对，这里只是一个函数。有趣的是：你基本上把不同过程 Fan-out〔存疑：find out〕出去。有的过程像同步函数，有的只是带工具的 Agent。如果你能提前画出这张图，就可以把它们一起 Fan-out。类似地按这里的指令。我们可以看看

我们的 lab，也可以看 App 长什么样。这是 ADK Web〔存疑：ADK map〕。我刷新一下以免忘了。这个标签是 Web App。我再刷新一次，让 Web App 和

以及 ADK Web 都更新。这是我们说的 ADK Web。这是 Web App。你会看到：我们一改工作流的构造，Web App 这边也跟着变。这是 ADK 的内建能力：你可以直接跟 Agent 说话。我们之所以要看 ADK Web，

50:00 · ADK Web 可视化与动态 Fan-out

50:15 而不是直接从 Web App 看，是因为：想象你在搭生产系统，你不想在 App 层做全部排障、调试和修复。你想要一个开发工具〔存疑：depth tool→dev tool〕，直接测试、可视化状态、可视化 artifact、做评估，都在开发工具里。这就是为什么我们

想同时有 Web App 和（ADK Web），好让你能玩。快速检查：如果我在 Web App 里输入，我也会启动这个过程看 Web App。你会看到，现在在 Web App 上，我一问问题，它一定会走这条工作流，然后拉起

51:05 三个并行过程；绘图这部分在等结果，然后继续做渲染。类似地，ADK Web 也可以可视化整件事。不仅如此，你能看到生成的图像、每一步，也能看到步骤状态。这是这条工作流系统里所有节点共享访问的状态。

所以下周我们会讲怎么管理状态、怎么管理持久状态，尤其是在 Human-in-the-loop 的情况下。那是下周的内容。这周是你在构造这条工作流，可以点开每一个，看参数，也看函数响应，用可视化很容易做到。

这是 Web App 上正在发生的：基本上在 App 上可视化并模拟〔存疑：stimulate→simulate〕整个过程，我们也能在这里看到结果。那边是 runtime inspector。这就是我们现在的 Fan-out 处理。快速总结目前有的：我们在创建这个——

对，我们在理解每个节点。第一，为什么要 workflow：我们想要受控、结构化的方式，用这种控制结构来结构化地解题。第二，搭这条工作流时，每一个组件可以是

函数节点、Agent 节点，也可以是工作流。然后我们讲了怎么搭顺序流，也讲了怎么做 Fan-out 和 Join。接下来会快速介绍一些动态 Fan-out 的情况。还有：如果我想要一个循环，想在这个 App 里放一个 Router，

这样你几乎可以搭任何开放图和封闭图。任何——如果你能提前画出这张图来解业务问题，你几乎都可以用我们的框架实现。这就是要点。我很快回到幻灯片

介绍它们。幻灯片在这。好，在这边。太好了。这就是我们刚讲的。这是我刚才说的 parallel worker。基本上你可以拉起。今天 lab 没有介绍，但要启用 parallel worker，左边代码是把 parallel worker 设为 true，

这样它就能根据输入把同一个节点拉起多次。另外我们也可以有动态 Fan-out / Fan-in：那是你不知道会有多少个的时候。在这个例子里，不管你想创建什么样的房子、建筑、结构，它总是跟着

54:16 拉起。它总是做这三件事。所以是固定的，像是给系统加结构。但灵活性也更低：也许某种永久建筑，或不同类型的建筑，你不会有相同的并行过程。那样你可以在这次

运行时〔存疑：round time→runtime〕决定要多少个 Fan-out。这就是我们说的动态 Fan-out 和 Fan-in。要启用它，你需要 ctx.runtime node〔存疑：ctx.round node〕。我们会分享资料，讲怎么在 Google ADK 里做〔存疑：Google educate〕。它要解决的整个问题是：如果你不知道要 Fan-out〔存疑：find out〕多少东西，

以及里面是什么。你不知道的时候，就可以用动态 Fan-out。你可以在 runtime〔存疑：round time〕生成这些 Fan-out。ADK 也允许这样做。

快速总结：有多种走法，可以说三种「走宽」的方式，也就是不同的并行处理方法。第一种是我们会做到这个 lab 里的：你已经有三条过程，ground、stock 和 weather，然后你

可以并行跑它们。第二种是用 parallel worker 让同样的事情并行，取决于输入数量，然后按你给的输入次数拉起同一个节点。第三种是创建动态 Fan-out：比如你可以有一个 for 循环，然后处理、

生成它们。你可以遍历列表里的每一项。对迭代器，你可以有不同类型的节点。你可以在实时、在 runtime 生成 Fan-out。稍后会讲到动态工作流，会更多讲怎么用递归等做动态 Fan-out〔存疑：dynamic final〕或动态工作流。

但这些都是好东西。如果你第一次学 workflow 觉得太多，完全可以理解。慢慢消化概念，先确保理解今天的基础。我觉得已经很多了，而有了这个

工作流基础，你已经能做不少事。好。回到今天的 build：目前我们构造了顺序，以及 Fan-out 和 Join〔存疑：final and join〕。接下来我想学 Router。我想检查作品、核验，然后决定：需不需要返工，还是可以直接到 finish。所以下一步我要

57:08 有这个 Router，做这次检查。我不希望这个循环处理超出限制。这些是我们下一步 lab 要学的问题和内容。lab 下一步是：如何通过 Router 创建循环？我分享 lab 屏幕，这样

你们会明白我在说什么。我分享这个。好。如果你看

现在 lab 在看第五步，我们去第六步，把这个发回去。还是到这个 agent 文件，取消注释这一段〔存疑：uncommon→uncomment〕。这段基本上是在告诉 Agent：这种情况下做 restock，那种情况下做 finish。在里面你可以谈政策、谈规则：

什么情况下走哪个节点〔存疑：note〕。现在看编辑器。

基本上在工作流最底部，你只需取消注释

这最后一段。最后一段是：我要构造这个 Router 来重定向。这个 stock，记得我们前面已经有 stock。然后 basically，rework 指向某个已经存在的节点，这就是你如何创建 Router。如果你指向一个新的节点，你不会创建（回边的）Router，你只是重定向到图里另一个节点。

但这个例子里，我们指向之前已存在的节点、向后指，这样你就能创建封闭图，像一个循环系统。如果你想持续改进系统，这也是做 Loop Engineering 的方式。回到终端，我重启 ADK Web，也重启 App。然后我想

试一下，在 Web UI 上可视化一切。这些只是随机问题，是用户想创建的请求。你也可以说：哦，我想要一个今天下午写代码的地方，之类。哦，好，我把两边都重启〔存疑：boasting→both things〕。

我开一个新 session，然后问这个问题。这里你还是可以随便输入，也可以选你想要的请求。但在这里你可以看到：因为我们启用了这个 Router，它指回 stock，所以渲染完成后，它会检查是否符合要求。

1:00:14 如果不符合，就会再 restock，再走一遍这个过程。如果通过检查，就到 finish。所以我们在这里通过加一条具体检查，创建了确定性 router。但在检查逻辑里，你可以做成 LM router，也就是用 AI 做决定；或者如果你有

清晰规则，可以写确定性逻辑来做 router。比如你在检查温度：是热还是冷，你可以有清晰规则：大于 30 度做什么，低于 30 度做什么。如果你有清晰规则，而且

容易定义，就可以用确定性 router、确定性逻辑，来决定这里怎么写 router 做控制。但如果你有开放式问题，很难有非常清晰的规则，就可以靠 AI 处理输入。比如你很难覆盖所有用例，那就可以那样做。看起来这次通过了。

这次直接通过。我想如果我选「带着松木气味的热（房子）」〔存疑：hot that smells of pine〕，它会做 inspect。看看。对，这就是这边的过程。这也是为什么你想——哦，我们遇到 resource exhausted。如果你看到 resource exhausted 错误，那是限流错误〔存疑：fortunate→429〕，意味着有 rate limit 问题，你可以

稍等再试。但如果你看 ADK Web UI〔存疑：ADQ〕，图会更清楚：发生了什么、我们怎么 Join、怎么路由、它选了什么决定。它选择 restock，然后你选择 restock，就会再做一遍。这也是

restock 的力量。我想在这个过程中，因为部分处理用了 AI，然后有一些 rate limit 错误——所以你可能需要再试一次，忽略这个。好，我有这个 rate limit 错误，也许因为我同时跑着这两个处理，可能就是这个问题。不过，再次，

我回到幻灯片，把 Router 概念收个尾，再多讲一点动态工作流，这样我们可以进入 Q&A。我希望到目前为止你们享受整个体验：看着这条工作流，看着这座房子被创建、计划被提出，觉得有趣。

1:03:07 你会发现，当你改那边的代码时，这些工作流会被创建成不同样子：它在生成，你可以在更新代码时创建不同的工作流。对，大部分代码都在 agent.py，你可以只管玩 agent.py，它会直接

反映到 ADK Web〔存疑：adkb〕，也会反映到这个 Web App。好，我回到幻灯片。好。这就是我们说的 Router，这就是今天的 build。你大概已经在 ADK Web App 和 Web App 上看到了：我们从单个节点开始，然后做顺序，再后来有

Fan-out 和 Join，然后有这个 inspect——那是可以往回指的 Router。这就是你可以提前画出工作流、提前画出这张图的情况。然后你可以用 ADK workflow 实现这张图。现实里会这样发生：比如你解题时，你确切知道

要踢开多少个过程。回到我们的客户退款例子：你知道并行处理是——我要并行拉起：同时查用户画像、同时查购买历史、同时查产品信息，因为它们如果互不依赖——也许

购买历史依赖于用户画像，但对互不依赖的过程，我可以拉起这些。这对每一种退货退款请求都是刚性的。所以我有这个刚性数量、对每种退款请求都精确的过程。我就可以画出这段 Fan-out 处理，然后实现它。

1:05:00 · 何时用固定图、何时开放式

1:05:21 所以当你有非常固定的流、想确保事情完全按你的设计走时，这很管用。但现实情况很难——真的取决于用例。有时你想事情完全按你画的走，有时你又想要更多灵活性。所以这真的取决于

你要解的业务问题。有些业务问题你故意要非常开放、非常灵活；有些业务问题是非常敏感的数据，或必须考虑隐私、安全，你想强制非常结构化、刚性的顺序，那时你就要加入确定性逻辑〔存疑：terms of logic〕。这真的取决于

1:06:10 业务逻辑或你的用例。幸运的是，用 Google Agent Development Kit（ADK）〔存疑：google agent divan we educate〕做你创建的工作流，你不仅可以从图已经画好的地方创建工作流，也可以创建动态工作流。想象这个系统：比如你在盖房子，你可以画出一切——左手边是那种情况：

你已经知道确切过程；右手边那种情况是：你有楼层，楼层数是客户说的，每层放什么也是客户说的。你不知道客户会说要几层，也不知道每层会放什么，这真的取决于用户

请求。所以你想要某种结构，也想要灵活性。你想在结构和灵活性之间取得平衡。那时你可以靠 AI，或者用确定性的，或者用动态工作流。一种可能的解法是：你可以有一个单 Agent，

用 AI 把任务委托给子 Agent。这种情况下你看到的是一个单 Agent，带着不同的子 Agent；或者这也可以是带 LM router 的工作流〔存疑：LIM router〕。关键是：你用 AI 当 Router，路由到不同步骤、

不同工作流。那样你就有了灵活性。这是处理灵活性、在控制和灵活性之间取得平衡的一种方式。另一种就是我们前面说的动态 Fan-out 和 Fan-in，这正是我们之前讲过的。在 Fan-out 过程中，你不知道有多少东西

要提前 Fan-out〔存疑：find out〕，但你大概会从代码里的某段逻辑得到一份 topic 列表。一种做法是遍历这份列表，尝试在实时生成它们。这可能是一种做法。这是另一种给你受控工作流加入动态、加入灵活性的方式。

另一种可以是：比如你做这种循环处理时，我不想要精确控制、不想确切知道怎么做，而想像让代码决定下一步跑什么那样，把整段处理放在实时里。所以我不是提前创建图，我在跑的时候，想让这段代码

1:09:16 在实时运行。这个例子里，我在尝试创建类似的流，但不是提前创建这个节点，而是用 rerun on resume。用这些 ctx runtime node 配置〔存疑：context out wrong note〕，会基于真实代码生成不同结果，然后由代码决定下一步做什么。

类似地，比如我想做一个深度研究的例子：我的代码可以决定要生成多少东西。比如我不知道盖房子的计划要考虑多少因素，所以我需要做深度研究，需要上网研究：

设计房子要考虑多少因素。我可以这样：如果我提前知道过程，我就精确画出图里的样子，像我们今天这样构图。另一种方式是靠这个——我可以创建动态工作流，在实时构造节点：我可以提问，

然后它会基于实时发现，生成一个子 Agent，或生成那些不同的子处理。不同的子处理，比如我发现需要考虑天气、位置、材料，基于每个因素我还想继续做更多研究。

然后——这个例子里我有两栋建筑，像 floor 和 floor two，每一层可能有不同的东西。这只是一个例子：你不确定有多少、提前不知道会是什么样，因为输入可以非常开放、非常灵活。所以它真的

取决于输入。然后在我们跑节点处理的过程中〔存疑：load→node〕，我们在生成子处理，继续做研究或继续做对应逻辑。我们再给你们分享更多资料。如果你好奇怎么给系统用动态工作流——它没有包含在今天的 lab 里，因为今天的

lab 主要聚焦基础，而这更像进阶，知道就好。如果很多人感兴趣，我可以再做一个 lab 讲动态流。好。快速总结我们目前看到的不同东西：今天的 lab 主要聚焦于——你提前知道图，

1:12:03 所以你画图，再在代码里构造这张图，并且可以可视化一切。那样你给系统加了很多控制和结构〔存疑：flex it up〕，但缺点是灵活性。所以你可以要么靠模型决定下一步做什么，要么有代码，你在

实时跑这段代码来决定过程：可以有并行工作流、parallel worker，也可以有递归等等。就像你在实时跑代码，它会在这条工作流处理中生成树。本质上这是一种权衡：你要多少控制、

多少控制或灵活性，当你有这条工作流时。本质上是关于你的业务问题，那会帮你做这个权衡。用 ADK 搭工作流，基本上是给你的一个工具；一旦你知道怎么搭每一种，你就可以决定怎么挑选它们来解题。

好，今天的 lab 就到这里，希望你们玩得开心。上周我们讲召唤〔存疑：quitting / summary→summoning〕你的第一个 familiar；这周我们有多个 Agent，讲怎么创建工作流来解题。下周我们会讲带长时运行处理的 Human-in-the-loop。

如果你的退款流程需要人来核验，或者你需要人检查某些事——因为搭 Agent 系统时，你不能总是靠系统自动化一切。你想要自动化，也想要安全、想要控制。我们怎么加入 Human-in-the-loop，我们怎么

为系统里所有组件管理状态。所以下周会讲 Human-in-the-loop 和状态控制。希望你们喜欢目前这些。我邀请 Tilda 回到屏幕，我们做一点快速 Q&A。Hi Tilda。Hello hello。非常感谢大家加入。

我们很乐意接收你们的任何问题。我先从一个来自 Eric Domeni 3589 的问题开始。他问：到什么时候你决定一条工作流不该再用结构化图表，而需要另一种设计模式？因为这个人的问题大概是：如果你有一个

完全非确定性的东西，不太适合你在这里描述的工作流结构，怎么办。是这个问题吗？对。哦 Eric，不再用结构图、需要另一种设计模式。我觉得这是很好的问题。本质上还是回到你要解的问题。对我要

1:15:05 解的问题，比如我通常想从小做起：解退款场景，我就先查画像，再查退款政策，然后下一步。所以我从简单开始，基于已有逻辑解题，然后意识到：用户输入非常开放，有些并不是——

也许我意识到：这份确定性逻辑覆盖不了所有用例，所以我想加入更多控制。我可以改进工作流，加更多 handler、更多控制来覆盖不同用例；或者加一些系统，用 AI 处理更开放的问题；或更多地用动态工作流来处理

实时跑的事情。按我的经验，通常你想从小做起、从一个可行方案开始，然后意识到要改进过程：也许想加速，于是引入 Fan-out〔存疑：final〕，加入并行工作流来改善延迟；或者想提高可靠性，通过

加入那些确定性检查〔存疑：tracker〕。所以你会不断给系统加东西。设计上，你在给设计和给工作流加东西，以便处理更多用例，或者你想加更多灵活性。我会这么想。Tilda 你怎么看？我觉得这是很好的回答，归根结底就是

你在尝试解什么样的问题。完全抽象地回答这些问题很难，但那是一个很好的例子。谢谢 Eric 的问题，这是个好问题。各位如果还有问题请发过来。刚才还有一个，我在找——有人问：如果想完全在本地跑，你会怎么改这段

代码。哦，我分享屏幕。对，如果我想完全在本地跑这段代码，我基本上会先 clone 这个仓库，然后配置。这个仓库你可以 clone，然后我可以配置：这是创建项目并关联项目

ID。但如果你已经有自己的账单账户〔存疑：building account〕——现在一切都跑在 Vertex AI〔存疑：what has AI / wrong on〕上，你也可以用自己的 API key，但这个 lab 我把一切都配成 Vertex AI。要用 Vertex AI 你需要 project ID，但你也可以走 API 的方式。如果你想用——无论是 Google

1:18:00 · 本地运行、环境变量与收尾 Q&A

1:18:00 project ID，我就——好，我去 Google Cloud Console。左上角是我创建项目的地方。我会创建我想要的项目，然后关联到我在 Google Cloud 设置里的账单账户〔存疑：building〕。我去账单。如果你已经有账单，像现在——

我记得如果你注册 Google Cloud，他们会给你 300 免费额度。你可以把免费额度连到你想要的项目。在项目里，你可以连到已有账单，或更换账单。我这边没有可用账单，但你可以改成你想要的账单，然后你就有这个 Google Cloud

project ID。你只要把它们放进 .env 文件。这边 .env 文件——这是我的代码。对，我已经给你写好了 .env 文件，但你也可以改成自己的 .env。我把隐藏文件显示出来〔存疑：hold in〕。对，这是项目，这边有 project ID。你只要把

project ID 改成你实际拥有的 ID，然后启用 Vertex AI〔存疑：what has to be true〕，把 location 改成离你近的。我用的是 global，但你可以选不同 location。然后已经给你配置好了，你可以直接跑一切。并确保本地环境装了 uv，因为我所有依赖

都在这边的 uv 里。确保装了 uv，然后你只需跑：uv run adk web〔存疑：adkvab〕，或 uv run valley.sh 脚本〔存疑：value dot ssh〕，就可以跑起来。整个 lab 的关键就在这个 agent.py 文件：它几乎配置好了工作流，并在这里创建了所有节点。所以相当

直接：你只需确保环境变量配置正确。所有 setup 脚本只是帮你自动化这些；如果你想自己试，也可以手动创建。希望这回答了问题。对，你把它做成这么容易移植到本地跑，太酷了。如果想的话。

好。又来了一个问题。jib lakta vongs〔存疑：用户名听写〕问：当你怀疑 Agent 在当前状态下可能没在正常工作时，你怎么实时调整，从而不总是自己当 Human-in-the-loop？这是很好的问题。当你怀疑——首先，这也是我们为什么要有工作流的好处，因为我们有

工作流，就像我之前在 lab 里演示的。对。你可以点开每一个节点。我分享这个：你可以点单个节点看输入和输出，而这正是我知道它感觉对的那个阶段。首先，这个问题提到：你怎么怀疑 Agent 在当前状态下可能没在工作？

1:21:17 我会先在 ADK lab〔存疑：etiquette lab〕里试，把东西可视化，理解整条工作流里哪一部分可能有问题。你可以可视化每一个组件的输入和输出，然后看到：是这部分有问题，还是另一部分有问题。所以我先排障、缩小问题，搞清楚

根因是什么。然后你问：怎么实时调整，从而不总是自己当 Human-in-the-loop？一种做法是：你可以有一个自我演进的工作流〔存疑：self-involving→self-evolving〕，用这种方式创建循环。一种可能是：如果你自己创建一个自我演进的工作流，

通过创建循环工作流，让系统的这一部分在循环里做检查：它是否在工作；如果没有，在循环里你可以做一些状态变更或修改，或加入不同逻辑，确保它达到目标。这是一种你可能采用的方式。

当然在真实系统里你可以做得不同。我会这样着手。另外两位怎么看？我觉得这非常说得通，回答得很好，我没什么要补的。谢谢这个问题。对，谢谢这个问题。sharuya 9912〔存疑：用户名听写〕问：我怎么决定一个任务

什么时候真正需要多个专门化 Agent，而不是一个带多工具的单 Agent？这是很好的问题，因为「一个 Agent 带许多子 Agent」和「一个 Agent 带多个工具」不同：工具是无状态的，Agent 是有状态的。然后，如果你有一个带多工具的单 Agent，你有可能让多个工具在一次

运行里并行；但每次工具结束〔存疑：two→tool〕，都会回到那个单 Agent，所以控制权还在这个 Agent。但如果你有专家——如果一个 Agent 有不同的子 Agent，你决定把这项工作委托给子 Agent，你基本上就把控制权交给了另一个子 Agent，然后子 Agent

从那里继续。类似于这个工作流的情况。所以你基本上把这个交给下一阶段，把控制权交给下一个子 Agent。子 Agent 决定：我是要把这个以 Agent swarm 的方式传给另一个对等 Agent，还是要返回〔存疑：return the bag→return back〕，还是做点别的。

所以主要区别是：你是否真的希望子处理是有状态的还是无状态的？你是否要把控制权交给子处理？如果是，我会说子处理可以是工具——无状态工具，做完一项任务，然后你仍保持控制；或者你希望子处理

1:24:04 有一个大脑，再决定下一步做什么。我觉得这是主要差别之一。但这是个好问题。好。最后再问有没有问题。我只想说非常感谢 Annie，我学到很多，也很期待下周同一时间继续。我们下周学什么？对，我们会

学 Human-in-the-loop，也会学怎么做状态管理。如果你好奇：你怎么在这条工作流里管理状态？怎么既有 Human-in-the-loop，又能自动跑？引入 Human-in-the-loop 时怎么管理状态——你可以在那里暂停，第二天回来，

给出你的输入，再继续自动化。整件事怎么做，我们下周会讲。也非常感谢 Tilda〔存疑：deodor〕，你主持得非常好，我很感谢你的帮助，也感谢大家回答问题，也感谢今天来到

直播的每一个人，真的非常感谢。这太有意思了。我想没有更多问题进来了，我们可以收尾了。对。好，非常感谢，祝大家接下来一天愉快。Bye。

来源

原直播 / 账号：Annie Wang @anniewangtech
X 转载帖：Magic @Pengran1217 / status/2098256750113931551
媒体：Twitter amplify video 2098179679123656704 · 720p · duration ≈ 5129.6s（~85.5 min）· 1920 源缩放至 1280×720
转写：faster-whisper small · device=cpu · int8 · vad_filter=True · language auto→en（p≈0.998）· 原始片段 JSON：transcript.raw.json
声明：本页为 ASR 转写 + 学习向整理，不是庭审级 / 发布方官方逐字稿；引用请回听原片。转载帖语气未写入教学正文。