Мультиагентні пайплайни в Agentspan: паралель, хенд‑офф і nested‑стратегії

Python‑розробник і автор каналу Tech With Tim у великому курсі про production‑агентів показує третій, найскладніший приклад — мультиагентний оркестратор на базі Agentspan. Це вже не «чатик з моделлю», а дослідницька фабрика з низкою спеціалізованих агентів, які взаємодіють між собою через різні стратегії — від послідовної до паралельної та вкладеної (nested). У центрі прикладу — реалістичний пайплайн для аналітичних звітів, який спирається на веб‑скрейпінг через Firecrawl.

Дослідницька фабрика: дослідник, райтер, редактор і команда аналітиків

Третій агент у курсі визначений як «multi‑agent orchestrator where we actually have multiple AI agents running at the same time to achieve a longer running task». Ідея проста: замість одного «універсального» асистента запускається кілька вузьких агентів, кожен зі своїм набором інструкцій і роллю в процесі.

У прикладі формується повноцінна дослідницька команда:

• researcher agent — відповідає за первинний збір інформації;
• writer agent — формує чернетку тексту на основі зібраних даних;
• editor agent — редагує й полірує текст;
• market analyst, risk analyst, financial analyst — три профільні аналітики;
• analysis team — надбудова, що об’єднує трьох аналітиків в окрему мультиагентну «команду».

Такий склад потрібен не заради ефектного демо, а щоб показати, як в Agentspan розбивати складний workflow на логічні ролі. У реальному запуску автор пропонує сценарії на кшталт: «I’m going to tell it hey I want to do research on Tech With Tim… and the strategy I want to use for the research is sequential», після чого вся зв’язка агентів збирає інформацію та видає готовий дослідницький репорт.

Кожен агент у цій схемі — звичайний Agentspan‑agent із власними інструкціями. Наприклад, дослідник отримує доступ до інструментів для пошуку і скрейпінгу, тоді як редактор працює переважно з текстом. Над ними стоїть оркестратор, який керує порядком запуску та обміном результатами.

Багато стратегій для багатьох агентів: handoff, sequential, parallel і не тільки

Базова можливість, яку демонструє цей блок курсу, — підтримка в Agentspan різних multi‑agent стратегій: «AgentSpan supports these multi‑agent strategies… first is handoff… then you have sequential… then we have parallel… then we have router… we have swarm… round robin, random and manual.»

Handoff використовується як дефолтна модель, коли «ln chooses which sub agent to handle the request». По суті, один «верхній» агент має доступ до інших як до підагентів, і LLM вирішує, до кого передати конкретний запит. У коді це виглядає як агент із переліком інших агентів і стратегією handoff. Далі можна «чатися» з цим оркестратором, а він у фоні делегує задачі.

Sequential — це класичний конвеєр: «we always run the agents in a linear path… we run them one by one and then we take the result of one agent and we pass it to the other». У документації це ілюструється прикладом із трьома агентами — researcher, writer, editor — які викликаються один за одним. Результат дослідника стає вхідними даними для райтера, результат райтера — для редактора.

Parallel, навпаки, «allows us to run these all concurrently. This means that I can run all three agents at the exact same time at scale. So I don’t need to wait for one response before I get the next.» Замість чекати, поки кожен агент послідовно завершить свою частину роботи, Agentspan запускає їх одночасно, а потім збирає результати.

Окрім цих трьох, у фреймворку є й інші моделі:

• router — окремий агент‑«класифікатор» маршрутизує запити до потрібного підагента;
• swarm — режим «рою» з багатьма можливими переходами;
• round robin, random, manual — різні підходи до того, як розподіляти задачі між агентами.

Але в прикладі з дослідницькою фабрикою фокус робиться саме на трьох ключових: послідовному, паралельному та їхній комбінації у вигляді nested‑пайплайнів.

Parallel‑команда аналітиків: analysis_team як окремий вузол

Щоб показати перевагу паралельного режиму, у коді формують спеціальний мультиагентний блок: «I then create an analysis_team… and this analysis team, I want to run in parallel where I say, hey, for the market_analyst, the risk_analyst, and the financial_analyst… we want to run those at the exact same time.»

Analysis_team — це фактично оркестратор усередині оркестратора. Він тримає три аналітичні агенти й запускає їх у стратегії parallel. Ключова перевага така: замість чекати, поки кожен аналітик по черзі підготує свій шматок розбору, система одночасно запускає ринковий, ризиковий і фінансовий аналіз, а потім зводить результати.

У веб‑дашборді Agentspan це виглядає як один execution із кількома дочірніми агентами: «you can see that this is running. We actually have three agents running… analysis_team, financial, risk, and market». Після завершення зʼявляється повідомлення «the report was saved», а відкривши файл звіту, можна побачити повний текст із трьома різними точками зору.

Такий блок можна використовувати як будівельний елемент для складніших сценаріїв: аналітика в паралелі, а генерація та редагування тексту вже в послідовному режимі.

Nested‑пайплайн: спершу паралельна аналітика, потім дослідження і текст

