1. 项目概述为什么我们需要编排多 Agent 工作流如果你最近也在捣鼓大模型应用开发尤其是尝试让多个 AI 智能体Agent协同工作那你大概率会遇到一个头疼的问题怎么让它们听话地、有逻辑地、高效地配合起来是让 Agent A 干完活把结果扔给 Agent B然后等 B 干完再给 C还是说有些任务可以同时开干最后再汇总又或者某个环节需要根据中间结果反复迭代直到满足条件这就是“工作流编排”要解决的核心问题。它不再是单个 Agent 的“单打独斗”而是上升到团队协作的“项目管理”层面。Google 的 Agent Development Kit (ADK) 正是为了解决这个痛点而生的一个框架。它提供了一套直观的“积木”让我们可以用代码清晰地定义出 Sequential顺序、Loop循环、Parallel并行这些经典的工作流模式。想象一下你要开发一个智能内容创作助手。流程可能是先让一个“主题分析”Agent 理解用户需求然后一个“大纲生成”Agent 列出结构接着多个“章节撰写”Agent 可以并行填充不同部分最后再让一个“校对润色”Agent 循环检查直到质量达标。手动用回调或者一堆if-else来管理这个流程代码很快就会变成一团乱麻。而 ADK 的编排能力能让这个复杂流程像搭乐高一样清晰、可维护。所以这个项目实战的目的很明确我们不只满足于知道 ADK 有这些概念而是要亲手拆解用具体的代码案例看看 Sequential、Loop、Parallel 这三种核心模式在 ADK 里到底怎么用背后有什么讲究以及在实际操作中会遇到哪些坑。无论你是想构建一个复杂的自动化流程还是单纯想提升多 Agent 系统的可控性这次拆解都能给你提供可直接复用的“脚手架”。2. 核心模式深度解析Sequential, Loop, Parallel 的设计哲学在深入代码之前我们必须先理解这三种模式在 Agent 协作语境下的本质区别和适用场景。这决定了你如何为你的任务选择正确的“编排模式”。2.1 Sequential顺序执行最基础的流水线设计哲学这是最简单、最直观的链式调用。Agent B 必须等待 Agent A 完成任务并输出结果后才能开始自己的工作。数据流是单向、分阶段的。这种模式模拟了传统软件中的函数调用链或者工业生产中的装配线。核心特点与考量强依赖性后置 Agent 的输入严重依赖于前置 Agent 的输出。如果 A 失败了或者输出的格式不符合 B 的预期整个流程就会中断。状态传递ADK 的 Sequential 编排通常会负责将前一个 Agent 的输出自动地、结构化地传递给下一个 Agent 作为输入的一部分。你不需要手动写胶水代码去传递result。错误传播任何一个环节的失败都会导致整个 Sequential 链的失败除非你显式地设置了错误处理这在 ADK 中通常通过try-catch或类似的错误处理节点来实现。适用场景适合步骤清晰、阶段明确、且后续步骤必须基于前序步骤完整结果的任务。例如数据清洗 - 数据分析 - 报告生成。注意不要因为简单就滥用 Sequential。如果任务间没有强依赖用 Sequential 会导致不必要的等待拉低整体效率。2.2 Loop循环执行基于条件的反复迭代设计哲学让一个或多个 Agent 重复执行直到满足某个退出条件。这引入了“状态”和“条件判断”的概念是实现自动化决策和优化的关键。核心特点与考量循环条件这是 Loop 模式的核心。条件可以是最大迭代次数防止无限循环例如“最多重试5次”。结果质量判断由一个“判断 Agent”或一个条件函数来评估当前结果是否达标例如生成的代码是否通过了单元测试摘要的 Rouge 分数是否超过阈值。状态变化直到某个状态变量不再改变例如优化算法收敛。循环体可以是一个简单的 Agent也可以是一个复杂的子工作流比如一个小的 Sequential 链。状态管理每次循环迭代都需要处理上一次的结果作为下一次的输入。ADK 的 Loop 构造需要能清晰地维护这个迭代状态。适用场景代码调试与优化、文本迭代润色直到无错误或风格达标、强化学习中的策略尝试、数据爬取直到获取到目标信息。实操心得设计循环条件时要格外小心。过于宽松的条件可能导致早停结果质量不佳过于严格或存在逻辑漏洞的条件则可能导致无限循环。务必设置一个“安全阀”——最大迭代次数。2.3 Parallel并行执行提升吞吐量的关键设计哲学让多个独立或半独立的 Agent 同时执行最后收集所有结果进行聚合。目标是充分利用计算资源缩短整体任务的端到端延迟。核心特点与考量任务独立性这是并行有效的前提。并行执行的各个分支任务之间不应该有直接的、执行过程中的数据依赖。它们可以依赖共同的初始输入但彼此间不通信。并发与控制ADK 需要管理并发的执行可能是线程、异步任务或分布式任务。你需要考虑并发度同时运行几个 Agent以及资源限制避免压垮你的后端或 API 配额。结果聚合所有并行分支完成后需要有一个“聚合”步骤。聚合方式多样合并如汇总多个 Agent 搜索的结果列表。投票/选择如多个翻译 Agent 的结果由另一个 Agent 选择最佳。合成如多个文案 Agent 生成的广告语被汇总成一份报告。错误处理与 Sequential 不同一个分支的失败不应导致整个并行任务立即失败。通常有两种策略all一个失败则整体失败或any忽略失败的分支聚合剩余成功的结果。ADK 需要支持这种策略配置。适用场景同时查询多个知识源或 API、批量处理一个列表中的不同项目如分析多篇文档的情感、生成同一任务的多种备选方案A/B 测试思路。避坑指南并行不是银弹。它会增加系统的复杂性和调试难度日志交织、错误来源分散。同时如果并行任务最终需要竞争同一个稀缺资源如同一个数据库的行锁、同一个 API 的严格速率限制可能会引发性能瓶颈甚至死锁。3. 基于 Google ADK 的实战代码拆解理解了理论我们进入实战环节。假设我们构建一个“智能技术博客助手”工作流它需要1) 分析主题2) 并行生成大纲和寻找参考链接3) 根据大纲循环撰写并润色章节4) 最终合成发布。我们将用简化的代码示例来拆解 ADK 中如何实现这些模式。首先假设我们已经定义了几个基础的 Agenttopic_analyzer_agent: 分析博客主题返回核心要点和受众。outline_generator_agent: 根据要点生成博客大纲。reference_finder_agent: 根据主题寻找相关的参考文档链接。section_writer_agent: 根据大纲中的一节标题和要点撰写该节内容。polisher_agent: 润色一段文本使其更流畅、专业。quality_checker_agent: 检查文本质量返回是否通过及修改意见。3.1 Sequential 编排实战从分析主题到生成大纲这是最直接的模式。在 ADK 中你可能会通过定义一个Workflow类并使用装饰器或特定方法来串联 Agent。# 假设的 ADK 风格代码用于示意 Sequential 流程 from google.adk import workflow, agent workflow.chain def blog_planning_workflow(topic: str): 顺序执行分析主题 - 生成大纲 # 第一步执行主题分析 Agent analysis_result yield agent.run( agenttopic_analyzer_agent, inputs{topic: topic} ) # ADK 会自动将 analysis_result 传递给下一步 # 第二步基于分析结果生成大纲 outline_result yield agent.run( agentoutline_generator_agent, # inputs 会自动包含上一步的 analysis_result你也可以显式指定 inputs{key_points: analysis_result.get(key_points)} ) # 返回最终结果 return { topic_analysis: analysis_result, blog_outline: outline_result } # 使用工作流 result await blog_planning_workflow(大模型多智能体编排) print(result[blog_outline])关键点解析workflow.chain或类似的装饰器声明这是一个顺序工作流。yield关键字是关键。它告诉 ADK“在此处暂停执行这个 Agent 任务等它完成后把结果带回来再继续往下执行。”数据流是自动的。analysis_result自然成为工作流状态的一部分可供后续步骤访问。这避免了手动状态管理。3.2 Parallel 编排实战同时获取大纲和参考资料现在我们在生成大纲的同时并行地去寻找参考资料。这可以节省时间。from google.adk import workflow, agent workflow.chain def enhanced_planning_workflow(topic: str): analysis_result yield agent.run( agenttopic_analyzer_agent, inputs{topic: topic} ) # 关键点使用 workflow.parallel 来定义并行分支 outline_future, references_future yield workflow.parallel( agent.run( agentoutline_generator_agent, inputs{key_points: analysis_result.get(key_points)} ), agent.run( agentreference_finder_agent, inputs{topic: topic, context: analysis_result} ) ) # 等待所有并行任务完成并获取结果 outline_result yield outline_future references_result yield references_future # 聚合结果 return { analysis: analysis_result, outline: outline_result, references: references_result }关键点解析workflow.parallel()接收多个 Agent 执行任务通常以Future或类似对象表示并同时启动它们。它返回的是对应每个任务的“未来结果”句柄如outline_future而不是立即的结果。通过yield outline_future来等待并获取该分支的最终结果。你可以选择等待所有也可以根据需要处理部分完成的结果。错误处理策略一个更健壮的版本可能需要配置并行策略。例如ADK 可能支持workflow.parallel(..., failure_policycontinue)这样即使找参考资料的 Agent 失败了大纲生成的结果仍然可用工作流可以继续。3.3 Loop 编排实战迭代撰写与润色章节这是最复杂的部分。我们需要为大纲中的每个章节循环执行“撰写 - 检查 - 若不达标则润色 - 再检查”的过程。from google.adk import workflow, agent workflow.chain def write_section_workflow(section_title: str, key_points: list): 循环执行撰写章节内容直到质量达标 # 初始撰写初稿 draft yield agent.run( agentsection_writer_agent, inputs{title: section_title, points: key_points} ) current_content draft[content] max_retries 3 attempts 0 is_approved False # Loop 核心while 循环 条件判断 while not is_approved and attempts max_retries: # 检查质量 check_result yield agent.run( agentquality_checker_agent, inputs{text: current_content} ) is_approved check_result.get(approved, False) if is_approved: break # 质量达标退出循环 # 质量不达标进行润色 attempts 1 polishing_result yield agent.run( agentpolisher_agent, inputs{ text: current_content, feedback: check_result.get(feedback) } ) current_content polishing_result[polished_text] # 下一轮循环将使用润色后的 content 再次检查 if not is_approved: # 循环结束仍未达标可以记录日志或采用兜底内容 current_content f{current_content}\n\n[注经过{max_retries}次优化仍未完全达到标准] return {final_content: current_content, attempts: attempts}关键点解析手动循环与 ADK 内置 Loop 节点上述示例展示了用基本控制流while来实现循环。更高级的 ADK 可能会提供专门的Loop或While节点允许你以声明式的方式配置“循环体”和“条件”。# 假设的声明式 Loop 用法 final_state yield workflow.loop( # 循环体一个可以包含多个步骤的小工作流 bodysection_iteration_workflow, # 条件一个函数或 Agent判断是否继续循环 conditioncondition_checker_agent, # 初始状态 initial_state{draft: draft_content}, max_iterations3 )状态管理在循环中current_content就是迭代状态。在声明式 Loop 中ADK 会负责在每次迭代后将输出状态作为下一次迭代的输入状态。退出条件这里有两个条件质量检查通过 (is_approved) 和最大尝试次数 (attempts max_retries)。两者结合确保了循环的可靠性。4. 组合起来构建完整的工作流将以上模式组合就能形成一个完整的多 Agent 博客创作系统。workflow.chain def full_blog_creation_workflow(topic: str): # 1. Sequential: 分析主题 analysis yield agent.run(topic_analyzer_agent, inputs{topic: topic}) # 2. Parallel: 同时生成大纲和寻找参考 outline_future, refs_future yield workflow.parallel( agent.run(outline_generator_agent, inputsanalysis), agent.run(reference_finder_agent, inputs{topic: topic}) ) outline yield outline_future references yield refs_future # 3. Parallel Loop: 并行撰写各个章节每个章节内部是撰写-润色循环 section_tasks [] for section in outline[sections]: # 为每个章节创建一个并行的撰写任务该任务内部包含Loop task write_section_workflow( section_titlesection[title], key_pointssection[key_points] ) # 注意这里可能需要 yield from 或 ADK 特定的子工作流调用方式 section_tasks.append(task) # 等待所有章节完成 section_results yield workflow.parallel(*section_tasks) # 4. Sequential: 最终合成与格式化 final_blog yield agent.run(blog_composer_agent, inputs{ outline: outline, sections: section_results, references: references }) return final_blog这个组合工作流清晰地展示了如何将 Sequential、Parallel 和 Loop 像搭积木一样组合起来解决一个复杂的现实问题。5. 实战中的常见问题、调试技巧与优化建议多 Agent 工作流编排在带来强大能力的同时也引入了新的复杂性。下面是一些从实战中总结的坑和技巧。5.1 问题排查当工作流不按预期运行时Agent 执行卡住或无响应检查超时设置每个 Agent 调用都应设置合理的超时时间。在 ADK 中这可能是在 Agent 定义或run调用时配置。网络调用或复杂模型推理可能很慢。查看日志与追踪利用 ADK 或云平台提供的分布式追踪工具如 OpenTelemetry 集成。查看每个节点的输入/输出定位卡在哪一步。简化测试将复杂工作流拆解单独测试每一个 Sequential 块或 Parallel 分支甚至单个 Agent进行隔离验证。数据格式错误或丢失强化类型与模式验证在 Agent 的输入输出定义中尽可能使用 Pydantic 等工具定义严格的 Schema。这能在运行时早期捕获数据不匹配的错误。记录中间状态在关键步骤后将中间结果的结构化日志打印出来或存入临时存储确保数据按你想象的方式传递。处理空值或异常结果Agent 可能返回None或包含错误信息的字典。下游 Agent 的输入处理逻辑需要健壮避免因KeyError导致整个工作流崩溃。并行任务资源爆炸限制并发度不要无节制地启动并行任务。尤其是调用外部 API如 OpenAI时要考虑其速率限制。使用信号量或 ADK 提供的并发控制机制来限制最大并行数。实现队列与退避对于大量并行任务考虑使用任务队列并实现指数退避重试策略以应对暂时的服务不可用。5.2 性能与成本优化缓存中间结果如果工作流经常以相同或相似的输入运行考虑缓存那些计算成本高的 Agent 结果例如主题分析、参考查找。这可以大幅降低延迟和 API 调用成本。惰性执行与条件分支不是所有分支都需要执行。ADK 可能支持条件节点if-else允许你根据中间结果动态决定执行路径。例如只有当初稿质量检查不通过时才触发润色 Agent。Agent 的粒度选择不要过度分解。如果一个“超级 Agent”能可靠地完成一个连贯的子任务可能比用三个需要频繁通信的小 Agent 序列更高效、更简单。在编排复杂性和 Agent 能力之间找到平衡。监控与度量为工作流中的关键节点添加监控指标如执行时间、成功率、Token 消耗量。这能帮助你识别性能瓶颈和成本中心进行针对性优化。5.3 设计模式与最佳实践单一职责每个 Agent 应该只做好一件事。这样更容易测试、复用和编排。定义清晰接口明确每个 Agent 的输入和输出格式并将其作为团队契约。使用 JSON Schema 等工具进行文档化和验证。实现幂等性尽可能让 Agent 和工作流具备幂等性即同样的输入总是产生同样的输出。这对于错误重试和调试至关重要。版本化当你更新某个 Agent 的提示词或逻辑时考虑对整个工作流进行版本化。这样你可以回滚到稳定版本并进行 A/B 测试。多 Agent 工作流编排是一个强大的范式它将 AI 应用的开发从“编写智能”提升到了“编排智能”的层次。Google ADK 提供的这些基础模式Sequential, Loop, Parallel是构建复杂、可靠 AI 系统的基石。从理解它们的本质出发通过小范围实战不断迭代你就能设计出既能解决复杂问题又易于维护和扩展的多智能体系统。 Google ADK多Agent工作流编排实战：Sequential、Loop、Parallel模式深度解析
1. 项目概述为什么我们需要编排多 Agent 工作流如果你最近也在捣鼓大模型应用开发尤其是尝试让多个 AI 智能体Agent协同工作那你大概率会遇到一个头疼的问题怎么让它们听话地、有逻辑地、高效地配合起来是让 Agent A 干完活把结果扔给 Agent B然后等 B 干完再给 C还是说有些任务可以同时开干最后再汇总又或者某个环节需要根据中间结果反复迭代直到满足条件这就是“工作流编排”要解决的核心问题。它不再是单个 Agent 的“单打独斗”而是上升到团队协作的“项目管理”层面。Google 的 Agent Development Kit (ADK) 正是为了解决这个痛点而生的一个框架。它提供了一套直观的“积木”让我们可以用代码清晰地定义出 Sequential顺序、Loop循环、Parallel并行这些经典的工作流模式。想象一下你要开发一个智能内容创作助手。流程可能是先让一个“主题分析”Agent 理解用户需求然后一个“大纲生成”Agent 列出结构接着多个“章节撰写”Agent 可以并行填充不同部分最后再让一个“校对润色”Agent 循环检查直到质量达标。手动用回调或者一堆if-else来管理这个流程代码很快就会变成一团乱麻。而 ADK 的编排能力能让这个复杂流程像搭乐高一样清晰、可维护。所以这个项目实战的目的很明确我们不只满足于知道 ADK 有这些概念而是要亲手拆解用具体的代码案例看看 Sequential、Loop、Parallel 这三种核心模式在 ADK 里到底怎么用背后有什么讲究以及在实际操作中会遇到哪些坑。无论你是想构建一个复杂的自动化流程还是单纯想提升多 Agent 系统的可控性这次拆解都能给你提供可直接复用的“脚手架”。2. 核心模式深度解析Sequential, Loop, Parallel 的设计哲学在深入代码之前我们必须先理解这三种模式在 Agent 协作语境下的本质区别和适用场景。这决定了你如何为你的任务选择正确的“编排模式”。2.1 Sequential顺序执行最基础的流水线设计哲学这是最简单、最直观的链式调用。Agent B 必须等待 Agent A 完成任务并输出结果后才能开始自己的工作。数据流是单向、分阶段的。这种模式模拟了传统软件中的函数调用链或者工业生产中的装配线。核心特点与考量强依赖性后置 Agent 的输入严重依赖于前置 Agent 的输出。如果 A 失败了或者输出的格式不符合 B 的预期整个流程就会中断。状态传递ADK 的 Sequential 编排通常会负责将前一个 Agent 的输出自动地、结构化地传递给下一个 Agent 作为输入的一部分。你不需要手动写胶水代码去传递result。错误传播任何一个环节的失败都会导致整个 Sequential 链的失败除非你显式地设置了错误处理这在 ADK 中通常通过try-catch或类似的错误处理节点来实现。适用场景适合步骤清晰、阶段明确、且后续步骤必须基于前序步骤完整结果的任务。例如数据清洗 - 数据分析 - 报告生成。注意不要因为简单就滥用 Sequential。如果任务间没有强依赖用 Sequential 会导致不必要的等待拉低整体效率。2.2 Loop循环执行基于条件的反复迭代设计哲学让一个或多个 Agent 重复执行直到满足某个退出条件。这引入了“状态”和“条件判断”的概念是实现自动化决策和优化的关键。核心特点与考量循环条件这是 Loop 模式的核心。条件可以是最大迭代次数防止无限循环例如“最多重试5次”。结果质量判断由一个“判断 Agent”或一个条件函数来评估当前结果是否达标例如生成的代码是否通过了单元测试摘要的 Rouge 分数是否超过阈值。状态变化直到某个状态变量不再改变例如优化算法收敛。循环体可以是一个简单的 Agent也可以是一个复杂的子工作流比如一个小的 Sequential 链。状态管理每次循环迭代都需要处理上一次的结果作为下一次的输入。ADK 的 Loop 构造需要能清晰地维护这个迭代状态。适用场景代码调试与优化、文本迭代润色直到无错误或风格达标、强化学习中的策略尝试、数据爬取直到获取到目标信息。实操心得设计循环条件时要格外小心。过于宽松的条件可能导致早停结果质量不佳过于严格或存在逻辑漏洞的条件则可能导致无限循环。务必设置一个“安全阀”——最大迭代次数。2.3 Parallel并行执行提升吞吐量的关键设计哲学让多个独立或半独立的 Agent 同时执行最后收集所有结果进行聚合。目标是充分利用计算资源缩短整体任务的端到端延迟。核心特点与考量任务独立性这是并行有效的前提。并行执行的各个分支任务之间不应该有直接的、执行过程中的数据依赖。它们可以依赖共同的初始输入但彼此间不通信。并发与控制ADK 需要管理并发的执行可能是线程、异步任务或分布式任务。你需要考虑并发度同时运行几个 Agent以及资源限制避免压垮你的后端或 API 配额。结果聚合所有并行分支完成后需要有一个“聚合”步骤。聚合方式多样合并如汇总多个 Agent 搜索的结果列表。投票/选择如多个翻译 Agent 的结果由另一个 Agent 选择最佳。合成如多个文案 Agent 生成的广告语被汇总成一份报告。错误处理与 Sequential 不同一个分支的失败不应导致整个并行任务立即失败。通常有两种策略all一个失败则整体失败或any忽略失败的分支聚合剩余成功的结果。ADK 需要支持这种策略配置。适用场景同时查询多个知识源或 API、批量处理一个列表中的不同项目如分析多篇文档的情感、生成同一任务的多种备选方案A/B 测试思路。避坑指南并行不是银弹。它会增加系统的复杂性和调试难度日志交织、错误来源分散。同时如果并行任务最终需要竞争同一个稀缺资源如同一个数据库的行锁、同一个 API 的严格速率限制可能会引发性能瓶颈甚至死锁。3. 基于 Google ADK 的实战代码拆解理解了理论我们进入实战环节。假设我们构建一个“智能技术博客助手”工作流它需要1) 分析主题2) 并行生成大纲和寻找参考链接3) 根据大纲循环撰写并润色章节4) 最终合成发布。我们将用简化的代码示例来拆解 ADK 中如何实现这些模式。首先假设我们已经定义了几个基础的 Agenttopic_analyzer_agent: 分析博客主题返回核心要点和受众。outline_generator_agent: 根据要点生成博客大纲。reference_finder_agent: 根据主题寻找相关的参考文档链接。section_writer_agent: 根据大纲中的一节标题和要点撰写该节内容。polisher_agent: 润色一段文本使其更流畅、专业。quality_checker_agent: 检查文本质量返回是否通过及修改意见。3.1 Sequential 编排实战从分析主题到生成大纲这是最直接的模式。在 ADK 中你可能会通过定义一个Workflow类并使用装饰器或特定方法来串联 Agent。# 假设的 ADK 风格代码用于示意 Sequential 流程 from google.adk import workflow, agent workflow.chain def blog_planning_workflow(topic: str): 顺序执行分析主题 - 生成大纲 # 第一步执行主题分析 Agent analysis_result yield agent.run( agenttopic_analyzer_agent, inputs{topic: topic} ) # ADK 会自动将 analysis_result 传递给下一步 # 第二步基于分析结果生成大纲 outline_result yield agent.run( agentoutline_generator_agent, # inputs 会自动包含上一步的 analysis_result你也可以显式指定 inputs{key_points: analysis_result.get(key_points)} ) # 返回最终结果 return { topic_analysis: analysis_result, blog_outline: outline_result } # 使用工作流 result await blog_planning_workflow(大模型多智能体编排) print(result[blog_outline])关键点解析workflow.chain或类似的装饰器声明这是一个顺序工作流。yield关键字是关键。它告诉 ADK“在此处暂停执行这个 Agent 任务等它完成后把结果带回来再继续往下执行。”数据流是自动的。analysis_result自然成为工作流状态的一部分可供后续步骤访问。这避免了手动状态管理。3.2 Parallel 编排实战同时获取大纲和参考资料现在我们在生成大纲的同时并行地去寻找参考资料。这可以节省时间。from google.adk import workflow, agent workflow.chain def enhanced_planning_workflow(topic: str): analysis_result yield agent.run( agenttopic_analyzer_agent, inputs{topic: topic} ) # 关键点使用 workflow.parallel 来定义并行分支 outline_future, references_future yield workflow.parallel( agent.run( agentoutline_generator_agent, inputs{key_points: analysis_result.get(key_points)} ), agent.run( agentreference_finder_agent, inputs{topic: topic, context: analysis_result} ) ) # 等待所有并行任务完成并获取结果 outline_result yield outline_future references_result yield references_future # 聚合结果 return { analysis: analysis_result, outline: outline_result, references: references_result }关键点解析workflow.parallel()接收多个 Agent 执行任务通常以Future或类似对象表示并同时启动它们。它返回的是对应每个任务的“未来结果”句柄如outline_future而不是立即的结果。通过yield outline_future来等待并获取该分支的最终结果。你可以选择等待所有也可以根据需要处理部分完成的结果。错误处理策略一个更健壮的版本可能需要配置并行策略。例如ADK 可能支持workflow.parallel(..., failure_policycontinue)这样即使找参考资料的 Agent 失败了大纲生成的结果仍然可用工作流可以继续。3.3 Loop 编排实战迭代撰写与润色章节这是最复杂的部分。我们需要为大纲中的每个章节循环执行“撰写 - 检查 - 若不达标则润色 - 再检查”的过程。from google.adk import workflow, agent workflow.chain def write_section_workflow(section_title: str, key_points: list): 循环执行撰写章节内容直到质量达标 # 初始撰写初稿 draft yield agent.run( agentsection_writer_agent, inputs{title: section_title, points: key_points} ) current_content draft[content] max_retries 3 attempts 0 is_approved False # Loop 核心while 循环 条件判断 while not is_approved and attempts max_retries: # 检查质量 check_result yield agent.run( agentquality_checker_agent, inputs{text: current_content} ) is_approved check_result.get(approved, False) if is_approved: break # 质量达标退出循环 # 质量不达标进行润色 attempts 1 polishing_result yield agent.run( agentpolisher_agent, inputs{ text: current_content, feedback: check_result.get(feedback) } ) current_content polishing_result[polished_text] # 下一轮循环将使用润色后的 content 再次检查 if not is_approved: # 循环结束仍未达标可以记录日志或采用兜底内容 current_content f{current_content}\n\n[注经过{max_retries}次优化仍未完全达到标准] return {final_content: current_content, attempts: attempts}关键点解析手动循环与 ADK 内置 Loop 节点上述示例展示了用基本控制流while来实现循环。更高级的 ADK 可能会提供专门的Loop或While节点允许你以声明式的方式配置“循环体”和“条件”。# 假设的声明式 Loop 用法 final_state yield workflow.loop( # 循环体一个可以包含多个步骤的小工作流 bodysection_iteration_workflow, # 条件一个函数或 Agent判断是否继续循环 conditioncondition_checker_agent, # 初始状态 initial_state{draft: draft_content}, max_iterations3 )状态管理在循环中current_content就是迭代状态。在声明式 Loop 中ADK 会负责在每次迭代后将输出状态作为下一次迭代的输入状态。退出条件这里有两个条件质量检查通过 (is_approved) 和最大尝试次数 (attempts max_retries)。两者结合确保了循环的可靠性。4. 组合起来构建完整的工作流将以上模式组合就能形成一个完整的多 Agent 博客创作系统。workflow.chain def full_blog_creation_workflow(topic: str): # 1. Sequential: 分析主题 analysis yield agent.run(topic_analyzer_agent, inputs{topic: topic}) # 2. Parallel: 同时生成大纲和寻找参考 outline_future, refs_future yield workflow.parallel( agent.run(outline_generator_agent, inputsanalysis), agent.run(reference_finder_agent, inputs{topic: topic}) ) outline yield outline_future references yield refs_future # 3. Parallel Loop: 并行撰写各个章节每个章节内部是撰写-润色循环 section_tasks [] for section in outline[sections]: # 为每个章节创建一个并行的撰写任务该任务内部包含Loop task write_section_workflow( section_titlesection[title], key_pointssection[key_points] ) # 注意这里可能需要 yield from 或 ADK 特定的子工作流调用方式 section_tasks.append(task) # 等待所有章节完成 section_results yield workflow.parallel(*section_tasks) # 4. Sequential: 最终合成与格式化 final_blog yield agent.run(blog_composer_agent, inputs{ outline: outline, sections: section_results, references: references }) return final_blog这个组合工作流清晰地展示了如何将 Sequential、Parallel 和 Loop 像搭积木一样组合起来解决一个复杂的现实问题。5. 实战中的常见问题、调试技巧与优化建议多 Agent 工作流编排在带来强大能力的同时也引入了新的复杂性。下面是一些从实战中总结的坑和技巧。5.1 问题排查当工作流不按预期运行时Agent 执行卡住或无响应检查超时设置每个 Agent 调用都应设置合理的超时时间。在 ADK 中这可能是在 Agent 定义或run调用时配置。网络调用或复杂模型推理可能很慢。查看日志与追踪利用 ADK 或云平台提供的分布式追踪工具如 OpenTelemetry 集成。查看每个节点的输入/输出定位卡在哪一步。简化测试将复杂工作流拆解单独测试每一个 Sequential 块或 Parallel 分支甚至单个 Agent进行隔离验证。数据格式错误或丢失强化类型与模式验证在 Agent 的输入输出定义中尽可能使用 Pydantic 等工具定义严格的 Schema。这能在运行时早期捕获数据不匹配的错误。记录中间状态在关键步骤后将中间结果的结构化日志打印出来或存入临时存储确保数据按你想象的方式传递。处理空值或异常结果Agent 可能返回None或包含错误信息的字典。下游 Agent 的输入处理逻辑需要健壮避免因KeyError导致整个工作流崩溃。并行任务资源爆炸限制并发度不要无节制地启动并行任务。尤其是调用外部 API如 OpenAI时要考虑其速率限制。使用信号量或 ADK 提供的并发控制机制来限制最大并行数。实现队列与退避对于大量并行任务考虑使用任务队列并实现指数退避重试策略以应对暂时的服务不可用。5.2 性能与成本优化缓存中间结果如果工作流经常以相同或相似的输入运行考虑缓存那些计算成本高的 Agent 结果例如主题分析、参考查找。这可以大幅降低延迟和 API 调用成本。惰性执行与条件分支不是所有分支都需要执行。ADK 可能支持条件节点if-else允许你根据中间结果动态决定执行路径。例如只有当初稿质量检查不通过时才触发润色 Agent。Agent 的粒度选择不要过度分解。如果一个“超级 Agent”能可靠地完成一个连贯的子任务可能比用三个需要频繁通信的小 Agent 序列更高效、更简单。在编排复杂性和 Agent 能力之间找到平衡。监控与度量为工作流中的关键节点添加监控指标如执行时间、成功率、Token 消耗量。这能帮助你识别性能瓶颈和成本中心进行针对性优化。5.3 设计模式与最佳实践单一职责每个 Agent 应该只做好一件事。这样更容易测试、复用和编排。定义清晰接口明确每个 Agent 的输入和输出格式并将其作为团队契约。使用 JSON Schema 等工具进行文档化和验证。实现幂等性尽可能让 Agent 和工作流具备幂等性即同样的输入总是产生同样的输出。这对于错误重试和调试至关重要。版本化当你更新某个 Agent 的提示词或逻辑时考虑对整个工作流进行版本化。这样你可以回滚到稳定版本并进行 A/B 测试。多 Agent 工作流编排是一个强大的范式它将 AI 应用的开发从“编写智能”提升到了“编排智能”的层次。Google ADK 提供的这些基础模式Sequential, Loop, Parallel是构建复杂、可靠 AI 系统的基石。从理解它们的本质出发通过小范围实战不断迭代你就能设计出既能解决复杂问题又易于维护和扩展的多智能体系统。