Google Cloud 的 Agent Development Kit（ADK）将图形工程引入 Agent 开发：把任务拆成节点、用边连接、决定每一步由代码、模型还是人控制。这篇教程用一个退款流程展示了 Workflow 的几种核心编排模式，以及何时用静态图、何时让 Python 动态调度。

工作流从三个并行的查询开始。订单、支付、退款历史互不依赖，用嵌套元组即可让它们同时启动，再用 JoinNode 汇聚结果。依赖关系决定边：如果支付查询需要订单查询的 transaction ID，它们就必须串行。ADK 中把工具转成节点时，参数 node_input 接收上一节点的输出，其他参数默认从 ctx.state 取值，需要注意绑定关系。

路由有两种。确定性路由按显式规则走固定分支，例如超过 30 天的订单自动拒绝，同一输入永远得到同一结果，无需模型调用。Agent 路由则用模型解读用户意图，选择可能变化，适合「识别换货还是退款」这类语义判断。退款流程里先用 Agent 路由器识别意图，再用确定性规则应用政策。人工审核节点用 RequestInput 暂停运行，等审核人通过 resume_inputs 返回决定后继续，支持单节点重跑和双节点传递两种变体。

批量场景用 parallel_worker=True 让同一节点对输入列表的每一项各跑一次，结果按原顺序收集，无需 JoinNode，批次大小变化不影响图结构。动态编排则用 ctx.run_node 在 Python 中调度子节点：先 asyncio.gather 并行查询，再用代码决定下一步，适合结果会衍生新工作的场景。动态版在恢复运行时会从会话历史重放已完成的子节点结果，避免重复副作用；也可以限定每项发现最多三次跟进、深挖两层就转人工。

静态图和动态 Python 并不互斥。静态图的边列表清晰展示所有可能路径，适合流程固定、分支可预见的场景；动态节点适合结果驱动后续工作的场景，也可以嵌入静态工作流中。核心判断标准是：能否在输入到达前画出可能的路径？能，就用边列表；不能，就交给 Python。退款示例最终让图协调查询、代码应用政策、人处理例外、模型写回复，各司其职。