23Workflow Agents顺序、并行与循环协作《Eino 实战用 Go 构建 AI 应用与智能体》· 第 23 篇关键词SequentialAgent、ParallelAgent、LoopAgent、确定性编排、上下文传递前置条件已完成 22AgentAsTool 与 08Workflow 实战。第 22 篇讲的 AgentAsTool 是动态协作何时委派由父 Agent 决定。但有些协作流程是固定的不需要模型来判断先规划、再执行、最后总结——顺序是确定的。同时产出多个方案供选择——可以并行。反复改进直到满足条件——需要循环。这类场景用Workflow Agents更直接你用代码声明协作结构而不是让模型去猜。一、三种预设模式Eino 提供三个构造函数类型构造函数行为Sequentialadk.NewSequentialAgent按数组顺序依次执行子 AgentParalleladk.NewParallelAgent并发执行所有子 Agent全部完成后结束Loopadk.NewLoopAgent循环执行子 Agent 序列直到BreakLoop或超过MaxIterations三者配置结构一致typeSequentialAgentConfigstruct{NamestringDescriptionstringSubAgents[]adk.Agent}关键理解这不是“让模型决定顺序”而是“你决定顺序让每个子 Agent 在自己的环节里自主工作”。自主性与确定性的边界因此变得清晰。二、上下文如何传递官方文档说明Workflow Agent 之间通过 Transfer 传递上下文上游 Agent 的输出会自动拼接到下游 Agent 的输入消息中。也就是说planner 输出 → 自动进入 executor 的输入 executor 输出 → 自动进入 summarizer 的输入这和 AgentAsTool 的隔离设计正好相反Workflow Agents 是共享上下文的。AgentAsToolWorkflow Agents上下文子 Agent 独立上游输出拼入下游控制权父 Agent 动态决定结构预先确定适合开放任务固定流程因此选择依据很直接流程固定就用 Workflow Agents需要动态决策就用 AgentAsTool。一个需要知道的背景官方对 Workflow Agents 标注了 “NOT RECOMMENDED”理由是它们建立在“转交 全量上下文共享”之上而这在实践中未证明更有效。这不代表它们不能用——流程确实固定时用代码声明顺序仍然比让模型猜更可靠。但如果你的场景只是“做完 A 再做 B”用 compose 的 Chain第 06 篇可能更简单。三、完整示例下面这段程序演示顺序与并行两种模式不访问外部服务packagemainimport(contextfmtloggithub.com/cloudwego/eino/adkgithub.com/cloudwego/eino/components/modelgithub.com/cloudwego/eino/schema)typeechoModelstruct{tagstring}func(m*echoModel)Generate(_context.Context,_[]*schema.Message,_...model.Option)(*schema.Message,error){returnschema.AssistantMessage([m.tag] 处理完成,nil),nil}func(m*echoModel)Stream(ctx context.Context,in[]*schema.Message,opts...model.Option)(*schema.StreamReader[*schema.Message],error){msg,err:m.Generate(ctx,in,opts...)iferr!nil{returnnil,err}sr,sw:schema.Pipe[*schema.Message](1)gofunc(){defersw.Close();sw.Send(msg,nil)}()returnsr,nil}func(m*echoModel)WithTools([]*schema.ToolInfo)(model.ToolCallingChatModel,error){returnm,nil}funcmakeAgent(ctx context.Context,name,descstring)(adk.Agent,error){returnadk.NewChatModelAgent(ctx,adk.ChatModelAgentConfig{Name:name,Description:desc,Instruction:你是desc,Model:echoModel{tag:name},})}funcmain(){iferr:run();err!nil{log.Fatal(err)}}funcrun()error{ctx:context.Background()planner,err:makeAgent(ctx,planner,制定计划)iferr!nil{returnerr}executor,err:makeAgent(ctx,executor,执行计划)iferr!nil{returnerr}summarizer,err:makeAgent(ctx,summarizer,总结结果)iferr!nil{returnerr}// 顺序执行planner - executor - summarizer。seq,err:adk.NewSequentialAgent(ctx,adk.SequentialAgentConfig{Name:pipeline,Description:计划-执行-总结流水线,SubAgents:[]adk.Agent{planner,executor,summarizer},})iferr!nil{returnerr}runner:adk.NewRunner(ctx,adk.RunnerConfig{Agent:seq})iter:runner.Query(ctx,处理一个复杂工单)fmt.Println( SequentialAgent )for{event,ok:iter.Next()if!ok{break}ifevent.Err!nil{returnevent.Err}ifmv:messageOutput(event);mv!nilmv.Message!nilmv.Message.Content!{fmt.Printf( agent%-12s content%q\n,event.AgentName,mv.Message.Content)}}// 并行执行两个专家互不依赖同时跑。writerA,err:makeAgent(ctx,writerA,撰写草稿)iferr!nil{returnerr}writerB,err:makeAgent(ctx,writerB,撰写备选方案)iferr!nil{returnerr}par,err:adk.NewParallelAgent(ctx,adk.ParallelAgentConfig{Name:parallel-team,Description:并行产出多个方案,SubAgents:[]adk.Agent{writerA,writerB},})iferr!nil{returnerr}runner2:adk.NewRunner(ctx,adk.RunnerConfig{Agent:par})iter2:runner2.Query(ctx,写两个方案)fmt.Println( ParallelAgent )for{event,ok:iter2.Next()if!ok{break}ifevent.Err!nil{returnevent.Err}ifmv:messageOutput(event);mv!nilmv.Message!nilmv.Message.Content!{fmt.Printf( agent%-12s content%q\n,event.AgentName,mv.Message.Content)}}returnnil}funcmessageOutput(event*adk.AgentEvent)*adk.MessageVariant{ifeventnil||event.Outputnil{returnnil}returnevent.Output.MessageOutput}实机输出 SequentialAgent agentplanner content[planner] 处理完成 agentexecutor content[executor] 处理完成 agentsummarizer content[summarizer] 处理完成 ParallelAgent agentwriterB content[writerB] 处理完成 agentwriterA content[writerA] 处理完成两点观察顺序模式的执行次序严格符合数组顺序事件按planner → executor → summarizer排列。并行模式的输出顺序不保证。上面这段writerB在前、writerA在后的顺序就是一次实际运行的输出同一程序多次运行先后顺序可能不同。不要依赖事件顺序判断哪个 Agent“先跑完”。四、Loop循环改进LoopAgent会反复执行子 Agent 序列直到满足退出条件。它适合“生成—评审—改进”这类模式。退出有两条路径退出方式说明BreakLoop动作子 Agent 主动发出表示“可以结束了”MaxIterations达到上限强制结束必须设置MaxIterations。如果子 Agent 永远不发BreakLoop没有上限就会一直循环下去——和第 07 篇 Graph 循环的注意事项完全一致。loop,err:adk.NewLoopAgent(ctx,adk.LoopAgentConfig{Name:improve-loop,Description:反复改进直到满足条件,SubAgents:[]adk.Agent{writer,reviewer},})五、与第 08 篇的 compose.Workflow 有什么区别这是本系列里第二次出现“workflow”这个名字必须区分清楚compose.WorkflowADK 的 Workflow Agents层次组件编排低层智能体组合高层节点是组件Lambda、ChatModel 等Agent数据传递结构体字段映射消息自动拼接自主性无完全确定每个子 Agent 内部自主所在包composeadk它们不是同一个东西也不能互相替代。简单的判断方式流程里每一步都是组件级操作查库、调模型、转换数据→ 用compose。流程里每一步都是一个需要自主工作的 Agent→ 用 ADK 的 Workflow Agents。六、什么时候用 Workflow Agents场景建议顺序固定规划→执行→总结SequentialAgent多个独立产出多方案、多视角ParallelAgent需要反复改进直到达标LoopAgent步骤是组件级操作不涉及 Agentcompose.Chain/Graph第 06–08 篇何时委派不确定AgentAsTool第 22 篇还有一点值得重复如果条件允许优先用现有的编排 API 表达流程而不是引入更多 Agent。多一层 Agent 就多一层模型调用、多一层延迟、多一处可能出错的地方。能用确定性代码表达的不要让模型去决定。七、常见问题并行模式输出顺序不确定这是正常的。并行调度不保证完成顺序需要顺序时应改用SequentialAgent。下游 Agent 看不到上游输出Workflow Agents 会自动把上游输出拼入下游输入。如果没看到检查是否误用了AgentAsTool它的默认行为是隔离。循环停不下来缺MaxIterations或子 Agent 没有发出BreakLoop动作。两个条件至少要有其一。子 Agent 报了Exit但整个流程没结束在 Workflow Agents 内部Exit等动作的作用范围受限于子 Agent 自己不会意外终止父流程。这是保护机制不是 bug。和 compose.Workflow 混用了确认使用的包compose.NewWorkflow与adk.NewSequentialAgent是完全不同的东西。八、小结Workflow Agents 让你用代码声明协作结构适合流程固定的场景。三种模式SequentialAgent顺序、ParallelAgent并行、LoopAgent循环。上游 Agent 的输出会自动拼入下游 Agent 的输入与 AgentAsTool 的隔离设计相反。并行模式的输出顺序不保证循环必须有MaxIterations或BreakLoop。compose.Workflow是组件编排ADK 的 Workflow Agents 是智能体组合两者不可混用。能确定性表达就别引入 Agent——多一层就多一层成本与不确定性。下一篇《Supervisor 模式让协调者管理多个专家》看另一种有明确层级关系的协作方式。参考资料与版本说明资料核对日期为2026 年 10 月 9 日Agent 协作Workflow AgentsEino ADK 概述Eino 主仓库本文示例按Eino v0.9.21编写使用回显模型不访问外部服务已实机运行正文输出为真实结果。