У тривалому курсі на каналі Tech With Tim розробник і контентмейкер Тимофі Бьючемі показує, як перейти від «демок у терміналі» до реально продакшн‑готових AI‑агентів на Python. У центрі — фреймворк Agentspan від Orkes: сервер для оркестрації стану плюс воркери, які виконують код. Саме через цю призму він розбирає головні проблеми реального запуску агентів і те, які фундаментальні властивості мають бути в інфраструктури, якщо її планують навантажувати тисячами користувачів.
Чому «демо‑агенти» сиплються в реальному світі
Тим починає з критики того, як сьогодні виглядає більшість навчальних матеріалів по агентам: «Most AI agent tutorials show you demos that fall apart the moment you try to run them in the real world.» Код, який здається переконливим у відео чи Jupyter‑ноутбуку, майже ніколи не враховує два базові факти продакшену: процеси падають, а користувачі поводяться непередбачувано.
Одна з перших реальних проблем — краші посеред виконання. «First we have processes that crash mid run… your AI agent just gets killed and that means that a lot of the work that’s done can be completely wasted.» Причини можуть бути будь‑які: нестабільна мережа, зависла база даних, рестарт контейнера. Якщо виконання агента привʼязане до одного процесу без збереження стану, будь‑який збій означає втрачений контекст і змарновані токени.
Друга категорія клопоту — часові розриви через участь людини. Агент може дійти до кроку, де потрібно натиснути кнопку «підтвердити повернення коштів» або схвалити видалення файлу. Цей крок може висіти хвилини, години чи дні. Якщо архітектура не передбачає «заморожування» і відновлення таких сесій, все ланцюжок доводиться проганяти з нуля.
Третя проблема, яку Тим називає «однією з найважливіших» — відсутність видимості: «A lot of times when you build these AI agents, you have no idea what they’re actually doing. So you need observability into the platform to see what step it’s on, where is it going wrong, what tools is it calling.» У звичайних фреймворках на кшталт базового LangChain розробник часто бачить лише вхід і вихід моделі, але не розуміє, як саме агент обходив інструменти, скільки було спроб, на якому саме кроці все розвалилося.
І нарешті — масштабування. Тим прямо формулює обмеження популярних «легких» стеків: «A lot of times if you just build a simple like LangChain agent or something, it’s not going to scale to tens of thousands of users and you have to pretty much reinvent the wheel and spend most of your time deploying out all of this infrastructure.» Інакше кажучи, якщо потрібні десятки тисяч одночасних користувачів, доводиться окремо будувати черги, стійке зберігання стану, обробку ретраїв, тестування — замість того, щоб концентруватися на логіці самого агента.
Сім ознак «справжнього» продакшн‑агента
На цьому тлі Тим формулює набір із семи властивостей, без яких агент не можна вважати продакшн‑готовим: «There’s seven things that you need if you want to have an AI agent actually be production ready… durability… retries… human in the loop… observability… long‑running tasks… and then scale and testing.»
Першою він називає durability — стійкість виконання. Суть: якщо агент падає, він має відновитися з того місця, де зупинився, «and it doesn’t need to completely restart». Тобто стан усієї сесії не повинен бути привʼязаний до одного процесу — його потрібно зберігати деінде і мати можливість підʼєднатися повторно.
Друге — retries. «Sometimes a step will fail. That doesn’t mean we should completely exit the process. We should retry it multiple times.» З точки зору інфраструктури це означає, що кожний крок workflow повинен мати політику повторів, а черга — механізм перезапуску завдань без ручного втручання.
Третя властивість — human in the loop. Агент повинен вміти повертати завдання людині з чіткою формою: «”Hey, are you sure you want to do this? Do you want to issue the refund? Do you want to delete this file? XYZ.”» І головне — вміти чекати скільки завгодно, не втрачаючи стану, поки людина не підтвердить або не відхилить операцію.
Четверта — observability. «We need to be able to actually see what’s going on in real time.» Йдеться не лише про логи, а про структурований огляд: на якому кроці агент, які інструменти викликає, які аргументи передає, що відповідає LLM і як змінюється стан від кроку до кроку.
Пʼята характеристика — підтримка long‑running tasks. «If agents take 20, 30, 2 hours to run, we should be able to handle that.» Тобто система має витримувати сценарії, де один агент виконує складний робочий процес протягом годин, з численними зверненнями до зовнішніх API, баз даних і людськими підтвердженнями.
Шоста й сьома — scale and testing. Масштабування означає можливість обробляти багато одночасних workflow без ручного мікроменеджменту кожного процесу. Тестування — можливість проганяти агентів у симульованих сценаріях, у тому числі без реальних викликів LLM, щоб виявляти помилки в інструментах, схемах виводу та конфігурації до того, як код потрапить у бойове середовище.
Усі ці вимоги виходять далеко за межі простого «виклику моделі» і наближають агентів до повноцінних розподілених систем workflow‑оркестрації.
Архітектура Agentspan: сервер стану та легкі воркери
Для реалізації цього набору властивостей Тим використовує Agentspan — фреймворк, який, за його словами, «comes from Orks» і є повністю open source. Ключова ідея — розділити код агентів і керування станом між воркером та спеціалізованим сервером.
«Orkes essentially gives us a server which is going to handle all of the different state and kind of track the progress of the multiple AI agents that we’re running.» Цей сервер виступає бекенд‑інфраструктурою: зберігає історію, статуси завдань, рішення про ретраї, human‑in‑the‑loop, multi‑agent‑оркестрацію. Воркери ж запускаються там, де зручно команді, — на локальній машині, на VPS чи в будь‑якому іншому середовищі.
Код агента у Python виглядає як звичайний клієнт: «from the worker side, we pretty much just say, “Hey, we’re building an agent. We’re going to connect to this server.” All of the rest of the code stays exactly the same.» Вказується URL сервера (через змінну середовища), а все, що пов’язано з durable execution, бере на себе Agentspan‑сервер.
Схема, яку показує Тим, складається з трьох блоків: воркер, сервер Agentspan і будь‑який LLM‑провайдер. «We have a worker. The worker is what we’re going to write ourselves. We have the agent span server. This is already provided to us… And then, of course, we have an LLM. We can use any LLM that we want.» Важливий момент: сервер вміє зберігати credentials до LLM‑провайдерів у себе, тож ключі не потрібно хардкодити у воркер‑код.
Такий поділ означає, що воркер можна зупинити й перезапустити в будь‑який момент, не втрачаючи прогресу. «If there was a crash, for example, we could recover from that crash because all of the state is stored on this server… we could just reconnect, restart where we left off and it’s not a big deal and this task can run for as long as it needs to.» Ця властивість безпосередньо закриває проблему крашів посеред виконання і робить допустимими багатогодинні workflow.
Durable execution, черги, ретраї та «людина в середині»
На практичних прикладах Тим показує, як Agentspan поєднує кілька із перелічених семи вимог в одну архітектуру.
По‑перше, durable execution. Сервер зберігає execution_id кожного запущеного workflow. Якщо воркер падає на пʼятому з десяти кроків, виконання залишається «живим» на сервері. Достатньо перезапустити воркер і підʼєднатися до вже існуючого виконання за цим ідентифікатором. Система продовжить з того самого кроку, не повторюючи вже успішні операції й не витрачаючи додаткові токени.
По‑друге, ретраї та черги. На дашборді, який працює поверх Agentspan‑сервера, Тим показує, як один агент генерує багато «tasks» усередині одного виконання, а сервер тримає для них вбудовану чергу. Це дозволяє автоматично перебирати кроки, що тимчасово падають (наприклад, через тимчасову помилку API), не перериваючи весь процес.
По‑третє, human‑in‑the‑loop. У другому прикладі сапорт‑агента використовується інструмент process_refund з прапорцем approval_required. Сценарій виглядає так: агент сам шукає замовлення, обчислює суму, формулює, що саме хоче повернути, але зупиняється в статусі waiting. У стримі подій воркер бачить, що агент чекає схвалення, виводить користувачеві пояснення, яку суму і за яке замовлення планує повернути, і на основі відповіді людини викликає handle.approve або handle.reject. При цьому «this can take any amount of time. It could take a day. It could take an hour or it could take 10 minutes. Doesn’t matter. The server will keep running here.» Стан очікування живе на сервері стільки, скільки потрібно.
По‑четверте, підтримка довгих завдань. Тим окремо демонструє агент з «повільним кроком», який кожного разу чекає кілька секунд і має виконати десяток таких кроків. Коли воркер зупиняють посередині, сервер продовжує «тримати» виконання. Перезапущений воркер через connect до попереднього execution_id бачить уже виконані кроки і рушає далі, не перезапускаючи весь процес.
Усі ці сценарії спираються на одну властивість: сервер є єдиним джерелом істини щодо стану агента, а воркери — лише виконавці кроків, які можна безболісно міняти, масштабувати чи перезапускати.
Observability як обовʼязкова умова
Особливий акцент у курсі робиться на видимість того, що робить агент у кожен момент. Через веб‑інтерфейс серверу Тим показує історію виконань: список агентів, кожен execution, окремі turns, токени, причину зупинки, тривалість кроків.
«For any given AI agent… You can see a full log of everything that’s actually gone on. And you can see this in real time.» Для кожного кроку відображається вхід у LLM, JSON‑опис викликів інструментів, їхні аргументи та результати. Це дає можливість буквально покроково відмотати, чому агент ухвалив саме таке рішення, де саме відбулась помилка, якою була відповідь інструмента.
Ця observability повʼязана не лише з налагодженням, а й з довірою до системи, яка приймає бізнес‑рішення. У прикладі з поверненням коштів можна в будь‑який момент відкрити виконання, побачити, який order_id було використано, яку суму агент збирався повернути і на підставі якого документа прийняв це рішення.
У масштабному сценарії з «дослідницькою фабрикою», де працюють кілька агентів‑аналітиків, дослідник, райтер і редактор, той самий інтерфейс дозволяє відслідковувати, коли паралельні агенти завершили роботу, як їх результати були передані далі й як у підсумку було сформовано фінальний звіт.
Масштаб і тестування: від локального запуску до тисяч користувачів
Повертаючись до своєї тези, що «simple like LangChain agent… is not going to scale to tens of thousands of users», Тим показує, як Agentspan намагається зробити цей перехід менш болісним.
По‑перше, шлях масштабування воркерів стає тривіальним: кожен воркер — це звичайний Python‑процес, який реєструється на одному й тому самому сервері. Сервер тримає чергу, роздає завдання воркерам, відстежує стан, робить ретраї. Якщо потрібно обробити більше навантаження, додаються нові воркери, не чіпаючи центральний стан.
По‑друге, тестування вбудовано безпосередньо в фреймворк. Тим демонструє, як можна створювати «мок‑тести» агентів, описуючи очікувані виклики інструментів, результати та фінальний structured output, і проганяти їх без звернення до реального LLM. Це дає змогу швидко перевіряти, що агент правильно інтегрує інструменти, коректно збирає schema‑відповіді й не ламається на базових сценаріях.
Комбінація цих речей — durable execution, черги, human‑in‑the‑loop, observability, тестування — робить Agentspan більше схожим на оркестратор бізнес‑процесів для LLM‑агентів, ніж на черговий обгортковий фреймворк до API моделей.
Висновок: від «іграшкових» ботів до робочих AI‑систем
Курс Tech With Tim показує, що перехід від демонстраційних агентів до продакшн‑сервісів — це не стільки про «кращий промпт», скільки про інженерію навколо LLM: стійке збереження стану, обробку збоїв, участь людини, спостережуваність, можливість довго працювати і масштабуватися.
«At the end of this video, you could very easily go deploy this app by just deploying the server and deploying your workers and you’re good. That’s it. because of the way that we built it as opposed to if you use a lot of the other frameworks out there.» Ця проста формула — сервер+воркери — може бути особливо привабливою для команд, які сьогодні мають ефектний агент у ноутбуку, але не розуміють, як безболісно винести його в бойове середовище.
Для українських продуктових і аутсорсингових команд, що будують AI‑фічі для реальних користувачів, головне в цьому підході — чітке формулювання вимог до «дорослої» агентної інфраструктури. Сім ознак, які перераховує Тим, — це фактично чек‑лист, без якого будь‑який AI‑агент ризикує залишитися красивою, але крихкою демкою.
Джерело
Build 3 PRODUCTION AI Agents in Python – Full Course (Agentspan)