У великому практичному курсі на каналі Tech With Tim автор розбирає, як будувати AI‑агентів на Python, які реально витримують продакшн‑навантаження. Один з ключових акцентів — «durable execution»: здатність агента пережити краш, довгі простої та повернення людини в процес, не втрачаючи зроблену роботу. Саме ці можливості Agentspan стають визначальними, коли агент працює не секунди, а десятки хвилин чи години.
Довгі workflow як норма, а не виняток
Вихідна постановка задачі доволі прагматична: агентам у реальному світі часто не вистачає кількох секунд інференсу. Вони оперують складними бізнес‑процесами, зовнішніми API, очікуванням відповіді від користувача й можуть «висіти» дуже довго.
Формула тут прозора: якщо агенти працюють 20, 30 або навіть 2 години, інфраструктура має це витримувати. Відмова процесу на 80‑й хвилині без можливості відновлення — це не просто незручність, а прямі втрати: від вартості LLM‑запитів до зірваних SLA.
Саме тому в Agentspan від самого початку закладена ідея, що довготривалі задачі — це не крайовий кейс. Серверна частина платформи спроєктована так, щоб завдання могло виконуватися «скільки потрібно», а стан виконання при цьому не прив’язувався до життєвого циклу окремого воркера.
Сервер як «чорний ящик» стану
Архітектура Agentspan будується навколо серверу‑оркестратора і зовнішніх Python‑воркерів. Воркери запускають код агентів, але стан усіх виконань зберігається централізовано.
Цей сервер — бекенд‑інфраструктура, проти якої запускаються агенти. Вона відстежує історію, кроки, виклики інструментів, токени, причини зупинки. Головне ж — утримує повний стан виконання в базі. Якщо відбувається краш, можна відновитися саме тому, що весь state живе на сервері, а не всередині процесу, який упав.
Наслідок для розробника очевидний: завдання може працювати стільки, скільки йому потрібно. Воркери можна перезапускати, мігрувати, оновлювати — при цьому сам execution продовжиться з того місця, де обірвався.
Демонстрація: агент «впав», а workflow живе далі
Щоб показати, як виглядає durable execution у дії, в курсі зібрано невеликий демо‑приклад. Він максимально простий за логікою, але добре розкриває ключову ідею.
Створюється агент із єдиним інструментом — повільним кроком slow_step, який займає приблизно три секунди. Інструкція для моделі: виконати 10‑кроковий workflow, послідовно викликаючи slow_step для кожного кроку. У сумі це тривала задача, яка спеціально «гальмує», щоб було зручно моделювати збої.
Скрипт має два режими — start і resume. У режимі start агент запускається звичайним чином: через runtime створюється handle, який стрімиться в термінал, де видно всі події виконання, поки процес не закінчиться.
На сервері при цьому з’являється новий execution: у веб‑інтерфейсі видно, як агент переходить від кроку до кроку. Наприклад, у якийсь момент видно, що він дійшов до кроку 3 або 4 й чекає завершення slow_step.
У цей момент воркер просто насильно «вбивається» — процес зупиняється. У терміналі все обірвалося, але в дашборді Agentspan execution усе ще позначений як «running». Лог показує, що агент дістався четвертого кроку й «завис» на повільному інструменті; подальшого прогресу немає, адже ніхто не виконує код.
Суть проблеми очевидна: як не запускати все з нуля, а продовжити з того кроку, де виконання обірвалося?
execution_id як якір відновлення
Відповідь — у механізмі execution_id. Під час старту агента Agentspan друкує в логах ідентифікатор поточного виконання. Він також відображається в інтерфейсі сервера для кожного запуску.
Якщо цей execution_id зберегти, можна під’єднатися до вже існуючого виконання замість створювати нове. У демо‑скрипті саме так і відбувається: після крашу розробник копіює execution_id з логів та вставляє його в код у гілку resume.
У режимі resume замість start_… використовується інший шлях: спочатку запускається agent runtime, але далі handle отримується не шляхом запуску нового execution, а через під’єднання до попереднього — за тим самим execution_id.
З цього моменту відпрацьовує головна властивість durable execution: оскільки весь стан зберігається на сервері Agentspan, при реконекті воркер повертається в той самий контекст. При наступному запуску скрипта він «підхоплює» існуюче виконання і продовжує обробку — наприклад, переходить до кроку 5, 6, 7, доки не завершить усі 10 кроків.
У логах на сервері добре видно, що нових execution не створювалося: оновлюються лише події в межах уже існуючого запуску, а статус змінюється з незавершеного на завершений.
Як це виглядає в платформних сценаріях
Демо‑скрипт показує базову механіку, але в розмові окремо підкреслюється, що це напряму масштабується на реальні платформи.
Якщо писати власне рішення поверх Agentspan, можна просто зберігати всі execution_id десь у своїй базі або бекенді. Якщо будь-який із них переходить у стан помилки чи «зависання» через падіння воркера, достатньо:
- перезапустити воркер (або підняти новий),
- замість запуску нової задачі під’єднатися до існуючої за відомим
execution_id, - продовжити виконання, коли воркер знову онлайн.
Це особливо важливо, тому що в продакшені падіння процесів — радше норма, ніж виняток. Воркери можуть оновлюватися, рестартуватися через деплой, гинути через мережеві чи інфраструктурні збої. Без durable execution кожне таке перезавантаження означало б необхідність перезапуску довгих задач з нуля, повторних LLM‑запитів, повторних викликів зовнішніх API та очікувань.
Коли ж стан живе окремо від воркера, ці накладні витрати зникають. Платформа може спокійно масштабувати й перезапускати воркери, не боячись, що це «зламає» ланцюжок дій агента.
Тестування агентів без LLM: швидкість і безпека змін
Durability — не єдина продакшн‑орієнтована фіча, яку підкреслюють у курсі. Окремий блок присвячений тому, як тестувати агентів Agentspan без реальних LLM‑запитів.
Підхід базується на тому, що в Agentspan можна емулювати події всередині виконання агента, не звертаючись до моделі. Це дозволяє перевірити:
- чи коректно налаштовано модель та їй передається правильний
model‑ідентифікатор; - чи не конфліктує Pydantic‑response‑модель з тим, що очікує агент;
- чи коректно описані та підключені tools, включно з їхніми аргументами й очікуваними результатами;
- чи логіка обробки подій (tool call, tool result, done) поводиться так, як задумано.
У прикладі береться support‑агент із другого блоку курсу, який використовує structured output через Pydantic‑модель SupportResponse. Тестовий файл описує сценарій: агент має, наприклад, знайти інформацію про політику повернень. Для цього готується:
- змокана подія tool‑call до
search_knowledge_baseз певним запитом; - змоканий результат цього tool‑виклику з шаблонною відповіддю;
- подія завершення виконання.
Далі вказується очікуваний результат для SupportResponse — з певним stage, прапорцем successful і фрагментом тексту в message. Через expect‑перевірки тест гарантує, що:
- агент завершився в статусі
completed; - у вихідному повідомленні є слово
refund(або інший очікуваний фрагмент); - під час виконання дійсно використовувався потрібний інструмент
search_knowledge_base.
Коли умови виконані — тест проходить миттєво, без єдиного звернення до LLM. Якщо ж змінити очікування, наприклад замінити refund на refunded, тест одразу падає з чітким assertion‑error, вказуючи, що поведінка агента не відповідає очікуванню.
Це дає важливу перевагу для команд, які часто змінюють інструкції, структуру відповідей чи набір інструментів: можна мати швидкі, дешеві й детерміновані тести поверх складної агентної логіки.
Чому це важливо для реального продакшену
Сукупність durable execution і можливостей для тестування без LLM формує ту «надійність за замовчуванням», якої бракує більшості іграшкових агентних демо.
З одного боку, довгі workflow перестають бути ризиком: якщо агент працює десятки хвилин чи годин, падіння воркера не обнуляє прогрес. Execution зберігається на сервері, а перезапуск воркера — лише технічна деталь.
З іншого боку, зміни в логіці агента перестають бути «темним лісом». Їх можна швидко проганяти через змокані сценарії, не обпалюючись на вартості LLM‑запитів і не чекаючи хвилинами відповіді моделі.
У результаті Agentspan виступає не просто як черговий агентний фреймворк, а як інфраструктурний шар, який вирішує типові продакшн‑болі: краші, довгі простої, залежність від зовнішніх моделей і потребу в швидкому, передбачуваному тестуванні. Саме ці риси й роблять durable execution центральною ідеєю, коли йдеться про запуск AI‑агентів у реальних продуктах, а не лише у вікні термінала.
Джерело
Build 3 PRODUCTION AI Agents in Python – Full Course (Agentspan)