У спільноті AI-інженерів дедалі частіше звучить запит на системи, які не просто «генерують текст», а проводять справжнє дослідження: шукають джерела, перевіряють факти, аналізують відео й збирають усе це в структурований, цитований матеріал. Команда освітнього проєкту Towards AI, яку очолює CTO та співзасновник Луї-Франсуа Бушар разом із інженером і технічним автором Самрідхі та розробником і автором «LLM Engineer’s Handbook» Полом Юстіном, побудувала саме таку систему — і перетворила її на практичний воркшоп.
Цей матеріал розбирає технічне ядро їхнього підходу: як спроєктований глибокий дослідницький агент, як використовується Model Context Protocol (MCP), які інструменти підключені через FastMCP, чому обрано Gemini як рушій пошуку й аналізу YouTube, і як усе це в підсумку виводить один артефакт — файл research.md, що стає основою для подальшого технічного письма.
Дві половини однієї системи: гнучкий дослідник і детермінований письменник
У виробничій версії свого пайплайна Towards AI розділили систему на два чітко різні компоненти. Перший — це гнучкий, агентний дослідницький модуль, другий — більш детермінований, жорстко структурований модуль письма.
Дослідницький агент відповідає за все, що пов’язано з невизначеністю: постановку цілей, планування, пошук, перевірку джерел, зміни стратегії, коли початкові гіпотези не підтверджуються. Це зона, де потрібна автономія, можливість «повороту» й ітеративне уточнення розуміння теми. Саме тут використовується агентний підхід.
Натомість модуль письма — це вже не агент, а керований робочий процес. Його завдання — взяти готовий дослідницький артефакт і перетворити його на короткий, структурований технічний текст, наприклад, пост у стилі LinkedIn. Тут немає потреби в динамічному плануванні чи складних рішеннях: кроки відносно стабільні, послідовність відома наперед, а головний акцент — на контролі якості, стилю та довжини.
Це розділення відображає ключову інженерну ідею: автономію варто застосовувати там, де вона справді потрібна. Дослідження — це простір невизначеності, де агент може приносити користь. Письмо — це простір обмежень, де краще працюють чіткі воркфлоу, рев’ю-петлі та явні інструкції. У продакшн-системі обидва компоненти запускаються послідовно простим скриптом, без важких оркестраторів: спочатку дослідницький агент створює research.md, потім модуль письма споживає цей файл і формує кінцевий контент.
Глибокий дослідницький агент як цільовий цикл: план, пошук, інспекція, поворот
У центрі дослідницької частини — агент, спроєктований як цільовий дослідницький цикл. Його завдання — не просто відповісти на запит, а пройти повний шлях від постановки цілі до структурованого, цитованого артефакту.
Архітектурно це виглядає як петля, у якій модель:
формулює або уточнює дослідницьку мету, виходячи з вхідної теми;
планує стратегію: які аспекти теми потрібно покрити, які типи джерел будуть корисними, де можуть бути ризики застарілої чи ненадійної інформації;
виконує пошук у вебі, використовуючи спеціалізований інструмент глибокого дослідження, що повертає не лише відповіді, а й джерела;
інспектує знайдені матеріали, оцінює їхню релевантність і довіру, відкидає слабкі або підозрілі джерела;
за потреби «поворочує» — змінює напрямок пошуку, додає нові підзапити, заглиблюється в окремі аспекти або шукає альтернативні точки зору;
ітеративно уточнює власне розуміння теми, накопичуючи проміжні нотатки, витяги й висновки.
Ключова відмінність від звичайного чат-бота полягає в тому, що агент не обмежується одним проходом «запит–відповідь». Він працює як дослідник, який може визнати, що поточні дані неповні або ненадійні, і свідомо змінити стратегію. Саме для цього йому потрібен доступ до зовнішніх інструментів, пам’яті та можливість багаторазово викликати моделі.
Щоб зробити таку поведінку керованою й розширюваною, команда спирається на Model Context Protocol (MCP) — стандарт, який дозволяє описувати інструменти, ресурси й промпти як сервіс, до якого підключається агент.
MCP як клейова тканина: FastMCP, Claude Code і сервер інструментів
Model Context Protocol у цьому проєкті виконує роль «контракту» між агентом і зовнішнім світом. Замість того, щоб жорстко вшивати виклики API в код агента, інструменти описуються й публікуються MCP-сервером. Агент, який працює в середовищі Claude Code, виступає як MCP-клієнт: він бачить доступні інструменти, їхні сигнатури, опис і може автономно вирішувати, коли й як їх викликати.
Щоб не витрачати час на ручну реалізацію протоколу, команда використовує бібліотеку FastMCP. Вона бере на себе більшу частину низькорівневої роботи: обробку запитів і відповідей MCP, реєстрацію інструментів, серіалізацію параметрів. Розробнику залишається описати бізнес-логіку кожного інструмента — наприклад, як саме викликати Gemini API для веб-пошуку чи аналізу відео.
У воркшопі Claude Code використовується як «агентний хрестовий ключ»: це середовище, де модель Anthropic може діяти як агент, бачити MCP-інструменти й викликати їх у процесі діалогу. Така конфігурація дозволяє учасникам воркшопу будувати власний MCP-сервер локально, а потім підключати його до вже готового агентного інтерфейсу без необхідності створювати складну інфраструктуру з нуля.
У результаті архітектура виглядає так: локальний MCP-сервер, реалізований через FastMCP, експонує набір інструментів; Claude Code підключається до цього сервера як клієнт; агент у Claude Code, керований промптами, запускає дослідницький цикл, використовуючи ці інструменти для пошуку, аналізу й компіляції.
Три інструменти, одна мета: від вебу й YouTube до research.md
MCP-сервер у цьому проєкті надає три основні інструменти, які разом покривають повний шлях від сирих даних до структурованого дослідження.
Перший — інструмент глибокого дослідження, який використовує Gemini API для веб-пошуку. На відміну від простого пошуку, він повертає не лише текстову відповідь, а й прив’язані джерела. Це критично для завдання, де потрібно не просто «щось написати», а обґрунтувати твердження посиланнями. Команда раніше покладалася на Perplexity як зовнішній сервіс для пошуку, але згодом мігрувала на Gemini з функцією grounding, щоб мати більш точний контроль над відповідями й джерелами в межах власної інфраструктури.
Другий — інструмент аналізу YouTube-відео. Він також побудований на Gemini API, але замість загального веб-пошуку приймає на вхід URL відео. Далі Gemini може безпосередньо обробити це посилання, витягнути транскрипт або одразу побудувати аналітичний огляд. Важливий момент: саме здатність Gemini працювати з YouTube-URL без додаткового скрейпінгу стала однією з причин вибору цієї моделі. Це суттєво спрощує інтеграцію відеоконтенту в дослідницький пайплайн.
Третій — інструмент компіляції дослідження. Він не звертається до зовнішніх API, а працює з локальними проміжними результатами. Його завдання — прочитати всі збережені в процесі дослідження файли, нотатки й витяги, а потім зібрати їх у фінальний Markdown-документ research.md. Саме цей файл стає основним артефактом, який споживає наступний модуль системи — технічний письменник.
Такий поділ інструментів дозволяє агенту поводитися гнучко. На ранніх етапах він може багаторазово викликати веб-пошук, потім заглибитися в окремі відео через YouTube-аналіз, а вже наприкінці — один раз запустити компіляцію, коли обсяг доказів і нотаток достатній для синтезу.
Локальна пам’ять як журнал і страховка: папка memory і верифікація
Щоб зробити роботу агента прозорою й перевірюваною, усі проміжні результати дослідження записуються в локальну папку пам’яті. Це можуть бути окремі файли з відповідями веб-пошуку, витяги з відео, чернеткові конспекти або структуровані нотатки за підтемами.
Такий підхід вирішує одразу кілька завдань. По-перше, він створює журнал дій агента: можна подивитися, які запити виконувалися, які джерела були використані, як змінювалася стратегія пошуку. Це важливо як для налагодження системи, так і для навчальних цілей у межах воркшопу.
По-друге, локальна пам’ять дає можливість верифікації. Людина може відкрити конкретний файл, звірити цитати з джерелами, перевірити, чи не було перекручень або помилкових узагальнень. У контексті боротьби з «AI slop» — поверхневим, неконтрольованим контентом — це принципова відмінність: тут є слід, який можна перевірити.
По-третє, така структура спрощує роботу інструмента компіляції. Замість того, щоб покладатися на довгу контекстну історію в одному виклику моделі, система працює з набором файлів, які можна читати, сортувати, фільтрувати й комбінувати. У результаті фінальний research.md стає не просто «відповіддю моделі», а синтезом явно зафіксованих проміжних артефактів.
Файл research.md оформлюється в Markdown-форматі, що робить його зручним як для людей (читання, редагування), так і для подальшої машинної обробки. Саме цей документ потім споживає модуль письма, який перетворює його на короткі пости, конспекти чи інші формати.
Gemini як рушій дослідження: Pro, Flash і ставка на YouTube
Усі зовнішні дослідницькі операції в системі — веб-пошук і аналіз YouTube — побудовані на моделях Gemini. Команда використовує як Gemini Pro, так і Gemini Flash, перемикаючись між ними залежно від складності завдання.
Gemini Pro застосовується там, де потрібне глибше міркування, складніший аналіз або робота з великими обсягами інформації. Gemini Flash, своєю чергою, корисний для швидких, менш ресурсомістких операцій, де важливіше швидкість і вартість, ніж максимальна глибина.
Вибір Gemini був зумовлений кількома практичними міркуваннями. По-перше, моделі вміють безпосередньо обробляти YouTube-URL, що знімає потребу в окремому скрейпері чи транскрипційному сервісі. Це спрощує архітектуру й зменшує кількість рухомих частин у системі.
По-друге, наявність безкоштовного тарифу робить Gemini привабливим для студентів і учасників воркшопу. Оскільки кодова база доступна у відкритому GitHub-репозиторії, важливо, щоб кожен міг відтворити систему без значних витрат на інфраструктуру. Безкоштовний рівень дозволяє експериментувати з глибоким дослідженням навіть тим, хто лише починає працювати з LLM.
По-третє, перехід від Perplexity до Gemini з grounding дав команді більше контролю над тим, як саме формуються відповіді й як прив’язуються джерела. Замість чорної скриньки зовнішнього сервісу, вони отримали можливість будувати власну логіку поверх API, інтегруючи її в MCP-сервер і агентний цикл.
Окремим компонентом у ширшій системі є інструмент для інжесту GitHub-контенту через бібліотеку Gitingest, яка перетворює репозиторії на Markdown і може працювати з приватними репозиторіями через токен. Хоча цей аспект виходить за рамки базового воркшопу, він демонструє, як та сама MCP-архітектура може масштабуватися на інші джерела, крім вебу й YouTube.
Від внутрішнього пайплайна до відкритого репозиторію
Система глибокого дослідження й письма, яку демонструють у воркшопі, не є лабораторним експериментом. Вона виросла з реальної потреби Towards AI автоматизувати частину внутрішнього пайплайна для створення технічних курсів, відео й уроків. Компанія працює в ніші, де потрібні не просто тексти, а глибоко опрацьований, технічно точний контент, і де людські автори витрачають значний час на дослідження.
Звідси й прагматичні рішення в архітектурі: розділення дослідження й письма, ставка на MCP як універсальний шар інтеграції, використання локальної пам’яті для верифікації, обережне застосування агентності лише там, де вона справді додає цінність.
Для воркшопу команда спростила продакшн-систему, зосередившись на компактнішому дослідницькому агенті й письменнику, орієнтованому на короткі пости. Водночас ключові ідеї залишилися незмінними: агент як цільовий дослідницький цикл, MCP як спосіб підключення інструментів, Gemini як рушій пошуку й аналізу, research.md як центральний артефакт.
Кодова база доступна у відкритому GitHub-репозиторії, посилання на який надається учасникам через QR-код і README. Це дозволяє не лише повторити приклад, а й розширити його: додати власні MCP-інструменти, інтегрувати інші API, змінити стратегію дослідження або формат фінального артефакту.
Висновок: дослідницькі агенти як інженерна дисципліна, а не магія
Історія цього глибокого дослідницького агента показує, що «агентність» у LLM-системах не обов’язково означає складні багатошарові оркестратори чи десятки взаємодіючих моделей. Натомість це може бути чітко спроєктований цикл, де модель має доступ до обмеженого, але добре описаного набору інструментів через MCP, працює з прозорою локальною пам’яттю й завершує роботу конкретним, перевірюваним артефактом.
Розділення на гнучкий дослідницький агент і детермінований модуль письма дозволяє поєднати автономію там, де вона потрібна, з контролем там, де він критичний. Використання Gemini як універсального рушія для вебу й YouTube, разом із FastMCP і Claude Code, робить систему доступною для відтворення й навчання.
У підсумку йдеться не стільки про «розумних агентів», скільки про дисципліновану інженерію: чіткі межі відповідальності, прозорі інструменти, відтворювані артефакти. Саме такий підхід дає шанс перетворити LLM з генераторів «AI slop» на повноцінних учасників дослідницьких процесів.
Джерело
Full Workshop: Build Your Own Deep Research Agents – Louis-François Bouchard, Paul Iusztin, Samridhi