串行、并行还是主从三种多智能体编排模式横评与选型建议【免费下载链接】harness-sdkBuild an agent harness and control it end-to-end. Open-source SDK for production AI agents in Python TypeScript - any model, any cloud.项目地址: https://gitcode.com/GitHub_Trending/sdkpython13/harness-sdk多智能体系统的第一道分水岭不是模型选型而是谁来决定下一个 Agent 跑、怎么跑。同一批 Agent用链式边连起来是串行流水线用扇出边连起来是并行 fan-out交给一个调度者去调则是主从委派——而 harness-sdkStrands Agents恰好把这三类模式都做成了同一套可组合的原语Agent、Graph、Swarm与Agent作为工具。社区近期的多篇 harness-sdk 实战文章反复提及串行/并行/主从三种典型编排模式与max_concurrency调优本文不再停留在概念层而是直接打开仓库源码从 GraphBuilder、Swarm、Agent 作为工具 的实现出发横评三种模式的复杂度、稳定性与状态管理差异并给出可落地的选型建议。三种模式从能画白板到画不出来Strands 官方文档对三种模式给过一句精准的判据Graph 用在你能在白板上画出工作流的场景Swarm 用在团队需要一起摸索的场景Agents-as-Tools 用在管理者与专家关系清晰的场景见 multi-agent-patterns-agents-as-tools.mdx 与 multi-agent-patterns-graph-workflows.mdx。对应到标题的三类问题串行执行顺序由边的依赖关系完全锁定。A - B - CB 必须在 A 完成后启动顺序可预测、可审计。并行同一拓扑内没有依赖关系的节点并发执行。Graph 的 fan-out 是显式并行的唯一官方形态并发度受 maxConcurrencyTS 或 Python 端按批次调度的约束。主从一个编排者orchestrator通过工具调用把任务委派给专家 Agent。Strands 有两种实现Agent.as_tool()的 hub-and-spoke 模式以及由模型自主handoff的 Swarm。三者并非互斥——文档明确说明三种模式可以嵌套Swarm 可以作为 Graph 的节点Graph 可以放进 Agent 的工具里。选型的第一步是先判断你的任务属于哪一类。同一任务三种实现的代码对照以研究 AI 对医疗健康的影响并输出报告为例先看串行 Graph四个 Agent 按research - analysis - summarize - report依次执行每个下游节点会收到上游带标签的输出该拼接逻辑见 graph.py 的_build_node_inputfrom strands import Agent from strands.multiagent import GraphBuilder from strands.vended_tools.web_fetch import web_fetch researcher Agent(nameresearcher, system_promptGather comprehensive information from the web., tools[web_fetch]) analyst Agent(nameanalyst, system_promptIdentify patterns and key insights from research.) summarizer Agent(namesummarizer, system_promptCondense raw research into concise key points.) report_writer Agent(namereport_writer, system_promptSynthesize analysis into a final report.) builder GraphBuilder() builder.add_node(researcher, research) builder.add_node(analyst, analysis) builder.add_node(summarizer, summarize) builder.add_node(report_writer, report) builder.add_edge(research, analysis) builder.add_edge(research, summarize) # analyst 与 summarizer 并行 builder.add_edge(analysis, report) builder.add_edge(summarize, report) # report 等待两者完成 builder.set_execution_timeout(600) graph builder.build() result graph(Research the impact of AI on healthcare)上面这段其实同时展示了并行 fan-outanalysis与summarize都只依赖research彼此无依赖于是它们在同一批次内并发执行。执行器层面Python 的 Graph 采用批次调度——_execute_graph先把当前就绪节点整批并发启动等待整批完成后才调度下一批而 TS 实现是节点就绪即启动并发上限由maxConcurrency决定默认 Infinity。两种调度哲学差异详见源码注释 graph.ts。再看主从hub-and-spoke一个 writer 编排者直接持有 researcher 作为工具专家上下文与编排者上下文完全隔离专家即使跑完上千 token 的检索也只把结论回传给编排者from strands import Agent researcher Agent( nameresearcher, system_promptYou are a research specialist. Find factual information., tools[web_fetch], ) writer Agent( namewriter, system_promptYou are a technical writer. Use the researcher to gather facts., tools[researcher], # 直接传入 Agent 实例 ) writer(Research the FastAPI repo and write a 3-sentence summary.)Agent实例被包装为_AgentAsTool见 _agent_as_tool.py支持delegateTrue子代理结果直接作为最终答复、不再多一轮模型调用和preserve_contextTrue跨调用保留子代理会话两个关键开关。若希望委派更受控可用make_subagent工厂subagent.py它把工具入参 schema 交给 authority-mode 系统推导——轴的策略Fixed/Inherit/Open/Choice决定模型能看到哪些参数、能填哪些值实现预设角色 模型自主补充的混合治理详见 spec.py。最后是去中心化的主从协商Swarm没有固定编排者每个 Agent 通过注入的handoff_to_agent工具把控制权完整移交给下一个 Agent同时共享累积上下文。仓库自带的集成示例multi-agent-patterns-agent-swarms.mdx展示了故障排查场景triage 先评估再按发现把控制权交给日志分析师或指标分析师最后交给部署审查者收尾——执行路径在执行前完全不可知。复杂度与稳定性源码层面的关键差异控制流的确定性不同。Graph 的执行顺序由边决定条件路由由边的 condition 函数决定——condition 既可以只看GraphState也可以读取调用方传入的invocation_statefeature flag、用户角色等运行时上下文路由决策不依赖模型自觉而 Swarm 的路由完全交给模型的 tool 调用属于非确定性路径。这正是能画白板就选 Graph画不出来才选 Swarm的根本原因。失败语义不同这是最容易踩坑的差异。Python 的 Graph 节点失败会直接抛异常、fail-fast 终止整图graph.py 的_execute_node中所有失败统一 re-raise而 TS 的 Graph 恰好相反——节点失败产生FAILED的 NodeResult并行分支可以继续走graph.ts 的注释明确写了这一差异。Swarm 则在三层防护下运行max_handoffs限制交接总次数、max_iterations限制总执行次数另有repetitive_handoff_detection_window与repetitive_handoff_min_unique_agents检测两三个 Agent 互相 ping-pong的循环实现见 swarm.py 的SwarmState.should_continue。实测中 Swarm 必须配齐这些上限否则自组织很容易变成死循环烧 token。状态与并发控制粒度不同。Graph 的状态是显式的GraphState记录 completed/failed/interrupted 节点集合、execution_order、累积 token 用量与延迟并通过serialize_state/deserialize_state支持跨进程持久化与中断恢复仓库测试 test_multiagent_graph.py 验证了中途失败后从持久化状态继续只补跑未完成节点。Swarm 则用SharedContext让每个后继 Agent 看到前序 Agent 沉淀的结构化上下文附带handoff_message与节点历史。Graph 侧可控参数包括max_node_executions防环、execution_timeout总时长、node_timeout单节点时长、reset_on_revisit节点被重访时是否重置消息与状态TS 侧另有maxConcurrency直接限制并行度。这些参数在测试套件中均有对应用例如 self-loop 计数、maxConcurrency: 1强制串行。选型建议先定结构再调并发最后管状态综合源码与实战情报给出三条可直接套用的建议结构优先于并发。凡是流程可预先画出的合规流水线、报告生成、数据处理一律用 Graph显式边保证执行顺序与可审计性条件边实现分支无依赖节点天然并行。凡是流程依赖前一步发现的故障排查、开放式研究才考虑 Swarm——但务必配齐max_handoffs/max_iterations/execution_timeout三件套。主从模式优先给上下文隔离场景。编排者上下文要保持干净、专家要跑大量噪音工具时用Agent.as_tool()或subagent让专家在独立上下文中消化原始输出只回传结论。需要控制委派边界角色、工具子集、模型时用spec.py的轴策略收紧模型可配置空间而非放任自由。并发参数按失败代价调。Graph 并行时先调小批次/maxConcurrency验证稳定性再逐步放大同时设置max_node_executions与execution_timeout作为兜底护栏并配合serialize_state让中途失败可以断点续跑而不是整图重来。Swarm 侧则要额外开启重复交接检测避免少数 Agent 之间来回空转。三种模式没有优劣只有适配。决定性的问题始终只有一个这个任务的下一步到底该由代码决定还是由模型发现Graph 把答案写在边上Swarm 把答案交给模型主从模式则把答案锁在编排者的工具调用里——理解这一点比记住任何 API 都更有价值。【免费下载链接】harness-sdkBuild an agent harness and control it end-to-end. Open-source SDK for production AI agents in Python TypeScript - any model, any cloud.项目地址: https://gitcode.com/GitHub_Trending/sdkpython13/harness-sdk创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 串行、并行还是主从？三种多智能体编排模式横评与选型建议
串行、并行还是主从三种多智能体编排模式横评与选型建议【免费下载链接】harness-sdkBuild an agent harness and control it end-to-end. Open-source SDK for production AI agents in Python TypeScript - any model, any cloud.项目地址: https://gitcode.com/GitHub_Trending/sdkpython13/harness-sdk多智能体系统的第一道分水岭不是模型选型而是谁来决定下一个 Agent 跑、怎么跑。同一批 Agent用链式边连起来是串行流水线用扇出边连起来是并行 fan-out交给一个调度者去调则是主从委派——而 harness-sdkStrands Agents恰好把这三类模式都做成了同一套可组合的原语Agent、Graph、Swarm与Agent作为工具。社区近期的多篇 harness-sdk 实战文章反复提及串行/并行/主从三种典型编排模式与max_concurrency调优本文不再停留在概念层而是直接打开仓库源码从 GraphBuilder、Swarm、Agent 作为工具 的实现出发横评三种模式的复杂度、稳定性与状态管理差异并给出可落地的选型建议。三种模式从能画白板到画不出来Strands 官方文档对三种模式给过一句精准的判据Graph 用在你能在白板上画出工作流的场景Swarm 用在团队需要一起摸索的场景Agents-as-Tools 用在管理者与专家关系清晰的场景见 multi-agent-patterns-agents-as-tools.mdx 与 multi-agent-patterns-graph-workflows.mdx。对应到标题的三类问题串行执行顺序由边的依赖关系完全锁定。A - B - CB 必须在 A 完成后启动顺序可预测、可审计。并行同一拓扑内没有依赖关系的节点并发执行。Graph 的 fan-out 是显式并行的唯一官方形态并发度受 maxConcurrencyTS 或 Python 端按批次调度的约束。主从一个编排者orchestrator通过工具调用把任务委派给专家 Agent。Strands 有两种实现Agent.as_tool()的 hub-and-spoke 模式以及由模型自主handoff的 Swarm。三者并非互斥——文档明确说明三种模式可以嵌套Swarm 可以作为 Graph 的节点Graph 可以放进 Agent 的工具里。选型的第一步是先判断你的任务属于哪一类。同一任务三种实现的代码对照以研究 AI 对医疗健康的影响并输出报告为例先看串行 Graph四个 Agent 按research - analysis - summarize - report依次执行每个下游节点会收到上游带标签的输出该拼接逻辑见 graph.py 的_build_node_inputfrom strands import Agent from strands.multiagent import GraphBuilder from strands.vended_tools.web_fetch import web_fetch researcher Agent(nameresearcher, system_promptGather comprehensive information from the web., tools[web_fetch]) analyst Agent(nameanalyst, system_promptIdentify patterns and key insights from research.) summarizer Agent(namesummarizer, system_promptCondense raw research into concise key points.) report_writer Agent(namereport_writer, system_promptSynthesize analysis into a final report.) builder GraphBuilder() builder.add_node(researcher, research) builder.add_node(analyst, analysis) builder.add_node(summarizer, summarize) builder.add_node(report_writer, report) builder.add_edge(research, analysis) builder.add_edge(research, summarize) # analyst 与 summarizer 并行 builder.add_edge(analysis, report) builder.add_edge(summarize, report) # report 等待两者完成 builder.set_execution_timeout(600) graph builder.build() result graph(Research the impact of AI on healthcare)上面这段其实同时展示了并行 fan-outanalysis与summarize都只依赖research彼此无依赖于是它们在同一批次内并发执行。执行器层面Python 的 Graph 采用批次调度——_execute_graph先把当前就绪节点整批并发启动等待整批完成后才调度下一批而 TS 实现是节点就绪即启动并发上限由maxConcurrency决定默认 Infinity。两种调度哲学差异详见源码注释 graph.ts。再看主从hub-and-spoke一个 writer 编排者直接持有 researcher 作为工具专家上下文与编排者上下文完全隔离专家即使跑完上千 token 的检索也只把结论回传给编排者from strands import Agent researcher Agent( nameresearcher, system_promptYou are a research specialist. Find factual information., tools[web_fetch], ) writer Agent( namewriter, system_promptYou are a technical writer. Use the researcher to gather facts., tools[researcher], # 直接传入 Agent 实例 ) writer(Research the FastAPI repo and write a 3-sentence summary.)Agent实例被包装为_AgentAsTool见 _agent_as_tool.py支持delegateTrue子代理结果直接作为最终答复、不再多一轮模型调用和preserve_contextTrue跨调用保留子代理会话两个关键开关。若希望委派更受控可用make_subagent工厂subagent.py它把工具入参 schema 交给 authority-mode 系统推导——轴的策略Fixed/Inherit/Open/Choice决定模型能看到哪些参数、能填哪些值实现预设角色 模型自主补充的混合治理详见 spec.py。最后是去中心化的主从协商Swarm没有固定编排者每个 Agent 通过注入的handoff_to_agent工具把控制权完整移交给下一个 Agent同时共享累积上下文。仓库自带的集成示例multi-agent-patterns-agent-swarms.mdx展示了故障排查场景triage 先评估再按发现把控制权交给日志分析师或指标分析师最后交给部署审查者收尾——执行路径在执行前完全不可知。复杂度与稳定性源码层面的关键差异控制流的确定性不同。Graph 的执行顺序由边决定条件路由由边的 condition 函数决定——condition 既可以只看GraphState也可以读取调用方传入的invocation_statefeature flag、用户角色等运行时上下文路由决策不依赖模型自觉而 Swarm 的路由完全交给模型的 tool 调用属于非确定性路径。这正是能画白板就选 Graph画不出来才选 Swarm的根本原因。失败语义不同这是最容易踩坑的差异。Python 的 Graph 节点失败会直接抛异常、fail-fast 终止整图graph.py 的_execute_node中所有失败统一 re-raise而 TS 的 Graph 恰好相反——节点失败产生FAILED的 NodeResult并行分支可以继续走graph.ts 的注释明确写了这一差异。Swarm 则在三层防护下运行max_handoffs限制交接总次数、max_iterations限制总执行次数另有repetitive_handoff_detection_window与repetitive_handoff_min_unique_agents检测两三个 Agent 互相 ping-pong的循环实现见 swarm.py 的SwarmState.should_continue。实测中 Swarm 必须配齐这些上限否则自组织很容易变成死循环烧 token。状态与并发控制粒度不同。Graph 的状态是显式的GraphState记录 completed/failed/interrupted 节点集合、execution_order、累积 token 用量与延迟并通过serialize_state/deserialize_state支持跨进程持久化与中断恢复仓库测试 test_multiagent_graph.py 验证了中途失败后从持久化状态继续只补跑未完成节点。Swarm 则用SharedContext让每个后继 Agent 看到前序 Agent 沉淀的结构化上下文附带handoff_message与节点历史。Graph 侧可控参数包括max_node_executions防环、execution_timeout总时长、node_timeout单节点时长、reset_on_revisit节点被重访时是否重置消息与状态TS 侧另有maxConcurrency直接限制并行度。这些参数在测试套件中均有对应用例如 self-loop 计数、maxConcurrency: 1强制串行。选型建议先定结构再调并发最后管状态综合源码与实战情报给出三条可直接套用的建议结构优先于并发。凡是流程可预先画出的合规流水线、报告生成、数据处理一律用 Graph显式边保证执行顺序与可审计性条件边实现分支无依赖节点天然并行。凡是流程依赖前一步发现的故障排查、开放式研究才考虑 Swarm——但务必配齐max_handoffs/max_iterations/execution_timeout三件套。主从模式优先给上下文隔离场景。编排者上下文要保持干净、专家要跑大量噪音工具时用Agent.as_tool()或subagent让专家在独立上下文中消化原始输出只回传结论。需要控制委派边界角色、工具子集、模型时用spec.py的轴策略收紧模型可配置空间而非放任自由。并发参数按失败代价调。Graph 并行时先调小批次/maxConcurrency验证稳定性再逐步放大同时设置max_node_executions与execution_timeout作为兜底护栏并配合serialize_state让中途失败可以断点续跑而不是整图重来。Swarm 侧则要额外开启重复交接检测避免少数 Agent 之间来回空转。三种模式没有优劣只有适配。决定性的问题始终只有一个这个任务的下一步到底该由代码决定还是由模型发现Graph 把答案写在边上Swarm 把答案交给模型主从模式则把答案锁在编排者的工具调用里——理解这一点比记住任何 API 都更有价值。【免费下载链接】harness-sdkBuild an agent harness and control it end-to-end. Open-source SDK for production AI agents in Python TypeScript - any model, any cloud.项目地址: https://gitcode.com/GitHub_Trending/sdkpython13/harness-sdk创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考