Найцікавіший момент прикладу — nested‑стратегія, де поєднуються паралель і послідовність. «For my nested_pipeline this is where I take my analysis team which I run in parallel and then after that… I write the researcher, writer and editor. So I run this whole thing sequentially but this first step runs these three agents in parallel.»

Nested_pipeline — це конвеєр із двох великих етапів.

Спочатку запускається analysis_team у режимі parallel. Три аналітичні агенти одночасно оцінюють тему (в одному з прикладів це «Nvidia stock»), формують свої висновки й повертають їх як узагальнений проміжний результат.

Далі в хід ідуть три інші агенти — researcher, writer, editor — але вже в режимі sequential. Вони виконують класичний маршрут: дослідження, написання, редагування. У вхід досліднику передається те, що напрацювала команда аналітиків, далі цей результат підхоплює райтер, потім — редактор.

У дашборді цей nested‑пайплайн виглядає як єдиний execution із кількома шарами агентів: «we now have a bunch of agents running, right? So we have the analysis team, researcher, writer, editor, the analyst team, market risk, financial, and these are going to run sequentially.» Спочатку видно паралельний блок аналізу, потім — покрокове проходження дослідника, райтера й редактора.

У фіналі код зберігає звіт у вигляді markdown‑файлу в окремій директорії. Для прикладу з Nvidia у файлі зʼявляється «full markdown report about Nvidia stock analysis with the different sources», а посилання ведуть на реальні сторінки, які були використані в дослідженні.

Firecrawl як інструмент для веб‑досліджень

Щоб мультиагентна система могла працювати не в ізоляції, їй потрібен інструмент виходу в зовнішній світ. У прикладі на цю роль обрано Firecrawl: «I’m using Firecrawl to just search the web for a bunch of pages on whatever topic we’re going to look up… this will allow you to do a ton of scraping and searching of the web more effectively than with like a default search.»

У коді це реалізовано двома інструментами‑функціями:

• search_web (у поясненні його називають саме так) — використовує Firecrawl для пошуку релевантних сторінок за темою;
• fetch_page — отримує вміст конкретної сторінки й віддає агенту повний текст.

Ці інструменти позначаються як tools в Agentspan і підключаються до researcher agent. Решта агентів працюють уже з результатами пошуку, а не напряму з веб‑ом.

Важливий момент — робота з credential‑ами. Для Firecrawl використовується API‑ключ, який не зберігається в коді. Натомість у сигнатурі інструмента зазначається, що йому потрібні credentials, а всередині функції значення підтягується з os.environ. Ключ задається через CLI Agentspan і потім зберігається на сервері; при виклику tool‑а сервер тимчасово передає його воркеру.

Ця модель дозволяє не «зашивати» секрети в код і не тримати їх постійно в середовищі виконання, а підвантажувати тільки тоді, коли цього справді потребує інструмент.

Реальне виконання: від запуску пайплайна до збереженого звіту

У прикладі з nested‑режимом користувач запускає скрипт із режимом nested і темою «Nvidia stock». Далі все виглядає як типовий production‑workflow:

1. Agentspan створює execution та піднімає analysis_team у режимі паралелі.
2. Три аналітичні агенти викликають Firecrawl‑інструменти, отримують сторінки, дістають текст і будують власні фрагменти аналізу.
3. Після завершення paralell‑блоку їхні результати об’єднуються й передаються в researcher agent.
4. Дослідник продовжує роботу з веб‑даними, ще раз викликає Firecrawl, збирає додатковий контент і формує більш цілісну картину.
5. Writer agent перетворює агреговані дані на зв’язний текстовий звіт.
6. Editor agent редагує й полірує текст.
7. Пайплайн завершується, а допоміжні функції в коді зберігають фінальний звіт у markdown‑файлі з людиночитабельним slug‑іменем у директорії reports.

Автор окремо звертає увагу на те, як це відображається в UI: у вкладці agents видно, які саме агенти працюють просто зараз, які вже завершили роботу і як передаються результати між ними. Це важливо не лише для дебагу, а й для розуміння, що саме відбувається всередині багатокрокового процесу.

Висновки: мультиагентні стратегії як основа складних AI‑workflow

Приклад із «multi‑agent researcher» у курсі наочно показує одну річ: як тільки задачі виходять за межі простого питання‑відповіді, одного LLM‑виклику стає замало. Потрібні ролі, пайплайни, різні стратегії виконання й чітке розділення на етапи: паралельні й послідовні.

Agentspan пропонує для цього готову модель:

• окремі агенти з інструкціями та інструментами;
• гнучкі стратегії оркестрації — від handoff до parallel і nested;
• інтеграцію з зовнішніми інструментами на кшталт Firecrawl;
• прозоре логування й візуалізацію виконання в дашборді.

Для команд, які будують складні workflow поверх LLM, мультиагентний підхід із таким набором стратегій дає змогу переходити від «демо‑бота» до багатоступеневих дослідницьких систем, що реально можуть працювати в продакшені.

Джерело

Build 3 PRODUCTION AI Agents in Python – Full Course (Agentspan)