AI 选城市、代码查时间：Google ADK 把两种步骤接成一条工作流

一个 AI 助手要完成的事，往往一半需要理解语言，一半有确定答案。例如先选一个城市，再查询该城时间，最后写成一句易读回复。选城市可以让模型做，查时间应交给数据和代码；把这几步排好，也是应用的一部分。

Google ADK 的图工作流文档用这个小例子说明，Agent 和普通函数怎样接力。它适合正在把模型接进业务流程的人：你不仅能描述目标，还能明确每一步接收什么、产生什么，以及下一步是谁。

一条链上，可以只有部分节点调用模型

官方 Python 示例先建立 city_generator_agent，要求模型只返回一个城市名。它的输出交给 lookup_time_function，函数返回一个 CityTime 对象，里面有 city 与 time_info 两个字段。

接下来，city_report_agent 用这个类型作为 input_schema，按字段生成时间报告；最后一个普通函数追加 WORKFLOW COMPLETED 事件。Workflow 的 edges 将这些节点从 START 串起来，顺序直接写在代码里。

这里有个容易忽略的细节：官方 lookup 函数只是模拟查询，固定返回 10:10 AM。它展示的是数据怎样走通，并没有接实时世界时钟。把样例改成自己的工具时，需要替换的正是这个函数，而不是期待模型自己把固定值变成真实时间。

这种组合让一段提示词里的多个要求，变成几个可分别查看的节点。城市生成是否带了多余解释，查询函数是否收到了正确城市，报告是否使用查询结果，可以沿着传递的数据逐项检查。

教学情境中，若把查时间换成读取包裹状态，流程可以仍是“理解查询对象→业务函数读取状态→组织回复”。已有查询代码负责返回业务结果，模型负责语言表达。这个情境是对节点组合的说明，不是官方已经接好的快递功能。

图里也能写条件路由。文档另一个例子把用户消息分类为 BUG、CUSTOMER_SUPPORT 或 LOGISTICS，再由函数返回 route，把任务分发给对应处理节点。需要精确控制的分支，可以由代码表达，不必全部埋进长提示词。

当前 README已使用 ADK 2.0 的 Agent、Workflow 形式。旧教程中的 LoopAgent 等模板，在相应页面有替代说明；新项目应按当前语言版本核对接口。图工作流适合路径明确的过程，循环和复杂条件很多时，文档还提供直接在代码中编排的动态工作流。

ADK Python 采用 Apache-2.0 许可，模型服务与凭据另行准备；图工作流仍有部分第三方集成兼容限制。这个城市案例的价值，是把“AI 完成任务”拆出了可编辑的接缝：哪里生成，哪里查询，什么数据继续往下传，最后怎样交付给用户。