Головна / Статті

Робочі потоки проти агентів: хто має обирати наступний крок дослідження?

Робочі потоки проти агентів у дослідженнях: коли слід жорстко вказати шлях, а коли модель має обирати наступний пошук, з прикладом проектування веб-інструментів LangGraph та Anthropic.

Видавець: REACTAPP.TOP5 хв читання1188 слів

Джерела: Workflows vs. Agents: Who Should Choose the Next Step?

Дослідницький агент бачить речення „LangGraph підтримує стабільну роботу“, ставить галочку у таблиці порівняння та рекомендує цю платформу. Ви розробляєте локальний додаток – процес зупиняється, і нічого не продовжується. Що пішло не так?

Якась умова була проігнорована. „Підтримка зберігання даних“ – це не те саме, що „зберігання даних налаштоване в цьому додатку“. Корисний агент збору ринкової інформації має помітити цю різницю, прочитати більше, ніж просто назви функцій, та іноді змінити своє наступне запитання в залежності від отриманих даних.

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

Два способи дослідження одного завдання

Припустимо, завдання вимагає визначити зв’язок між LangGraph та Deep Agents, а також з’ясувати, що потрібно для відновлення роботи Python-дослідницького сервісу, використовуючи лише офіційну документацію.

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

Інший підхід дозволяє моделі самій обирати наступний крок. Вона шукає, відкриває сторінку, помічає відсутню умову та вирішує, що досліджувати далі. Це і є агент.

Обидва підходи можуть використовувати моделі, інструменти, різні варіанти дій та можливість повторних спроб. Справжнє розмежування полягає у тому, хто вирішує шлях виконання завдання. Примітка LangGraph щодо робочих процесів та агентів чітко це проілюструє.

Практичне правило:

  • Документи та кроки вже відомі: краще використовувати робочий процес.
  • Корисні джерела з’являються лише під час дослідження: спробуйте використати агента з обмеженими можливостями.
  • Результат має бути передбачуваним, але дослідження — не обов’язково: поєднайте обидва підходи.

Цей проект належить до третьої категорії.

Коли результат дослідження змінює поставлене запитання

На перший погляд це завдання схоже на змагання між фреймворками. Однак огляд Deep Agents показує, що він працює на середовищі виконання LangGraph. Таким чином напрямок дослідження змінюється.

Старе запитання: який фреймворк переможе?

Нове висновок: вони функціонують на різних рівнях.

Краще запитання: які завдання належать до самого додатку, а які — до більш високорівневого інструментарію?

Для зберігання даних потрібен такий самий рівень уваги. У документації описано налаштування контрольних точок та ідентифікацію потоків для локальних графів. Також розрізняються внутрішні буфери пам’яті та сховища, підтримувані базою даних, зазначається, що Agent Server самостійно керує інфраструктурою зберігання. Див. розділи «Зберігання даних» та «Контрольні точки».

Корисна відповідь враховує ці умови. Позначка у таблиці функцій — ні. Усе, що наведено нижче, походить безпосередньо з читання документації, а не з запису розмови агента.

Форма системи: робочий процес, що охоплює дослідника

Додаток визначає завдання, дозволені джерела, ліміти запитів та спосіб обробки результатів. У межах цього процесу модель обирає пошукові запити та документи. Дослідження залишається гнучким, а результати — чіткими.

Учасники процесу:

  • LangGraph виконує зовнішні етапи додатка.
  • SDK Anthropic надає моделі інструменти для пошуку та отримання даних з Інтернету.
  • Збережений звіт фіксує джерела, записи про цитування, статистику використання та помилки інструментів.

Один виклик постачальника може включати кілька дій з пошуку та читання. LangGraph керує зовнішнім процесом, але не створює кожен запит самостійно. Один дослідник може легко контролювати всі етапи. Deep Agents можуть чекати, поки не знадобиться більше керування контекстом та делегування завдань. Зміна постачальника також означатиме переписування контрактів щодо інструментів та цитування.

Пошук знаходить сторінки; завантаження їх читає

Запит використовує обидві ці інструменти:

tools = [
    {
        "type": "web_search_20250305",
        "name": "web_search",
        "max_uses": 3,
    },
    {
        "type": "web_fetch_20250910",
        "name": "web_fetch",
        "max_uses": 4,
        "max_content_tokens": 6000,
        "citations": {"enabled": True},
    },
]

Ці визначення походять із супровідного коду та не є повноцінною програмою. Обраний вами модель має підтримувати задокументовані версії інструментів. Anthropic документує обидва інструменти у розділах Agents та Tools на своєму сайті для розробників; там ви знайдете актуальні специфікації пошуку та отримання даних.

Дизайн формується під впливом трьох обмежень.

  1. Ліміти діють за кожним запитом. Дозволяється щонайбільше два виклики SDK, включаючи продовження паузованого кроку, причому повторні спроби SDK заборонені.
  2. Цитування під час отримання даних увімкнене навмисно, щоб зберігалися записи цитувань, а не лише текст відповіді.
  3. Код HTTP 200 не є доказом наявності даних. API може успішно виконатися, навіть якщо операція отримання даних зазнає невдачі, тому необхідно також перевіряти блоки з результатами роботи інструменту.

Ці ліміти обмежують кількість запитів та використовуваних інструментів. Вони не є верхньою межею витрат чи жорстким терміном.

Цитування все ще можуть допомогти

Уявіть звіт, у якому стверджується, що додаток автоматично відновиться після збою, посилаючись на сторінку про налаштовувану стабільність роботи. Посилання є справжнім. Однак твердження є ширшими, ніж наявні докази.

Базовий аудит включає чотири запитання типу «так/ні»: чи завершив модель роботу нормально? Чи завантажила вона принаймні один документ? Чи повернула вона текст відповіді? Чи містить кінцева відповідь автентичні посилання? У разі позитивного результату статус стає needs_review; у разі невдачі при обов’язковій перевірці — incomplete.

Жоден з цих статусів не означає, що твердження є правдивими. Посилання можуть вказувати на індекси та місця розташування уривків, а не на URL-адреси, і прототип зберігає ці записи, не визначаючи способу їхнього поєднання.

Корисна практика під час перевірки: візьміть одне суттєве твердження та перегляньте його джерело. Яка умова, виняток чи обмеження могли б змінити рекомендацію?

Збільшуйте складність лише тоді, коли можете виміряти отриману вигоду

Довгі дослідження можуть вимагати вибіркового завантаження контексту, компактних нотаток або окремих дослідників для незалежних гілок. Ці ідеї зустрічаються у публікаціях Anthropic про оптимізацію контексту для агентів та про багатоагентні дослідницькі системи. Для цього додатку це опції для оцінки, а не оновлення, які встановлюються за замовчуванням.

Чотири перевірки становлять справедливу першу перешкоду:

  1. Чи пояснюється у ньому зв’язок між LangGraph та Deep Agents?
  2. Чи зберігаються у ньому умови для відновлення після перезапуску?
  3. Чи фіксується він випадки невдалих завантажень документів?
  4. Чи визнається у ньому те, що самі документи не можуть визначити найдешевший варіант розгортання?

Розмістіть процес обробки наданого документа поруч із пошуком, спрямованим на модель. Зберігайте модель та вимоги до відповідей незмінними, чітко вказуйте, які джерела може бачити кожна сторона, та фіксуйте фактичне використання. Оцінюйте отримані результати, відсутні умови та справжню невизначеність, а не лише кількість посилань.

Сучасний стан справ: десять тестів інтеграції пройшли з використанням справжнього SDK та середовища роботи LangGraph із імітацією HTTP-запитів. Жодних тестів з реальним API ще не проводилося, оскільки не були встановлені облікові дані, тому немає даних щодо якості, затримки чи витрат.

Перспективи

Тепер існує дизайн, який варто протестувати: дослідник, здатний слідувати за доказами, реалізований у програмному забезпеченні, яке залишає перевірюваний слід. Наступна проблема виникає, коли процес зупиняється на півдорозі. Збережені файли відповідей допомагають побачити, що сталося; вони не запускають граф заново. У наступній частині описується стан постійної екзекуції та тестується відновлення в новому процесі, все ще використовуючи цей веб-інструмент для досліджень.

Пов’язана література

  • Створення агента підтримки LEPA за допомогою LangGraph — передача даних SupportState, створення та класифікація вузлів, умовні ребра та маркери START/END, щоб запит на підтримку школи міг бути уточнений або переданий до відповідних документів.
  • Навчання невеликого GPT на індійських народних казках: токенізатор, маска та функція втрат — створення GPT з 9 мільйонів параметрів з нуля: чому токенізатор GPT-2 не справляється зі словами з народних казок, як працюють методи BPE та каузальна маска, та як одна партія даних дає 4 096 значень втрат для наступного токена.